Bit-cycling : Windows Vista

Castle and HomeGroup: A study in the evolution of user needs

justsean — Fri, 16 Jan 2009 13:34:54 GMT

Several years ago, at the beginning of the “Longhorn” project (which eventually became Windows Vista), I worked on a project that was attempting to solve the problem of how to make file sharing in small networks (particularly at home) both simple and secure – something that, frankly, Windows has been working for a long time.

I worked with a small team of architects from across Windows to develop a technical concept that was eventually codenamed Castle†. Castle eventually became a fairly major project in Longhorn. Details of this project have trickled over the years, but since it never shipped in any usable form, it’s not widely known or understood, though some have tried to figure it out.

The Castle idea

Castle was based on the idea of creating a small network (typically in a home environment) with a shared concept of user accounts. In typical home networks, the main gating factor in a simple, secure sharing model is that the PCs each have their own idea of the users – a user on one PC doesn’t even “exist” on the other PCs. Earlier versions of Windows have approached this by having a password-based sharing model (the user create a password, and tells it to other people who want to get stuff from their PC), or having a completely open sharing model (put something in a particular folder, and anyone on your local network can get to it).

With Castle, the user accounts were shared with all PCs, with changes made to the user account information on one PC replicated to the other PCs automatically. A user on one PC could share pictures with the other members, and, using standard permissions model, make decisions about who could see what. Any single user could also log on on any of the other PCs using their own account (with replicated settings, of course). The advantage of this model from a technical perspective was that it would take advantage of all of the security and file sharing features that users in a corporate domain have used for years.

The interesting* thing about Castle, however, was that it was built around a model of home networks that assumed that, for the most part, home PCs were shared by users in the home. At the time (early 2002), home networks were uncommon, but were growing in usage, but typically, they were an extension of the home PC – two or three PCs shared by the users of the home, occasionally with one or more them primarily used by one person.

On HomeGroup

Contrast the model of Castle with this description of observations from the HomeGroup post on the Engineering 7 blog:

A majority of the computers in our panel only had one primary user. While we all know that laptop sales have overtaken desktop sales in the last couple of years, this data tells us that people are buying PCs more for specific people rather than for a shared location [emphasis mine].

HomeGroup is solving the same things that Castle was trying to solve – simple and secure sharing of documents, media and devices. But, this simple shift in the dynamics of home networks from shared PCs to single-owner PCs suggests a change in the solution. Instead of attempting to create a shared concept of user accounts, HomeGroup assumes a network of “equals and peers”, and uses the concept of a single shared password (a well-chosen analogy in the E7 blog compares this to the concept of the front-door key in a home) to build a trust relationship between the home PCs on top of which the media sharing, libraries and search features are layered.

Evolution of ideas

Some have postulated that HomeGroup is basically dusting off and shipping Castle. I’m not part of the team building HomeGroup (nor was I part of the Castle team at the end – I had switched focus to Wireless and Bluetooth projects and handed off the project to another team), but the Castle project ultimately died as a victim of the Longhorn reset in 2004 – at its height, it had grown to be a joint project of at least four different Windows teams. Like HomeGroup and its integration with Win7 technologies, Castle had pieces that depended on WinFS and other Longhorn technologies that never shipped in any form. It’s highly unlikely, given the different fundamental directions of Castle and HomeGroup, that they share any code.

In a world of single-owner PCs, Castle would, frankly have been overkill. If Castle had existed, the current HomeGroup concept could have been built on the base framework, but instead, like much of Windows 7, HomeGroup is a simpler, easier-to-use solution to the same fundamental problem Castle was trying to solve. HomeGroup was most likely built from scratch and integrated with other Windows 7 concepts and technologies (NLA, Libraries, Media Player sharing).

What the Castle and HomeGroup projects ultimately did share was the desire to make home sharing simple and secure‡ that Windows teams have been trying to solve for years. I don’t have enough PCs with Win7 at home yet to fully try out the HomeGroup feature, but from everything I’ve seen, the team seems to have delivered a simple and effective solution to the problem we set out to solve over six years ago.

Windows 7 seems to be, yet again, living up to the promise of Windows Vista.

/fin..

