Slashdot Mirror

← Back to Stories (view on slashdot.org)

When Good Interfaces Go Crufty

Posted by timothy on from the skin-deep-is-an-important-depth dept.

An anonymous reader writes "A good article over at mpt on why good interfaces go crufty." A nice read before or after a visit to the Interface Hall of Shame.

40 of 662 comments (clear)

  1. My cruft-o-meter: by Longinus · · Score: 5, Funny

    Is the interface a command line? If not, it's crufty ;-)

    1. Re:My cruft-o-meter: by RustyTaco · · Score: 5, Insightful

      Find somebody who knows how to use AutoCAD and be educated on how GUI & command-line are not mutually exclusive concepts. AutoCAD has the GUI for all gui bits, but still has a command line for when it's easier and saner (think typing in desired dimensions instead of trying to fake it with a mouse) to type things in. As most people can type faster than they can take their eyes off what their working on, move the mouse to the top of the screen and guess at which icon is which it also seems to be great for switching tools & modes quickly.
      More programs really should allow that sort of functionallity. Now I have to see if anybody is working on it for The Gimp. :)

      - RustyTaco

  2. A bit of history... by acehole · · Score: 5, Informative

    GEOS on the commodore 64 had a good interface for it's time.

    yes kids, that's right! the c64 had a GUI.

    --
    Be you Admins? nay, we are but lusers!
  3. Re:pardon? by bumby · · Score: 4, Informative

    See http://info.astrian.net/jargon/terms/c/crufty.html

    --
    Hey! That's my sig you're smoking there!
  4. somewhat OT by zephc · · Score: 5, Insightful

    But I have karma to burn...

    I just wanted to know, WHY on earth MS would use the directory name 'Program Files' when so often installers and path names, etc. can only work with the 8.3 format and end up calling it 'PROGRA~1'. Plus, the space in the file path screws up some apps... just WTF were they thinking? Why not call it 'Applications'? At least that abbreviates to 'APPLIC~1' which sounds slightly less silly

    --
    "I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
    1. Re:somewhat OT by 91degrees · · Score: 4, Insightful

      Or even better.... Call it 'Programs'. 8 characters.

    2. Re:somewhat OT by Jugalator · · Score: 5, Informative

      Yeah, and that's especially annoying when software developers aren't aware of SHGetFolderLocation and hard code directory names like "Program Files". :-P

      --
      Beware: In C++, your friends can see your privates!
    3. Re:somewhat OT by Tim+Browse · · Score: 5, Insightful

      This one's easy actually - a friend of mine independently came to the same conclusion as me on this one, which is that Microsoft deliberately chose "Program Files" as both a 'long filename' and a filename with a space in it precisely to speed the adoption of long filenames. They did it to bring into sharp relief any program that didn't support LFN properly. Remember, Windows 95 was the time when they introduced their "Designed for Windows" logo, which at the time was a pretty big deal, and as far as I can remember, pretty much mandated support for LFN.

      The PROGRA~1 is ugly, but it only happens on old programs - I certainly now use it as an indicator of quality in a Windows app (it reflects how much the author respects the user experience).

      Now, if you want a real gripe, I hate the way most apps just plain don't work if you install them somewhere other than Program Files. I also hate the way most apps have a slavish belief in whatever path information they stored in the registry, meaning you can't ever move an installed app. I try to make my own apps as location agnostic as possible (Mac users: feel free to gloat at this point, with considerable justification).

      Tim

    4. Re:somewhat OT by Amazing+Quantum+Man · · Score: 5, Funny

      C:\Windows is the same in all language versions,

      Really? Then why does my Win2K install have C:\WINNT, but no C:\Windows?

      --
      Fascism starts when the efficiency of the government becomes more important than the rights of the people.
  5. Crufts - Not only software! by krazyninja · · Score: 5, Informative

    Though the author points out crufts only in software, these are prevalent in other places too, including interfaces to portable devices. I have a similar document on portable device interfaces here.

    It comes out of designing without taking into account user actions and reactions. This subject is un-fashionably called "Industrial Design", but is becoming fashionable again....

    --
    "Do something man. Right now."
    1. Re:Crufts - Not only software! by Anonymous Coward · · Score: 5, Insightful

      Good user interface is hard and even though the author claims that "we have the technology now", some of the ideas just reflect his personal preference and are not really the obviously better design. Many times the interface which users would find "working as expected" requires nothing short of magic (or artificial intelligence, whichever arrives first). "Industrial design" has one major advantage over user oriented design: It's learnable. Learning a system which itself adapts its behaviour to the user can be really frustrating and time consuming because it follows more complicated hidden rules. That's why "power users" turn off as many automagic functions as possible.

      The real user interface crimes are when well researched principles of perception are ignored: Making every icon round by dropping the actual icon into a marble of colored glass may be pleasing to the eye, but it's working against the way we recognize patterns. Adding bevelled lines around and between everything, even when there is no logical or functional separation, makes user interfaces distracting. And those are just the worst offenders in the graphical representation area.

    2. Re:Crufts - Not only software! by corporatemutantninja · · Score: 5, Insightful

      Well, you wrote my comment for me, but I'll add that the author tries to deflect this sentiment at the end by implying that anyone who disagrees with his preferences has obviously just bought into the dominant paradigm. ("But I *like* QWERTY..."). I suppose the proper reponse to him is, "If you're under 25 years old you obviously haven't had enough time to really think about this problem." And some specific criticisms: - Lots of modern software does, in fact, automatically save your documents. But by doing at least one manual save you get to pick a name and a location so you can find it again without needing Autonomy built into your computer. And while I like that the computer saves its own copy for safety, I specifically do NOT want it overriding the master copy without permission. - On Mac OS X the file picker does in fact look exactly like the file manager, with a few extra buttons around it. - I read his criticism of the "Quit" function several times and still don't understand his gripe. Yes, our computers can multi-thread so we can run multiple applications, but they have limited memory so we can't run EVERYTHING at once. And I for one would rather control which ones are running rather than wondering what my computer chose to quit. Also, Windows doesn't behave as he describes...close the last window and the application quits. Finally, there aren't any "mystery" menu commands unless you don't actually look at the menu bar when you use hot keys. I will admit that the "invisible application" phenomenon can be confusing to new Mac users, but I disagree with MPT's prescribed solutions. The current state is less "cruft" than it is the lack of a perfect alternative. Overall grade for mpt's "cruft" essay: C+.

      --
      Actually, I was trying to be Insightful, not Funny.
    3. Re:Crufts - Not only software! by arkanes · · Score: 4, Informative

      The file dialog on windows is an extension of the Explorer shell, as of win2k - you can do just about anything in it you'd do in the shell. Properly behaving apps get the new dialog automagically, poorly coded or badly behaving ones rolled thier own or hardcoded the style, so you're stuck with the nasty ones.

  6. Why do we have to save our work by hand? by Svenne · · Score: 4, Insightful

    Well, I'll tell you why. In the article, the author compares a wordprocessor to a pen and a paper, where everything you write gets "stuck" on the paper, while in the computer world you have to manually "Save" the work before anything really gets written. This, he deducts, is an arbitrary obstacle, and not intuitive at all.

    On the contrary, my dear Watson. What if I change something in my Word document, but later on decides it was no good and wish to discard it? Nope, sorry. My old document is already rewritten with no turning back. Or is he suggesting that everyone should always make a copy of a document before editing it, just in case? Wouldn't THAT seem terrible unintuitive?

    The "Save" function is one thing that separates the wordprocessor from a real pen and paper, and it certainly has it's uses.

    --

    Slagborr
    1. Re:Why do we have to save our work by hand? by panaceaa · · Score: 5, Insightful

      Or is he suggesting that everyone should always make a copy of a document before editing it, just in case? Wouldn't THAT seem terrible unintuitive?

      I really like the article's idea. I've lost a lot of work in my lifetime due to software crashes, power outages, or clicking things without thinking. On the other hand, it's not often that I change things temporarily and then revert back to the saved version. (Probably 20 to 1 ratio) With this paradigm, it'd be easy to get in the habit of marking a document as 'temporary' with all the benefits.

      It might make even more sense when content management platforms mature. These platforms keep track of different versions of a document, allowing you to revert back or see document evolution with ease. Then you can have it both ways, your latest changes will always be saved, and you can revert to previous versions. But of course, then you'd have the non-intuitive 'Save This as New Version' button, since you wouldn't be saving your documents manually anymore.

      --
      my blog
    2. Re:Why do we have to save our work by hand? by Katravax · · Score: 5, Insightful

      There are already programs that support undo past save. If we do something intelligent like get rid of the save command, we should also do something intelligent like undo past save. For the file-size whiners (like myself), we could have the option to lose prior undo information to reduce the file size.

      File systems that support multiple streams (like NTFS) could save undo information in a separate stream. "Not everyone has such a file system," you might say. I say, whatever -- if we're talking about moving forward here, we'll have to go past FAT and other beginner's file systems.

      We're not talking about taking away something that's required for usability today. We're talking about improvements for the next generation. Get over your "Save" command. You'll be able to undo beyond the automatic save.

    3. Re:Why do we have to save our work by hand? by photon317 · · Score: 5, Interesting


      I wrote a GTK+ text editor that saves the document on every keystroke with a frequency limiter so that you don't save more than once every 5 seconds. It used a background thread for the saving so the user interface didn't hiccup, and every save file contained a complete undo/redo history to the beginning of the document's life. It had no save buttons, only "open" and "close". I never finished it because it was plaintext-only anyways, so nobody was ever gonna use it.

      --
      11*43+456^2
    4. Re:Why do we have to save our work by hand? by Ed+Avis · · Score: 4, Insightful

      It might be better to unify the 'undo' and 'save/load' functions, so that loading an older version is a kind of undo. But there needs to be a better way to navigate back to these old versions.

      IMHO all desktop apps should have built in version control, so instead of File->Save you do File->Tag this version and give it a description. All editing changes are saved to disk immediately they are made (this is only a few bytes per second, no problem on modern machines) and you're prompted to make another version tag before quitting the app.

      There's no longer any disk space argument against saving all versions of the document, all the time. At least not for wordprocessing and most 2d graphics, small spreadsheets etc.

      Collaborative working with merging in different sets of changes (a la CVS) would be tricky to implement, depending on the application: it might require storing a list of commands executed rather than the current state of the document.

      --
      -- Ed Avis ed@membled.com
    5. Re:Why do we have to save our work by hand? by Shimbo · · Score: 4, Interesting

      Like an eraser, or a bottle of tippex, that's what the "undo" button is there for. All this means is that the save process has to be a bit more sophisticated and store the last n changes.

      A more sophisticated file system could help us there. During the day, we rsync the development areas every 15 minutes. It takes a trivial amount of space and CPU time. Yet for years I was stuck in the metaphor of doing nightly backups and telling folks they couldn't get back the files they changed in the morning.

      The point is that saving files or versions in case we stuff things up shouldn't be our problem. We should have 'hard' commit points (this is a published document/reviewed code). Between then 'soft' checkpointing could be managed by the OS.

    6. Re:Why do we have to save our work by hand? by kcbrown · · Score: 5, Insightful
      Version control is something any user-friendly system should handle automatically. It seems to me that programs should automatically save the diffs against the previous version and should save the full version on a very regular basis (with saves happening after a relatively short timeout or after a certain amount of changes have been made, whichever comes first). Reverting to an old version is a matter of applying the diffs in reverse to the current version. You should always be able to drop back to any previous version you want.

      There's no need for a "save as new version" button: the program will do that automatically when you exit, when you switch to a different program, or when the timeout/max diff condition occurs.

      What is needed in addition is something that should be intuitively obvious: "create a new document based on this one". This will create a "fork", and doing so will cause the program to ask you by what name you'd like to refer to the new document (as it should whenever you create a new document). Perhaps this is what you were talking about.

      We've gotten so used to working with low-level files that methodologies like this get discarded automatically by developers. But that should be done only if there's a lot of hard data that shows that users actually have a harder time dealing with it that way. That may be true of users who are used to dealing with files, but I strongly suspect people who are new to computers will have an easier time with an application that doesn't know about "files" but only about "documents". The system should keep track of the mapping between the two, and the filestore should never be seen directly except with a tool designed to manage it.

      All IMHO, of course.

      --
      Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
    7. Re:Why do we have to save our work by hand? by hacker · · Score: 4, Informative
      File systems that support multiple streams (like NTFS) could save undo information in a separate stream. "Not everyone has such a file system," you might say. I say, whatever -- if we're talking about moving forward here, we'll have to go past FAT and other beginner's file systems.

      VMS has done this for a decade or more. Every time you edit a file, you get 'file.txt;1', 'file.txt;2' and so on, which you can pick up at any point and continue editing. It's semantically similar to cvsfs, where every file saved revisions itself. Implementing cvsfs globally could be "A Good Thing[tm]" overall.

  7. I recognize this... by HiQ · · Score: 4, Informative

    "software archeology"

    I work day in day out on a ten year old system. I do not use the term archeology, however I frequently find what I call 'fossils'. Parts of code that are still there, but are never executed. Fields of the database that should have been deleted but are still there, and are still updated, though no program ever uses them. A system has to be sufficiently large however, to experience this. But actually funny to read about this.

  8. Flawed by Mr_Silver · · Score: 5, Informative
    Whilst the author makes some good points, there are plenty of flaws in his reasoning.

    Fortunately, technology has improved since the 1970s. We have the power, in today's computers, to pick a sensible name for a document, and to save it to a person's desktop as soon as she begins typing, just like a piece of paper in real life. We also have the ability to save changes to that document every couple of minutes (or, perhaps, every paragraph) without any user intervention.

    Yes we do, but for starters a computer is a tool. You tell the computer what to do, the computer does not tell you. Sure we have autosave, but any sensible application auto-saves to a different filename so that if you decide to abandon your changes, you can just quit, not save and revert back to your original format. If you quit a document, you'd still have to agree. What happens when you do want to commit those changes to your file but you don't want to quit? You have to "save".

    Fortunately, technology has improved since 1984. We have the power, in today's computers, to run more than one program at once, and to load programs in less than five seconds.

    Here the author obviously hasn't used a PocketPC. With the PPC its very very easy not to close applications. What happens? The system slows down to a crawl as it tried to run 5 or 6 different applications. Again, this is the user being in control of the computer. I want the ability to close applications when I'm not using them. That is my decision, not the computers. It's the desktop analogy. Once i've finished with a book, I put it away because otherwise my desk gets cluttered. I don't leave it out because otherwise my desk gets full and working becomes a problem. Sure, we could get around this by having the PC unload or suspend applications that aren't used in a while - but how does it decide? Just because I've not typed something into Word for the past 30 minutes doesn't mean that I'm not using it. You'd get to the point where the cleverness of the OS/Application was causing me more hassle as it tried to be helpful and suspend stuff for me.

    Fortunately, technology has improved since 1984. We have the power, in today's computers, to run more than one program at once, and to run the file manager all the time. We can open documents from the file manager without quitting all other programs first, and we can save copies of documents (if necessary) by dragging them into folders in the file manager.

    What about if the application is taking over the whole of the desktop? I'll have to minimise and then drag. Having said that though RISCOS (I think, the one on the Archimedes) used to allow that. You hit Save and the icon appeared for you to drag somewhere. Best thing was that you could drag from one application into another to have it load in there. Neat. But very wierd.

    As for inode stuff, sounds neat. But I know so little about that type of thing, I wouldn't even know it's feasible.

    So in short, some good ideas, but some of them just aren't practical or possible and would end up being a bigger annoyance than it currently is.

    --
    Avantslash - View Slashdot cleanly on your mobile phone.
  9. Skinning == crap! by SexyKellyOsbourne · · Score: 5, Insightful

    One thing I hate is the "skinning" of everything, particularly media players. It was popular for mainstream kids software, and it worked okay there; but for everything else, the standard GUI (preferrably written with something nice like WxWindows) should be the only thing that is used. If I see something with colorful, bubbly bitmaps on the gui, I probably won't use it.

    What is intuitive to us is what is standard -- adding new buttons with new pictures, new dials, and other things in a single instance interface only confuses everyone. Even if some of the properties are inefficient, regular GUI standards are the way to go.

  10. More cruft! by krazyninja · · Score: 5, Insightful
    The most annoying one I have found is when you are typing away madly at the keyboard, and this window pops up saying "xxx yyy operation failed", or "zzz download complete". It does two agonising things:
    1. The alphabet you are typing corresponds to a shortcut in the window, and the window happily closes itself, having done god-knows-what-damage-it-did.
    2. It slows down your pace, disturbs your thinking process, and by the time you close the window and move to the position you were in before, one more word gets added to your swearing vocabulary.

    --
    "Do something man. Right now."
  11. He has a point but he dosn't get it!!!! by Slashamatic · · Score: 5, Informative
    I agree with the general point about cruft accumulating in old s/w but the guy gives some very bad examples.

    In a) he talks about the use of inode numbers as an internal reference used by the system. Regrettably, inodes and other equivalent internal reference numbers used by other file systems under other alternative operating systems can move around. Generally opening by inode is only recommended after first opening by name.

    Having more than one pathway to a file as mentioned in d) in windows is most definitely a feature. For engineering reasons a manufacturer may want to keep a set of files from related applications together, however to the user they may be presented somewhat differently. If anything this is an improvement of interface because of the separation between external and internal representations.

    As for the problems of moving applications around, that is also an issue with meta information held in INI files or the registery. It is quite possible to make a program easier to move (i.e., by including code to update the file locations), but this isn't often done.

    The file/folder metaphor may have probems for newbies but the only real problem is that file (particularly with Unix style file systems) may have more than one name. This is a feature not a bug.

    1. Re:He has a point but he dosn't get it!!!! by BlueGecko · · Score: 5, Insightful
      Having more than one pathway to a file as mentioned in d) in windows is most definitely a feature. For engineering reasons a manufacturer may want to keep a set of files from related applications together, however to the user they may be presented somewhat differently. If anything this is an improvement of interface because of the separation between external and internal representations
      No it isn't; it's a kluge to hide the fact that applications have gotten more complex and Microsoft wasn't prepared to deal with it. On the Macintosh, until about 1995, applications, generally speaking, did not need support files. You had the application, you had a preference file, and possibly you had an extension or two, but the application usually sat by itself. However, at about that time, both in response to Windows and in response to the fact that applications simply were getting far more complex, most applications began having massive numbers of support folders. Macs just ignored the implications and kept on treckin'; Windows adopted the solution you mention.

      But Mac OS X, and OPENSTEP/NEXTSTEP before it, manage to keep the Mac metaphor while still hiding the implementation details, and it does it much better. Each application is actually a fairly complex directory structure, and all support files can be hidden within the application itself. This can include movies, help files, whatever--you name it, it's there. Now, to the user, you still have just the application, but the application can suddenly be dragged around at will without disturbing anything. For the application, you now can also guarantee a very rigid directory structure that the user can't even mess with. Next time you're on an OS X system, control-click a program and choose "Show Package Contents," or, if you prefer, cd right into the app. You'll see what I mean.

      That's the right way to solve the problem, and that's why he's slamming Windows' metaphor and lauding ROX/OS X app wrappers/packages/bundles.
  12. Did I read that right? by flippet · · Score: 5, Insightful
    We have the technology. So why do we still punish people by including "Quit" or "Exit" menu items in programs? Cruft.

    So we should get rid of ways to close programs? I dread to think how much you'd have running if the computer is on for more than an hour or two.

    Phil, just me

    --
    "Cattle Prods solve most of life's little problems."
  13. Think beyond the today by Katravax · · Score: 4, Insightful

    Some people are posting that they can't undo past a save, or don't like the slowdown of multiple apps, etc. By the time we can lose the cruft the author is talking about, you won't have that problem. The system will intelligently swap out applications and you'll be able to undo past save.

    If you're fighting for reasons we need the crappy methods we have today, the very methods the author was talking about, then you haven't thought it through. It's obvious there's a better way than we have now. It will take some intelligent design and programming to make it happen. That's all. We're smart enough to figure out how to make this happen, and shouldn't screw it up making excuses for why we have to keep old methods around.

  14. thought-provoking, but no alternatives by X_Caffeine · · Score: 4, Insightful
    Like most other articles and editorials that criticize GUI design, he points out a lot of flaws, but few answers.


    Oddly enough, most of his complaints about the handling of files are being addressed in the next Microsoft file system, that's reportedly being based on ODBC (effectively turning the entire file system into a massive database -- the BeOS guys tried and failed at doing something similar).


    Perhaps the Windows right-click-drags he vilifies should be an "advanced feature" that has to be turned on manually, and maybe it isn't magically intuitive, but damn, I'd sure like to see him come up with an alternative that allows a user to quickly and easily take files and copy, move, or alias them with a single gesture this easily.

    --
    // I will show you fear in a handful of jellybeans.
  15. About menus by jeti · · Score: 5, Insightful

    Slightly OT:

    Did you notice the different feel of menus in
    common GUIs? Without tricks, it would be hard
    to select submenus. You have to keep the mouse
    pointer in a narrow 'tunnel'.

    MacOS Classic works around that problem by using
    a V shaped buffer zone. If you move your mouse
    to the right within a certain angle, the submenu
    doesn't change.
    MS used an inferior workaround. Submenus open with
    a delay, and you have to select them slowly or they
    won't open at all.

    KDE submenus work like the Windows ones. Gnome
    behaves like the old MacOS. Sadly enough, menus
    in MacOS X now work like the ones in Windows.

    The worst implementation is used by Swing.
    Submenus open with delay, but close without one.
    You have to wait for a submenu to open, and when
    your pointer leaves the tunnel, it vanishes instantly!

    1. Re:About menus by Mr_Silver · · Score: 5, Informative
      MacOS Classic works around that problem by using a V shaped buffer zone. If you move your mouse to the right within a certain angle, the submenu doesn't change. MS used an inferior workaround. Submenus open with a delay, and you have to select them slowly or they won't open at all.

      The reason for this is that during the many studies and research that Microsoft did into user interfaces it found that users did not like the fact that the sub-menu option appeared immediately. They actually found it less intimidating when it appeared after a second or two.

      It also reduces screen clutter. As you move up a set of menus, their sub-menu doesn't appear until you come to rest on the option you want, rather than all the sub-menus popping open and then closing again as you move. Having all these sub-menus flashing about tended to unsettle users.

      Having said all that, there is a registry setting that can increase or decrease this to any number of milliseconds you want. I've no idea where it is, but I do remember TweekUI allowing you to change it.

      --
      Avantslash - View Slashdot cleanly on your mobile phone.
  16. Many good points... by jonr · · Score: 5, Interesting

    I agree to many points. Modern GUIs use a lot of crutches to make them self workable. Some problems and wishses:

    My favortie is the Save/Open Dialog box, a relic from the single tasking days, why do people use crippled version of the file browser? Risc OS did it correctly, drag an icon from the app to the browser, or even other application!
    Just get rid of the File menu all together.
    Finding files is still a chore, I do miss BFS instant and always up to date live queries. Can we please have that, Apple/Microsoft/Others?

    Installation of applicatons, what is up with that? Why can't I just copy a file from the CD/Net and be done with it?

    File ID's are good idea, I could move apps/files around on BeOS and my shortcuts still worked!

    Why can't we implement version control transparently in the filesystems? Hardly due to lack of space? Each save creates a new version. Word processors could even use intelligent versioning, like making a new version for each paragraph or chapter. Does Photoshop save undo in its files?

    Right now I am using very Explorer-like client for CVS, and it doesn't matter if I am browsing my hard drive or some remote server in Elbonia, it all looks the same, wonderful! :)

    I have been using XP for a while now, and it is making me quite frustrating. Why can't I use all that NTFS has to offer? (AFAIK, NTFS is pretty close to BFS in features, not sure about Live Queries, though)

    What else... yes... Use open standards when data leaves the application!!!!. I can't <em> this enough. BeOS sort of did this with it's Translator service. Your image viewer/editor didn't even have to know how to load/save JPEG or PNG files!

    Well, enough of this rant. :)
    J.

  17. The cure is worse than the disease. by tlambert · · Score: 5, Insightful

    Personally, I don't like cruft, but the way he wants to "correct" some of the things he doesn't like, well... the cure is worse than the disease.

    My idea of hell is an editor that auto-saves code that I'm in the process of hacking up in an editor to let me think about the problem over top of code that already works.

    My idea of hell is a platform where every document I've ever opened has no way to close it and no way to exit the application that's got it up in a window, because there;s no 'Quit' or 'Exit' option.

    My idea of hell is not being able to drag something in a GUI from one folder to another, because they have an obscure "parent of my parent" relationship, which makes me have to cut and paste the document, instead of just dragging it, because I on;'y have one file manager, which is running all the time, instead of a "file picker".

    My idea of hell is symbolic links that get changed when I rename a file out from under them because the OS thinks it knows what I want better than I do, so it's impossible to replace a file with another, while keeping, and the old one, unless you copy it, rename the original, rename the copy, and then edit the original (instead of replacing it).

    -- Terry

  18. Cruft alternatives have already died by dpilot · · Score: 4, Interesting

    For the most part, we have only ourselves to blame for this cruft problem. Alternatives have already been brought to market and died. Maybe we were short-sighted consumers?

    Example 1: Single-level store
    Actually this one survived in the market - sort of. It was part of the old IBM Future Systems effort, and made it out the door as the System/38, with followons in the AS/400 and iSeries. Single level store says you get rid of that silly distinction between RAM and disk - everything is memory. What we quaintly call main-memory is merely another level of caching to the disk, which is the real memory. Then you make the big thing a database instead of just a filesystem, and it can readily solve pretty much all of his numbered problems in one fell swoop. Was this perhaps something like Longhorn, only about 20 years ago?

    The System/38 and descendents has met with success, largely as the closest thing to 'just plug it in and run' that has made it to market. At another level it hasn't been that successful, largely because of its unconventional and rather opaque system model.

    As an interesting aside, IBM's first entry into the workstation arena, the Romp microprocessor, also had single-level store capability. (actually expressed in inverted page tables) Then in order to make it more Unix-familiar they mapped a conventional filesystem on top of that. I don't know if Rios and PowerPC followons retained that capability or went to more conventional paging architectures.

    Double aside: Romp/Rios/PowerPC are yet another fallout of the Future Systems effort. Any big project has a backup plan, and one of the backup plans for FS was the 801 minicomputer, the original RISC.

    Example 2: The OS/2 Workplace Shell
    Just a bunch of UI glue, but what a bunch of it! It directly solved the broken link problems, and had a more consistent, if different set of mouse semantics. It also has a group feature that kind of got around his 'quit' problems.

    But I disagree with overusing the inode the way he suggests. The inode is an internal structure and isn't meant to have a UI-level life. He really wants access to Data, not to Filename or Inode. Does he really want a database-type filesystem?

    My own fantasy is a semi-conventional filesystem, but instead of a conventional directory structure use a semantic network. The role of directory navigation is taken on by relationships. It's an incomplete idea at the moment, though.

    --
    The living have better things to do than to continue hating the dead.
  19. Smacks of Negropontification. by thatguywhoiam · · Score: 5, Interesting
    (as in the former Wired columnist)

    As off-base as I think the author is, it's good to think this way. Even if it's not practical or better.

    Save is an advantage, not an obstacle. The article's author limits the use of Save to things like Word-processing (immediately betraying his experience with more esoteric formats). As others will surely point out, Save can save you when something you're working on goes on a tangent. Besides, Word (and others) can AutoSave.

    Launching/Quitting programs, while arguably cruft, has been accepted insofar as people do like the tool metaphor. You use a jigsaw to cut complicated shapes in wood. A screwdriver for attaching things. Photoshop for graphics, etc. Although I will admit Quit is getting a bit weird... esp. on modern systems like OS X, where there isn't that much of a reason to Quit things. I still do it out of habit.

    Filenames are... well, filenames, and they don't seem to ever change. I don't really see a disadvantage with a 256-character filename. The dot-3 suffix is a bit of an anachronism, but it's a comfy one, one that gives the user a bit of metadata as well as the computer. Windows' behaviour of only recognizing files with certain suffixes in file dialogs by default has reinforced this.

    I don't know what he means by the File Picker. I launch/pick stuff from the Finder all the time.

    What I'd really like to see is a better representation of relationships between files. Something akin to The Brain, or another derivative of Xerox's Hyperbolic Tree structures. Radial menus, with branches running in various directions to the related objects/files, have been proven to be more effective than lists of data (there's something humans like about remembering angles as opposed to just the names). People themselves need a better representation, too. iChat has taken baby steps towards this, but really, ponder for a moment; why can you not see the heads of all your friends popping up on your desktop? Why is it that we have to 'browse' for other people, either through an AIM window (another list) or some such mechanism? If I get an email from Mike I want to see a mail icon next to Mike's head. I want to send files to Mike by dropping them onto his head. I want to see *everything* that is related to Mike at a click.

    Also, to mention another pet peeve: themes. People love themes. People abuse themes. There is a need here that has never been addressed fully, IMHO - the problem is that people are dressing up the cosmetics of the interface while doing nothing to change the behaviour. It's sort of ridiculous to think that we can come up with a Swiss Army Knife interface that will be maximally productive for all conceivable computer tasks. I've actually taken to creating several different accounts on OS X, each with their own specialized settings. If I'm doing graphics work, I want everything to look like a light table; big shiny icon previews, sorted by meta data (time photo was taken, type of graphic, etc.) If I'm doing coding, I want list views or column views everywhere, and lots of reporting tools running on the desktop (bandwidth, terminal). There really should be interface schemas that can switch on-the-fly to whatever sort of task you are engaged in.

    --
    If Jesus wants me it knows where to find me.
  20. Does anyone else see the irony... by bmabray · · Score: 5, Funny

    ...in the "Interface Hall of Shame" using frames? :-)

    --
    human://billy.j.mabray/
    "Every good system has a backup." -- Dale Hanchey
  21. Save and Exit by Bugmaster · · Score: 4, Insightful
    Much of the stuff he says is true. However, I think the author gets carried away when he declares the "Save" and "Exit" commands as "Cruft!".

    These commands are, IMO, actually examples of good interface design. The (unwritten) rule these commands are implementing is,

    A program should not try to outsmart the user
    Let's say the "Save" command was automatic. Where are the files saved ? Under what name ? How often ? What if I made a mistake, and want to restore the old file -- is it possible ? How far back can I go ? Infinitely back ? What if I don't have infinite disk space ? Etc. etc. Instead of making a program that would try to solve these questions for all people and all applications at once, I can simply tell the user, "look, when you want to permanently persist your document, hit Save". This is a lot better in the long run than a program that would overwrite your files every so often because it feels like it.

    Similarly, the "Quit" command is useful. Without it, applications would just pile up on the screen and in RAM. When I am done with writing my letter, and want to play some Warcraft 3, I want to close MS Word and open WC3. It's very natural; just as when I am done working and want to go to the beach, I take off my suit and put on swimming trunks. If I could not quit any programs, they would pile up like layers upon layers of dirty clothes -- media players, web browsers, p2p programs, text editors, word processors, compilers, virtual machines, graphics editors... and that's just what I use before breakfast ! Yes, it would be nice if we had infinite CPU, RAM, disk space and screen space, but we don't, so the "Quit" command is the next best thing.

    Note that, ironically, on single-threaded OSs, such as PalmOS, the Quit command is actually not neccessary. There, it makes a lot more sense to just save the state of the current program when you want to run something else, then restore the state when you reactivate the program. This only works because you can run one program at a time, and that's it, so there's no room for confusion.

    Contrast the ease of use of the "Save" and "Quit" commands to other commands which have been implemented as automatic agents, just as the article suggests. MS Word's "auto-correct" (more like auto-confuse), Visual Studio's auto-complete (it knows best what function you want to call) and that damn paperclip all come to mind. My computer is not psychic (yet); it cannot sense what I want to do. If it tries to predict what I want to do ahead of time, it will fail and mess up.

    --
    >|<*:=
  22. Strongly disagree with the 'save' comment by w3woody · · Score: 4, Insightful

    I strongly disagree with the author's comment about saving documents, but not for the reason that most people think.

    The problem with eliminating save and only having one version (the version that is currently open, which is reflected in the file on the disk) is that you eliminate a primitive sort of "versioning" where the saved document on disk represents an older version of the document. The "save" command becomes a sort of "push current version out" and "revert" becomes a sort of "roll back changes to last version."

    Now I would happily eliminate the "save" menu from my programs, but only if we could replace it with a "mark version" and "rollback version" command which would allow me to maintain several versions of the same document. That is, I wouldn't mind if we created a word processor which saved the current version of the document to disk as it was typed, but only if I have the power to mark different document versions and either roll back to an older version or mark the contents as the current version in that file.

    I strongly believe this is the reason why eliminating the "save" command was not accepted by MacOS usability testing when they were working on OpenDoc. OpenDoc eliminated file saving entirely, and users hated it--because users were using the "save" command and "revert" command as a sort of "commit changes/rollback changes" command--that is, as a primitive way of version control. And OpenDoc, by eliminating the save command, took that away from users.

    Don't take away file version control; give me a more powerful version of it!

  23. Code Archiologist by Bill_EEE · · Score: 4, Insightful

    I worked on a very valuble system as a code archiologist. The legacy system was in a million dollar a piece semiconductor furnace. Doing the work involved grepping through old C code that was written by a brillient assmebly language programmer.

    If code is working and shipping you don't throw it away. What I did was decouple the various patterns that I found and made something that was more modern. I did all of this work in C. It involved a lot of grepping and creating interfaces.

    Just because code is old an kludgey doesn't mean that it is not valuble. Elegance is getting paid a million dollars for a device that only costs a fraction of that to manufacture.

    Bottom line: if you don't have the cash you can't stay in business.

    There is a difference between bad code and old idiom code. Archaic code that is shipping and works is much more valuble than pie-in-the-sky new code that no one wants. ;)