PhilM

So now that all the hype surrounding Windows 8 has died down a little, I think it’s time to take a step back and analyze, with a cool head, at what Microsoft promises to bring to the table in their next OS release.

First of all, I want to make clear that I have no partisanship with any software vendor.  I use Microsoft’s Windows 7 for gaming at home, I use a Macbook Pro for my day-to-day computing needs, and my phone is an Android.  I am a software developer, and most of my code runs on open source, UNIX-based systems.  But most of all, I love new technology, and I definitely don’t fear change, as long as it brings improvements in the “mainstream digital life” that people are now pursuing more and more.  

That said, looking at what Microsoft has shown at BUILD and on their tech blog, it’s hard not to get a little excited about Windows 8 (and yes, also a little doubtful).  So in this series of articles I’ll be looking at each major change that truly define this new release, and speculate about whether it is good for the industry or not.

Metro: a new UI paradigm to replace the aging desktop

Of course, the most apparent change in Windows 8 is the Metro UI, whose origins date back to the Zune media player back in 2006. The basic idea is to replace the old paradigm of a “desktop” with a UI that is mostly text- and tile-based.  It’s the most visible change in Windows 8, and also the most controversial.

A lot of people seem to erroneously equate Metro with the new Start screen, which replaces the old Start menu.  The Start screen is merely one important component in the Metro environment.  But Metro’s scope is much more ambitious: it is a separate ecosystem, with its own set of applications that the user can download and use to fulfill his or her computing needs.  Metro is not a UI panel; it’s a design language.

Note that I have used the word “replace” in the heading.  This is not an accident. While Windows 8 allows a user to use both Metro and desktop apps in the same session, there is a sort of obvious-but-unspoken reality that Microsoft hopes to entirely ditch the old desktop in future versions of Windows.  This is made apparent by the fact that most of the advancements in the set of Windows APIs that are used to develop apps are exclusive to Metro apps.  Also, for versions of Windows running on an ARM processor (read: Windows 8 tablets), the desktop will most likely be completely inaccessible, since most desktop win32 applications are compiled for x86 only. Basically, if you want to support the entire Windows 8 family, you have to develop for Metro.

Is this a good change?  The existence of something like Metro is based on the simple idea that the desktop-and-windowing paradigm, which has dominated the industry for so long, no longer effectively fulfills the computing needs of people today.  With the advent of small, more portable screen sizes, as well as touch screens, it’s hard to make a case against that conclusion.  The desktop is not suitable for tablets and PDAs; it’s been tried before, and failed miserably.  When looking at the latest “mobile interface design” recommendations by usability experts like Jakob Nielsen, it’s easy to see why the desktop just doesn’t cut it anymore: bigger text, larger icons, no reliance on drag-and-dropping as well as hover effects, etc.

That, however, does not indicate that Metro is a suitable replacement.  In order to replace something, you have to be able to support the majority of the old paradigm’s use cases.  Yes, Metro is obviously more suitable than desktop for mobile scenarios.  But most of the criticism toward Metro comes from Windows 7 users that argue that for desktop use and productivity purposes, the desktop remains a better solution.

What are the advantages of the desktop and windowing systems?  Having multiple application windows side-by-side and drag-and-dropping elements between them is a classic example.  Well, Metro doesn’t do that.  But wait!  What’s the real need here?  

• To view information from multiple applications on the same screen
• To share data and files between applications

When you deconstruct use case scenarios this way, it’s easier to see how Metro solves the problems.  Metro supports splitting the screen in two in order to display two applications side-by-side.  If you need to view information from more than two application at a time, Microsoft will direct you toward Live Tiles on the Start Screen, where each application can use a small portion of the screen to display its data. And since the Start screen is fully customizable, you can decide which apps get to have space on your screen. 

As far as sharing data goes, Metro introduces a new concept (unfortunately called “Charms” right now, but let’s hope that changes).  As this concept is rather complex and very interesting on its own, I feel it deserves its own article; therefore, it will be the subject of Part 2 of this series.

