semi/signal

I spent some time recently investigating file tagging on Windows Vista and Windows 7, and I was less than happy with my findings. The problem is that only certain file formats that support metadata can be tagged, for file types without such support it’s simply not possible to do any tagging. This is a major limitation and without ubiquitous tagging support, the feature itself becomes all but useless; as an end-user, I don’t care about file type, if I’m searching for a document should I have to remember whether it’s a Word document or a plain-text file? JPEG or TIFF? Absolutely not. The confusing thing is, at some point, Microsoft seemed to believe this as well, by default Win 2000 and higher hides file extensions for know file types – isn’t it then completely counter-intuitive to present a limitation based on file type. What this ultimately boils down to is the question of why would I bother tagging anything if only a subset of my files, based on file type, an attribute I don’t care much about, would benefit from the additional metadata?

This isn’t to say that there is necessarily an easy solution. I found this blog post to be the best write up on the topic which explains several approaches that could be taken to implement tagging and why storing metadata in the files themselves was chosen as the best approach. However, I don’t think storing metadata in the file system would be such a bad idea, I can understand the issues about losing metadata when copying to another volume, typically one with a older file system, but at some point you have to do what’s best for the future, not the present, by that I mean the only way you’d actually start to see file systems with proper support for metadata (via. NTFS-esque alternative streams or whatever) in use is by providing an imperative for users to buy or format devices with those file systems; as-is, we’ll continue to use systems such as FAT32 and programmers will continue to remain agnostic to metadata. At the very least, a hybrid approach, storing metadata both in the file itself, when supported, and within the file system would seem a worthwhile solution.

I recently read about the Windows Advanced Rasterization Platform (WARP), which is a software rasterizer that will ship as part of Windows 7. WARP is targeted at:

Casual Games: Games have simple rendering requirements but also want the ability to use impressive visual effects that can be hardware accelerated. The majority of the best selling game titles for Windows are either simulations or casual games, neither of which requires high performance graphics, but both styles of games greatly benefit from modern shader based graphics and the ability to scale on hardware if present.

Existing Non-Gaming Applications: There is a large gamut of graphical applications that want to minimize the number of code paths in their rendering layer. WARP10 enables these applications to implement a single Direct3D 10, 10.1, or 11 code-path that can target a very large number of machine configurations.

Advanced Rendering Games: Game developers that want to isolate graphics card or driver specific rendering errors. We believe that all games, even extremely graphically demanding games would benefit from being able to render their content using WARP to validate that any visual artifacts they might experience are due to rendering errors or problems with hardware or drivers.

Using WARP as a tool for isolating rendering errors is understandable, but as a fallback for DirectX 10 casual games or non-gaming applications attempting to run on a PC w/o a DX10 GPU, a few things pop into my mind.

• As a fallback mechanism, it goes back too far. We’re talking about going from DX10 -> software rasterization. There’s still lots of graphics hardware out there that targeted previous versions of DirectX, at the very least DX7, DX8, and DX9. Why not allow for seamless fallback to these earlier classes of graphics hardware, instead of a making a gigantic leap backwards to software rasterization? From a developer’s perspective, there would be a real benefit here in writing a DX10 codepath and having it run on older hardware.
• DX10 adoption is slow to non-existent due to the slow adoption rate of Windows Vista. Unless Microsoft is able to generate massive demand for Windows 7, WARP will have little impact due to the little impact of DX10.
• A project like WARP seems to be based around the mentality that a GPU is something special for a PC instead of a requirement. Versus software rasterization, GPU rasterization is orders of magnitude faster and the price of a decent card is under $50. Why is setting a GPU requirement such an endeavor, for Microsoft of all companies?!
• On performance, WARP beats Intel integrated graphics. This really isn’t a surprise or any sort of accomplishment. Intel is really just selling overpriced garbage here.
• Perhaps Microsoft working on a project like WARP instead of setting stricter graphics hardware requirements for Windows 7 is due to another shady deal with Intel. Remember the one with Vista.

I was reading Ars Technica’s first look at Windows 7’s UI and one thing in particular stood out for me, the fact that text descriptions for buttons on the taskbar will be going away.

Text descriptions on the buttons are gone, in favor of big icons.

There are still text descriptions, but they appear over thumbnails that show up when you mouse over one of the taskbar icons.

There’s a big dependence on iconography here. There was a very small bit of this in Vista, as the Start button was replaced with the Windows logo, but these changes are a much greater shift towards favoring icons over icons+text in the UI. Unfortunately, a potential issue I see here is that unless a user recognizes an application’s icon instantly, they’re now forced to mouse over all the taskbar icons unknown to them in order to find the app or window they’re looking for. This may, however, be a non-issue as the taskbar may typically just be filled with application icons familiar to the user, so cases of scanning over unknown icons in the taskbar will be rare. Whether this is a success or not remains to be seen, but the reason this caught my attention was because of something I read a long time ago on the importance of labels, written by a program manager on the MS Office User Experience team,

One of the problems noticed again and again among non-expert users was that people didn’t use the toolbar at all! … people used the menus to reply, forward, and to create new messages.

… one change caused a total turnaround: labeling the important toolbar buttons. Almost immediately, the toolbars were a big hit and everyone at all skill levels starting using them.

It’s not that icons can’t work by themselves, but that most people have a fairly limited vocabulary. Floppy disk = save. Printer = print. …

… considering that I already know how to speak English; it’s a lot of work to learn how to speak “Iconese” on top of that.

What’s particularly interesting is that the icons being talked about aren’t particularly exotic (reply, forward, send, etc. in Outlook), and toolbar icons are perhaps as common as taskbar icons.

Finally, developers will understand this, what happens if you have 2 applications with the same icon? I don’t expect this to be a major concern, but still, I have a bunch of apps I’ve written with just the default application icon, these changes to the taskbar will certainly make switching between them more difficult.