View Full Version : Reflecting on our first conversations (part 2)

09-02-11, 07:40 PM
More... (http://blogs.msdn.com/b/b8/archive/2011/09/02/reflecting-on-our-first-conversations-part-2.aspx)

09-02-11, 11:04 PM
This guy is definitely a good writer. Obviously it's hard to say what the final outcome will be but there is at least one person who seems to understand how changing things can drastically effect the final product.

I really liked this line from the first part:

In that sense, we learned one very valuable lesson early on, which is that discussing user interface is something a lot of people want to do, but doing so through static images very quickly misses the point. Very much like zooming in too far with a microscope, the big picture is lost. It also surfaces the least actionable sorts of feedback to wade through of the “love it” / “hate it” variety. Even with short videos we have not found the right way to put context around the overall experience. Given enough focus, light, and magnification, anything can become important and the subject of a big debate. We certainly contributed to that.

My take is they understand that one little feature isn't going to make or break things, but making sure that everything works well collectively is what will make the OS better.

From the 2nd article this was a good paragraph:

To me the most interesting feedback has been about the visual overhead. The role of “Metro” came up and how we should use a lighter graphical treatment and also just expose fewer commands because people want minimalism now. Obviously we all want less—fewer exposed features means less surface area which means less code to write, test, maintain. Minimalism is not hiding features or making useful things hard to get to. Minimalism is about stripping things down to fundamental features. The question then is really defining that set of features. Our approach to minimalism is to avoid layers of commands or hidden pockets of features (those mechanisms themselves become conceptual and code overhead—bloat can come from UI itself, not just what UI exposes), and to reduce the number of mechanisms in the UI. In doing so, we aim to present the capabilities of the product in one manner. We also know that minimalism is not about doing less stuff, especially in light of all the feedback over features people want to see added to explorer.

It's basically the double edged sword. How do you make the UI have less options while providing more features? I can think of a few examples for situations like this. When I write a batch file there are lots of ways someone might want to use it, so you try to program it in a way that it can be customized as much as possible. The problem with that is you end up with so many options it detracts away from the final product. There are a lot of options that are present for only edge cases that could probably be removed. Obviously that means it's not going to work as well in those scenarios, but overall it will help performance the rest of the time.