Extending the Metro design language beyond the current "App" model? RRS feed

  • General discussion

  • I have a deep appreciation for the ideas behind the Metro Design Language. I think it shows great promise for moving beyond the current limitations of the iconographic systems prevalent today. The use of typography and clean layout to provide information at a glance without the unnecessary clutter of modern OSes fits the way my mind works. However, I don't see how Microsoft intends to extend Metro beyond the current full screen single-tasking Metro App model demonstrated in the developer preview.

    The nature of my work, I'm a network engineer by day, requires me to run and monitor a number of applications, both web and local, simultaneously. I usually have multiple browsers open with multiple windows with multiple tabs, a number of SSH sessions, a suite of productivity tools, excel, word, etc., all open and visible. My biggest problem is screen real-estate. I monitor the network and log flows with my peripheral vision while I work in the productivity suite, switching focus as tasks require, but leaving as much visible as possible.

    How will the Metro design language be expanded to accommodate my kind of work flow? How will it translate to true multitasking, not task-switching, use with 10, 12, or more application spaces visible simultaneously across multiple displays? Will the WinRT APIs be extended or will my usage pattern be relegated to second class citizenship?

    I've been around this business long enough to see multiple windowing systems come and go. I've seen everything from Ivan Sutherland's Mother of All Demos - on tape not in person, I'm not _that_ old, through Sun's NeWS, through every version of DOS multitasker, every version of Windows, and the current crop of attempts to move Linux beyond X Window. I think that Metro is the most promising approach I've seen in years, but I fear it may be still-born if it is limited to the current Metro App model.

    When will we see demonstrations of metro being applied beyond the current app model and what are the implications for usability and user interface design in a larger Metro based UI environment?



    Wednesday, October 12, 2011 5:01 AM

