Click here to monitor SSC

Tony Davis is an Editor with Redgate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the and websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his blog or his author page. As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management. In his spare time, he enjoys running, football, contemporary fiction and real ale.

Going Metro

Published 13 April 2012 10:53 am

When it was announced, I confess was somewhat surprised by the striking new "Metro" User Interface for Windows 8, based on Swiss typography, Bauhaus design, tiles, touches and gestures, and the new Windows Runtime (WinRT) API on which Metro apps were to be built. It all seemed to have come out of nowhere, like field mushrooms in the night and seemed quite out-of-character for a company like Microsoft, which has hung on determinedly for over twenty years to its quaint Windowing system.

Many were initially puzzled by the lack of support for plug-ins in the "Metro" version of IE10, which ships with Win8, and the apparent demise of Silverlight, Microsoft’s previous ‘radical new framework’. Win8 signals the end of the road for Silverlight apps in the browser, but then its importance here has been waning for some time, anyway, now that HTML5 has usurped its most compelling use case, streaming video. As Shawn Wildermuth and others have noted, if you’re doing enterprise, desktop development with Silverlight then nothing much changes immediately, though it seems clear that ultimately Silverlight will die off in favor of a single WPF/XAML framework that supports those technologies that were pioneered on the phones and tablets.

There is a mystery here. Is Silverlight dead, or merely repurposed? The more you look at Metro, the more it seems to resemble Silverlight. A lot of the philosophies underpinning Silverlight applications, such as the fundamentally asynchronous nature of the design, have moved wholesale into Metro, along with most the Microsoft Silverlight dev team. As Simon Cooper points out, "Silverlight developers, already used to all the principles of sandboxing and separation, will have a much easier time writing Metro apps than desktop developers".

Metro certainly has given the framework formerly known as Silverlight a new purpose. It has enabled Microsoft to bestow on Windows 8 a new "duality", as both a traditional desktop OS supporting ‘legacy’ Windows applications, and an OS that supports a new breed of application that can share functionality such as search, that understands, and can react to, the full range of gestures and screen-sizes, and has location-awareness.

It’s clear that Win8 is developed in the knowledge that the ‘desktop computer’ will soon be a very large, tilted, touch-screen monitor. Windows owes its new-found versatility to the lessons learned from Windows Phone, but it’s developed for the big screen, and with full support for familiar .NET desktop apps as well as the new Metro apps. But the old mouse-driven Windows applications will soon look very passé, just as MSDOS character-mode applications did in the nineties.


