Tag: UI

Overcoming the New Visual Studio UI

In a blog post last week, Monty Hammontree, the Director of User Experience for Visual Studio, announced the UI refresh for Visual Studio. This is a project that I had some involvement in (mostly as a reviewer) while still at Microsoft, and have been waiting patiently for this announcement so that I could talk about it.

iconRefreshPersonally I love the new UI. Sure, its not perfect, but it is a huge improvement over where Visual Studio has been for the past ten years. What is surprising to me is the amount of negative reaction the blog post has gotten. Some of my favorite comments from the blog post are:

Okay, i get wanting to reduce distraction and “lighten” the UIs feel… but GEEZ! Why do good ideas always get taken too far? This UI is SO bland and SO dead, I’d be afraid of it putting me to sleep on the job as opposed to reducing distractions. ICH! – Aaron – 23 Feb 2012 10:20 AM

Is it a desktop app?  Is it a metro app?  Decide and stop mangling the two UIs together.  The capitalized titles hurt my eyes.  They’re distracting and out of place. – Mike – 23 Feb 2012 10:26 AM

…While I do like introducing simplicity, I won’t be installing this if there is no option to replace these very low contrast lay-outs. And I’m pretty sure other people will don’t want to upgrade to this either, which will cost you some Metro developers in the long term… – Tom Wijsman – 23 Feb 2012 10:31 AM

Windows 3.1 is back? – Andrey – 23 Feb 2012 10:52 AM

The monochromatic color scheme is so bad it is distracting.  Instead of staying out of the way, my eyes are drawn to just how bad it really is…It is so bad and so distracting that a new word should be created to describe how bad and distracting it is…like baddistracting or bastracting.  The monochromatic scheme is bastracting and should be stopped. – jparramore – 23 Feb 2012 11:38 AM

Anyway, you get the point. There is a lot of negative reaction to the new UI. But is the new UI really that bad. Is it possible that it is actually a significant improvement, and we, the develoeprs who use and love Visual Studio, are just not ready to accept change?

A Bit on Metro

The Metro design echoes the visual language of an airport or metro system signage in both its design and typeface. The goal of the Metro design style is to create contextual relevance through content – primarily icons. Icons should be clear and understandable, and leverage real-world metaphors that are familiar to users. They should have simple geometry and limit the amount of fine detail.

Simplicity is the key. Every icon should be as simple as it can be (and no simpler). The primary purpose of the action the icon enables should be clearly and cleanly represented by the icon.

420.xamlLook all around your life and you will find these icons. They are not only on airport and metro signs, they are on your electronics, your clothing tags, and the dashboard of your car. You are so used to seeing Metro style icons, that you have developed an ability to quickly understand instructions and information based on a simple icon.

Metro style’s main goal is to make understanding information and instructions at a glance easy. The challenge is always balancing what you need to know with how much you can consume. For example, look at the laundering instructions on a piece of clothing. There could be 5 or 6 icons there, some of which you may not understand. That is likely because they are not within your domain, or context. I guarantee you that anyone working in a dry cleaning facility understands them all at a glance.

A Good Metro Implementation Focuses on Content

I think of the dashboard of my car, an Audi A6, as a great Metro style implementation. It provides me easy access to the information that I need in context, and easy way to switch context (e.g. between audio entertainment and navigation), and draws my focus and attention to the content that matters (speed, RPMs).

IMG_0087-2

Most command buttons have an easy to understand icon (seat heaters, parking brake, fans, etc.). Some things use text (On/Off, Nav, CD/Aux, etc.) instead of icons. In either case it is easy to quickly infer the meaning and intent of the button. All of the command buttons and interfaces are the same color – white icons and text (redish backlight if its dark) on a black button. Essentially a monochromatic UI that makes finding and using the commands easy, but focuses my attention on the important stuff – warnings and content.

    • Warning information is indicated with a different color than the rest of the UI. For example the “Passenger Air Bag Off” warning and the check engine icon are both yellow.
    • Content that requires my focus and attention is white, such as the speedometer and tachometer, and the navigation screen (which includes a small set of other colors to indicate route, landmarks and warnings).

