Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
Larry is very appreciative of the reception and comments his post received. Thank you! It is worth noting that we’ve surpassed over 2000 comments and I’ve received and equal amount of email. I am trying to reply as often as I can!
We’re 10 days from the PDC and so we might take a short break from the blog while we practice our demos of Windows 7…we’ll keep an eye on comments for sure and maybe a post or two on the way. :-)
Let's move "up" in the dev process and look at how we come up with what is in a release and how we think about taking a feature from an idea to feature.
As we’ve posted on various engineering challenges we’ve often distilled the discussion down to a few decisions, often between two options (make a feature optional or not, add a window management feature one of two ways, etc.) Yet this doesn’t quite get to the challenge of where does the product definition begin and how do we take an idea and turn it into a feature. Most choices in engineering Windows are not between two choices, but the myriad of considerations, variables, and possibilities we have before we even get to just a couple of options. This post looks a bit at the path from an idea to a feature.
A common thread we’ve seen in the feedback is to make “everything customizable and everything optional” (not a direct quote of course). Of course, by virtue of providing a platform we aim to offer the utmost in extensibility and customization by writing to the APIs we provide. There is an engineering reality that customization and extensibility have their cost—performance, complexity, and forward compatibility come to mind. One way to consider this is that if a feature has two “modes” (often enable the new feature or enable the old feature) in one release, then in a follow-up release if the feature is changed it potentially has four modes (old+old, old+new, new+old, new+new), and then down the road 8 modes, and so on. The complexity of providing a stable and consistent platform comes with the cost that we aren’t always able to “hook” everything and do have to make practical choices about how a feature should work, in an effort to plan for the future. Designing a feature is also about making choices, tough choices. At the same time we also want to provide a great experience at the core operating system functions of launching programs, managing windows, working with files, and using a variety of peripherals--to name just a few things Windows does. This experience should be one that meets the needs of the broadest set of people across different skill levels and different uses of PCs, and also providing mechanisms to personalize with user interface and to customize with code. Every release we plan is a blending of fixing things that just don’t work like we all had hoped and developing new solutions to both old and new problems, a blending of features and extensibility, and a blending of better support for existing hardware and support for new hardware.
This post is jointly written by Samuel Moreau the manager of the user experience design team for the Windows Experience, Brad Weed, Director of User Experience Design and Research for Windows and Windows Live, and Julie Larson-Green, the VP of Program Management for the Windows Experience. With the number of comments that describe a specific feature idea, we thought it would be good to give you an overview of how we approach the overall design process and how ideas such as the ones you mention flow into our process. Also for those of you attending the PDC, Sam will be leading a session on the design principles of Windows 7. –Steven
In general, we follow a reasonably well-understood approach to product design, but that doesn’t make it easy or “automatic”. Often this is referred to as a "design funnel" where ideas go from concept to prototype to implementation and then refinement. By reading the various design ideas in the comments of Chaitanya’s post on “Starting, Launching and Switching”, you can see how difficult it can be to arrive at a refined feature design. In those comments you can find equally valid, yet somewhat opposite points of view. Additionally, you can also find comments that I would paraphrase as saying “do it all”. It is the design process that allows us to work through the problem to get from idea to feature in the context of an overall product that is Windows.
From a product design perspective, the challenge of building Windows is the breadth of unique usage of just a single product. In a sense, one of the magic elements of software is that it is “soft” and so you can provide all the functionality to all customers with little incremental cost and little difference in “raw materials” (many comments have consistently suggested we have everything available along with options to choose components in use and we have talked about minimizing the cost when components and features are not used even if they are available). And at the same time, there is a broad benefit to developers when they can know a priori that a given PC has a common set of functions and can take advantage of specific APIs that are known to be there and known to behave a specific way--the platform. This benefit of course accrues to individuals too as you can walk up to any PC and not only have a familiar user experience, but if you want to do your own work, use a specific device, or run a certain program on the PC you can also do that. This breadth of functionality is a key part of the value of a Windows PC. Yet it also poses a pretty good design challenge. Learning, understanding, and acting on the broad set of inputs into designing Windows is an incredibly fun and challenging part of building Windows.
As Larry pointed out the design and feature selection happens takes place in his part of the organization (not way up here!). There’s another discussion we will have in a future post about arriving at the themes of the overall release and how we develop the overall approach to a release so that the features fit together and form a coherent whole and we address customer needs in an end-to-end fashion.
We have a group of product designers that are responsible for the overall interaction design of Windows, the sequence and visualization of Windows. Program Managers across the team work with product designers as they write the specifications. Along with designers we have UX Researchers who own the testing and validation of the designs as we’ve talked about before. The key thing is that we apply a full range of skills to develop a feature while making sure that ownership is clear and end-to-end design is clear. The one thing we are not is a product where there is “one person” in charge of everything. Some might find that to be a source of potential problems and others might say that a product that serves so many people with such a breadth of features could not be represented by a single point of view (whether that is development, testing, design, marketing, etc.). We work to make sure engineers are in charge of engineering, that the product has a clear definition that we are all working towards implementing and that product definition represents the goals across all the disciplines it takes to deliver Windows to customers around the world. And most importantly, with Windows 7 we are making renewed effort at "end to end" design.
Let’s look at the major phases of product design in Engineering Windows. What we’ll talk about is of course generalized and doesn’t apply to each specific incident. One thing we always say internally is that we’re a learning organization—so no process is perfect or done and we are always looking to make it better as we move through each and every iteration of building Windows.
Throughout this post when we say “we” what this really means is the individuals of each discipline (dev, test, pm, design) working together—there’s no big feature or design committee.
We get an idea from somewhere of something to do—it could be big (build UX to support a new input method such as touch), wild (change the entire UI paradigm to use 3D), or an improvement / refinement of an existing feature (multi-monitor support), as some examples. There is no shortage of creative ideas, because frankly, that is the easy part. Ideas flow in from all corners of the ecosystem, ourselves included. We’ve talked a lot about comments and feedback from this blog and that is certainly one form of input. Product reviews, enterprise customers, customer support lines, PC makers, hardware and software developers, blogs, newsgroups, MVPs, and many others have similar input streams into the team.
The key is that working on Windows is really a constant stream of inputs. We start with a framework for the release that says what goals and scenarios we wish to make easier, better, faster. And with that program management builds up candidate ideas—that is ideas that will make their way through features. The job of getting a feature “baked” enough falls to program management and they do this work by working across the product and working with design, development, and testing (as Larry described).
With regard to where ideas come from, what we like to say is that the job of program management is not to have all the great ideas but to make sure all the great ideas are ultimately picked. The best program managers make sure the best ideas get done, no matter where they come from.
Given any idea, the first step is to understand what data we have “surrounding” the idea. Sometimes the idea itself comes to us in a data-centric manner (customer support incidents) or other times it is anecdotal (a blog).
The first place we look is to see what data do we have based on real world usage that would support the development of a hypothesis, refute or support the conventional wisdom, or just shed some light on the problem. The point is that the feature starts its journey by adding more perspectives to the input.
Essentially, we need an objective view that illuminates the hypothesis. We gather this data from multiple sources including end users, customers, partners, and in various forms such as instrumentation, research, usability studies, competitive products, direct customer feedback, and product support.
As many (including us) have pointed out, telemetry data has limitations. First, it can never tell you what a person might have been trying to do—it only tells you what they did. Through usability, research, and observation, we are able to get more at the intent. For example, the way we talked about high dpi and how the telemetry showed one thing but the intent was different (and the impact of those choices was unintended). The best way to see this is to remember that a person using a PC is not interesting in “learning to use a PC” but is trying to get their own work done (or their own playtime). And when faced with a “problem” the only solutions available are the buttons and menu commands right there—the full solution set is the existing software. Our job is to get to the root of the problem and then either expand the solution set or just make the problem go away altogether.
What about unarticulated needs? The data plus intent shows the “known world” and “known solution space”, but one role we have is to be forward thinking and consider needs or desires that are not clearly articulated by those who do not have the full time job to consider all the potential solution spaces. The solution space could potentially be much broader than readily apparent from the existing and running product—it might involve a rearchitecture, new hardware, or an invention of a new user interface.
A great example of this was mentioned in one of the comments on the taskbar post. The comment (paraphrasing) indicated that the order of icons on the taskbar matters so sometimes he/she would simply close all the open programs and then restart them just so the programs were in the preferred order on the taskbar. Here the data would look like an odd sequence of launch/exit/launch/exit/launch/lauch. And only through other means would we learn why someone would be doing that, and for the most part if you just walked up without any context and said “how can we make Windows easier” it isn’t likely this would bubble up to the top of the list of “requests”. Thus we see a number of neat things in this one example—we see how the data would not show the intent, the “request” would not be at the top of any list, and the solution might take any number of forms, and yet if solved correctly could be a pretty useful feature. Above all, in hindsight this is one of those “problems” that seems extraordinarily obvious to solve (and I am sure many of you are saying—“you should have just asked me!”) So we also learn the lesson that no matter what data and information we gather or what design we’re talking about, someone always noticed or suggested it :-).
The next step is where we propose a clear hypothesis – “people would benefit from rearranging icons on the taskbar because positional memory across different sessions will reduce the time to switch applications and provide a stronger sense of control and mastery of Windows”.
What is our hypothesis (in a scientific sort of way) as to what opportunity exists or what problem we would solve, and what the solution would look like, or why does the problem exist? Part of designing the feature is to think through the problem—why does it exist—and then propose the benefit that would come from solving the problem. It is important that we have a view of the benefit in the context of the proposed solution. It is always easy to motivate a change because it feels better or because something is broken so a new thing has to be better, but it is very important that we have a strong motivation for why something will benefit customers.
Another key part about the hypothesis is to understand the conventional wisdom around this area, especially as it relates to the target customer segment (end-user, enthusiast, PC maker, etc.) The conventional wisdom covers both the understanding of how/why a feature is a specific way today and also if there is a community view of how something should be solved. There are many historic examples where the conventional wisdom was very strong and that was something that had to be considered in the design or something that had to be considered knowing the design was not going to take this into account—a famous example is the role of keyboard shortcuts in menus that the “DOS” world felt would be required (because not every PC had a mouse) but on the Mac were “unnecessary” because there was always a mouse. Conventional wisdom in the DOS world was that a mouse was optional.
For any hypothesis, there are numerous design alternatives. It is at this stage where we cast a broad net to explore various options. We sketch, write scenarios, story board, do wireframes and generate prototypes in varying fidelity. Along the way we are working to identify not just the “best answer” but to tease out the heart and soul of the problem and use the divergent perspectives to feed into the next step of validation.
This is a really fun part of the design process. If you walk our hallways you might see all sorts of alternatives in posters on the walls, or you might catch a program manager or designer with a variety of functional prototypes (PowerPoint is a great UI design tool for scenarios and click-thrus that balance time to create with fidelity, and Visio is pretty cool for this as well) or our designers often mock up very realistic prototypes we can thoroughly test in the lab.
With a pile of options in front of us we then take the next step of interpreting our own opinions, usability test data and external (to the team) feedback. This is the area where we end up in conversations that, as an example, could go something like this… “Option ‘A’ is better at elevating the discovery of a new feature, but option ‘B’ has a stronger sense of integration into the overall user experience”.
As we all know, at the micro level you can often find a perfect solution to a specific problem. But when you consider the macro level you start to see the pros and cons of any given solution. It is why we have to be very careful not to fall into the trap of a “tests”. The trap here is that it is not often possible to test a feature within the full context of usage, but only within the context of a specific set of scenarios. You can’t test how a feature relates to all potential scenarios or usages while also getting rich feedback on intent. This is why designing tests and interpreting the results is such a key part of the overall UX effort led by our researchers.
A mathematic way of looking at this is the “local min” versus a “global min”. A local min is one you find if you happen to start optimizing at the wrong spot on the curve. A good example of this in software is when faced with a usability challenge you develop a new control or new UI widget. It seems perfectly rational and often will test very well, especially if the task asked of the subject is to wiggle the widget appropriately. However, what we’re after is a global optimization where one can see that the potential costs (in code, quality, and usability) of another widget by erase any potential benefits gained by introducing a new widget. Much has been written about the role of decision theory as it relates to choosing between options, but our challenge with design is the preponderance of qualitative elements.
Ultimately we must pick a design and that choice is informed by the full spectrum of data, qualitative and quantitative.
Given a choice for a design and an understanding of how to implement it and the cost, there is still one more choice—should we do the feature at all. It sounds strange that we would go through all this work and then still maybe not build a specific feature. But like a movie director that shoots a scene that ends up on the cutting room floor, sometimes the design didn’t pan out as we had hoped, sometimes we were not able to develop an implementation plan within reason, or sometimes there were other ideas that just seemed better. And this is all before we get to the implementation, which as Larry pointed out has challenges as well.
We have two tools we use to assist us in prioritizing features and designs. First is the product plan—the plan says at a high level what we “require” the product to achieve in terms of scenarios, business goals, schedule, and so on. Most of the time features don’t make it all the way through prototyping and testing because they just aren’t going to be consistent with the overall goals of the release. These goals are important otherwise a product doesn’t “hang together” and runs the risk of feeling like a “bunch of features”. These high level goals inform us quite a bit in terms of what code we touch and what scenarios we consider for a release.
And second we have the “principles of design” for the release. These principles represent the language or vocabulary we use. These represent the core values—we often think of the design principles as anthropomorphizing the product—“if Windows were a person then it would be…”. This is the topic of Sam’s talk at the PDC.
As mentioned in the introduction, it isn’t possible to do everything twice. We do have to decide. This could be a whole series of posts—customization, compatibility modes, and so on. We definitely hear folks on these topics and always do tons of work to enable both “tweaking” and “staying put” and at the same time we need to balance these goals with the goals of providing a robust and performant platform and also moving the OS forward. Some of us were involved in Office 2007 and there is a fun case study done by Harvard Business School [note fee associated with retrieving the full text] about the decision to (or not to) provide a “compatibility mode” for Office 2007. This was a choice that was difficult at the time and a few folks have even mentioned it in some comments.
Finally, we build and iterate to refine the chosen solution. Inevitably there are new discoveries in the implementation phase and we adjust accordingly. As we integrate the solution into its place in Windows, that discovery continues. The beta period is a good example of how we continue to expand and learn from usage and feedback. In a Windows beta we are particularly interested in compatibility and real-world performance as those are two aspects of the design that are difficult to validate without the breadth of usage we can get if we do a great beta.
It is important to keep in mind that we follow intensely all the feedback we receive from all forms—reviews, blogs, and of course all the telemetry about how the product is used (realizing that the beta is a select group of people).
One of the things we hope to do with the blog, as you might have seen on the IE 8 Blog, is to discuss the evolution of the product in real-time. We’re getting close to this transition and are looking forward to talking more about the design choices we made!
-- Sam, Brad, and Julie
Are these comments moderated? I ask because I read this post when it first went up and there were no comments on it, and I signed in and commented. When I didn't see my comment show up, I tried again. After that, I just assumed you weren't accepting comments or something.
For what it's worth let me just mention a couple of things I'd tried to say:
Customization introduces too much complication for developers and users alike for many features, but I believe the Start Menu is an exception. Some nice options are already there (link vs flyout menus, folders like Control Panel, etc) but I think it's been a big mistake that we're limited to Documents and Music and so on for what folders can be shown here. I think it is important to allow us to put different user folders, maybe mapped drives, maybe search folders. I love how extensible the taskbar already is and I know you're doing great work there for 7, but look for other little places like the Start Menu where it is not clear why our options are so fixed.
A week and we see what is behind W7 and it is where the public start talking about W7 and blogging about it ;).
first thing to say: I enjoy reading this blog. So thanks for it!
Although I'm using Vista for over a Year now, and I'm very pleased with it, there are some things I'd like to see in Win7.
The first thing is from a developers view: Windows has got a lot of powerfull APIs, but as a .Net Developer a lot of them are not easy to use: there are no managed APIs for them. I hope, as the .Net Framework evolves, it will include more and more APIs, so the need of doing dll imports will slowly fade away.
As a developer, I think the .Net Framework is important for Windows as a platform.
Another thing is that I'd like to see Windows using more WPF. When I see videos of some Longhorn Builds, I get "knocked of my socks" by the effects. Some of them are really great, for example in the explorer. It would be great if some of them return in Windows 7.
But there's always a balance to make between "eye candy" and performance. I wonder wether the animations / wpf-based explorer was cut off because of performance issues.
Performance improvements should be a big issue for ALL new Windows Versions. I don't think Windows itself is using too much performance, it's more about offering better performance for applications (by better scheduling, and so on).
Yet another great post! Thank you very much!
I'm sure it must be tiring to read all those nonsense "put Vista in a virtual box", "let's get rid of the registry" or "we need MinWin" (both comments show a serious lack of understanding of Windows, MinWin and what those features would mean in practice). I hope my comments are more valuable.
If you really want to hear comments on how to improve Windows: Make it easier for everyone to comment. Add a "Show us how to improve Windows"-application that let's everyone record video screen captures, comment and submit them. You could rate users (to get rid of the noise), categorize requests, .... The "Was this Information helpful?" questions in Office message boxes are another way to achieve something similar.
I once heard that there was a MS-internal widget that shows a random rant that was sent to firstname.lastname@example.org. Is that true?
All I hope for personally is that Win7 looks more polished (no flickering when resizing, fade-in that always fades in after login, no flickering when moving gadgets on the sidebar, ...) and runs faster (less IO).
I really, really can't understand why the registry can't be fixed by using an SQL database, it could be a MS-SQLite.
In the first instance you could just use a couple of tables to implement the "tree" structure, and another table for the key/value pairs. A bit of normalization, easy.
Just add in a few more tables to note the exe that created the key, and purging the tables would be simple, and it gives the place to implement a "read only" and flag.a
Using a SQL dB, if properly done could allow a remote DB to be used on a managed network (corporate, educational or cafe).
Also, when using in a client-server environment, a redo log could speed up profile access if no SQL database is at hand.
Another useful feature of a server based SQL registry is it could, in theory at least, be shared over machines:
you could be logged in in multiple places and your stuff would be shared instantly.
> I'm sure it must be tiring to read all those
> nonsense "put Vista in a virtual box", "let's
> get rid of the registry" or "we need MinWin"
> (both comments show a serious lack of
> understanding of Windows, MinWin and what
> those features would mean in practice).
> I hope my comments are more valuable.
well, it's possible to leave situation like is & having compatibility with 100% of apps. Market found weaknesses of Windows architecture in Vista, will do it again. there will be many USD required for advertisements.
it's also possible to implement somehow these "nonsences" and things like total uninstalling applications & making them more secure will be possible... (World and MS) programmers will have possibility to forget about these problems (at least partially) and will have time for implementing new features...
this is situation like with win311 or win9x -> it wasn't to do some new features in old architecture, there were required changes.
This UI stuff is fascinating, I particularly appreciate the depth you are going to. I wonder if you'll be moving down the stack and covering any kernel-mode topics in the future?
Sounds like a complex process you go through to decide new features, which I guess when you consider the number of users you will have an effect on - that's a good thing. If only our governments planned stuff like that :)
> shared Registry is big problem in Windows. Install MS Office - thousands of entries, add few apps - many other. try to uninstall them and many entries will be still there. is it OK ? I don't think so...
It is indeed ok. User settings are data and should not be removed on uninstallation. Why would you think otherwise?
> only some parts of Registry will be shared (for example info about devices or extensions handling). when application X will want to see settings from application Y, will need special user permission.
What you are basically asking for is per-application permissions. This a common mistake caused by misunderstanding the Windows security model.
> the same, when application tries to save something to system directory, it should go into virtual directory for example in Program Files. no more writing to real system directory or winsxs.
What do you define as an application? Many applications, installers an important example, spawn multiple processes. One process creates a file, another reads it, does not find it, crashes.
> both solutions are kind of virtualization. already implemented (see sandboxie for example), don't need a lot of memory. How many current apps will work with it ? 90% ?
Breaking 10% of applications is, of course, completely unacceptable.
Great work guys. Looking forward to Win7. By the sound of things Win7 will be the greatest OS to come our of redmond to date.
I realize this isn't the same kind of design, but I must say PLEASE PLEASE change the look of the Vista Basic scheme for Win7.
I realize it was basically designed to punish people that get the low-cost version of Vista, but I see it way too often while running Vista Business. Not to mention that tons of screenshots used in reviews have it as well (due to reviewers running Vista in virtualization), so it's hurting you from a marketing standpoint as well.
The Vista/XP theme used by the Windows Live apps on XP, as well as Google Chrome on XP, is MUCH better looking. PLEASE switch over to this or something better looking for "Seven Basic" or whatever.
It's much better for everyone.
An interesting (if quite wordy!) post.
I'm curious to see if these 'principles of design' were inspired by J. Harris' Office UI team and their 'Design Tenets' that produced Office 2007's Ribbon.
Office 2007 was possibly one of the best Microsoft products released to date and being able to duplicate that success would definitely do Windows good.
Will be tuning in to the PDC webcasts to find out!
@Nidonocu -- I'm sure Jensen appreciate the notice :-) For every project we always start with a set of principles (or more than one). It just depends on the project as to whether they are design focused, architecture focused, or some combination. For example way way back when we were making the Microsoft Foundation Classes 1.0 we had key design/architecture principles: (1) If there is a Windows API then use it, (2) Do not duplicate Windows state, (3) We ship our source code, and (4) We're building a C++ class library not a C++ compiler test suite [so don't use every nifty new C++ language feature for kicks]. Well something like that---it has been a *long* time.
So when we did Office 2007 we had principles as well :-)
@briantist and folks asking about the registry...We understand the challenges people see with the registry. I don't think I can do the whole topic justice in a comment though. However, Raymond has touched on this many times in his blog and there is one thread in particular that I find helpful to look at when discussing the topic of registry v. text files v. database. There's lots of good content and comments and responses and so on... see http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx.
@d_e -- Windows Vista had some of this type of feedback mechanism in the beta and today we pay close attention to telemetry we have spoken about and also to all the questions asked through the help system. You often will see new articles written because of the volume of questions we receive on a topic.
Stay tuned for the expansion of the tools we will have for beta testers to provide feedback on Windows 7.
3700 Words?! This is nuts guys. I also have to agree with bobharvey. Did anybody think of a post that describes an actual example of some feature. So that people know exactly what's going on.
I would suggest there be a Windows Dev blog. Not tied to any specific release. Just an ongoing blog about whatever the devs think people should know, or want to get direct "focus group" type feedback on. For more than a year after Vista's release Microsoft refused to talk about what was next. That should never happen again. This blog should always be a place to go to see what is 6+ months down the line.
All this "Welcome to the windows development process" while interesting from a conceptual level, is nothing really meaningful, or usefully transparent.