A Better Finder? 490
Build6 writes "Ars Technica opens today with another one of their deeply-thought-out articles relating to MacOS X issues, pointing out another thing which the old MacOS had and the current one doesn't."
"Life begins when you can spend your spare time programming instead of watching television." -- Cal Keegan
I don't agree with the article (Score:5, Interesting)
Any desktop uses a spacial metaphor for data - however, for me, the desktop is just a holding area - short term memory, if you will.
I do like the idea of other means of filtering: LifeStreams seems like a good idea: being able to filter based on time and document type (for example).
Anyway, it is a free world - I will stick with OS X.
-Mark
Paying more, getting less (Score:1, Interesting)
Re:a better finder? (Score:2, Interesting)
A Better Finder (Score:4, Interesting)
Re:I don't agree with the article (Score:2, Interesting)
yes, I dual-boot my Macs and I still use OS9. Am looking warily at the new generation of machines that won't boot OS9, although apparently there are some indications that special ROM files are available to Apple service providers that would allow OS9 bootability even on those not "officially" OS9 bootable.
How did this get modded to 5? (Score:1, Interesting)
Meta data may be coming (Score:5, Interesting)
The filesystems used by OS X are the same ones that have been used by OS 9 for years, with the recent addition of journalling. Apple have employed the designer of the BeOS filesysem (which is widely held up as the best example of a desktop filesystem) and is keeping everything under wraps for Panther. I would expect some developments in this area to be revealed in July.
Once the meta data is in place, and people have moved over to the new filesystem, look for a more intelligent finder.
Solution is a more flexible "finder" api (Score:3, Interesting)
The difference between this and what some people already offer would be on Apple's end. Trying to make a very good desktop alternative is often difficult because it becomes too much of a monumental task to become a true replacement. And if your app just sits on top of the original gui, often times there are many things you either can't do, or can do but in a kludgey way. If the powers that be at Apple sat down and thought of a way to provide hooks into the gui (as well as the most important thing, to make sure that functionality is separated from the gui), then doing these types of things could be much simpler as well as providing a viable market for alternative interfaces.
Re:Paying more, getting less (Score:1, Interesting)
Re:Evil bit support (Score:5, Interesting)
Eventually I learned about the different meta-data types and how to edit them. If anything, I found that the Mac had several power user features too well hidden for me.
One thing I really agree on... (Score:5, Interesting)
I know that the "all photos in one folder" feature could be accomplished at the command prompt by running "find ~/Pictures/iPhoto\ Library/* -type f -print0 | xargs -0i ln -s {} destination ", but it would be nice to have it automatically done for you by the Finder.
Re:If Ars Technica is so concerned about usability (Score:4, Interesting)
Re:Metadata benefits (Score:3, Interesting)
Do a google search for "alternate data streams NTFS"
OS X Finder Laundry List - Please add yours. (Score:4, Interesting)
Renaming files: There is a delay in renaming that makes me crazy. I'll click on a file and it won't go into the rename unless I wait a moment and click again.
There is no undo for renaming. If I accidentally rename a file, I have to find the file (not easy with numbered files), find out what the original name was (could take a few minutes to never) and manually rename it. I want 'apple-z' to undo the rename. (It works for copy, paste and other finder operations.)
There is a delay in the update of windows after a file has been renamed and/or saved. This also shifts the files viewable up or down so that when I go to click on the next one, I click on the file that has somehow magically appeared under my cursor. Most annoying.
Copy/replace dialogs: There is information missing from these, that I could use to make my decision of whether or not to replace that file/s. Where is the date? It just gives me 'newer'.
Collumn view: No viewing by date, size, or anything but name. It's there in the other 'views', why can't I have it here?
Save Dialogs: Same with collumn view. I hated how the old os9 save dialog (think pagemaker - grr.) would pop up and be immovable - invaribly, I needed some info that was immediately under that window. Let me move it. Let me sort the contents by date, size, name.
Labels: If you haven't used labels, you have no idea what you missed out on. Putting a colored cast to an icon was about the most useful thing I had ever seen. I used it extensively in the short time before I moved to OS X. Now the labels are gone, still visible in some os9 apps, but unused by OS X. Nothing would allow me to find a folder in a sea of blue like one with a red sheen to it.
In fact, icons were easier to maipulate in os9 than X. It seemed I could take anything and make an icon out of it, whereas X requires more forethought and a concerted effort. This may be different now; I've stopped trying.
Pop-up folders were swell, however I don't miss them like the labels.
Lastly, Unresponsiveness and Instabillity: The Finder likes to sit for a moment and think about how it's going to perform the operation you told it to do. Copy the file, already. You've done it a million times, and you're wondering how this one is different? (pardon my anthromorphising). Recently, I had to ftp several thousand jpgs, and had to do it at home on my windows machine, since the finder choked at the prospect. "You want me to do what? Uh. I'm busy that weekend..."
Mac users should know that my widows machine said nothing, but did the requested operation with no flair at all, of course.
Apple *should* incorporate some of these features (LABELS!); they have years of a great user interface to build on. They have already impressed the hell out of me with OS X, it just needs some polishing.
Please add your thoughts.
Re:Meta data may be coming (Score:2, Interesting)
System-specific metadata should be left at the filesystem level (file permissions, ownership, etc.) but file-specific metadata shouldn't be moved out of the file. Keeping one's data files as one big block of data is a Good Thing, especially when transferring them around between systems or over the internet. Having said that, I do think that the OS should be willing and able to cache that info so that users can sort their mp3s by ID3 tags (for example) without a nasty performance hit.
Re:If Ars Technica is so concerned about usability (Score:2, Interesting)
The only reason black-on-white seems natural is when we started printing, it cost money to make a page full of black ink, while a white page was free.
For web pages, it makes sense to have white text on a black background - it is easier to read, especially if you're on a CRT... at least with all that black there it's not like you're trying to read off a lightbulb.
Re:Full Mirror (Score:2, Interesting)
Re:If Ars Technica is so concerned about usability (Score:3, Interesting)
Gag me with a spoon, but it's more readable once you get your lunch wiped off it.
All studies have found that dark text against a plain light background is easier than the opposite on CRTs with reasonable refresh rates.
Why so mad at Cut and Paste in Finder? (Score:2, Interesting)
Furthermore, as astute readers have already figured out, the shelf eliminates any need for the perversion of interface metaphors that is the use of copy and paste for files. The "Edit -> Copy File" command now becomes "File -> Place on Shelf", and the "Edit -> Paste File" command now splits into two commands, "File -> Copy from Shelf" and "File -> Move from Shelf", making it more powerful that copy/paste (since "cut" is not an option) in addition to being more sane and consistent with the rest of the UI.
Why the hostility? The "Cut" feature is practically the only thing from Windows that I miss in OS X. It's annoying to not be able to move files in OS X without dragging. Often you know you want to move some files, but say you get to the destination and want to make a new folder for them. This is incredibly annoying to do with OS X, but would be way easier with keyboard Cut as well as Copy/Paste.
What is the down side to having a "Cut"? I assume there's some usability study that shows users messing up more with Cut around. But I find this hard to believe. Cut and Paste to a hidden clipboard is so ingrained in computer users that introducing an explicit "shelf" makes things more, not less complicated. In fact, OS X is going in the opposite direction... nowadays you can cut and paste almost everything to a hidden clipboard and it tries to sort out what you meant (e.g. copy a file and paste it into a text editor, or drag a file onto a terminal window).
You can get an OS X version of the shelf mentioned (a kind of visible clipboard) at XShelf [mac.com] today. I have it around as a kludge for moving files more easily. But it would all be solved by having a "Cut" option as well as Copy and Paste.
- Eric
Integrating Finder with Terminal (Score:2, Interesting)
When accomplishing a task, it is sometimes more convenient to use the Finder's graphical user interface. Other, generally more complicated, tasks require the use of the Terminal's CLI. To perfrom a sequence of tasks, I often find myself switching back and forth between one or more Finder and Terminal instances to get the job done. If the two applications were combined into one, the transition between GUI-oriented work and CLI-oriented work would not be as mentally disconcerting. In addition, the strengths of both approaches could be combined to offset their weaknesses.
The Terminal would be embedded in the Finder as a splitter pane above or below the graphical view of the file system (according to user preference). The working directory of the Terminal could either be linked to automatically update during point-and-click navigation through folders or decoupled with a sync-to-current location button provided to update the Terminal's working directory. Special "pipeable" objects would be provided to redirect the results of Terminal commands to the current GUI view.
Here is a simple example to illustrate this:
1.) The user opens a new Finder window and navigates to a folder using the GUI.
2.) The user types a command in the embedded Terminal: ls *.log | FinderView.
3.) The results of the command are piped to the Finder's current view and presented graphically.
Obviously, there are many issues that would have to be resolved to make all of this work properly, but I think it would be worth the effort to create a hybrid CLI/GUI Finder-like application.
Spatial Finder, etc. (Score:5, Interesting)
My impression is that, when Mr. Siracusa speaks of spatial orientation, many times he is actually referring to basic consistency.
First points: labels and pop-up windows are a bit of a moot point, as they are coming in Panther. (Yes, I've seen builds.) So don't sweat it.
Spatial qualities are useful; however they are just that, qualities. The original Finder was very much in the vein the author describes; a window was a folder which contained icons that were your files. The current iteration of OS X, I might point out, pretty much sticks to this as long as you have the toolbar collapsed (that underused widget in the right side of the toolbar). Collapsing this toolbar will give you something very very similar to what we had before. Furthermore OS X takes it even futher with the use of packages - I'm surprised he didn't mention this - which allows whole applications to keep their guts in one place. Therefore the icon is the application now, as well. I could see Apple taking this further: imagine being able to install a Photoshop plug-in by just dragging it onto the single Photoshop icon.
Now, as far as spatially oriented interfaces being insufficient for the task of managing many thousands of files... there is something to that. The old Finder would have absolutely choked on certain computing situations common now (giant nested MP3/photo folders, for instance). It just doesn't scale to that many files cleanly.
Having said that, it shouldn't have to. A user generally has far fewer abstractions they are mentally adhering to than what is presented in your interface. I think this is where half-baked implementations like favourites really fall down. Favourites is a great idea. When you save something, or move something, you are generally thinking about the project you are working on. Odds are you have one master folder for this project, with several sub-folders divided the way you like. The data contained within these folders takes various forms (text, code, media). Depending on what kind of work you are doing, one 'view' that is entirely appropriate for say, code, is not appropriate for graphics previewing. You want to work in the view that is appropriate, and have it 'stick'. You don't want to drill through 'My Computer -> My Documents -> My Whatever' to get to it, if possible. This mixing of standard OS bits and pieces with your actual 'work' files is what causes people to lose their work in some loopy abstraction. While the idea of just having a filename field and a pull-down for a Save dialog is great, people just don't take the time to define Favourites as they are quite used to simply creating folders when they need them, and then navigating each time to that folder. OS X could do a better job by remembering which folder you last saved to, no matter what. I hate it when Flash constantly thinks I want to save Flash projects in the Flash application directory. If you could tell the OS, when you create a folder, that is is a project folder, and have it automatically add it to your Favourites (I like 'Projects', can you tell?), that would be spiffy.
So Mr. Siracuse's idea of Finder plug-ins is sound. I might just add that you only really need one plug-in, QuickTime, which can handle damn near anything you throw at it. What QuickTime can't catch, Quartz sure can (i.e. previews of PDFs and other vector artwork). The idea that the Finder should be an end-all to every kind of work is somewhat mad. The author's ideas about metadata are great, and I also think Apple is working on this (that Be guy they hired). I'm not sure about abstracting the Finder to a true 'browser' even more, I can't make up my mind on that. What I don't want to see is a schizo metaphor like Windows, where you have two distinct ways of browsing and no preference given to either (i.e. re
Re:Oh, wonderful... (Score:3, Interesting)
I think the article's flaw is on a different level. It's not that he wants spacial representation, but that he wants a specific spacial representation that he happens to be familliar with. He says "there must be a one to one relationship between folders and windows." This is not the only way to create a coherent spacial relationship, it's just the one he's used to. He's so convinced that he's right that he came up with this argument, wrote a multi-page article about it, and didn't think it through with the open mind he asked of his readers. A spacial interface, by his definition, only needs a uniform spacial representation for files and folders. The relationship between windows and folders he insists on was the result of a logical leap he made because it seemed obvious to him. He never justified it beyond saying that it was how MacOS 9 and earlier did it, and it never occured to him that there were other posibilities. There is no way he'll ever convince me that he's come up with the perfect spacial interface when he's shown that he's too short sighted to see more than one possibility.
Re:If Ars Technica is so concerned about usability (Score:4, Interesting)
There might be some useful information here [howstuffworks.com].
Re:If Ars Technica is so concerned about usability (Score:3, Interesting)
No it isn't. Paper is made out of wood. It's 'natural' color is a nasty dirty brown. We bleach the hell out of it to make it white.
off topic:
when I was in college, my professor was highlighting the volume of nasty chemicals used to process the things in our homes. One example was this: If you take a roll of toilet paper, soak it overnight in a jar of water, then drink the water, it'll probably kill you. Kids, don't try this at home.
A.
Re:OS X Finder Laundry List - Please add yours. (Score:2, Interesting)
"The Finder likes to sit for a moment and think about how it's going to perform the operation you told it to do. Copy the file, already. You've done it a million times, and you're wondering how this one is different?"
You're forgetting that it can very well be different from those million other copy operations. The Mac OS does (and always has done) so-called preflighting before initiating a copy. It checks to see if the item you are copying can fit onto the disk you're copying it to. This means that it will not try to write a file onto a disk that's full and then throw an error at you if it fails like most flavors of Windows do. It'll check to see if it can do the copy, and tell you to free up space or use another disk if it can't fit the item on the destination disk.
Additionally, imagine running five copy operations at once. Imagine that four copies run, but the fifth can't fit onto the disk now that you just filled up the disk with the four other copies. If the system didn't do preflighting, you would have no clue as to which operation failed. If things went badly, the system might have tried to write parts of each of the five files onto disk, failing to complete even one of them. Preflighting makes sure you know which copy operations were succesful and which weren't. It will also make sure that an ongoing copy doesn't fill up the disk while other copies are being written onto the same disk.
Essentially, you're screaming at the OS for being slow, while it's actually being smart for you. I imagine you'd scream at least twice as hard if the OS was faster but much more stupid -- like most other OSes.
Re:It's fun to violate DMCA... or not. (Score:2, Interesting)
Re:Oh, wonderful... (Score:3, Interesting)
As was pointed out in the article, people who are used to remembering file paths can handle non-spacial interfaces better than newbies. If you're trying to access a file buried four layers deep, the column view works fine if you can remember the path, but spacial orientation allows you to use OTHER clues (such as which corner of the window you left it in) to choose the correct folders to open on your way. This is more natural to people who aren't already used to dealing with file paths. For those of us who are used to dealing with file paths, it doesn't get in the way.
Yes, NeXTStep worked well. The people I know who used it are all intelligent people who are accustomed to dealing with file paths and would not have trouble with that kind of interface. My mother would be lost.
Labels: Worse than useless, at least in the incarnation we know from OS9.
I didn't use them that often, but I certainly used them. It's not something I usually thought about much - it was just another tool available to me, that I could use for various purposes. I could color particular icons to make them stand out, or apply different labels to affect search order. I remember taking a bunch of MP3s in folders sorted by artist, going through each one, and making any necessary corrections to the ID3 tags - then using labels to mark which artist folders I had finished going through. Obviously when I was done, I cleared all the labels - I'd never intended for the labels to be permanent. It was just a temporary thing, and there are other ways I could have done it (moved them into a "done" folder), but labels were there so I used them.
Sure, they could be better. You're right. How? Suggestions?
The "Finder Browser": I oppose the name pretty strongly...
Hush. It's not a web browser. It's a file browser. IMHO the Finder is long overdue for renaming, but having browser windows isn't a problem, and doesn't confuse people. "Finder" confuses people.
Live Searches: Interesting, but I don't think these should be part of the Finder, per se. Don't make them folders; make them documents.
I completely agree. You should be able to save a search as a sort of bookmark file, and when double-clicking it should open into a Search Results window much like the current Search Results window you get as a result from using the Find command.
Metadata: Hellz yeah.
Damn right.
OSX's lack of support for metadata: Um, OSX does support metadata. The problem is, as is the case with most of Apple's best stuff, there's no documentation on it, leaving developers out in the cold.
When OSX was initially released, developers were told that when saving a file, setting the file and creator types was optional, because the OS would simply use the file extension (which would be hidden from the user by default) to determine both. I wanted to smack somebody. The importance of metadata was downplayed by Apple, and now that they've maybe realized their mistake, some damage has already been done.
As a final note: with a Unix system, it isn't possible to achieve the one-to-one relationships between icons and files seen in OS9 and such. You can do it with windows and folders, which seems to be Siracusa's main beef, but it's impossible with icons and files, which may be equally important. The reason: hardlinks. Simply put, a single file can be in multiple locations in OSX; even HFS+ supports this.
True. Symbolic links appear as aliases, which is fine, but with hardlinks, the same file shows up in two places (with an icon in each place). However, I'm not convinced that this breaks anything. They simply behave as two separate files, that happen to share the same content. Each icon exists spacially (it can be moved around and positioned how you like).
The fact is, hard links aren't that common, and the average user isn't likely to see one. The more advanced user knows what they are and how to deal with them.
The UI for handling hard links could certainly be improved, but the existance of hard links doesn't break the entire paradigm.
How about... (Score:2, Interesting)