† On naming: One early set of notes I still have that was written by one of the technical architects, Richard Ward (currently a Microsoft Distinguished Engineer in the Windows Core Architecture group), used the term “Minidomain.” I toyed with the codename “dominion” -- a play on “mini domain” – but it didn’t really catch on. The idea for the final codename originated with Andrew Sinclair, the GPM of my team at the time (currently General Manager of Hosted Exchange) and one of the inventors of the Castle concept, who opined, in his typically British way, during brainstorming, “A man’s home is his castle.”

I wrote most of the early scenario documents related to the project (used to flesh out and sell the concept), which made it easy for me to be the one to choose the codename. I latched onto the word “castle” from Andrew’s quip, which worked since it had the same medieval echoes of its technological ancestor, the Windows Server domain (a domain is a Windows enterprise concept of centrally administrated network systems). It was also a perfect analogy for what we were trying to build – a wall of protection around a set of PCs.

As a side note, we did spend quite a bit of time brainstorming with marketing about a branded name to use in the product. I had a moment of panic when, in one of these meetings, the marketing team got quite excited when I jokingly tossed out the name “workgroup .net” – the term “.net” was making the rounds in the company as the popular term to add to things, and Castle was, as HomeGroup is, an evolution of the long-existing idea of a workgroup. I think we can all breathe a sigh of relief that the “.net” fad has run its course.

* There were plenty of interesting things about Castle, for what it’s worth. Castle was, as was typical of Longhorn-era projects, quite ambitious. In my first scenario documents that I used to popularize the idea around the company, I had designs not only for simple and secure file sharing (the primary goal), but also for ways to potentially revolutionize concepts like application installs (install an app on one PC, and, via the secure mechanisms we were developing, we could replicate the application and its settings to the same user account on all of the PCs in the home, making it easy, as a user to move from one PC to another – obviously this would have required changes to the way apps were licensed, but we had a number of ideas for how to, for example, allow a user to use the app on only one PC at a time). I talked with the Windows Update team about using the Castle framework to distribute patches within the home after one system downloads them (patch distribution has be done via a secure distribution because systems basically install them automatically, so if someone can insert bad code that would be a bad thing). I also spent some time with the media player DRM team on techniques to automatically license downloaded music to all PCs in the home. We didn’t really plan to ship all of this in Longhorn, but we wanted to to lay a foundation for building features and applications in future versions of Windows that could rely on a secure, trusted home network.

‡Simple and secure – I harp on this phrase, because it’s relatively straightforward to make home sharing simple, and other products have made strides in that direction. It’s also easy to make home sharing secure – just lock everything down :). It’s a real challenge to bridge both concepts.

Surfing through my phone – Windows Vista and Windows Mobile

justsean — Thu, 07 Aug 2008 00:03:18 GMT

A long time ago when I worked on Windows XP, I worked on a project to add Bluetooth PAN support to Windows. At the time (March 2004), I wrote:

We also added Bluetooth Personal Area Networking (PAN) support. PAN is a Bluetooth profile that essentially creates a standard IP network over a Bluetooth connection. PAN support is the first step to enabling rich Bluetooth networking scenarios, which can be secured using the well-tested IP-based security standards (IPSec, 802.1x, etc.). Devices supporting the PAN profile are already on the market, and there should be many more in the coming year (demand it from your vendor!).

Well, it took a while (I didn’t quite demand it from my vendor), but I finally got a phone that supports Bluetooth PAN earlier this year, specifically, the HTC Hermes, or the AT&T 8525, as it’s known. It runs Windows Mobile 6.1 (I think it comes with 6.0, but I upgraded). I like this device because it has a full keyboard, as well as a touch screen, which is handy for use with the Live Search mapping software.

Windows Mobile 6 comes with an application called Internet Sharing, which enables the Internet pass-through. I’ll let you use one of the many instructional sites on the web to do it yourself. Side note: that article I linked to talks about how to use your phone as a “modem”, which is not strictly correct – there are two Bluetooth profiles, one that lets your phone look like a modem and one that makes it look like a network router. This technique sets up your phone to look like a router, which allows the full networking stack to come into play and is ultimately more efficient (plus you don’t need to dial into an ISP – you just use the phone’s Internet connection).

All of the UI I designed in Windows XP is unchanged in Windows Vista, which was nice for me, since I never used it in the real world on XP. It was clearly not an area that was invested in for Windows Vista, in part, I’m sure, due the fact that it was rarely useable at the time, since most people’s phones didn’t support it. As more and more phones start to support Bluetooth network passthrough, I expect it’ll get some cleanup and better integration into the rest of the experience.