I can’t imaging how distracting it would be to drive my car if every icon and button were a colorized button. It would make finding and focusing on the important content much more difficult. As it is, I know to focus on the white content, and pay extra attention to any yellow content.
The new Visual Studio UI is attempting to do exactly what my Audi dashboard does. Make it easy for you to find information and commands, but draw your focus and attention to the content that matters most (aka your code).

Resisting Change

The fact of human psychology is that we tend to resist change before we embrace it. This seems to be the tone of many of the comments on Monty’s blog post. Many people are likely going through the stages of grief – Shock, Denial, Anger, Bargaining, Depression, Acceptance.

    Many people seems to be in the first four or five stages.

Shocked by the change.

WO WO WO. Let’s get one thing straight. There had better be a GIANT button in there to “MAKE IT LOOK LIKE IT USE TO.” – Don’t “Windows 8” me! – 27 Feb 2012 3:07 AM

Denying the change.

Why not keep the current GUI? it seems that your vs11 will be the worst design ever… please, see all these post, reconsider your transition… – ammin – 26 Feb 2012 5:15 AM

Anger toward Microsoft for the change.

I assume these god damn awful UI changes are meant to hide the lack of real changes over VS2010? – Steve – 27 Feb 2012 10:56 AM

Bargaining with Microsoft regarding the change.

Folks, we need to organize & mobilize to fight this: talk to your co-workers, give them link to this page, ask them to comment here. – Dee – 25 Feb 2012 9:32 AM

Depressed about the change.

Don’t care.  It is what it is and nothing anyone says here can change that. – Not Anal – 27 Feb 2012 12:12 AM

Its not clear to me that the mass of Visual Studio developers will reach acceptance of the new UI, nor is it clear to me if the bargaining will result in change. I like to believe that both will happen.

The Path Ahead

My opinion is that this is a step in the right direction. Of course, its near impossible to actually tell if its an improvement with out extended usage of the new UI, to see if it improves my productivity or not. This means that for many people there is likely a step of “testing” that must occur prior to acceptance. The testing may be challenging at first because we have to unlearn a few old things in order to learn some new things. Like the Audi dashboard example above, this happens almost anytime you buy a new car as well. Basically things work the same – there is a speedometer and tachometer, although they may be in reverse positions from what you are used to; there is a console for controlling audio, heat and AC and possibly navigation; and there are warning indicators, but possibly different ones, or they are in different positions. Testing the change requires a little patience in order to fully determine if the change is manageable – that is to say, you may not be able to affect the change, but you can determine your acceptance of the change.I encourage everyone to withhold judgment until you’ve had a chance to try the new Visual Studio UI. Once you’ve given it a fair chance, provide actionable feedback to the team via Monty’s blog (e.g. “There had better be a GIANT button in there to “MAKE IT LOOK LIKE IT USE TO.” isn’t really actionable).

As someone who leads product development, I can tell you that there is nothing more important than hearing from customers. It is the challenge of the product development team to determine actionable, real feedback from shock, denial, anger and depression driven feedback. A good product development team will be innovative and creative, and it may not immediately resonate with the customer, but if they’ve done their job right, the customer will accept and embrace the change in the long run, and have a better product experience as a result.

My favorite Henry Ford quote:

If I asked my customers what they want, they simply would have said a faster horse.

Henry Ford went on to introduce a radical change and innovation, that was met with both immediate acceptance and criticism. Can you imagine if that change had not been widely accepted?

Language Choice in Windows 8 is Not About Portability

Every time I go to talk to folks about Windows 8, the same questions pop up. I blame this largely on Microsoft’s silence about Windows 8 following the release of a tidal wave of information followed by the Windows 8 Developer Preview at Build in September. C’est la vie. This too shall pass.

