Slashdot Mirror


When Good Interfaces Go Crufty

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.

10 of 662 comments (clear)

  1. 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!
  2. 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!
  3. 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 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.

  4. 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.

  5. 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.
  6. 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.

  7. 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!
  8. 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.
  9. 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.