I have to admit, I cringe a little when I look at that UI, but given the constraints I was under at the time, I’m not completely embarrassed by it. A lot of what I was doing, as the owner of the user experience, was attempting to build a usable experience on top of a technology that was overwhelmingly technical and complicated. I’m not sure I completely succeeded in this case, but I think it might have been much worse :).

Once connected, the experience using the passthrough is pretty smooth. It’s completely unnoticeable to any of the applications I use and with the AT&T 3G network (unlimited data plan required for this activity :), it’s slow, but very usable. I can surf, have Outlook sync’ing the background, and have a remote desktop connection open to a system at home without any real problems. I tend to use it at the airport or at a coffee shop when I don’t want to pay for Wi-Fi. It can suck battery life from the phone, so I try to keep usage limited unless I know I’m going somewhere where I can charge the phone – but I have gotten at least two hours out of a fully charged phone without fully draining the battery.

A laptop that makes me grin – Lenovo Thinkpad X300

justsean — Wed, 06 Aug 2008 08:26:47 GMT

About a month ago (shortly after joining a new team), I upgraded laptops at work. For the first time in my Microsoft career, I selected a non-Toshiba laptop, choosing the ridiculously small delight of the Lenovo ThinkPad X300. Yes, that would be the 3.5 pound, 0.73 inch thick, 13.3 inch widescreen, boot-to-desktop-in-25 seconds (5 seconds from sleep), star of the following video (with credit to Miladin for first discovering it).

I do like the mini-ad campaign Lenovo ran (only) online that ended with: “Everything else is hot air.” I appreciate a good solid poke.

This is the first laptop in a long time that has made me grin idiotically when I first used it. It weighs nothing (the monstrosities in common use by my peers make my wrists hurt just to look at them), looks great, and runs like the wind. I’ll pen a few thoughts on Vista itself in a future post.

One caveat: Lenovo needs to learn how to leave things out. The keyboard is a serious victim of an unwillingness to compromise. It includes every single key that you’d find on a full-size keyboard, including, the completely useless ScrLk and Pause keys (I challenge anyone under 30 to tell me what those keys ever did). They also include both a trackpoint and a touchpad. Now, since I love trackpoints (they take time to get used to, but they are far faster and more precise than touch pads), I appreciate having it, but I’d be willing to deal with the touchpad if they left it out (and in particular, if they used some of the saved space to make it bigger).

All in all, it’s an amazing laptop – if you can afford it (or you can convince someone to buy it for you), I highly recommend it.

Vista DST coolness

justsean — Tue, 06 Mar 2007 18:32:00 GMT

Blah, blah, blah, Daylight Saving Time is changing... Yawn.

This, however, is very cool mini-feature in the Vista clock (click on your clock on the tray).

One thing I like about Vista is the tiny little features that add up to a great experience.

Windows and Office Launch Video

justsean — Sat, 17 Feb 2007 02:09:44 GMT

I like this one, too.

On names and codenames...

justsean — Fri, 09 Feb 2007 20:02:57 GMT

The naming of products at Microsoft is something that never ceases to fascinate the world.

The latest thing to get the blogosphere's proverbial knickers in a twist is the re-renaming of Windows Live Mail to Windows Live Hotmail. Well, guess what... I actually have no opinion on this re-rename. Why? Because while Live Mail is orders of magnitude better than Hotmail Classic, it's still not overly imaginative as a product. So, until the product is something I can really get excited about, it doesn't really matter what it's called.

Note: I did have a very strong opinion about the renaming of Windows Live Local to Windows Live Maps.I won't go into the details, but let's just say I'm a lot happier with the new name.

Anyway, on to my real topic: codenames.

Over on InsideMicrosoft, Nathan Weinberg wrote an post recently, titled "Sinofsky's on to something: Codenames must die." He discusses the "problem" with codenames in some detail, and proposes a solution:

Microsoft has this problem all the time. People are still referring to Windows codename: Longhorn today, even though the final name of Vista was announced 18 months ago, and that Vista is nearly a completely separate project from Longhorn. Windows Mobile 6.0 is probably going to be called “Crossbow” for the next year or so. Many analysts and Microsoft employees have complained of products that have better codenames than final brand names. The next version of Windows is on its third codename, first BlackComb, then Vienna, now Windows 7.

