Developing Business Applications For Windows 8
The arrival of Windows 8 and Windows Server 2012 will bring its tablet inspired user interface to the mainstream. While many application types will readily benefit from the new design, developers of traditional business applications may wonder how their applications will fare. What might not be as readily apparent is that Metro represents a shift in mental design philosophy as much as a new graphical theme.
This is an important distinction because it shows how Metro can be relevant to all users, not just those with tablets or touchscreen based devices. To explore some of the design decisions being made when embracing Metro, Microsoft's Robert Green introduces Nadine Fox of Macadamian. Together they profile an application they developed for Metro which is representative of a traditional line of business application, a business expense management system.
One of the themes Green repeatedly mentions is "content over chrome". The results of this convention are apparent in the look of the application. While the application is running under Windows 8 and driven by a mouse, the traditional menu bar and the newer ribbon are both gone. Instead, the primary content-- expense report items-- are the focus. The only tie to the traditional application is the "App Bar" which appears based on context when certain application items are selected. Otherwise it hides off screen, to minimize user distraction.
To further emphasize the content over chrome mantra, even the traditional message boxes are discouraged. Instead notifications from the application are placed inline with the fields that require the information:
Green also demonstrated some of the other Windows 8 specific features his sample application could take advantage of, including the sharing facility. This provided access to sharing via email, Twitter, or sending to quick note.
In watching the presentation, one is left with the impression that there indeed a viable path forward for business applications under the Windows 8 style UI, but they will require a new approach in their presentation and design. The challenge facing developers will be in obtaining the necessary time and artistic design resources to take advantage of the new look.
This won't work
Actually, UX design deals with full requirements specification, process specification and even information architecture, so, in 4+1 terms, your application is 3/5 specified, deployment and implementation is left - all that remains for you is the code monkey job.
Basically your job is to type in the UML diagrams into visual studio / C# like in the old days, except this time, you actually have to deduce the UML from the screenshots (internally, a lot of UX firms use UML-like notations, it's just they don't give it to you.)
If your company has to hire a UX firm in order to design a business application, an internal tool, you're f.ed.
Besides the considerable deficiencies of the Metro UI (you can't really differentiate between a button, a text entry box and an info box, simply because all of them are colored rectangles with big letters) you're lost if you need to hire a consultancy firm to write a 10-liner form based application build for native windows and for internal employees.
And the text, "Form is not saved" just adds a bit of irony: it seems the UX guys themselves came from the stone age of Windows 3.1 or what... Anyone with 10 minutes of Google Docs or any iOS text editor knows that saving can be avoided, and it is done so on most mobile interfaces today.
No, this won't work. If you need the same design effort to design something for desktop as you have for web, you could easily do it right to web instead.
And perhaps all devs should learn psychology and UX really quick.
This bears repeating
And by doing it right to web (emphasis on "right"), you've got support for mobile devices as well as conventional browsers already, without the need for a new operating system. Is Metro a solution in search of a problem?
In the presentation, the developer comments at one point, "Shockingly, there are probably bugs in this app." So, there are more fundamental issues with development methods than just a fancy "new" UI. Why not address those before worrying about the niceties?
Re: This bears repeating
"Shockingly, there are probably bugs in this app." So, there are more fundamental issues with development methods than just a fancy "new" UI. Why not address those before worrying about the niceties?
A bug is a result of a misunderstanding: it's a misunderstanding of how a certain component works, or how certain components are to interact., or what kind of approach is to be used to a certain problem.
Now, you can't really avoid misunderstandings, if you have two teams working on a single product, one of them not understanding technology, the other one not understanding user interface design.
The only solution to this would be that someone does both: either a technical lead, or developers understand UI design on a level that they are able to point out the misunderstandings, or UXes understand development on a level so that they're able to bring inputs to the devs which they won't misunderstand.
But UI is not a nicety: it's your system to the outside world. A system is created to be used. Wether it's used by humans or other machines is a different matter, at the end of the day, it's always used by humans anyway: even an SQL database is used by office clerks at the end of the day. So, there's always a human user, as computers are deployed to solve problems for humans, not for themselves.
Therefore, you can change any part of the system, as long as the UI doesn't change, users won't notice. These could be small changes, like a refactor, or large-scale changes, like full platform change from Windows to Linux, from C# to Java, from HTML to native widgets, as long as it looks exactly the same, has the exact same data, the same speed and the same bugs, for everyone actually using the system, it didn't change at all.
The user interface is where, at the end of the day, your system stands or falls: it is where it's decided wether your system helped to bring humanity forward, wether it has added the sum happiness of humanity or did it detract from it.
Worse, since the UI is the system for your users, it will be the language they'll speak to you: all the requirements, all the change requirements will come in in terms of UI:how they expect the system to appear to work to the outside world. The users will never give you ERDs or flowcharts they will speak the language of the UI, that's what their mental model will be based on.
And since the system can only be specified in the language of the UI, it'll be specified by the guys who actually do speak that language: the UX guys. In most enterprises, it's already the UX department who does the specs.
Of course, data structures and basic process flows can be deduced from that language. Worse: the UX guys do deduce it, it's just that they don't give it to you: you'll get a bunch of screenshots only. Internally, most UX firms deduce data structures and algorhithms, they'll represent it in non-standard ways, they'll build the screen mockups based on those diagrams, and then they'll throw it out and give you only the screenshots, so you'll have to start from scratch again. And since they have no engineering or mathematical background, those flows will contain certain errors.
So, all in all, a design firm today doesn't do interface design only: they do a full system design, they specify every part of the system which is visible to the outside world, and will leave the implementation to the devs.
Now enter Metro.
Metro is a design language. It's like C++, the only difference is that while it's straightforward for C++ to know how it translates to C, and for C how does it translate to assembly, which can be translated to running code, Metro wasn't built that way. Metro was designed by people with no knowledge or understanding of how software works internally, and they were deliberately separated from the technical guys. It just levitates in the air.
How it should be translated to code in a consistent manner... this exercise is left to the developer, and it's not guaranteed that it's possible.
Metro was designed so that Microsoft can have a distinct interface: so that as a latecomer to the smartphone revolution, they can't be called a clone-company. In order to be not a clone, it shouldn't look or behave similarly to an iPhone or to an Android device. It should be fundamentally different.
And here comes its weakness as a design language: they had to throw out well-known best practices. We know for example, that a button has to "bump out" from a plane so that people expect it to be pressable. This was shown both with physical devices (eg. totally flat remote controls) and virtual interfaces (eg. the Athena widget library). When something doesn't bump out, there's always a moment of mental confusion. It doesn't have to recede on press, as long as it has good feedback (something actually happens immediately), but it has to bump out.
Sometimes, there's only one best way to do something, and anything else you do it will be inferior. It doesn't matter that you had a business reason to be different, your interface will be inferior.
But the problem here, again, it's not that: the problem is that Metro wasn't designed with the developer in mind. If it takes a design firm to do a simple internal app, that means that all companies employing the new MS technologies will have to employ UX departments on a permanent basis.
And it means that devs won't get to design even a hello world. They're there just to code, like in the old days of tower architects.
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014