All replies

  • Hi D,

    Metro Style applications are only one style of applications available to the desktop windows application developers and users.  You would stay with desktop applications for the situations you are talking about.  Your usage pattern is not that of a 'second class citizen' as you alluded to!  As mentioned in the talks, certain types of applications lend themselves to the Metro style and some will remain desktop applications.


    Jeff Sanders (MSFT)
    Wednesday, October 12, 2011 12:07 PM
  • Hi Jeff,

    Thanks for the quick reply.

    I'm glad to hear that the desktop model is not being considered "legacy". I know it is extremely early days, but can you provide any insight into how the Metro design language will translate to desktop application design? Can you share any thoughts regarding changes to the "desktop" metaphor itself?

    I had the impression from the Build conference videos that WinRT would eventually be extended to encompass all the features of the current desktop API sets. It appeared to me that Metro, the design language not the App models, would be extended to span both Apps and Desktop Applications. In fact, I took the dual mode of IE 10 as an indication of this as we have two GUIs for the same engine.

    Any insight will be greatly appreciated. Keep up the great work.


    Wednesday, October 12, 2011 11:11 PM
  • Hi D,

    I did not get the impression that the Metro style would translate at all into the desktop apps (and I am not aware of any announcement of that sort).  Can you point to a specific build session (they are available online).  Also the sessions I saw on WinRt were pretty specific that they are only a subset of the Win32 API and would not encompass all the features of the desktop model.  Everything I have seen has said there would be two distinct models.  In fact in the one keynote, it was even explicitly mentioned that certain types of applications just to not fit the Metro style (photoshop was used as an example).  Can you point to something that contradicts this?


    Jeff Sanders (MSFT)
    Thursday, October 13, 2011 2:40 PM
  • Jeff,

    "...certain types of applications just to not fit the Metro style..."

    Can you help me understand what exactly "Metro style" is? After watching over a dozen hours of build presentation videos, reading dozens of blog posts, and reading through much of the "Metro style app development" content on MSDN, I can't even begin to formulate a description of "Metro style". The talking points for the conference were phrases like "immersive" and "fast and fluid", which presenters were clearly told to repeat like a mantra. But those are marketing terms; they don't actually help me understand what distinction Microsoft draws between Metro and non-Metro applications.

    Frankly, my impression is the same as that of the OP: the only reason Microsoft is conceding that not all applications are appropriate for Metro is because WinRT is still an immature technology that is missing many important features of modern productivity applications (like windows for example). But it seemed pretty clear to me that the ultimate goal was to transition all application development for Windows to WinRT and leave Win32 behind, while trying not to piss off too many people in the process. No, I can't give you a specific quote to that effect, because every time a presenter was asked directly, he fell back on the party line. But taking the entire conference as a whole, the impression of "Win32 is the past, WinRT is the future" was pretty clear.

    To be clear, I would not be opposed to that approach, IF the ludicrous restrictions that are currently in place for Metro (full-screen, auto-suspend with no background processing capability, no context menu, can only be obtained through the app store, and of course no close button) are eventually lifted. I just wish Microsoft would stop giving out such mixed signals.

    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Thursday, October 13, 2011 6:08 PM
  • Wow David!

    Not sure how you got that impression!  Watch the keynotes from the first day and see if you still have that idea!  Desktop apps are alive and well.  There were many sessions on Metro because that is new, but Desktop apps are alive and well (as mentioned in the 1st keynote I believe).  Can you point to some specific sessions or Keynotes? 



    Jeff Sanders (MSFT)
    Thursday, October 13, 2011 6:27 PM
  • Here:  Check out this blog from Steven Sinofsky: http://blogs.msdn.com/b/b8/archive/2011/08/31/designing-for-metro-style-and-the-desktop.aspx


    Jeff Sanders (MSFT)
    Thursday, October 13, 2011 6:39 PM
  • The developer preview has plenty of Apps (small, focused, immersive, single tasking applications) that show real potential for W8 on a tablet and more to the point they are concrete examples of the often repeated phrase 'Metro styled' as applied to 'apps'.

    Then you have the 'Metro Styled' Start Screen, again this is great on a tablet but a bit of a car wreck for some desktop users. Now I love the new start screen on both Tablet & Desktop but my usage patterns mean I hardly see the Start Screen once I've gone into Desktop land but I can see many valid reasons quoted on this forum as to why it interrupts people's workflow.

    Now if people are applying the phrase 'Metro Styled' to desktop applications (and I'm sure I've heard this but can't pin down where) I have the same worries as the OP - I like multi tasking multi windows all on screen at once and the current crop of 'Metro Styled' apps don't cut it.

    MS need to clarify with a concrete example the real meaning of the application of the 'Metro design language' to a desktop application otherwise people will associate 'Metro styled' with 'Dumbing down'.




    Acer W500 tablet & dock, New 'works' Lenovo laptop Too much apple stuff. Remember: A Developer Preview is just that, a preview for developers - not everything will work 'just right' on day 1.
    Friday, October 14, 2011 8:32 PM

    Hi Jeff,

    Thanks for posting this blog reference; it, and the focus on Metro Apps at the Build conference, were some of the reasons I developed my impression that Microsoft was planning a long-term migration away from the current desktop environment and API. It seems I'm not the only one to come away with these ideas.

    Please don't misunderstand, I'm not saying that I think Microsoft is going to drop the current APIs and desktop metaphor overnight, but it does seem clear from the various blog posts and videos, and I've watched most of the Build videos now - some multiple times, that the current API and interface are under heavy scrutiny and will be phased out, however slowly. Re-watch the sections where the WinRT APIs are introduced and see if you don't come away with at least an understanding of where I got the idea.

    You only have to look as far as the Zune application to see the metro design language in action in the desktop environment. Clearly Zune isn't written to the WinRT API, but it is closer in style to a Metro App than a traditional desktop application. It doesn't hang together quite as cleanly, so perhaps it was an early design study, or perhaps the current API doesn't make it easy to build Metro styled applications, but the design language is clearly visible. Regardless of which API was used in its development, Zune is another data point. It looks and feels different from other desktop applications. Is it a one-off or is it a view of things to come?

    I certainly wouldn't mind seeing Win32 retired in favor of a new clean and modern API. All software has its life cycle and the current windows API is no exception. Regardless of whether WinRT is extended to replace Win32 or if WinXX replaces it in parallel to WinRT, it seems certain that a new API is in the works. The only questions are when it will be released and what style(s) and metaphor(s) will it support?

    The desktop metaphor is a powerful one that fits well into our daily routine. Enhancing it with the design principles behind Metro seems a natural progression. When the printing press was first introduced, books were hand-decorated to make them appear to be handwritten manuscripts. It took decades before consumers accepted printed books as their own medium. Metro holds the promise of allowing digital to be a medium in its own right, unfettered by 2D/3D representations of physical objects.

    To put it more succinctly: If Microsoft is not extending Metro to desktop applications, let me be the first to urge them to consider it. Metro Apps are a good starting point, a safe place to experiment. The real work and benefit of Metro though will only be realized if and when it enhances fully capable desktop applications in a complex windowed environment.


    David Bertagni

    • Edited by dbertagni Sunday, October 16, 2011 5:28 AM
    Sunday, October 16, 2011 5:25 AM
  • David,

    Thanks for your comments and interest in the Metro style.  This is a great discussion!


    Jeff Sanders (MSFT)
    Monday, October 17, 2011 2:56 PM
  • Metro-Style vs Metro is fast becoming an overloaded term, so sooner Microsoft figures out that the word Metro should be budgeted strategically across all marketing and development discussions the sooner we can clean the terminology mess up.

    Metro Design Language is simply a bunch of principles that you can pick and choose from, you don't have to inherit the entire concept end to end but in reality these principles are just echoing what we are typically seeing on the web today via the CSS / Web 2.0 design style / crowd. There's nothing conceptually new here but given Microsoft have gone very specific in terms of their UI when it comes to WP7 and Win8 that often deviate from original concepts like Zune, its fair to say "wtf?"

    Having designed enterprise UI's in metro (see my flickr account "mossyblog") the concept works just as effectively as it does in a normal WinForm/WPF situation but you need to think about it in a chromeless form and at the same time lean a little more on typography and glyps found at places like thenounproject.com etc for your end users to execute their processing and perception index(s). That unto itself is a bit of a cognitive deep dive into the land of "I dunno, is this the right approach given habitual usage today, strong requirement that the end users have a fairly high degree of working memory muscle built and lastly can differentiate between content and input?" - jury's out! as aside from the "wow that looks pretty!" there is a need for the wow effect to be sustained beyond the 10sec-10hr initial usage, which is what I'm thinking the authors concerns stem from.

    The difference with a ms-vnext-design (aka what you see as being metro execution today) is that they rely heavily on what typically is found in most design-centric CSS sites today. You start out with a grid pattern, you wireframe the containers around how the elements fit in then start painting by numbers in terms of color selection around that - which for me is concerning as looking at the WP7 market place, the colour combinations being used are getting messy and at times the reliance on typography for 80% of the workload puts to much emphasis on intrinsic cognitive load and less on extraneous cognitive load balance.

    Also restrict your color palettes to a minimal amount, ie isolate 1-2 colors for branding, 1 for chrome and 1 for input to give it what i call "safety touch" points, meaning they represent "You can click or interact with this shape/text as its designated as being input"

    Then apply dark/light shades with background/fg to give depth as too much flatness is a bad thing imho.

    What I would say is if you do pick up the metro inspired way of life going forward, then you really need to break away from your traditional approach to product design, in that you're effectively given a free pass to interupt the habitual usage of software today with this new vibrant visual canvas, so why bring old habits forward.

    Examples are instead of using DataGrids to represents large amounts of data to then empower the user to digest this data and tell their own story, instead take a page out of infographics and tell the story of the data in an interactive fashion that compliments the overall application. Differentiate from your competitors in this way so that your application or your query around metro "fit or not?" makes sense in a more natural way?

    If you're hoping to take your typical LOB application thats filled with large amounts of datagrids, trees and tabs all over the place and then are wanting to cram that into a minimalist inspired set of principles then you're effectively trying to put out a fire with petrol? entertaining at first but eventually someone ends up in pain.

    eg: of ms-vnext-design style combination of app meets infographic.






    • Edited by Mossyblogz Wednesday, October 19, 2011 1:10 AM fixed Noun Project name as per below reply
    Wednesday, October 19, 2011 12:39 AM
  • will my usage pattern be relegated to second class citizenship?

    We've already got a good example of multiple styles of UI in Windows today. Open up a command prompt and there you go! Some applications are more suited to a command line interface than a GUI. Note how Microsoft is providing deep support for PowerShell scripting for products like Exchange because the command line is great for automating processes.

    The new WinRT apps are yet another dimension developers/designers can take advantage of in their arsenal. Command line applications for automated processing, traditional Windows GUI applications for high-density power-user applications, Metro UI's for simplified and focused full screen applications used by less techy users.

    It will take quite awhile, many years in all likelihood, but I see Metro UI's eventually being very useful for LOB applications. The delay is simply because businesses aren't going to rewrite all their custom apps from scratch anytime soon. But simplified and focused Metro UI's are perfect for reducing training time and letting users just get their work done. I'm not convinced Metro UI's will work well for Excel (though I'd love to see an attempt), but for email it's great. Our responsibility as developers is to figure out the right tool for the right job.

    Thursday, October 20, 2011 5:36 PM