I honestly don't understand this railing against codenames. Who cares? So what if the digerati are still referring to it as "Longhorn" or "Crossbow." It really doesn't matter.

How about the people who still refer to Mac OS X 10.4 as Tiger, and to the previous one as Jaguar? (In fact, Apple had some fun with the box art for Mac OS X 10.3). Or what about the code name for OS/2 3.0, "Warp" (from a long history of Star Trek related OS/2 codenames), which eventually became a part of the product name.

Do you really think, for example, that if Vista had been called "Windows 6" during the development, the problem that "Vista is nearly a completely separate project from Longhorn" would have been avoided? We would still have had PDC03 at which we told people about the amazing new things in Win6, and then we would have dropped it all and replaced it with new amazing thing by PDC05. Nothing about the codename helped or hindered in that scenario. And for what it's worth, Longhorn was the codename for Vista for a long time after the event known as the "Longhorn reset" (all we did was start referring to the version prior to the reset as "Alpha Longhorn."

In fact, the codename thing can often be a savior, because if too much "baggage" gets attached to one codename, you can drop it and start fresh. This happens over, and over again. Blackcomb became associated in people's minds as "the next big release" and teams would start planning the grand new projects they would deliver in Blackcomb. So jettisoning the codename and picking another was the only sane idea.

Or, how about Kodiak -- the version of Exchange that would switch to using Yukon (the product eventually known as SQL Server 2005) as its datastore? That name was tightly focused on the SQL Server datastore project (not the least because Kodiak is a town in Alaska located fairly close to the Canadian territory of Yukon), so being able to jettison the name (and the associated baggage) and move to another is a good thing. What if it had been called E8 -- would that have helped, or would Exchange be getting the same heat that Windows gets about the difference between the early visions of Longhorn and the later visions of Longhorn?

In short, it really doesn't matter what you call your product. No matter what you name it, it get a set of attributes attached to it as visions turn into plans and plans turn into code. When we rename Windows 7 as Windows Coffeetable (you heard it here first, folks), there will still be tons of people calling it Windows 7. It's just a habit. 2 years later -- it won't matter any more. So, just pick something, and move on.

As a minor anecdote, a short time after we started working on IE7, there was an effort afoot to come up with a codename for IE7. In particular, we wanted a codename-series (a series of codenames related in some way: Whistler, Longhorn, Blackcomb (Windows); Platinum, Mercury, Titanium (Exchange); etc.).