One of the topics of conversation that comes up repeatedly is how to choose between using HTML5 + JavaScript or XAML + C#/VB (aka .NET) to build Metro style applications. What are the factors that you should consider before making your choice? Is HTML5 better? Is there a future for XAML? How do you choose?

Inevitably someone in the conversation cites the portability of HTML5 and JavaScript as the answer. It goes something like this…

“You should use HTML5 and JavaScript for Metro style applications because its portable and XAML isn’t. If you build with HTML5 then you can use the same code for your website or other platforms because its standards-based….HTML and JavaScript.”

This couldn’t be further from the truth. The use of HTML5 + JavaScript in Windows 8 is about as proprietary as using XAML + .NET. Consider the “Hello World” of the modern era – an RSS feed reader.

If you are going to build a feed reader into your Metro style application using HTML5 and JavaScript, it would look something like this:

DEFAULT.HTML

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>RssReader</title>
<!-- WinJS references -->
<link rel="stylesheet" href="/winjs/css/ui-light.css" />
<script src="/winjs/js/base.js"></script>
<script src="/winjs/js/ui.js"></script>
<script src="/winjs/js/binding.js"></script>
<script src="/winjs/js/controls.js"></script>
<script src="/winjs/js/animations.js"></script>
<script src="/winjs/js/uicollections.js"></script>
<script src="/winjs/js/wwaapp.js"></script>
<!-- RssReader references -->
<link rel="stylesheet" href="/css/default.css" />
<script src="/js/default.js"></script>
</head>
<body>
  <h1>RSS Reader</h1>
  <div id="downloadStatus"></div>
  <div id="template" data-win-control="WinJS.Binding.Template">
    <div class="postTitle" data-win-bind="innerText: title"></div>
    <div class="postDate" data-win-bind="innerText: date"></div>
  </div>
  <div id="posts" data-win-control="WinJS.UI.ListView"
    data-win-options="{itemRenderer: template,
                       layout: {type: WinJS.UI.ListLayout},
                       selectionMode: 'single',
                       onselectionchanged: selectionChanged}">
  </div>
  <div id="contentTemplate" data-win-control="WinJS.Binding.Template">
    <div class="postTitle" data-win-bind="innerText: title"></div>
    <div class="postDate" data-win-bind="innerText: date"></div>
    <div class="postContent" data-win-bind="innerHTML: content"></div>
  </div>
  <div id="content"></div>
</body>
</html>

DEFAULT.JS

(function () {
  'use strict';
  WinJS.Application.onmainwindowactivated = function (e) {
    if (e.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch){
      downloadStatus.innerText = "Downloading posts...";

      var syn = new Windows.Web.Syndication.SyndicationClient();
      var url = new Windows.Foundation.Uri("https://dougseven.com/feed/");
      syn.retrieveFeedAsync(url).then(processPosts, downloadError);

      // Define an event listener for the onselectionchanged event.
      posts.addEventListener("selectionchanged", selectionChanged);
      // Process the declarative controls
      WinJS.UI.processAll();
    }
  }

  function selectionChanged(e) {
    content.innerHTML = "";
    var selection = posts.winControl.selection;

    if (selection.length) {
      var post = postItems[selection[0].begin];
      var contentTemplate = WinJS.UI.getControl(
        document.getElementById("contentTemplate")
        );

      contentTemplate.render(post).then(function (element) {
        content.appendChild(element);
        });
    }
  }

  var postItems = [];
  function processPosts(feed) {
    // Clear the process indicator
    downloadStatus.innerText = "";
    // Iterate over the items
    for (var i = 0, len = feed.items.length; i < len; i++) {
      var item = feed.items[i];
      var post = {
        title: item.title.text,
        date: item.publishedDate,
        content: item.summary.text,
        };

      postItems.push(post);
    }

    // Populate the ListView control's data source
    posts.winControl.dataSource = postItems;
  }

  function downloadError() {
    downloadStatus.innerText = "Error loading posts.";
  }

  WinJS.Application.start();
})();