Of course, this use case is but one of thousands.  This article is not meant to be an exhaustive analysis of the viability of Metro in all desktop usage scenarios, but rather an example that shows how deeply Microsoft has re-thought personal computing.  There will always be some people too afraid of change to accept something so radically different - this is why so many people cannot jump from Windows to Mac and vice versa - but this article hopefully shows that it is much too early to write Windows 8 off.  It is still at least a year away, and only weeks of daily usage will tell whether Microsoft’s gamble has truly paid off.

After realizing that tumblr is really not Twitter, I’ve decided to collect all my notes from the BUILD keynote into a single post.  Here they are, from most recent to oldest.  

”[…] and a little bit of Cloud to do the firewall traversal” may be my favourite quote from the whole keynote.

Same aggregation for other types of media like pictures.

Unified contact list aggregated using the Windows Live ID as the central point and other services like Facebook as satellite services.

Keyboard shortcuts for Start Screen.  They are making a case for using the Start Screen even for power users.

cmd.exe is still there, and it still looks as crappy as before. Disappointment!

You can run Start Screen on one monitor and Desktop on the other.  Very awesome for developing metro-style applications.

Task bar can show up on multiple monitors.  It can be in an independent mode to only show applications that are running on that particular monitor.

The Hyper-V Manager desktop app looks like an MMC snap-in!  I can’t believe they still haven’t revamped that terrible idea yet.

“Remote Desktop” is now a metro-style app.  When you connect to a remote PC, you have access to all its metro UI, not just the desktop.  You also use Remote Desktop to control your local virtual machines.

“Windows Assessment Console” desktop app for diagnostics purposes. The chrome looks like IE9, with some wasted space at the top.

Metro-style control panel.  Let’s hope they FINALLY get this one right.

“Refresh your PC” functionality.  This is an answer to those who keep reformatting.  It resets all Windows settings but keeps user files and downloaded apps.

“Windows 8 as a workstation” demo.  This is Windows using a mouse and keyboard.  Demo of the new task manager (desktop app).  Split into a simple and an advanced UI.

As expected, they’ll be handing out 5000 Windows 8 tablets to attendees for preview.  You can also use it to develop apps on it with Visual Studio!  Their original vision of “real desktop PC on a tablet” is coming to fruition.

Head tracking with standard webcam!  Very impressive.  They seem to be in a hurry to wrap things up.  Too bad, they are just glossing over details that need more explanation.

The side-by-side metro apps feature is only available for displays that are 1366px wide or larger.

Oh no!  Notepad is back, and still unchanged (as of yet…)!

Hardware-accelerated graphics is available for any app (even HTML/Javascript apps).

Windows 8 is demo’ed on desktop PCs, laptops, and multiple tablets.  They stress the fact that the same apps run on all these platforms, regardless of x86 or ARM chips at the core.  Boot time is incredible on all of these.  The multitasking and task-switching performance is smooth even on the most basic tablet.

“Connected-standy” power state.  Instant-on scenario like Sleep, and very little power draw.  It’s actually not clear what’s the difference between that and actual sleep.

The new WinRT API is very similar to .NET.  They cite “mostly namespace changes” as being part of the porting process.  So it will be very easy to port existing Silverlight, XAML-based UI applications into a new Metro-style app.

Windows Store will support desktop “Win32” applications like Quicken.  Do they have trials as well?  That is not clear.

The App Store has built-in support for time-based trials for paid apps.  That’s a very interesting feature; I wonder how long it’ll take for people to hack the trial?

There is a certification process for the Store, similar to Apple’s App Store.  The certification process for Xbox 360 is notoriously lengthy and annoying; they say they want to make this one as transparent and seamless as possible, but I’m skeptic.

First hints of “Windows Store” for Windows 8.  There is some integration in Visual Studio.

The HTML apps use the “CSS Grids” proposed standard for UI layout.

The new version of Expression Blend can generate UI code for XAML and HTML5/Javascript.  That’s very neat.

The HTML/Javascript API seems to work, but it still feels too foreign to me, like they’re trying to fit a square peg into a round hole.  I don’t like the idea that there’s another layer of javascript interpreter between WinRT and app code.

I find it ironic that Metro apps are developed using Visual Studio, which even the latest version is still an “old-style” desktop app.  Is this a sign that the Metro UI is simply not tailored for productivity applications? 