Eventually, we settled on beach-related codenames (because that's where people surf -- get it?), and the name Rincon was selected for IE7. Rincon is a famous surfing beach in Puerto Rico, which has a famous road leading to -- the roadsign is here, so you can see for yourself why it was attractive. :) I believe Tony was responsible for that one. Random trivia: the codename for the version after Rincon was going to be Maui (this was "decided" a year before IE7 even shipped).

Well, as it happened, it never stuck. IE7 had been used internally as the name for so long that we never really got any momentum behind it. I offered to be the champion for the name, but only as long as management agreed to take the team to the associated beach when each product was done. That one didn't fly.

Oh, well. At least IE is already ahead of the game on the current "productname + number" naming scheme trend that Sinofsky favors.

And the reason we don't shout this from the rooftops is...?

justsean — Thu, 11 Jan 2007 23:39:36 GMT

So, apparently, the Origami team working on UI for the Ultra-mobile PC (UMPC) form-factor (sexy name, eh), have been working hard on new experiences.

Apparently, it's been called by some "the best software I've seen at CES."

I have to admit, it looks damn cool. What I don't understand is why we're not shouting this from the rooftops? There was not a sniff of this in Bill's keynote (instead, we got the tour of the futuristic bustop). What's aggravating is that we made a big splash when it was first announced and got criticized for being "just" Windows XP Tablet Edition with some tweaks and a "touch pack" update, and for the expense and low battery life. Now, when we're releasing updates that address these issues, we choose to go under the radar?

Anyway, see the pictures and demos on the team's blog: http://origamiproject.com/blogs/team_blog/archive/2007/01/09/15189.aspx

Musings on Consistency in OS Design

justsean — Wed, 07 Apr 2004 10:28:00 GMT

I'm a bit behind in my browsing and posting, but I wanted to note that Pierre Igot has posted parts 2 & 3 of the Mac OS X Hall of Shame. I take these articles as object lessons -- examples of things I wouldn't want to repeat, and an opportunity to get a different perspective.

In part 2, Pierre starts off with a discussion of the dock's bouncing behaviour (I believe the best description was “like a Jack Russell f**ing Terrier”). Now, dock bouncing aside, there's a thread that runs through Pierre's examples in this installation of the Hall of Shame: consistency. “Huh?” I hear you say, “I can see that the last one is all about consistency, but the first two?” Well, here's where college classes in literary criticism (“lit-crit”) come into play -- the fine art of extracting a theme from a text when you're 99% sure the original author never intended that theme to exist. Bear with me.

An operating system is many things. A kernel, a collection of device drivers (even “poorly debugged” ones), a couple of APIs here and there, sure, those are good. But to a user (remember them?), what is it that an OS does for them? For the purposes of this discussion, I shall postulate that an operating system is a promise of consistency.

Let's start with the obvious one: consistency in interaction. Pierre's third example covers this very well (look, if you haven't read the article, you better go do so, and come back. I'll wait... okay, welcome back.). When I sit down in front of an app on Windows, I expect to be able to select some text and hit Ctrl-X to cut it, and Ctrl-V to paste it. If those don't work, I'm pretty ticked. All of my “learned behaviours” are out the window. I have to spend some time to learn how the new app does things that every other app does. Well, unless that app is more-or-less indispensable, it's going to find its way off my PC pretty darn fast.

This sort of functional consistency is everywhere and is key to the overall experience. This consistency is part of what it means to be a “Windows app” or to be be “Mac-like” (violating this notion is the great sin that Word 6.0 for Mac was -- apparently rightly -- accused of committing).

Windows, like everything else, has some issues here. This past Christmas I was watching my mother navigate her way around Windows. The most fundamental thing she had a problem with was knowing when to single-click and when to double-click. I developed a rule for her to use: Put the mouse over the object. If the object, or the mouse, reacts (changes colour, highlights, looks like a button, gets an underline), then click it once. If it doesn't, double-click. For the most part this works, but frankly it's a lame rule (and in list boxes, for instance, it isn't foolproof).

The point though, is that the operating system has a fundamental responsibility to establish the rules of consistency, to document them both in words (Style Guides) and deeds (internally applying the rules across the components of the operating system). An amazing number of OS developers (from all camps) don't even realise that they have this responsibility. Windows hasn't lived up to the responsibility particularly well. The Windows Style Guide hasn't been given the attention it deserves, and hasn't really been updated for Windows XP (not to mention, it's really hard to find). Across the Windows components, you'll find lots similar things that aren't consistently implemented.

Occasionally, this responsibility for documenting consistency is explicitly shirked, as in the first Hall exhibit of Pierre's article, wherein he notes that Apple developers have said (paraphrasing) that it is up to application developers to choose how they interact with the OS X dock. That may be true, but the OS components define the standard, and its difficult for anyone to do something different. Often, application developers assume that if the OS does something some way, then it's the right way -- I mean, they must have done tons of usability studies, right? It sometimes takes a certain confidence in oneself to do something differently from the way the OS does it. Additionally, the OS often provides support in the core APIs for doing things in a certain way, and doing things a different way becomes harder, and really, who cares if the dock icon bounces like a deranged puppy dog -- it gets their attention doesn't it? (Hmmm... one day, I'll post about the OS's putative responsibility to protect users from over-aggressive programs. Stay tuned).

Consistency, however, extends into another realm. Not only do users expect a program to open when they double-click on its icon, but they expect it to open every time. They expect that if they carefully formatted a document and saved it, it will look the same way when they open the document the next time. In CS classes, we called this “deterministic behaviour”. Fundamentally, the user has a defined a mental model of “the way things should work” and they expect that the OS will conform to that model. The model was formed by a combination of the “promises” that the system gave them, and subsequent observation. One key promise that a modern OS gives it that when an update is installed, it will fix problems, not create new ones (aha, I bet you were wondering how I'd get Pierre's final item into this discussion). When updates do not perform as expected, they break the consistency model and users are clearly dissatisfied. Interestingly, a broken update breaks two separate consistency models: the “updates shall do no damage” model and the model of whatever functionality was broken by the bad update.

One way to think about this consistency issue is to use what psychologists call a cognitive model -- a model for how people think about things (disclaimer: I am not a psychologist by any stretch of the imagination, so I'm probably going bastardize the concept). Think of how people use a computer as the building of a set of rules: given a set of conditions and actions, expect a certain result. These can be very abstract: if I put a mouse over an object and it react, single-click on it. Or they can be very specific: when I'm in notepad, if I need to see the status bar, I have to turn off “word wrap”. Obviously, the more abstract a rule is, the more situations it can be used in. Now the user's objective (and the designers) should be to keep the ruleset as small as possible, and hence, to provide more abstract rules than specific rules. The smaller the rule set, the easier it is for people to learn, and to use the system. If a user can apply a set of rules learned elsewhere, all the better. The first trick is getting people to learn a rule -- sometimes this is by explicitly stating it, or simply by consistently applying the rule and having the user learn it by experience. The other trick is get the right rules -- the most productive or most positive rules. For example, if a user applies a system update, and it hangs the system, they've learnt a rule: never apply system updates. Not exactly the rule that was intended...

Microsoft has felt the brunt of this kind of adverse rule-building recently. A few bad patches over the past few years have created a reputation in some areas that we're unable to consistently deliver solid patches. Now, when, because of widespread security attacks, we need people to be patched, some don't trust us and resist, thereby putting themselves in danger.

So, in the final analysis, we learn why consistency is truly valuable: trust. Consistency breeds trust. And trust is, ultimately, what we as OS developers need from our users, and what, frankly, we as Windows developers, don't have enough of.

Now... aren't you eager to find out about the theme of Part 3? Well, I'll save that for another post, but I'll give you a teaser: it's a different aspect of consistency... namely, “Compatibility and the Art of Rebuilding a Road”.

And introducing...

justsean — Fri, 09 Jan 2004 13:42:00 GMT

Alright, so I’m blogging. I’m Sean Lyndersay, and I’m a lead Program Manager on the Network Experience team in Windows (at Microsoft). What’s that mean? I don’t know either, but it sounds good, so I’m going to stick with it. Maybe I’ll explain it later. If anyone cares.

Anyway, I’m out here… trying out this blogging thing, seeing if it can be useful to me, and ultimately to you, the end-user. That’s right – I’m trying to get something useful out of this. Most people who blog seem to have something witty and intelligent to say to the world. Not me. I’m just here to see if this is a useful tool for getting in touch with people that it’s otherwise near impossible to have a dialog with.

You see, what I do is simultaneously one of the easiest and hardest (at least, imho, and, considering this is my blog, my opinion’s all that counts :) things to do in the world. I build UI. That’s “user interfaces.” Or, in the current lingo, I design “User Experiences” (short form: UX). Now, as a minor aside, I like the term “experience” because it does a great job of bringing together the intangibles of UI design, but since the release of Windows XP, the proliferation of the term “experience” (and in particular, it’s rarely-seen-outside-of-Microsoft plural form) comes dangerously close to the being another “Active-“, “Intelli-“, “Direct-“ or, more recently, “.Net”.

Back to my point (yes, I had one)… My goal is to build UI that I can be proud of. And that means UI that is “great” to everyone who uses it. Of course, that definition is completely arbitrary (and that is the topic of a completely separate entry). To do that, I need feedback, suggestions, and smacks on the head. I need people to say, “this sucks” or “that doesn’t suck”, or “what in heck is that supposed to mean?” and especially, “what were you thinking?”

So, with this blog, I’m going to try an experiment. A dialog, if you will (and yes, the pun is intended). I’m going to openly discuss the UI (specifically, the Networking UI) of Windows, starting with some new stuff we’ve introduced in the beta of Service Pack 2 for Windows XP.

If you reading this – first, I have no idea why you are, but thanks! – then, this is an opportunity to get involved. I hope this will be a great success and together, we can make sure Windows networking is “great” for you, and millions of other users.

Before I’m finished, since this is a litigious society, I’m going to include a little disclaimer. Come to think of it, I may attach to the page on the whole. I’ve borrowed it from the MS “wish” site, so it gets the point across, I think:

By offering suggestions through this page, you give Microsoft full permission to use them freely. We can't guarantee we will use your suggestions, but we will review them for use in future products. Due to the volume and variety of suggestions, we can't provide compensation or personal responses to each suggestion.

So there.

But seriously, I’m not out here to steal people’s ideas. I’m out here to make Windows better for everyone who uses it. If you have an idea you don’t want me to know about it – don’t post it.

Sean