Windows 8 for the Keyboard User

What we’ve seen so far of Windows 8 is that it’s all about touch.  We’re looking at really early bits and they were effectively delivered on a tablet; so, that’s to be expected.  But, for many people they’re going to be using Windows 8 Developer Preview on hardware that doesn’t have touch.  So, how do we navigate around Metro apps and the Metro UX when we don’t have touch?

Fortunately, the Windows team didn’t forget about keyboards and mice and recognized there are still scenarios that involve keyboard and mouse even when using at tablet.

My contention is that touch devices are best for consuming information, and worst for entering or producing information.  Windows 8 is powerful enough to not only run Metro apps but (depending on the tablet hardware you buy) also Desktop apps.  The major scenario is plugging your tablet into a docking station and connecting to a keyboard and mouse and using your tablet as a desktop PC and making use of your Desktop apps like Word and Excel.

So, over-and-above using existing Desktop apps in Windows 8, how can we use keyboard/mouse with the Metro UX?  Fortunately there’s been a few good blogs/articles about new Windows 8 shortcuts.  I’ll detail them here:

Win + O: Locks device orientation

Win + V: cycles forward through notification toasts

Win + Shift + V: cycles backward through notification toasts

Win + F: Opens File Search App

Win + C: Opens charms bar (same as swipe from right of screen gesture)

Win + I: Opens Settings charm (same as swipe from right gesture & tapping Settings)

Win + K: Opens Connect charm (same as swipe from right gesture & tapping Connect)

Win + Z: Opens App Bar (same as swipe from the bottom of the screen gesture)

Win: Opens the App Bar (same as Win + Z or swipe from the bottom of the screen gesture)


Other goodies

If you don’t have a Window key

If you’re on the Start screen, simply start typing and you’ll be sent to the Search Apps charm.  You don’t need to

see also:

Windows 8, What Does It Mean to Me?

Well, unless you’ve been hiding under a rock, you’ve probably heard about Microsoft Build conference that happened in Anaheim last week.  It was during this conference that Microsoft finally released details about the successor to Windows 7.  This event is solely developer-focused and, in my opinion, tablet-specific.  It went into a lot of detail about the added APIs and usability changes in Windows 8 to better support tablet and touch-based computers.

First off, the new touch-first usability changes are called “Metro” and applications written for touch are called “Metro-style apps”.

The term “touch-first” is used because it’s not touch-only.  Metro will work fine with a mouse and a keyboard; but the user experience is obviously designed for a multi-touch device and that you can “get by” adequately with a mouse and a keyboard.  This was done for various reasons, one being that touch isn’t good for entering reams of text and that you want to dock your tablet and use a keyboard and mouse when you want to do something that would be better served by a keyboard or a mouse.  e.g. tablet/touch-based UX is better for consuming information, whereas keyboard is better for producing information.

So, with all the focus was on tablet and touch, does that mean Windows 8 is all about Metro?  The focus of the conference was to show off (likely in answer to other vendors producing tablet-based hardware and systems) tablet- and touch-based user experiences.  In fact, paying attendees received a custom-made Samsung tablet computer with a version of Windows 8 (called Developer Preview) and the next version of Visual Studio (called Dev11, for now) pre-installed.  This puts the focus of Developer Preview almost solely on touch.  But, does this mean that mouse/keyboard was ignored or that we need a touch screen on our computers to be able to use Windows 8 when it is released?  No, of course not.  Discussing various things with numerous Softies, the message time and time again was that if something isn’t mentioned, or doesn’t have focus, that doesn’t mean it won’t exist in the release version or in the near future.  It was clear that this version of Windows 8 was produced strictly for this event, and since it was effectively deployed on tablet, it had a tablet edition of the OS.  I.e. if you by a desktop without a multi-touch monitor after Windows 8 comes out, the edition of Windows 8 that will be deployed will not likely have Metro on by default.  But, that’s my opinion.