The two main development APIs for desktop, Win32 and .NET, are finally replaced by “WinRT” for Metro apps.  This is huge!  It’s not a layer on top of win32; WinRT is directly plugged into kernel services and is the only layer standard between your code and the kernel.

Unified API for Metro UI apps regardless of the language.  This is NOT applicable to desktop apps; so old desktop applications will start to look really disconnected really soon.

The fabled Windows 8 tablet is finally shown!  Couldn’t see a make yet, but it is indeed running on an ARM processor.

This was hinted at in the first Building Windows 8 video that came out: there is an API for any application to expose files to the Metro UI filepicker (e.g. when choosing to upload a picture).

There is a Search API for applications to expose their data to the Windows Search feature. This is similar to what’s happening on the mobile space.

Spellchecking is built-in for any application.

Unified API for sharing data from an application with people; there is a “share” button on the Windows bar, in the same place as the Settings button. 

Little jib about IE10 being “Chrome-free” :-)  But really, it’s nice to see full-screen browsing being the default.

Every app has a “docking view” and a “side view”, for displaying two apps at once on the same screen.

Unified way for all Metro UI apps to expose app settings; the space is shared with the system settings.  So all settings for the OS are found in the same place.

The start screen’s tiles are fully customizable by drag-and-drop; it’s still a little buggy for this presentation. 

Picture password feature - click on various spots of a picture to log in.  Interesting…

Greatly reduced memory usage versus Windows 7 - the system requirements may actually be lower than 7!

The BUILD keynote is almost upon us.  Here are a few hopes and expectations regarding the announcements to come.

Expectations:

• Windows 8 can be configured for “tablet use”.  In this mode, the desktop is unreachable; only Metro UI is accessible.  Of course, power, input, audio and display settings are all optimized for a tablet.
• Bing will be the backend for all Windows searches.
• A Microsoft-curated App Store will be available for Metro UI apps. 
• Many technologies will be available to develop Metro UI apps.  In addition to the already-announced HTML5/Javascript, you’ll be able to write apps in Silverlight C#, and even managed C++ using the Windows API.
• It will be easy to develop a single app that can run on both Windows Phone and Windows 8 Metro, similar to iOS apps.
• Huge focus on cloud-based development: free cloud service for consumers (with upgradable paid accounts for additional storage/features), unified API for applications to store their data in the cloud.

Hopes:

• There will be no way for third-party applications to register themselves as part of the Metro UI boot sequence.  Only when the desktop is first launched will the OS boot all apps listed in the Startup sequence in the old msconfig, and that is strictly for backward compatibility.
• There will be an option to boot directly into the desktop instead of Metro UI.
• There will be a unified app update API that works both for Metro UI apps and regular desktop apps. No more need to start custom “update checker” executables when Windows starts!
• Most Windows Phone apps will work as a Metro UI app.  
• Support for Lightpeak/Thunderbolt port in addition to USB 3.0.
• Total archival and revamp of the MSDN documentation.  They need to start fresh and make it easy for app developers to find the correct articles describing how to write modern Windows apps.  In fact, they should just start a new “Developing for Windows” documentation site, and use MSDN for archival only.
• Tight human interface guidelines for new Metro UI and desktop apps.
• Full POSIX compliance built-in.  This sounds farfetched but not from a technical standpoint: they already have an optional module for previous versions of Windows that brings POSIX-compliance. If they don’t do this, it is purely for political reasons.
• Better Powershell windowed application, bringing all the modern features of a typical windowed shell (see iTerm for a good reference); retire the old command line utility.
• Most importantly: Windows 8 will bring back the “fun” of computing, where every components and apps just work together seamlessly.

The BUILD conference, Microsoft’s equivalent to Apple’s WWDC or Google’s I/O event, starts in just a few hours.  This year is especially important; they will finally reveal Windows 8 as seen from a developer’s point of view.  There will be details on how it is implemented, and what technologies will be available to develop applications in Windows 8.  

Of course, there will be plenty of information for non-techies as well; with Windows 8, Microsoft is finally pushing for an OS that can transcend the traditional desktop: you will see variants of Windows 8 on laptops, tablets, desktop PCs, etc. I’m personally very excited about the new Metro UI they are pushing; this is definitely the way consumer OSes should be presented. 

