Improving Save sheets
Pardon the empty buttons and such - open a current Save sheet to see the buttons with their proper icons.
My mock-up for a revised simple save sheet
My expanded save sheet
Additions which would increase functionality of Mac OS X Save sheets:
Finder Comment input field
This is building on the assumption that the UW research showing that users had much less trouble finding sites that they had described in their own words would also be applicable to local files.
Yes, adding comments to files is already possible, but how many users know how to do it? The input interface is hidden away in the Info window/inspector. Adding this more direct & immediate input method to Save sheets would make an existing feature more accessible and probably more useful.
Providing an easier way to add comments should be part of a reworking of the feature that includes indexing them and making them searchable, from both the Finder and possibly Open sheets. A standard rounded search field would allow for switching between filename, comment text, or both (probably should be the default).
Label assignment
It makes sense to allow the user to assign labels to files as they are saved, rather than having to switch to the Finder to do so. I would prefer to have the same selection interface as is present in the Finder’s contextual and File menus, but I think this gets the idea across.
Breadcrumbs?
I considered adding a horizontal breadcrumb navigation method to my mockup, but question whether such a solution would work well in the limited space of an Open or Save sheet. Breadcrumbs work well at the iTunes Music Store because the hierarchy is of limited depth (Home -> Genre -> Artist -> Album is the maximum, I believe) and the screen real estate available is much greater. An implementation similar to Path Finder’s might work, but then where would the “Recent Places” be listed?
Comments aren’t shown in any view but vertical list. They are superfluous when you consider longer file name limits. Also, that vertical list format is already wide by default, with information about file sizes and kind, etc. I don’t think many people would customise their views in finder, just like you don’t think it’s easy to find the comments field to edit it.
Hide extension, while interesting, doesn’t really work, at least not on my iMac. I just checked a .dmg file’s ‘hide extension’ property, and nothing happened.
I don’t even know why Apple brought back coloured labels. Yeah, I just set my Unison.dmg file (the one that wouldn’t hide its label) to green. But what does green mean. Unless one is able to attach meaning, and possibly a floating key of colours on demand, the data is somewhat out of sorts.
I’ve always been interested in bread-crumbs, but I’ve never found a method that doesn’t bollox up the interface. For example, you are running amok in your favourite shell, and jump to ‘/usr/local/www/data/phpmyadmin/config/’. If your shell is set to display the entire path, you just wasted half your real estate.
Just some thoughts, don’t mean to be any harsher than you are on Apple ;)
Not enough time…
Interesting developments in HCI on files and bookmarks management.
Eli -
I have to disagree with you about comments - they provide information about a file which doesn’t belong in the actual filename; I might want to add a note about an HTML file I’m working on, but I don’t want to call it “This is the file that doesn’t currently validate with the latest W3C validator. Also breaking in Opera 7/Win.” The interfaces for displaying and entering these comments need to be rethought, but I don’t think the feature should be completely abandoned. GNOME’s Nautilus file manager handles these somewhat better, providing a display method that is independent of view mode.
The whole file extension mess should be fixed. Users should not have to deal with them at all. Type and Creator codes weren’t perfect, but I think they were a better solution.
The utility of the labels is rather limited, I agree. I use them primarily as visual differentiators, a way to quickly visually locate an object in a long list or column. They aren’t much use as a way to organize things.
The GNOME people have been hard at work trying to fix what is currently the worst file selector of any shipping GUI. One of the ideas is to use breadcrumbs for quick hierarchy navigation. Check out these screenshots:
Eugenia Loli-Queru’s vertically-oriented mockup
Similar to above, but stretched width-wise.
TigerT’s variations of the above
I concede your point on comments. However, is this the right place to enter them? I think that people who know what comments are and use them will label things in a separate manner.
There is nothing wrong with file extensions. A lot of cross-platform applications use them, and therefore, what works for the barest minimum system (for example, Windows) must also work for superlative systems as well. Else we end up back in the 80s where without resource forks, one can’t tell what a file is. I do NOT want to go back to the bad old days. Until there are DBFSen out there, and everyone supports content/creator, we cannot change this.
Set a label to grey, or whatever your highlight colour is. What’s the difference between a selected file and a labelled one?
Not enough time…
Interesting developments in HCI on files and bookmarks management.
I think the Save sheets should be an optional place to add comments. It might be better to make them available only in the expanded form for the sake of simplicity.
Type and Creator codes did (and do) have their share of problems - compatibility with the Windows world being the primary one. One solution would be to retain the ability to use file extensions, but provide MIME type -> application associations as were available in the BeOS. I’ve read rumors that Apple is working on something similar. With Apple having the BeFS author on staff, there is some hope that HFS+ will be replaced by something more flexible.
I have experienced the label coloration problem you mention. Because I use the standard blue colors available in the Appearance System Prefs pane, the blue and gray label color are largely useless since they are so close to the active and inactive selection colors. Regardless of what highlight color is chosen, two of the available options are rendered nearly useless.