We now have Metro apps, and they’re XAML-based and very similar to Silverlight.  You initialize the runtime slightly differently and do some other things slightly differently; but if you’re a Silverlight developer you’ll be right at home in Metro.  Does that mean all Windows 8 development is Metro?  Definitely not.  It’s not C++ based and it is still managed code backed by the CLR (they shows using VB and C#; but F# support should be there for RTM).  The CLR backing Metro apps is the same CLR that backs “Desktop” apps written as WinForms (yes, they’re still supporting that) traditional Silverlight, Console apps, Windows services apps, etc. etc. etc.

Does this mean Silverlight and .NET is dead?  Well, no; but you could interpret it that way.  Metro apps are driven by a new Windows API called WinRT—which is basically a object-oriented alternative for the Win32 API and removes blocking methods leaving, or replacing them with, asynchronous methods.  This and the CLR that backs it are inherent parts of Windows 8.  So, it’s technically not it’s own product and simply just another part of Windows.  So, you could say that .NET and Silverlight are just bits of Windows 8 and thus no longer exist as “.NET” and “Silverlight”.  Just like Hydra or Terminal Services really doesn’t exist any more because it’s baked right into Windows.  But, that doesn’t mean they don’t exist in this new form.

Some discussion has occurred as to whether WinRT is truly CLI-compliant because it doesn’t support all the types and methods that .NET does now.  This isn’t true.  We had these same discussions when Silverlight and Windows Phone came out.  WinRT is just another “profile”.  It has a subset .NET API.  Just like how Silverlight doesn’t include classes like System.Windows.Forms.Form and Windows Phone doesn’t include classes like System.Windows.Browser.HtmlDocument.  The depth of the .NET classes that are available to WinRT developers is restricted, just restricted differently than Silverlight and Windows Phone.

Just how restricted is the WinRT profile?  Well, that remains to be seen at this point; but, from the looks of it it is minimally CLI compliant.  This means it doesn’t include things like the reflection namespaces.  WinRT is, after all, for producing touch-based applications that may run on very minimal processors and hardware.

One thing of note, to finish, is that the theme of WinRT is asynchronous.  Anything that could take a noticeable amount of time (“blocking”) is not available in the WinRT profile; so, get used to asynchronous programming.

Enterprise Service Buses, Brokers, Message Queues, Oh My!

Continuing on my theme of message-oriented, I thought I’d get into a bit of detail about the various middleware options and some details about these options.

Regardless of what type of middleware is chosen, one thing is common to all types of message-oriented middleware—the fact that they broker messages from producers to consumers.


Before I get too far into the options, let’s look at a couple of the common reasons behind moving to a message-oriented architecture.

One impetus towards MOM is to integrate various legacy or third-party systems into a new or exiting enterprise system.  This type of MOM has been know as Enterprise Application Integration (or EAI).  There’s all sorts of information about this architectural style.

The other major impetus towards MOM is to facilitate distribution.

Technically EAI is also distributed; but that’s more because the individual components are completely independent of one another and thus executing on different computers.  The purpose of EAI isn’t to get distribution but to integrate distributed components.

Enterprise Application Integration

Enterprise Service Bus

The technology-du-jour in the MOM world seems to be Enterprise Service Buses (ESB). Enterprise Service Buses, by definition are are horizontally scalable MOM that integrate disparate (including legacy) loosely coupled SOA components using web services. Not only do ESBs technically broker communication between producers and consumers, they also deal with routing, transformation and translation. It’s hard for ESBs to do what they’re good at without that specific loose coupling you get from web services, where interface definition is discoverable and service-oriented (web services, over http, etc. etc.).

From a .NET standpoint there’s a few options out there calling themselves ESBs like NServiceBus and MassTransit.


One form of EAI is a Broker.  “Broker” is considered an anti-pattern by more than a few people in the industry given what we now know because of it’s inherent hub-and-spoke shape.  A broker is a single component (hub) that brokers messages from producers to consumers (spokes).  It’s frowned upon because of its inherent scalability problems.  A single broker is constricted to a single computer and to gain scalability it’s forced to scale vertically so it has finite and expensive scalability options.  It’s unfortunate that this architecture is frowned upon because it’s still more than adequate when used where appropriate and technically a subset of all the other MOM options.

There isn’t technically a whole lot of options in NET for hub-and-spoke integration.  .NET became popular just as the many of the problems with hub-and-spoke were coming to light.  But, the closest thing to hub-and-spoke seems to be BizTalk.  It’s message box would technically be the hub and components integrated into BizTalk be spokes.  But BizTalk is a bit of hybrid of sorts (it supports translation, SOA, etc) so it’s a bit of a matter of opinion.


Message Queues

Almost all EAI middleware uses some form of queue BizTalk: MSMQ, MassTransit: MSMQ, RabbitMQ, ActiveMQ, etc, NServiceBus MSMQ, Azure Queue, etc.


Technically the other options are considered message queues; but they’re not message queues in and of themselves; they just operate like a message queue.  Like databases, RPC, web services, etc.

When to use which option

So now that I’ve confused the horizon with a bunch more terminology and a fair share of technobabble, why would you choose one over another?

The reason I divided the options in to two is because the choice on which to use should really be based on the impetus behind the composition of the system.

If you need to integrate legacy or disparate 3rd party services together, enterprise service buses are definitely the way to go.  If you’re dealing with integrating many components together with much routing and translation requirements, and a high number of messages, ESBs will help you immensely.  If your scalability requirements are very low, going the broker route is probably more than adequate.  The impetus here is the integration; but you don’t want to make a system completely unusable because it can’t scale.

But, if you have control over all the components in your system and your overall impetus is the distribution of work and horizontal scalability, then your focus is on performance not integration.  You want your endpoints to communicate in the most efficient manner and not be bogged down by unnecessary translations and routing. In which case you most likely want to avoid ESBs.

ESBs are kind of a Golden Hammer at the moment. ESB implies a SOA, web services, certain discoverability, lack of control of some or all components, etc.  If you *do* have control over all the components and don’t specifically require SOA, Web Services, and discoverability; implementing specifically to work with an ESB seems overkill.  If your have control over all components in your system and every message coming from a producer can be directly accepted by the consumer, you don’t need any of the translation aspects of ESBs.  You end up really only gaining in the routing aspect of ESB—which if you control all the components in your system, should be fairly static.