I am no Microsoft shill.  I am typing this on a Macbook Pro (NOT running Windows!), which is the computer I use for work on a daily basis.  I think Mac OS X is a more robust consumer OS than Windows, and is more poweruser-friendly to boot.  But that is exactly why I am so interested in this upcoming conference; I truly believe that if Microsoft does this right, there is a chance for Windows to finally supplant its competitors as the OS that gives a really compelling computing experience for “non-techie” people, while still satisfying the power users and those that are used to the old Windows way.

I’ll be watching the keynote live and posting important or otherwise interesting facts in this space over the course of the event as it unfolds. I hope you enjoy the conference as much as I will!

Whenever you enter someone else’s private home, it is generally accepted that you must adopt that person’s customs.  If the person tells you to take off your shoes, you should do so.  You don’t throw your coat on the sofa unless the person explicitly tells you that it is okay. If the person is having you for dinner, you let the person choose what you will be eating, since he or she will be the one to cook it.

Compare this with going into a restaurant.  When you enter a restaurant, you are the boss.  You tell them what you want to eat.  The owner (and his or her employees) are here to serve you.  They are providing a service for you. 

Developing software on someone else’s development framework should be similar to the latter.  The framework writer released his library for your use; they are providing a service to you, much like the restaurant owner.  Unfortunately, most framework developers seem to adhere to the former.  They have designed a system to accomplish a very specific task (such as creating a website), and they generally have a very specific idea as to how to accomplish that task.  More often than not, the framework only lets you structure your system in the same way that the framework author believes is “the best way”.

There are definite disadvantages to this “my way or the highway” approach.  By hindering the ability of your client developers to come up with new ways to solve a specific problem, you are effectively stating that you know better than everyone else, which is of course never true.  In fact, if your way of doing things is misguided, you’ll be doing a disservice to those who are learning development on your framework.  Junior programmers do not have the experience or instinct to distinguish bad design, and they will adopt your way without question.  It is also impossible for you to predict all of your client developers’ needs.  If you provide a rigid framework, you will often end up with requests from your users that the framework is impossible to satisfy.  You are then faced with two options: either restructure part of your framework to satisfy the needs that you had not anticipated, or simply tell them that the framework “wasn’t meant to solve that problem”.  

Of course, relinquishing control and offering more freedom of choice tends to increase learning curve of your system, as well as introducing a higher risk of client-side bugs.  The general solution to this conundrum is usually known as “convention over configuration”.  Basically, this philosophy favours coding by convention instead of having to configure every single aspect of the system.  This is fine and good, but most framework developers seem to interpret convention over configuration to remove choices and replace them with the most commonly-used options.  That’s the Apple way!  This is no good; we are back to square one.  

Convention over configuration can only make sense when it is interpreted as “offering options to cover as many needs as is sensible to do, but offer meaningful defaults for every option so that developers don’t have to make a choice right away”.  The best way to accomplish that is by developing a framework which has a modular design. Each “task” that your framework must facilitate should correspond to a separate module in your code.  Each module is programmed in such a way as to execute the task in the most intuitive way (this is the meaningful default).  But at the same time, provide a way for the client developer to override this module with his own custom code.  That way, if he is stuck in a particular situation where the default functionality is not applicable, he always has the choice to “roll his own”.  

Allow me to illustrate this with an example.  Let’s take an object-oriented web development framework.  Such a framework would need to facilitate many tasks; handling requests, cookie management, session management, data storage, etc.  Let’s take session management as an example.  Don’t juste write a session management class and dump it on your users.  If you have other parts of your framework that use this class, your client developers are stuck using it!  Instead, create an interface which describes the basic operations relating to session management (e.g. “ISession”).  Then create a basic class which implements this interface in the most intuitive way (e.g. “BasicFileBasedSession implements ISession”).  Finally, have a factory method (e.g. getSessionProvider()) which returns an instance of the class which is registered as the current implementor of ISession.  That way, if the client developer is creating a website which spans multiple servers, BasicFileBasedSession is not sufficient for his needs, but no matter; he can create his own ISession implementation called DatabaseSession and register that as the default implementor of ISession.  That way, even the other parts of your framework that use session management will be using his class.

All in all, it’s good to have a solid direction when designing a framework; but always let your client developers diverge from that direction whenever it makes sense.