| Date: | October 2, 2003 / year-entry #82 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20031002-00/?p=42303 |
| Comments: | 23 |
| Summary: | Blue means compressed; green means encrypted. This is an example of one of those "come on, it's a tiny, simple feature" requests. Yes, the code to do this isn't particularly complicated, but it adds another element of "Ha ha, I'm going to do something in a way that you will never be able to figure... |
Blue means compressed; green means encrypted. This is an example of one of those "come on, it's a tiny, simple feature" requests. Yes, the code to do this isn't particularly complicated, but it adds another element of "Ha ha, I'm going to do something in a way that you will never be able to figure out unless somebody tells you." We get a lot of these little requests. If we accepted them all, you'd have icons with so many incomprehensible decorations you'd never be able to figure out what all the colors and markers mean. So the next time you say to yourself, "Windows should change the appearance of X if simple condition Y," imagine what it would be like if we actually did even twenty of those simple things. As my last example: What does it mean if an item on your Start menu is grey? |
Comments (23)
Comments are closed. |
It means the shortcut is for an advertised feature (is that the right term? it’s an MSI thing) but the necessary files haven’t been installed yet.
I have *no* idea how I know this, I just do. Someone must have told me. ;)
I’m curious as to how and why the colors blue and green were chosen.
For example since no particular color is automatically associated with "compressed" I’m curious why blue was chosen, especially in light of the fact default HTML links are blue as well, and could cause confusion.
Didn’t some Norton or Symantec File Explorer tool color compressed files blue before Windows did (like making pkZipped files appear to be part of the filesystem)? If so, it might have been to maintain consistency.
What would be the downside to having additional optional, disabled-by-default features like showing compressed / encrypted files in different colors? People who wanted them would get something they consider useful and everyone else would continue to get what they have now.
Chris, here’s the downside –
The features that get described as "this is easy, it’ll only take a few minutes to do" require time from development, QA, docs, support, and whatever other internal groups you have that are affected by the feature set. Even if the developer *can* bang it out in 5 minutes, it certainly impacts the whole product group for a lot longer than that.
Now imagine that 10 people put in similar requests. You now have 10 times that amount of time spent. Not to mention time spent fixing this one weird bug that happens when 4 of the "quick things" are enabled all together in a particular order…. (something like that always creeps up)
On a product the size of an OS, I wouldn’t be surprised if cRequests > 500 over the product life cycle.
There’s also the viewpoint that if this feature is going to be disabled by default, and not really advertised, and not really used by a whole bunch of people, there are probably more important features to work on. At some point you have to say "this is fluff, drop it".
Mike is right on. It takes comparatively little time for dev to bang out a feature like this. The killer is all the follow-on stuff. QA will have to write up a test plan. (The color needs to be tested to make sure it remains readable in all color schemes and all visual styles.) Interoperability becomes an issue: Do you want Windows 95 Driveespace drives to show up blue? Linux squashfs drives over samba? Does Novell support per-file compression? Globalization needs to verify that the color does not have bad connotations in any particular culture. (Imagine the panic that would ensue if compressed files were red!) Doc will have to explain the feature, how to turn it on, how to troubleshoot it. Support will have to know that the feature exists at all so they can help people who inadvertently turned it on and are now all confused by the colors that weren’t there yesterday.
Testing doesn’t like features that are off by default, since it means that it gets comparatively little coverage. And if you let the user turn the feature on and off, you just doubled your test matrix, since you now have to test the system twice, once with the setting on and once with it off. Add three binary switches and your testing hit just octupled.
There’s no such thing as a cheap, simple feature.
True, but those points are all irrelevant: "it could confuse users who don’t want extra info" isn’t the appropriate question to ask – as everyone here seems to agree, it really boils down to the same question of whether enough users will find it useful to justify the development time asked of every feature. I just thought that was an odd position since the potential for confusion would rule out a significant portion of the current featureset in most applications.
I think that colorizing the text is the lesser of all relevent evils. I personally _want_ to know what folders I have compressed or not without having to actually dig to find out.
Wait, you can’t agree with our points then call them irrelevant.
Your criteria of "if usefulness > dev_cost then do_feature" doesn’t work in the Real World(tm). If you’ve never worked as a professional developer, I could understand how you would think that business decisions are always made 100% rationally.
In software companies, there are firm (often unreasonable) deadlines, other groups to think about (see Raymond’s post), marketing constraints, international considerations (see Raymond’s post), and on and on.
Sure, if you’re just one hacker writing shareware for the heck of it on the weekends, you can certainly weigh the usefulness/cost yourself. In a team, it just ain’t that simple.
I don’t want to configure the color of compressed files. If I want to have something to configure, than I use Linux:-)
But if I have a compressed file on my disc and I want to know what that blue color means and I don’t have raymond’s blog at hand, how do I figure it out?
Doesn’t TweakUI let you change the colours? I don’t have it to hand right now but I’m sure I remember seeing that feature.
John: you’re right, TweakUI allows changing the colors for compressed files and for hot-tracking (this is the single click feature available since Active Desktop if I am not mistaken).
So, is this why a file cannot be both compressed and encrypted at the same time, because then colors would clash? :) How come the *checkbox* to enable/disable the coloring is in the main Explorer UI (Folder Options), but the colors can only be set in TweakUI or directly in the registry? What if the user wants one of these colors as background? How many other file coloring rules could there be (directories in bold, executables in bright green, backups in red, and readme files in italic, so that the whole Explorer window looks like a parrot on an Xmas tree? :) )
The comments about testing are very valid. I completely agree with them. I also find chris adams comments interesting – he is thinking from an end user perspective – I want X – it costs Y to develop. If the users get Z use out of this, and Z >>>> Y then do it. But the testing is the big cost – if you factor all the costs, not just the developer time, then getting Z >>>> Y is unlikely. The other propblem here is, while at the moment, Compressed and Encrypted can’t class, what about in future. What if you show EXE’s in purple – what if the EXE is compressed? What criteria should you use?
Also, accessibility – what if the user is colour blind like me? I find it difficult to see purple (I just see blue) – how do you overcome that? Oh, you want to add a dialog that allows people to change it? Ah. Right. Thats ANOTHER bit of code to write, test, document, and support. I need to extend the theme file parser too to make sure that it picks up this new property etc…
UI Customization is often the bane of my existance as a Windows developer. There comes a point where it is FAR easier (for both developer and user) to just say "That’s the way it is, you can’t change it". Too many options confuse users. Over zealous managers are afraid to upset 0.5% of our users so, "You better let them disable that." Right, so when the other 95.5% accidentally does it, it pisses them off. And the 0.5% who WANT to disable it, they don’t know they can in the first place, so they just live with it!
Microsoft, IMHO, is a large offender in this area. For example: Dockable menus. NOBODY NEEDS IT. If you think you need it, heck, even if you think you WANT it, you’re wrong! The number of times I have acidentally grabbed the menu and dislodged it in VC6 makes me want to scream. It’s a UI customization the world would be better without.
Yes, dockable menus suck. I’ve used to enable ‘use screen-reader compatible menus’ under VC6, just to get rid of that. But menu customization was lost too :(
Heh, I hate both the dockable menus and the customized menus, they always end up slowing me down.
Mike: I too have spent plenty of time on commercial software development teams (as a programmer, if that’s an important qualification) – that’s why I’d assumed that anyone doing software development professionally (which was, after all, the original context) would assume that "development time" mean far more than the time needed to get that first compile without errors rather than, say, the time needed to turn a point on the product plan into what actually goes to the customer.
Yes, companies do silly things and work in inefficient fashions but I haven’t seen many where deciding what goes into a product wasn’t essentially a sort in order of increasing cost/benefit, albeit for what are often highly subjective definitions of cost and benefit.
If we’re both using the same definitions for cost and benefit, there really doesn’t seem to be a disagreement here. My point was simply that this is the real underlying issue, not simply the potential for confusion or a reluctance to add non-default customization options – any non-trivial product is going to acquire features which confuse some users but were valuable to others. That’s why people joke about not using 90% of the features in Office but never seem to buy something like Gobe Productive instead – no two people making that joke had the same 90% in mind.
RE: colouring EXEs or directories as different colours, you should try 4NT from JPSoftware — it’s a replacement for CMD.EXE and you can set up your DIR listings to use different colours for each type of file. It has a whole bunch of other really cool features, and is well worth the $70 license if you are a command-line junkie. (http://jpsoft.com/)
Yes, I could say 4NT is what CMD should have been :) Also, there is a file manager called FAR <http://www.farmanager.com/> that has long ago replaced Explorer’s file manager for me.
I suspect that the problems people had with the dockable, resizable menus and toolbars in IE 5.x are the reason that the ‘Lock Toolbars’ feature exists in IE 6 (and the reason it’s turned on by default in Windows XP).
Light-grey background of the icon in the classic Start Menu, using one of the XP themes (rather than Windows Classic), with personalized menus turned on, indicates that this is a program you haven’t used recently.
Windows 2000 renders this as flat rather than raised (I think the Windows Classic theme still does).
Mike Dunn had the intended answer: If the background is a normal color but the text is grey, then it means that the item corresponds to an MSI program that is only partially installed. More info here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gp/116.asp