11 Responses to “Going Metro”

  1. BuggyFunBunny says:

    – It’s clear that Win8 is developed in the knowledge that the ‘desktop computer’ will soon be a very large, tilted, touch-screen monitor.

    First, I assume that’s a typo: tiled. Second, and to the point, will the other shoe drop, and if so, who’ll be first to do so?

    That shoe, is the datastore. With a discrete (but not, so to say, discreet) tiled interface, the logical underpinning is a pickable data structure. IOW, a data structure which is chopped up into small bites of bytes, all of which can be displayed as touchable/pickable entities. No more typing, since the keyboard isn’t there. Yes, more screens, but traversed in a way, not necessarily hierarchical (in fact, never that way), which connects the bites by their relationships (notice how I slipped that in :) ) to one another. Hierarchies can’t do that. Hierarchies compel a fixed semantic, while relationships don’t. New relationships is merely a matter of adding new data (to sets which are already orthogonal; that’s important) or new foreign keys between existing data. Hierarchies can’t do that, either.

    “I’m the King of the World!”

  2. callcopse says:

    I’m not 100% convinced that we will all soon be using large tiled or indeed titled touch screen monitors. I’m not saying they haven’t got a part to play but business is not necessarily going to be that interested in investing in such frippery. I am possibly biased by working for several large corporates who are struggling / have recently struggled to get beyond IE6 on their desktops.

    As a devloper it is of limited application – for those who pay my bills I think the same holds.

  3. Octagon says:

    – There is a mystery here.

    Yes, the whole recent media campaign on Silverlight looks well orchestrated and who but Microsoft could do that? Silverlight is a secure way to run Internet based applications that process local data and has very little common ground with HTML5 innovations. Why all that brain dead talk that HTML5 video is a blow to Silverlight? Silverlight can be compared to Java FX and Adobe AIR, not to HTML and JavaScript, but the media was silent on that. My best and only guesses on Microsoft reasoning are:

    1. Disinformation campaign targeting the top, and consequently computer illiterate, management of the competition.

    2. Let people do LOB with JavaScript, fail, and run back to Silverlight.

    3. Prevent any raise of Java FX and Adobe Air since the same invalid death arguments are equally valid for that platforms.

    4. Make more Web developers to do toys since the entry barrier for HTML and Java Script is lower than for Silverlight. That will make that developers more desktop orientated and some may leave the Web and enter Metro.

    Now those who did LOB with Siverlight on MAC have a very good reason to switch to Win 8, those who did it on Windows have a good reason to upgrade to Win 8.

    – It’s clear that Win8 is developed in the knowledge that the ‘desktop computer’ will soon be a very large, tilted, touch-screen monitor.

    I doubt that.

    Tilted? Currently monitors are placed correctly. Remember book stands that attempted to place a book similarly? And ‘desktop computer’ also requires a desk top to put things on.

    Very large? I guess current ones are near the physiological limit, which is about 32 inch to me. Anything bigger must be curved, and this will not be done in time for Metro. A very large monitor is much more expensive and less customizable than several smaller ones. A very large monitor defies the Metro full screen paradigm, so new UI principles are to be incorporated into the OS, while the multi monitor support is almost done in Win 8.

    Touch? No way for the very same reasons the voice input is not used much. Besides, touch is fragmented. The hand held touch Microsoft have researched and expects in Metro is very different from a wall or ceiling touch.

    The only place where I see a very large tilted monitor 100% welcome is a control room or command bridge. People can stand near it and every detail like the ease of nonverbal communication or the speed of escape may be critical for survival.

    It also may be 90% welcome in an artist’s studio or medical lab. A niche product, anyway.

    If Metro and the associated idea of a universal touch/desktop device holds, I expect progress with input devices, not monitors. Current text input for touch dumbly imitates keyboard. Faster and better multi touch and gesture based ways will be introduced, making keyboards and mice obsolete. A touch panel can be smaller, allow to input text faster, and replace a keyboard, a mouse, and a pen tablet all at once.

  4. Keith Rowley says:

    I am not convinced that large tiled touch screens are the future either. As much as it has been pushed humans actually don’t do multi tasking that well (there was a recent article on this in wired I believe) so we are actually better off with full screen apps. Also I think multiple monitors are currently much more useful than tiles on a single monitor.

    The upshot is that metro is a toy interface, good for tablets and entertainment, but not really good for business.

  5. nick harrison says:

    I could be wrong, but I think that the comment about “large” was relative. Large compared to a phone or even an iPad. We will probably see 17- 18″ touchable monitors becoming very popular.

    I have a couple of friends with them running windows 7 and they love it. They still have and use the keyboard, but it is just very intuitive to lift your hand to the monitor to scroll or move a window around.

    If at all possible, folks will continue to use a keyboard to data entry, but the hand is very natural for navigation. It doesn’t take long to get used to switching back and forth, and remember that there is still a market for physical keyboard on cell phones and ipads. Just because your desktop sports a touch screen will not detract the importance of the keyboard.

    As for the question of the future of Silverlight? It may not be dead, but it is on live support and the priest is on speed dial. While Microsoft put its full support behind it, it had a questionable future. Most people did not see the benefits to justify the extra complexity and new learning curve required. Without even Microsoft truly supporting it, the future for the product is dim.

    I am encouraged that Microsoft may have learned from some of the mistakes here. Their treatment and response to jQuery is very encouraging. You don’t always have to provide a replacement for a popular concept. Sometimes, you can embrace it, extend it, and help shape its future.

    I also don’t really see databases being affected by Metro. They are more likely to be affected by NoSQL. Changes to the way the user interacts with the data should be handled in the UI without affecting the underlying database. The concepts for good database design have survived fat clients, thin clients, remote clients, web clients, cloud clients. These core concepts can survive Metro clients as well.

  6. Cheval says:

    I’m sorry, but “going metro” anytime soon? I don’t think so. For the LOB work I can’t see WinXP being moved on while it is good enough and therefore more importantly the XP apps with it. I predict that the XP apps will be the COBOL of the modern times, very long lived. While Microsoft still provides backward compatability of sorts then they will linger on still more.

    Even other ideas of keeping XP apps alive in virtual machines while they can still talk to the SQL Server and other data is talked about, like zombies of the 90′s.

  7. BuggyFunBunny says:

    – I also don’t really see databases being affected by Metro. They are more likely to be affected by NoSQL.

    Same coin, other side. IFF Metro developers take the interface seriously (admittedly, small chance), they’ll connect the dots that the structure of the datastore matters. To get the most out of a pick-able interface, data must be structured in a pick-able way; NoSQL can’t do that. Typical [un|de]normalized schemas can’t do that without gobs of code. Why do that? Moreover, a high normal form schema is perfect input to a UI code generator; all the logic is in the PK, FK, constraints, and other schema objects. The closer the UI semantics is to the data semantics, the less manual lifting is required. The further apart they sit, the more code is needed to correct the “impedance mismatch”; while that creates employment opportunities for coders, it doesn’t make for more robust applications.

    – The concepts for good database design have survived fat clients, thin clients, remote clients, web clients, cloud clients.

    If that’s been your experience, then God bless you. I’ve most often seen flatfiles dumped into RDBMS more often, far more often, than not. Flatfiles require code, sometimes bunches, to disambiguate twixt the datastore and the client, most often in the client. That’s how your grandpappy built his COBOL/3270 applications. Whether or not the datastore was, by name, a relational database. We can do better. In memory database, HANA from SAP, has been getting press recently. Add that into the melange of multi-processor/core with SSD machines, high normal form databases just make more sense.

    So, yes, Metro can (not necessarily will) affect how databases are structured. May be a coincidence, may be not, but Phil dealt with this a few weeks ago: . He said, “We’ll be looking at a typical database ‘migration’ script which uses an unusual technique to migrate existing ‘de-normalised’ data into a more correct form.” Perhaps Phil should ship the piece off to all budding Metro developers?

  8. DThrasher says:

    For occasional, casual computing, touch screens make a lot of sense. So it perhaps makes sense that Microsoft would try to recapture the home user market with the Metro redesign.

    I can’t imagine a Metro-style interface will be an improvement for anyone trying to do real work, however. If you do any significant typing, a full keyboard with tactile feedback is clearly superior. Tapping and swiping are all very nice, but it’s hard to imagine graphic artists giving up their mice or styluses any time soon. Unless Microsoft can demonstrate how a touch interface would significantly improve the experience of creating Excel Spreadsheets or PowerPoint presentations, I think Metro will be a hard sell to most businesses or power users.

    I wonder how well the Metro-like redesign given to the XBox 360 interface has been received? I find it awkward, but maybe it works better if you have a Kinect.

  9. nick harrison says:

    I did not mean to imply that all databases are designed perfectly. Only that if a database design worked for one presentation model, it will work for the next. On the flip side, a fancy new UI cannot fix a bad design.

    If folks take the opportunity to clean up their database along with converting their UI to Metro, more power to them, but Metro should not require a new data model as long as the current one works.

    If you have a choice between tapping away on a real keyboard vs tapping away at a touch screen most people will probably still opt for a real keyboard. A Metro interface alone is not likely to change that. Even with a touch screen interface, I don’t see the keyboard going away immediately. Your desktop will still have a place to plug in a physical keyboard. People do it to the ipad today.

    At the same time, it probably won’t be too long until we come to a point where the traditional keyboard becomes as quaint as a mechanical typewriter seems today.

    On my Android phone, I use swiftkey which analyzes what I have typed before to predict what I might type next. Sometimes I can type an entire email without ever typing out a full word and with the keyboard predicting as much as half of the words that I plan to use. Granted my writing may be more easily predicted than most. This creates a built in spell check and a rudimentary grammar check. If it guesses the word you are trying to type, it will guess the correct spelling of the word that it thinks.

    The swype keyboard is also very popular. Here you don’t have to actually tap each key, you can simply swipe your finger over a pattern that touches each of the letters. With a little practice, you can get very good at it.

    There are times when I wished my regular keyboard had some of these features. It would be nice to be able to swipe my finger over a physical keyboard and have it delete the previous word or judge the pressure and delete the line.

    It would be nice to have a keyboard smart enough to realize that I am typing code and separate the the { and [ keys so that I don’t have to use the shift key so much. Or how about a keyboard recognizing that I am typing in a URL and add a “.com” key.

    It would be nice to more easily switch from QWERTY to Dvorak if you are so inclined. I believe that we are only beginning to scratch the surface of what may be possible with context sensitive custom keyboards.

    One of my favorite features in emacs is the language sensitive editing modes. Imagine being able to have your keyboard customized based on the type of typing that you are doing. Typing numbers, hide all of the keys that you are not using. Type sql code, make the keys that you are most likely to use more prominent. I would love to have a keyboard optimized for sql vs c#, vs HTML vs JavaScript vs technical writing vs casual writing vs text messaging vs quick notes.

    The transition may be difficult for many, and will probably not happen over night, but in the not too distant future, we will probably look back and think how naive it was to expect a single keyboard to meet the needs for everyone in every situation.

  10. BuggyFunBunny says:

    I was going to, I thought, head out into unexplored territory, by suggesting that the non-menu semantic of Metro is designed to be relational, and that Metro is the Trojan Horse for winFS insurgence. Nobody could have seen that, right? Well, if you take to your favourite search engine, with ‘winfs metro’, you’ll see that the territory isn’t unexplored. Schweeet.

  11. says:

    This is somewhat tangential, but ArsTechnica had a discussion today about the interactions between Metro and the traditional desktop in Windows 8. It is up at

    One point Peter Bright implied in the article is that the majority of productivity applications that are used on desktop computers will likely remain desktop, rather than metro, applications for now and that if and when there are metro productivity apps, using them alongside traditional desktop apps can be somewhat jarring, especially on a multimonitor display.

Leave a Reply

Blog archive