The Results

The resulting application creates a simple two column RSS feed reader, with post titles on the left, and post content on the right (in HTML):

image

Now imagine you wanted to use the same code to make your RSS feed reader website. Immediately you have to cut out all references to the WinJS JavaScript files, since WinJS is a JavaScript wrapper around key WinRT functions.

<!-- WinJS references –>
<script src="/winjs/js/base.js"></script>
<script src="/winjs/js/ui.js"></script>
<script src="/winjs/js/binding.js"></script>
<script src="/winjs/js/controls.js"></script>
<script src="/winjs/js/animations.js"></script>
<script src="/winjs/js/uicollections.js"></script>
<script src="/winjs/js/wwaapp.js"></script>

For example, the Metro style RSS feed reader application uses WinJS to manage a lot of the UI look and feel, data binding and how you interact with the application, including controls, animations, etc. All of that functionality will have to be rewritten in non WinJS format.

You are forced to rewrite key functionality, such as the feed syndication capabilities written in JavaScript which leverage Windows.Web.Syndication.SyndicationClient – a WinRT class that manages the network interaction between the client and the feed provider, including the asynchronous calls to get the RSS data and parse and format it correctly.

var syn = new Windows.Web.Syndication.SyndicationClient();
var url = new Windows.Foundation.Uri("https://dougseven.com/feed/");
syn.retrieveFeedAsync(url).then(processPosts, downloadError);

You have to rewrite the data binding of the feed items to the HTML layout.

// Populate the ListView control's data source
posts.winControl.dataSource = postItems;

// Process the declarative controls
WinJS.UI.processAll();

<div id="template" data-win-control="WinJS.Binding.Template">
  <div class="postTitle" data-win-bind="innerText: title"></div>
  <div class="postDate" data-win-bind="innerText: date"></div>
</div>
<div id="posts"
  data-win-control="WinJS.UI.ListView"
  data-win-options="{itemRenderer: template,
                     layout: {type: WinJS.UI.ListLayout},
                     selectionMode: 'single',
                     onselectionchanged: selectionChanged}">
</div>
<div id="contentTemplate" data-win-control="WinJS.Binding.Template">
  <div class="postTitle" data-win-bind="innerText: title"></div>
  <div class="postDate" data-win-bind="innerText: date"></div>
  <div class="postContent" data-win-bind="innerHTML: content"></div>
</div>

That doesn’t feel very portable.

The conclusion is that your language choice when building a Windows 8 Metro style application has next-to-nothing to do with portability.

Before you get on your soap box, yes you can reuse some of the assets from the application. For example, the CSS is reusable between Windows 8 and the web. Some of the JavaScript is likely reusable, if it isn’t tightly coupled to WinJS or WinRT. But that’s it. Most of what makes the app work is dependent on WinRT, so its not portable – WinRT only runs on Windows 8.

Get Comfortable

So what should your language selection be based on? Comfort.

Microsoft architected an application development stack that does what Microsoft does best – provides flexibility and gives YOU choice. If you want to build an application for Microsoft’s upcoming platform, you can choose the language that you are most comfortable with. Microsoft isn’t making you learn an entirely new stack – just learn the new bits – and use the skills you already have.

Choose XAML

If you are a .NET developer currently working in WPF or Silverlight, then XAML+.NET will be right up your alley. Sure you will have to learn WinRT and some new syntax, but most of what you need to know you already do.

Choose HTML

If you are a web-standards developer, familiar with HTML and JavaScript, then use those skills. Use HTML5, JavaScript and learn WinJS and WinRT.

Either way Microsoft has made developing for Windows 8 very approachable. Make your language selection based on your skillset and what is comfortable for you. Don’t feel like you have to lean a new language. Use what you know.

D7