You're probably wondering what took me so long.
It's a valid question. The last part of this review appeared in late December 2003, over two months ago. The truth is, I've written other parts of this review, but I wrote them out of order, which seemed like a great idea at the time. And then, in early February, on a trip to Denver with my wife in a cramped coach seat, I had another great idea: Since I had to review a Palm wireless keyboard anyway, I'd write part of my Longhorn review on my Palm Tungsten T, and kill two birds with one stone. With the new keyboard unfolded, I set to work, and wrote for over an hour, becoming increasingly impressed with the feel and performance of the device, and how well it worked even in the cramped environment I was enduring. Then, the Palm moved a bit, lost its connection to the keyboard, and promptly froze up. After an increasingly impatient attempt to revive it without destroying my document, I had to reset the device. And here's the kicker: I hadn't saved my work, not even once. Can you believe I would make such a rookie mistake?
Yeah, I'm an idiot. (So much for my "technology has never betrayed me" mantra.) I lost over an hour of work, and effectively killed my Longhorn build 4051 review work-in-progress. I tried, and tried, but I just couldn't get back into it again. Heck, I had already written the damnable thing. But here we are, almost mid-March, and I'm trying again. The good news is that the next few parts should come more quickly because, as I noted before, they're already largely written. And yeah, this time I actually backed up.
Enough of my tomfoolery. Let's get moving.
When we last left our intrepid little perpetually delayed operating system--Windows Longhorn--in late 2003, build 4051 was still pretty fresh in most people's minds. Microsoft issued build 4051 at the PDC 2003 in late October 2003 and hasn't done much since, so it's still relatively current if you can believe that. Since the PDC build, Microsoft built another ten or so general Longhorn builds by late 2003 and then stopped, so the Windows development teams could focus on Windows XP Service Pack 2. A slightly more recent build, build 4053, leaked in early March 2004. That build, from November 2003, is visually identical to 4051, though it does fix the annoying memory leak problem in explorer.exe that renders the Longhorn sidebar virtually useless in build 4051. So if you can get your greedy little hands on build 4053, I guess I recommend it, if only for the memory leak fix. But no, I don't know where you can download it, sorry.
In the last part of this review, I focused on the general concept of user experiences, Microsoft's term for its holistic approach to the ways in which users interact with their computer systems. A user experience goes well beyond the simple widgets and UI elements that make up a user interface and encompasses a number of concepts, some obvious, some not. For example, when designing the Windows user experience, Microsoft considers the complete end-to-end scenarios. It's not enough to simply add a feature--say, CD burning. Instead, Microsoft examines how users expect such a feature to work, where they'd want to see links to that feature, and how they'd want it to work. When the task is complete, the user should be pleased and even excited that it worked so well. Sure, they could simply add CD burning functionality and check off a bulleted item in a long list, and consider the job done. That's how Microsoft used to do it, certainly.
That level of functionality won't fly in Longhorn, however, and you should read my interviews with Hillel Cooperman and Tjeerd Hoeck of the Windows User Experience team to find out more about Microsoft's holistic approach to software development to find out more, if you're into that kind of thing. In the meantime, this part of the review will focus on the user experiences that are available today, in Longhorn build 4051.
Frankly, there aren't many. But what's really interesting is that we can find see hints of where Longhorn is heading in this build, and analogous experiences in modern Microsoft software that's very clearly been designed to foreshadow Longhorn and get users used to the types of experiences they'll get in the next major Windows version.
Even in the unpolished and, frankly, ugly UI that we're provided with in Longhorn build 4051, there's a glaring and obvious change between this build and Windows XP. It's that big gray thing on the right side of the screen. Currently dubbed the Sidebar, this UI feature is designed to take advantage of the extra screen real estate many users have, especially those wise enough to invest in widescreen displays (Figure). (Tinkerers are free to move the Sidebar to any side of the screen, incidentally.) The Sidebar solves a user experience problem Microsoft has been wrestling with for decades: How do you provide status alerts, notifications, and other bits of information that are not central to the task you're currently working on, and how do you do it in a way that's unobtrusive? To answer this question, let's first look at how other systems handle this problem.
Windows XP features a number of alert UIs. For example, if you're working in one application, and other application throws up an alert dialog box, you wouldn't normally see it unless it somehow jumped to the front of the screen and interrupted you. Indeed, this is exactly what older Windows versions did, to the annoyance of users. Honestly, how many times have been typing away in an email or word processing application, only to have the text you're writing unintentionally trigger an action in a dialog box that popped up suddenly, and unwanted, because some other application simply had to get your attention? In XP, most of these alerts no longer interrupt you (I say "most" because this can still happen in certain situations); instead, the interrupting application's taskbar button blinks orange three times, by default, and then stays orange, alerting you that it needs your attention. You know, when you're ready.
Windows XP also includes balloon help notifications that pop-up in certain situations, such as when you install new hardware or need to install some Automatic Updates. And XP supports MSN-style "toast" alerts, those square wedges that pop-up when you get an MSN alert or a Windows Messenger contact comes online.
In Apple's Mac OS X, applications alert you by bouncing their dock icon, an increasingly annoying tactic that distracts the user and, ultimately, is as bothersome as it is helpful. But this functionality serves the same purpose as XP's orange taskbar buttons: It lets the user know that something else needs their attention.
In Longhorn, the goal is to unify alerts and notifications. So there won't be separate UIs, as there are now with balloon help, MSN toasts, and so on (there will probably still be some sort of taskbar button status change, but that remains to be seen). Like so many other technologies in Longhorn, alerts and notifications will be brought in-house, so to speak, and made system-level features that any application can and should use. As a result, all notifications in Longhorn will be consistent, regardless of where they originate. And because they'll no longer pop-up in front of the main application window, and will instead be integrated into the Sidebar, they'll be less intrusive and more useful than they are today.
But the Sidebar isn't just about alerts and notifications. The Sidebar is also designed to house small bits of UI, called Parts, which can supply status information to the user. Parts are not generally full applications. Instead, Sidebar Parts are, as the name implies, parts of other applications. As with the alerts and notifications functionality, the Sidebar's incorporation of Parts is designed to bring system-wide functionality in-house, so that any application which wants to constantly display status information to the user, outside of the main application window, can do so. Users can plug-in whichever Parts they want and have a fully customized UI. And ultimately, the Sidebar will replace XP's tray notification area, as a result, with a UI that is larger and more easily used.
In Longhorn build 4051, we only get a few working Parts (indeed, earlier Longhorn alpha builds actually featured more Sidebar Parts), though eager developers are busy creating unique Sidebar solutions as you read this. Longhorn 4051 includes a Classic Tray Part, which houses legacy (pre-Longhorn) tray notification icons; a Clock; a Quick Launch Part, analogous to the XP Quick Launch taskbar toolbar; a photo Slide Show Part, for displaying a single photo, or a slideshow or photos; and a Sync Part, which doesn't yet work, but will someday replace ActiveSync and provide a system-level interface for working with PDAs, portable music devices, and other devices that need to synchronize with a PC (Figure).
Let's look at the Clock as an obvious and useful example (Figure). The Longhorn Clock Part is reasonably attractive in build 4051, and uses the system's underlying vector engine to scale nicely as you resize the Sidebar. It also displays the date, which is handy. But when you click on the Clock, you get a glimpse at the true power of this feature, though it's annoyingly unrealized in this build: A fly-out window appears and displays a calendar (Figure). So what, you say? But what happens when this system-wide calendaring and scheduling functionality is absorbed by third-party applications? One gets the idea that Microsoft Office 12 will integrate with Longhorn's internal calendar and provide your scheduling information there, outside of Outlook. And naturally, when Outlook 12 wants to alert you of an upcoming meeting or other event, it will use Longhorn's unified notification scheme, and not its own custom solution. So will other third parties. Why write custom features if the OS already supplies an elegant, reusable, and integrated solution?
Back in the early days of the PC, floppy disk drives were common and high-capacity hard drives were not. Today, it's possible to purchase 400 GB hard drives at your local Best Buy, and it's only a matter of time before the typical American family has over a 1 TB of local storage at their disposal. Times change. But one thing that hasn't changed is the file storage and organizational schemes that today's otherwise modern operating systems implement to help us keep all this disk space under control.
Credit Microsoft for at least trying. In Windows 95, we got the My Documents system folder and true multi-user functionality, giving users an obvious and understandable place to keep their documents, separating personal files from those required by the OS and applications. This scheme was enhanced over the years with My Pictures, My Music, and My Videos folders, while Windows XP also added intelligent metadata support to the underlying system so that XP can recognize and deal with specific digital media types, like music and video files.
On a lower level, Microsoft has also advanced its storage technologies to include support for larger disks, disk virtualization technology that lets you span drive letters across multiple physical drives and even remote storage, encryption, and other related technologies. But we're still hobbled by the legacy drive letter scheme we first got in DOS 1.0 back in 1983. And even though today's GUIs are far prettier than the command line system we used twenty years ago, they're still woefully inadequate for managing the tens of thousands of files that exist today on a typical XP system. Searching is another huge problem. As Microsoft representatives often ask, somewhat rhetorically, "Why is it possible to search the Internet with Google in seconds, when it takes several minutes or longer to find anything on my local hard drive?" It's a great question.
Longhorn, as you might expect, has the solution. It's called WinFS, for Windows Future Storage, and it's the underlying storage engine in Longhorn. WinFS works with the pre-existing NTFS file system to abstract the Windows folder structure and provide users with simpler ways to find and work with files. If you're anal retentive you can still employ the old hunt and peck methods of the past, of course, and Longhorn will even provide drive letters for backwards compatibility. But storage and file management are getting dramatically updated in Longhorn, and there's no looking back.
The key is metadata. Metadata is "data that describes data." In today's Windows versions, you can right-click a data file (a text file, a bitmap image, a Word document, or whatever) and choose Properties to view this metadata. With a few exceptions--notably, digital media files--however, most of today's data files don't provide rich metadata information, and even if they did, it wouldn't matter because the underlying OS can't take advantage of it anyway. In Longhorn, data files (and, presumably, other types of files) are going to get a shot in the arm, thanks to new categories of metadata. This metadata will make it easier to find documents, and will help Longhorn organize your data in ways that are almost impossible today.
Let's look at an example. Today, if you're really careful (as I am), you might create intricate folder structures under My Documents to organize your data. People who do this do so because it helps them find things later. In my case, I have a "Penton" folder under My Documents that contains all the documents I've created related to my work for Penton. Predictably, I've got folders named "Connected Home," "SuperSite," "WinInfo," and "WinMagazine," among others, under the Penton folder. Inside the SuperSite folder structure, I organize documents related to this site. There are several subfolders, including one named "Windows & WinMedia." This folder contains further subfolders, one for each year, 1995 to 2004 (currently). Inside these folders are dated folders, like "2003-10-26 - PDC 2003," that contain various documents related to the event at hand. I have thousands of these folders, as you might imagine, all tied to specific events in the history of Windows and Windows Media.
OK, now that I've proven that I'm anal retentive (though arguably, I need to be, because I'm so disorganized otherwise), can anyone see the problem with this approach? What if I wanted to see all of the documents I've created or saved that are related to Longhorn? Right now, there's no real easy way to do this. I'd have to specifically include the word Longhorn in the name of each file, and then search only by file name. Or I could search for the word Longhorn inside of documents, which would be somewhat useful, unless of course I wanted to see image files related to Longhorn. Because Windows offers a very strict folder structure, I'm basically locked into whatever management scheme I've decided to implement. So I can basically search by topic (Windows and Windows Media) and then date, and that's it. I guess I could have broken out the topics more widely ("Windows XP," "Longhorn," and so on) and, in fact, that's exactly what I used to do, but it got to complicated.
In any event, we shouldn't have to worry about that kind of thing. When you think about it, aren't computers better at organizing and finding things than people? Shouldn't we let the computer do the hard work?
By applying metadata to these documents, it's possible to overcome the search limitations described above. In Longhorn, for example, I could assign the word Longhorn to a metadata tag called "Topic" or whatever. Then, when I searched for files in Longhorn, using the search term "Longhorn," they'd all come up. You can also search for files created by certain people ("Paul Thurrott," "Keith Furman," or even both "Paul Thurrott and Keith Furman"), by category, by keyword, by file type, and so on. The possibilities are endless.
If you're familiar with database technology, you'll be interested to hear that Longhorn's storage engine is based on relational database technology. In a very abstract way, all of the files on your PC represent the entire database. As with a database, you are typically not interested in viewing all of the data. Instead, you want to filter down the result set and view a specific subset of the data. In the database world, create such a filter on the fly is called an "ad hoc query," and you can save such a query in a View. In Longhorn, search results are basically ad hoc queries. And special shell folders, like Music (a replacement for XP's My Music folder), are actually Views of precompiled queries; in the Music folder case, this query is basically "Show me all of the music files stored on my system."
The beauty of this approach may not be immediately apparent, so consider the following. In Windows XP, you and your media player of choice must manually ensure that all of your music files are actually stored in My Music. That is, My Music abstracts a physical location on your hard drive (C:\Documents and Settings\[Your User Name]\My Documents\My Music\ by default). In Longhorn, the Music folder does not represent a physical folder on your system at all. Your music files could be scattered all over the hard drive, for all you care. They could be on network shares. It doesn't matter. But when you open up the Music folder, you see them all, instantaneous. That's the beauty of database technology: The computer does all the work, abstracts file locations you shouldn't care about anyway, and presents you with the information you need.
To continue the Music folder example, remember that you're not limited to the stock view. Pop over to the Filter By box and you can further refine the result set. If you're interested in just seeing all songs by Def Leppard, type in "Def Leppard" and you're good to go. Want to create a playlist of New Age songs? Type in "New Age," select all the files (which appear instantaneously, by the way), right-click, and choose "Queue-It-Up."
I've used words like "instantaneously" and "immediately" to describe the way Longhorn performs searches for a reason. This isn't a best case or limited scenario I'm describing: Even in Longhorn build 4051, which admittedly has a buggy and incomplete version of WinFS, searches are indeed instantaneous, every single time. It's an astonishing thing to see, especially if you're painfully familiar with how slowly searches occur in XP today. I can't wait to see the finished version.
Earlier in this part of the review, I discussed Longhorn's Clock and the way that a unified calendaring infrastructure could be beneficial. Another similar feature in Longhorn is its new Contacts library, which provides a centralized, system-wide contacts list and that can and will be utilized by other applications. Today, you probably manage one or more contacts list. There is a Windows Address Book (WAB), typically used by Outlook Express, but applications such as MSN Messenger, Microsoft Outlook, MSN 9, and third party email applications like Mozilla Thunderbird and Eudora also sport their own address books. That probably seems stupid at first, but the reason so many applications include their own address books is that the one built into Windows wasn't as feature-rich, accessible, or extensible to provide all the services they needed.
That's all going to end in Longhorn, though arguably third party developers may need some prodding to drop their proprietary address books for the short term. In Longhorn, Microsoft will offer a centralized address book, the Contacts library (Figure). You might think this isn't such a unique idea. After all, Mac OS X, for example, offers a centralized Address Book application too. Big deal, right? Not quite. Because of Longhorn's WinFS infrastructure, contacts in Longhorn will be built right into the file system (as will email and other services). That means it's possible to do a search for, say, "Paul Thurrott" in Longhorn, and come up with my contact information in addition to any email I may have sent you, any of my Web sites you have in your IE Favorites, any documents I've created that you have on your hard drive, and so on. Pretty exciting stuff, really.
Like just about everything else in Longhorn 4051, the Contacts library isn't feature-complete or particularly attractive. But it does sort of work, and it integrates any MSN Messenger contacts you may have automatically, and can import some other contact types, which together is a helpful preview of this system will work with legacy, contacts-based applications.
As I mentioned previously, Longhorn build 4051 is pretty light in the user experience category, but that doesn't mean you can't readily see where Microsoft is going with some of this stuff. That's because many of Microsoft's existing applications and services offer subtle and not-so-subtle previews to future Longhorn functionality. In this section, I'll explore a few of those features.
For a look at the work that formed the basis for Longhorn's Sidebar, check out the MSN Dashboard (Figure), which debuted in MSN 8 and was somewhat improved in MSN 9. Like its Longhorn counterpart, the MSN Dashboard can optionally adorn a side of your PC's screen (it can also be tied to the MSN browser window if you'd prefer), proving you with at-a-glance status information, such as upcoming schedule items, which contacts are online, and the like. Because it's part of MSN, the Dashboard is a bit more limited than the Sidebar and not extensible by third parties or end users. You can't configure it to resemble the OS theme, or change its color.
That said, the MSN Dashboard does provide a number of system-level and Internet-related services. You can mount a front-end to Windows Media Player there, for example, view photo slideshows, view the weather conditions, and get MSN alerts. For a limited, pre-Longhorn application, it's surprisingly full featured. That might be because it was designed by the same team that did the Windows/IE shell integration and the XP user interface. Go figure.
In any event, as a long-time MSN user, I've been excited to see MSN preview some early UI work for Windows over the past two MSN versions. And because of my bizarre work-related need to use different computers continuously, I've started using MSN Calendar for my scheduling needs, replacing the Calendar component in Microsoft Outlook. Now, any time I boot up any of my systems, the MSN Dashboard grabs my latest schedule information and displays it in a handy place, without the need to manually import and export data through Outlook. It even synchronizes nicely with Pocket PC and Palm OS-based PDAs, another feature we can expect to see in Longhorn. It's probably the most obvious Longhorn-related feature available today.
Windows 2000 introduced the notion of Balloon Help to Windows, while Windows XP added the MSN Alerts ("slice of toast") notification windows you see with Windows Messenger and MSN Messenger (Figure). Both of these bits of UI attempt to accomplish the same task: Alert the user to an event and do so in as inconspicuous a way as possible, so that the user can still complete the task their currently work on if needed. The problem is fairly obvious, however: Both bits of UI are also redundant, as they do the same thing, but present different interfaces. In Longhorn, Microsoft will make all alerts and notifications consistent, so users won't have to learn different interfaces to get work done. But today, we can see the gestation of this feature in MSN Alerts and balloon help.
Originally scheduled for inclusion in Longhorn, the Windows Firewall component in Windows XP Service Pack 2 (SP2, see my review) is on by default, protecting your system against electronic attack. In Longhorn, Windows Firewall will be updated to include true two-way protection (in SP2, it only parses incoming requests), so that errant applications on your system trying to "phone home" will be isolated and brought to your attention. But you can get the basics of Windows Firewall today in the SP2 beta.
In Office XP, Microsoft introduced the Task Pane to its office productivity suite, taking advantage of what is typically unused real estate on your PC screen. The Task Pane sits at the right side of many Office applications, offering quick access to task-centric functionality. Microsoft also offers a limited task-centric UI in Windows XP, which can be seen most readily in folders containing multimedia files: The folder task list will change based on the contents of the folder and/or which file(s) are selected (Figure). In Longhorn, this concept will be greatly expanded to cover a much wider range of tasks.
As Microsoft was building toward Longhorn in the late 1990's, it began experimenting with a task-based UI it called Activity Centers. Activity Centers were designed to encompass a number of related tasks into a single UI so, for example, you might have an Activity Center for photos, which links to various tasks--like acquiring, editing, printing, and sharing--all of which would launch sub-pages. Today, you can see the fruits of this work in various Microsoft applications, including the Help and Support Center in Windows XP, and Windows Media Player 9 Series, which is, perhaps, the most obvious example. Instead of using sub-pages, however, Windows Media Player 9 Series presents a set of tabs, sort of a list of options, on its leftmost side (Now Playing, Media Guide, Copy from CD, and so on), all of which are task-oriented and direct the user to a unique bit of UI (Figure).
Frankly, the complexity of Windows Media Player 9 Series' UI speaks volumes to the problems in achieving the goals Microsoft set out for Activity Centers. Because there are so many possible things one can do while working with digital audio and video files, the media player is a bit of a mess, with dozens of tiny, inscrutable buttons and many hidden features. Hopefully, Microsoft will get this right in a Windows Media Player update due in summer 2004, but in the meantime, Windows Media Player 9 Series does nicely encapsulate the basic theme of an Activity Center (albeit in a cluttered way). It will be interesting to see how this style of interface evolves with Longhorn.
