The Case for Metro Style Line of Business (LOB) Apps

Ambrose Little / Tuesday, May 15, 2012

Since Microsoft debuted the new Windows 8 "Metro" OS interface, there has been no end of people in the Microsoft dev space opining on both the interface and its applicability or lack of applicability. Not long after BUILD last year, one blogger announced that there are "only five Metro style apps in the world," definitely not including LOB. (I'm not linking so as not to embarrass that person..) I've also often heard a similar sentiment in private discussion lists that I participate on. Clearly, the sentiment goes, Metro is only for consumer apps. No real line of business work could be done using that interface.

I mean, as we all know, LOB apps have to have busy, intimidating, and overly complex, fiddly UIs, right? LOB implies an unfortunate huddled mass of pitiable information workers who don't deserve usable interfaces. The Man can keep them down--because they're paid to use these apps, after all. "You need a new feature? Okay, here's another menu item." "What, you think this is hard to use? Just read the manual!" And my personal favorite when justifying atrocious LOB app design: "We can just train them."

Okay, so granted, there are some valid concerns when considering a data-entry-intensive app on a touch-first interface. But for the most part, it seems that whether cognizant of it or not, these devs have some of the above assumptions in their minds. In addition, they are thinking of their existing, typically developer/BA-structured apps and trying to do a direct port, as if the Metro stack is just a new UI technology calling for yet one more port of outdated, circa early 90s app design. After all, it's all about the technology, right?

Or maybe they just personally don't like the Metro design language. I've certainly heard a lot of grumbling about that, and you can see it on comments on the Windows 8 blog. It is an extension of the self-referential design that has powered the vast majority of business app design since it became technologically feasible for such apps to proliferate. But good design is not about you/what you like--it's about the people who are going to use it and the businesses that they work for. And it's crucial to keep in mind that you are not they.

It seems that one of the key messages that Microsoft is trying to get across is being lost on these folks--that we need to "re-imagine" these apps. In fact, as I see it, Microsoft is using this new technology to force the point home. You simply cannot continue the same design approach on the new technology stack. They are in essence trying to wake up the huge swaths of Microsoft developers to what real Design is all about. It's not about technology. It's not about features. It's not about back end systems or services. It is about the user experience; it is all about the user experience. And great user experience very rarely (with some specific exceptions) is about loading an interface with tons of capabilities that requires the use of a special, high-precision pointing device (the mouse) in order to use it effectively. Certainly the vast majority of LOB apps do not call for this kind of design.

There is a lot of evidence that focusing on good design in LOB provides important ROI. Don't take my word for it--Bing or Google it. Great LOB app design increases employee job satisfaction; it increases effective team collaboration; it reduces error rates, and increases productivity. This means higher retention rates through happier employees and streamlined business operations. It is, in short, a win-win.

Since the announcement, slowly we've been seeing evidence to confirm that Microsoft does indeed intend for those building on this new technology stack to target LOB (and that others in the space are getting it). Here's a brief sampling of that:

This sampling delves into different aspects that indicate the intent. Some of them are OS features, like portability, security, reliability, and so forth--Microsoft is continuing to focus on these aspects for the Windows 8 OS. Some of the articles are more telling, though, in relation specifically to Metro-style apps (i.e., apps that run on the WinRT stack and have all the Design requirements we're talking about that supposedly aren't suitable for LOB).

Some prime examples of the latter are the Dynamics examples and the new Office 15 examples. But even in the current preview, you can see some central LOB apps--what is more LOB than email and calendar? What is more LOB than Office and CRM?

You can see the direction in that ARM is not supporting desktop apps. How many execs and business stakeholders want to be juggling multiple devices that almost do the same thing, switching back and forth between their lightweight, long-battery-life tablets and a heavier, clunkier laptop just to take care of business? The impetus is toward these lightweight devices that are touch first. There's a whole focus in IT these days on BYOD--bring your own device--because of this.

The Challenge

And that brings me back to the point. Instead of making snap judgments that this or that LOB app is not for Metro, how about seeing it as a challenge? The tech world has been and is changing, moving ever so surely towards more ubiquitous computing, more devices that can access the same information and augment and enhance human endeavors no matter where we are. Technology limitations managed to chain line of business workers to desks and then portable "laptop" desks for years, but we are shifting away from that. The more concrete bottom line: the days of assuming bigger and bigger screens with a keyboard and mouse-like pointing device are dwindling; the time for multiple screens and multiple modes of interaction is here.

Now is a great time for Microsoft devs. Microsoft is carrying forward a lot of the familiar development tooling and experience. You can still use XAML. You can use the ever-present HTML-driven stack. You can even bring forward C++ skills. But as part of the deal, you need to start re-imagining the way you think about application design. They're giving you lots of the design framework and guidance--MSDN has some great design guidance.

Now is not the time to be prejudging the Metro way of things based on your own preferences. It is indeed a strong design language, but that also carries benefits in helping you to design more usable apps that play well in the new world of technology (and to break away from a lot of bad design habits). And you don't have to rely on just Microsoft, either. You can look outside of what they offer. Luke Wroblewski has been promoting "mobile first" design for quite some time. Much of mobile first is applicable to Metro app design, including the core starting point of re-imagining and re-focusing on people--what they need, when they need it, instead of everything they could need at any time they might need it. Beyond mobile first, simply applying human-centered design in general will help you a lot in Metro app design.

Metro isn't just about whether or not someone wants to walk around with your app or not. It's not just about literal mobility. It is about focusing on great design to facilitate great user experiences, even in line of business. If after re-imagining your app, you find that Metro style still doesn't work for you, so be it. You still have (for now) the option to use the Desktop side of Windows 8 (on non-ARM devices). But please, at least try. This isn't about porting your app as-is to the latest technology; this is about using this as an opportunity to create a better app for real people, that truly suits the way they can work best.

For what it's worth, I have done some thinking about adapting LOB apps for Metro style. Here are a few questions to ask yourself that might help (in addition to the user-centered mobile first principles):

How can I craft new pickers to minimize reliance on the keyboard? (This is I think an area ripe for innovation in a touch-first platform.)
How can I chunk up my current app into smaller, more task-focused apps?
How can I leverage live tiles to create a dashboard for these small apps?
How can I design a snapped layouts to coordinate meaningful leveraging of two apps at once?
How can contracts help easily and effectively share information across these LOB apps?
How can I learn more about human-centered design? Should I perhaps hire/advocate for full-time UX staff? (Devs can do a lot to improve UX if they apply themselves to it, but getting "professional help" can certainly take things to the next level.)

As I said, the MSDN site offers much more design guidance for Metro as well; these are just some initial considerations that might help. But the first step is to break out of your preconceived notions about LOB apps! You can do it! :)

Want to discuss? Feel free to comment here, or you can reach me @ambroselittle, G+, or LinkedIn.