Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Computing Pet Peeves? 184

Posted by Cliff from the things-programs-do-to-piss-you-off dept.
Matthaeus asks: "I'm a 3rd-year CS student who will most likely be writing end-user applications after graduation. Naturally, I would like my apps to sell well, so I want to minimize user annoyance as much as possible. In an effort to improve my coding skills, what are Slashdot readers' biggest pet peeves when it comes to software? For example, my largest pet peeve is when a program steals the focus from another program while I'm typing. Maybe other software developers could take notice of this discussion also."
This discussion has been archived. No new comments can be posted.

Computing Pet Peeves? More

Computing Pet Peeves?

Comments Filter:
  • Not so much a part of programming, but cookies on websites that have no legitimate reasons to use them annoys me a lot.

  • Pet Peeves/requests of an HCI designer (Score:5, Insightful)

    by base3 ( 539820 ) on Thursday February 21, 2002 @08:40AM (#3043835)
    1. There should be a way to do anything with your hands on the keyboard whenever possible.
    2. The Escape key should always do just that.
    3. If the app is going to try to hold my hand, give me the option to turn it off.
    4. If it's a Windows app, follow the darned CUA guidelines [amazon.com] !
    5. If there's an operation that's going to take a long time, give me a progress indicator.
    6. But if you're going to give me a progress indicator, make it mean something--don't let it move across like the progress bar on MSIE when it can't connect to a site.

    I'm sure there are about a hundred more that I can't think of this early in the morning. Good luck!

    • Who is your audience? (Score:3, Insightful)

      by lupetto ( 16876 )

      What an average slashdot reader wants in a program is completely different than the vast majority of computer users.

      The majority of people on slashdot are programmers, unix administrators, and the like. These types of people usually want different things than most mainstream computer users.

      If you're going to write opensource software, go ahead and follow their advice.

      If your intention is to make money, take a look around and see what programs are making the most money. Say what you want about Microsoft and AOL, but you can't deny they make a shitload of money.

      My best advice is this: Ignore everything you read on slashdot. Look at which software companies are making the most money, then try to determine why people are spending money for their programs.
    • I want a progress bar, and I want it to be accurate

      You can't always. Sorry. Your example illustrates why, even. MSIE doesn't know how long connecting to a web site and downloading a page is going to take. Neither does Netscape or Opera. that's why none of these have an accurate thermometer bar as a progress indicator. They do have a 'I'm still doing something' animation, though. Which is about as good as you're going to get for some tasks.
    • Amusing anecdote about progress bars:

      In one project I worked on, there was this homemade progress bar which would update about 4 times over the course of connecting to a piece of hardware (which took about 15 sec.). Since it only updated a few times, there were several times over the course of these 15 seconds where nothing would appear to be happening (keep in mind, a wait of just a few seconds can seem very long and be very distracting, especially if it is something you are doing repetetively). Since it was connecting to external hardware, every time the progress bar would stop moving, you would reflexively think, "did it stop because of an error, or is it still connecting?"

      I got really annoyed with this progress bar, especially since I had to do about a million connects to verify my fixes, so I threw in enough extra updates to the progress bar that it kept on moving the whole time you were connecting.

      Boy, were the customers impressed! I got a bunch of calls about how much faster and more reliably the software was connecting to the hardware. Of course, it wasn't connecting any faster, and this was before I had fixed any real connection bugs, so it wasn't connecting more often, either. It is just that when it was working, you knew it was working, and when it failed, it stopped right away.

      The lesson I got from it is that user feedback is what creates the user's perception of what is going on. If a progress bar keeps stalling, the user's intuition is that the program is having some sort of trouble completing the task.

      • I remember a Umax scanner with a progress bar that updated only twice during a full-page scan. It sat at nothing for two of the colour passes, then jumped to 66%, then sat there for the last pass, then jumped to 100% then sat there for ages while the data was transferred to the Mac. Every time. Since then I have taken progress bars with a grain of salt.
      • I just installed Windows 2000 for a friend a couple of days ago. When I was copying over his old stuff (HD to HD), the progress bar kept jumping up the wrong way. When it hit '941873 minutes remaining,' I took a screenshot. Too funny. Yeah, I'm gonna wait a little over 654 DAYS for Windows to copy 2 Gigs of data. :-P
    • The Escape key should always do just that.

      I'm pretty sure "Escape" means "begin an escape sequence" (ie, ASC 27 xx xx xx). While we're on the topic of legacy key names though...

      The Return key doesn't return anywhere.
      The Scroll Lock key doesn't prevent scrolling.
      The Break key doesn't break.
      The Print Screen key doesn't print.

      We forget about those crazy, legacy key names and ignore them, but I'm always impressed how new users gravitate towards them and (reasonably) expect big results!

  • windows registry (Score:4, Insightful)

    by fist_187 ( 556448 ) on Thursday February 21, 2002 @08:41AM (#3043838) Homepage
    call me old fashioned, but i hate it when programs use the windows registry- especially the "small" gimmicky ones that i'm probably going to delete in a month anyway. IMO, unless you write a program that depends heavily on the registry, use an .ini file instead. it makes the program easier to uninstall and makes windows overall less bloaty while you run it.
    • Well, not always...?

      PuTTY [greenend.org.uk], a free ssh client for windows, is a single file with no installer. It saves its settings in the registry, and personally, I prefer this, since it means I just have to delete one file to uninstall it. I can download it to a friend's computer, throw it on the desktop, and not have to hunt around the desktop for the prefs file it created when I want to delete it.

      Sure, it leaves a few registry keys around, but as long as they're innocuous, I think that's a better solution that creating a file every time?
      • Well, strictly speaking, the program should

        a) come with an uninstaller;
        b) said uninstaller should wipe the registry keys

        • for this example... PuTTY does have a command line option to clean up its registry mess....

      • I would find it much more convenient if PuTTY would store its settings in a "putty.ini" file or whatever. That would be easier to move to another computer as needed. (It can be done now, by exporting the appropriate part of the registry.)
        • If you do save things in the registry, provide an import/export function so that you can take your settings with you when you upgrade/reinstall your computer.
      • One thing nice about the Mac is that they app guidelines state that a program should be able to start without it's preference file (and should create new preferences with default vaules).

        Most Windows apps will croak if they can't find their magic registry settings (or INI file, etc). All because the reg process is part of the installer and not part of the application itself. It would be nice if all apps worked like PuTTY!
    • I appreciate your 'Old fashioned'ness, but I'll tell you why most apps use the registry:

      Because back in 1995, Microsoft said "Stop Using INI files if you want to be compliant" People went along

      I use a mix. The is ONE advantage to the registry - if your company uses roving profiles, it allows your settings to follow you - this is nice, but other than that, I agree use INI files

  • Ordered Error Boxes (Score:2, Insightful)

    by dietz ( 553239 )
    One that I see a lot in "unpolished" programs is when several error boxes pop up at once and you have to close them in a specific non-obvious order (presumably in a LIFO pattern, but that's not always obvious depending on how your window manager is setup to create new windows).

    Also, I hate it when code is under-documented.

  • Standard widgets / UI elements (Score:5, Insightful)

    by Jon Peterson ( 1443 ) <jonNO@SPAMsnowdrift.org> on Thursday February 21, 2002 @08:57AM (#3043869) Homepage
    Contrary to what some people think, it is not clever or funny to funky new widgets and dialogs in place of standard ones. Does the standard windows file->open dialog need improving? Maybe. Are you the one to do it? No.

    Other peeves include:

    Not having tooltips. Tooltips are good. Use them. Everywhere.

    Useless error messages. I know it's a pain but there's nothing worse than a regularly re-produceable error state that gives no information.

    Useless help files. If you don't have time to create help documentation, then don't bother to do any. It's a waste of user time looking though unhelpful help files.

    I'd re-iterate what others have said about progress bars. I'd also add:

    * Threading. Be able to do two things at once. I don't care what the app is calculating, I should still be able to move the window and have it re-paint properly at all times.

    * Interruption. I should be able to cancel anything the app is doing. I hate waiting around for an app to timeout on some operation.

    • Interruption. I should be able to cancel anything the app is doing.
      I'll even be more specific. If you have a cancel button, make sure it works, and quickly. There are few things in the computing world more annoying than a cancel button that doesn't do anything.

  • Tips from the Marquis de Sade School of HCI (Score:5, Funny)

    by alecto ( 42429 ) on Thursday February 21, 2002 @08:58AM (#3043873) Homepage
    You know better than your users. Include lots of wizards and bots to guide them. Don't allow them to disable them--it's for their own good.

    If your program had been doing something in the background and was minimized or covered, be sure and let the user know it's finished by popping up! If this can be accomplished while the user is in mid sentence in a document or an IM, so much the better. The user paid good money for your application--you should be letting him know he got his money's worth!

    When performing processor intensive operations, don't waste cycles telling the user what's going on. To an astute user, the wait cursor is more than sufficient--if he has so little faith in you that he thinks your application is locked up, fie on him.

    Never repaint the screen while performing processor intensive operations--once again, performing repaints requested by the operating system interferes with the arduous task at hand for the application.

    If your application is a game, be sure and use keys that are near the hotkeys for the operating system. For example, an ideal Windows game would use Alt for fire and Tab for missiles. Other combinations are left as an exercise for the reader.

    If you write more than one application, be sure that the as few keyboard shortcuts as possible are the same between applications. Even better: take an innocuous, commonly used keyboard shortcut in one of your apps, and make it do something potentially dangerous in the other. For example, our alumni at Microsoft wrote Word to use Ctrl-Enter for a page break. In Outlook, when typing a message, this sends it immediately. If a user was typing a rant to his boss, he should have thought of that before putting venom in his draft email!

    If yours is a web application, be sure the "Back" button never operates.

    If a user fills out a form and it doesn't pass your rigorous validation checks, return him to the form and ensure that none of the entries he typed are filled in. If he made a mistake in the one you caught, who knows what other mistakes are in there? Can't be too careful!

    When validating a form, once you catch an error, report it and make the user fill it out again. There's no value in pointing out all the failed edits, since you're going to clear the form for him anyway, right?

    Next week's lesson: Desigining effective product upgrade notification dialogs.
    • "If a user fills out a form and it doesn't pass your rigorous validation checks, return him to the form and ensure that none of the entries he typed are filled in. If he made a mistake in the one you caught, who knows what other mistakes are in there? Can't be too careful!

      When validating a form, once you catch an error, report it and make the user fill it out again. There's no value in pointing out all the failed edits, since you're going to clear the form for him anyway, right?"

      Has anyone noticed this happening on Slashdot lately? There is nothing worse than typing a quick comment, clicking Submit, having Slashdot say you only waited 19 seconds instead of 20, then going back and having to redo the comment all over again!

    • Marquis de Sade

      Looks like you misspelled "Microsoft".

  • Computing pet peeves (Score:5, Informative)

    by ka9dgx ( 72702 ) on Thursday February 21, 2002 @09:01AM (#3043881) Homepage Journal
    • When the program thinks its smarter than I am, and trys to keep me from doing things that I want because it knows better. (This is a vague nonspecific emotion thing, but it tops my list)
    • Modes... never use modes if you can avoid it
    • Windows applications that pop up a dialog box that gets lost behind windows.... thus inadvertently creating a mode that you can't get out of (because alt-tab can't get you there)
    • If you offer resizable windows... try them out at at LEAST 1600x1200 pixels, and make sure they still use the screen space.
    • An application shouldn't need an install program... you should be able to copy the files to a new folder, and the first time it runs, it should just work... no registry crap, etc.
    • Don't put any DLL files anywhere else on the system, it's not bloat to keep your own DLLs, it's safer these days.
    • Copying a program's directory should allow you to move a program from one computer to another, with all options intact.
    • You should be able to operate the program with just the keyboard. A possible exception for paint programs.
    • Make sure the tab order is the same as the visual order on the display.
    • Context sensitive help should not merely repeat the error message, it should explain the issue.
    There's more... but it's time for work.
    --Mike--
    • Context sensitive help should not merely repeat the error message, it should explain the issue

      If I could add, have an error number along with the error message. For example instead of having a box pop up saying "You can't do this here", have it say "Error: ABC1234: You can't do this here". It is much easier to search by the error number in the online help and on Google then by the text of the message. This goes double when you app is localized in different languages.

    • Alt-Esc: a better Alt-Tab (Score:3, Informative)

      by xdc ( 8753 )
      • Windows applications that pop up a dialog box that gets lost behind windows.... thus inadvertently creating a mode that you can't get out of (because alt-tab can't get you there)

      In Windows, use Alt-Esc to switch between all windows, including properties dialogs and other windows normally ignored by Alt-Tab.

      Still, I totally agree with your suggestion. I find it really irritating when a program seems to have hung, and it turns out that it had merely popped a dialog box underneath all of the open windows.

      • wow, i did not know about alt-esc, thats very nice to know about... thanks :)

      • Here are some that I use quite often:
        • To save form data in IE (e.g. for later reference) before you submit it, hit alt-F4
        • To do an auto-save across multiple applications, hit ctrl-alt-. a few times (has to be the period on the numeric keypad with numlock off)
        • For a hidden easter-egg game in Windows, hit winkey-r (that's the key that has the Windows logo and 'r') and type regedit. The object is to delete as many of the evil keys as you can before time runs out. (I know you don't see a timer, but you'll know when time runs out).
        ;-)
    • An application shouldn't need an install program... you should be able to copy the files to a new folder, and the first time it runs, it should just work... no registry crap, etc.

      Windows users are used to having programs in the start menu. Putting an icon there requires an install proccess. Goodness forbid that you want to integrate with Windows further by adding a right click menu to explorer.

      Copying a program's directory should allow you to move a program from one computer to another, with all options intact.

      Copying a program from one computer to another should allow you to move the program from one computer to another, with the default options. Under no cicumstance should user data be stored with the program. It is bad for backup, bloating the size of your backups. It is bad for privacy, if you give a friend an application and all your data by accident. It is bad for multi-user systems because storing data and program together is inherently single user. User options should be stored in the user directory. Copying the program directory and the user directory should copy the program with all options.

      • Goodness forbid that you want to integrate with Windows further by adding a right click menu to explorer.
        If you do this, please make sure you can turn it on and off through an options menu in the program, not just during install.

        And speaking of install, be nice to file types. If you want to grab hold of some file extensions, save the previous association and give people a way to restore it. Especially if you're grabbing .gif and .jpg. Equally, give the users an easy way to reassociate your extensions with your program if an app takes them away.

    • a program that is conformant to the Made for Windows Guidelines can NOT do most of this. They are required to have an installer, and are required to store pertinent information in the registry. Besides, if you know what you're doing - reading info from the registry can be faster than reading it out of a text or xml file!
    • If you offer resizable windows... try them out at at LEAST 1600x1200 pixels, and make sure they still use the screen space.

      Go down to at least 640x480 too. As a number of our users have deteriorated sight, the apps that require 800x600 or higher to get the whole thing on the screen are inexcusable.
  • Document every function in detail. Every single one. Not just the most common ones, ALL OF THEM. Do it in an organized manner. Linked HTML files with a complete table of contents. Window's help is very bad. Provide a man-type page for the executables and their options. Configuration should be in a text file (provide a GUI for it if you like, i won't use it.) and provide several common example setups and a few complex ones. Document every directive and option. Teach someone who hasn't seen the program before and have him/her write a 'getting started' manual. And DOCUMENT EVERYTHING.

  • only a gui available (Score:4, Insightful)

    by joto ( 134244 ) on Thursday February 21, 2002 @09:02AM (#3043886)
    I really hate it when programs I have to use are entirely GUI-based. I want to automate as much as possible, and having the ability to create a simple shell-script for doing what I want is really useful. Not that I don't appreciate having a nice gui, I really do.

    But whenever you add functionality to a program, ask yourself the question: "Could this be thought to be even remotely useful for someone to use from a shell script?" If the answer to that question is "yes", then make it available from the command-line as well. An example of software that really doesn't follow this guideline is most installation programs. Most sysadmins do not appreciate sitting in front of 10's or 100's of computers pushing "Next" and "Finish".

    Secondly, follow GUI-guidelines wherever you can. Winamp (and most other mp3-players) are completely ridiculous. A gui built for usability would have larger buttons, standard focus mechanisms, less distracting eye-candy, etc...

    Third, document your program, and not just for the beginner. It's when you want to see if the program can really help you with some esoteric stuff that you really need documentation.

    Fourth, and most importantly: Make sure your programs do something useful. The world doesn't need another Visual Basic CD-player. Personally I need efficient theorem-provers, but that is kind of a hard problem to solve. But even simple things can have remarkable usefullness, e.g. the first visual text-editor/wordprocessor, spreadsheet, web-browser, etc... I believe there is still room for innovation.

    • Secondly, follow GUI-guidelines wherever you can. Winamp (and most other mp3-players) are completely ridiculous. A gui built for usability would have larger buttons, standard focus mechanisms, less distracting eye-candy, etc...

      My home stereo is black with buttons clearly labeled in white. The CD player is the only component that needs a display, and it only needs a very simple one. So why do mp3-players have junkloads of eye candy crap all over the place?

      Design the exterior of a box that would do what your program does. Make it easy to look at and easy to understand. Mimic that in your GUI.

      Could you imagine if someone made a computer controlled toaster?! It would have heat level indicators, time prediction displays, options to control heat, proximity of the coils to the bread, ejection speed, coil temperature, and tell you how many bread crumbs were in the bottom. Noone could ever figure out how to use it.
      • Right, and if all those options were left out to keep the design simple, geeks would endlessly bitch that they weren't allowed to micromanage their toaster! :)
      • The CD player is the only component that needs a display, and it only needs a very simple one. So why do mp3-players have junkloads of eye candy crap all over the place?

        Why do dogs lick their balls?

        Because they can.

    • I certainly agree with your first point (and the others actualy)

      As a mac user I am always annoyed at the number of apps that dont support apple-script when they realy should, it realy doesnt take that much more time to write your program well and add in the necessary hooks for applescript, it can also help for testing, a basic smoke test can be automated and this can realy cut down on the amount of time QA wastes on screwing with builds that just arent going to work.

      and if your developing on MacOS X give your user all of the scriping ability possible, from shell to applescript.
    • I love that in Linux I have a choice. For CD-Burning, I can use a bloated GUI app (I like Gtoaster), or I can use the command line. I can copy a cd the same way:
      cat /dev/cdrom > win2k.iso

      and then burn it just as easily
      cdrecord -speed=12 win2k.iso

      How easy is that???

      I also found a new favorite way to play cds or MP3s,
      I can use
      mpg123 --random *.mp3

      to play every MP3 I have in that directory
      or I use
      cdcd to play a cd.

      I have a CHOICE in using a Command Line OR a GUI.

    • > I really hate it when programs I have to use are entirely GUI-based. I want to automate as much as possible, and having the ability to create a simple shell-script for doing what I want is really useful. Not that I don't appreciate having a nice gui, I really do.

      > But whenever you add functionality to a program, ask yourself the question: "Could this be thought to be even remotely useful for someone to use from a shell script?" If the answer to that question is "yes", then make it available from the command-line as well. An example of software that really doesn't follow this guideline is most installation programs. Most sysadmins do not appreciate sitting in front of 10's or 100's of computers pushing "Next" and "Finish".

      Well, you've got the wrong impression, you've this ability in windows for a very long time, it's called window shell host scripting, there isn't much in windows that you can't do with it.
      And it's certainly true for all the installation programs that I'm familiar with.

  • log it (Score:2, Interesting)

    by oyenstikker ( 536040 )
    Everytime i learn a new software package, I invariably get to the point where I did what I wanted, but then wonder to myself, "Self? How did I do that?!!!" Have an option to log all mouse clicks, keystrokes, informative output, errors, and anything else that may help the user recreate what has been done.

    A seperate program than analyzed this log file and returned an optimized log (how the user could do it better/faster/smarter) would be brilliant.
  • My pet peeve is when the computer program is so horrible it cannot read my mind to pick out exactly what I want it to do, before I even think the thought and the do it before I have completed the thought, doing it nothingless than perfectly and surprising me everytime with a new rendered female and conjoining voice. But maybe I'm just picky..
  • my top two gripes are resource management and DLL hell.

    Once closed, programs should give back the resources they used. And if you must use a custom version of a standard DLL, put it in the program directory rather than screw up every other program that uses, say, mfc40.dll.
  • Flexability is a MUST with all software.

    If I find an app that does exactly want I want but has no way of outputting the result in a format I can use easily its annoying.

    If I want to use an app in conjunction with another couple of apps it must fix in seemlessly. I don't want to have to download the source code to fix a strange "side effect".
  • One thing that really pisses me off are programs that always open on some stupid place (usually MY Docsuments or something stupid).

    If I open something, and next time I go to a dir, the program should use the same dir as the last time I opened something, or the same dir as the place where the current file is saved. ALways going to My Documents or god know what is stupid, and very annoying. The Initial Directory of File/Open should track the current open file's location.

  • Behaviour blocking. (Score:4, Insightful)

    by spt ( 557979 ) on Thursday February 21, 2002 @10:11AM (#3044233)
    I frequently use this one piece of software that has arbitrary filters on what it allows you to do.

    It has two main modes - a read mode and a write mode. Read mode is okay, the information is presented in a very configurable way which allows you sort, index and filter with the methods of your choosing.

    Write mode is much annoying. There a minor peeves such as one of the text entry fields being too small and the options in a drop-down list are under-documented. There are also the artificial filters that I mentioned earlier which prevent many users from entering the data that they need or would like to.

    For example, there is a limit on the input rate - only one block of data can be entered per 2 minute time interval. Even more annoying than this are the filters on what information can be entered. The main form of input is arbitrary English text - often in the context of computing, other technology and legal/ethical issues; yet it is difficult to enter highly formatted and structured text such as source code or bulleted lists of observations because this text can easily not conform to per-configured limits on the amount of whitespace, capitalisation and line length.

    A final pet-peeve is insulting error messages; when users do something wrong it is due to ignorance with the system they're using or an honest mistake. It has long been realised that insulting users by blaming them is a bad thing to do; "You have chosen an invalid file" should be replaced with something like "That filename cannot be used because it is too long. Please reduce the length to less than 50 characters".

    This final peeve applies to the software described above as well ... if you violate one of the software's rules then the error message that appears calls the user 'lame'
    • Wow. Sounds pretty shitty. Why would anybody ever want to use something like that? Oh, wait... (sidenote: one of those filters caught me the first time I tried to submit this)
  • When you have a GUI, make sure that you test that it looks the same with different resolutions and smaller/larger fonts that you developed with. Make sure the GUI looks good from 800x600 small fonts to 1280x1024 large fonts...

  • Errors (Score:2, Informative)

    by tigersha ( 151319 )
    Oh yeah, while I am working with Notes, another thing.

    Error messages should tell you WHERE the !"!" error happened as well as What happened. If I have a form with 50 fields an error such as "Number expected" does NOT HELP!!!!! "Number exptected in Field for variable " is a good error message. Just tell me WHERE error was.

    Lotus Notes is full of this sort of crap. The weird thing is, the system can pretty much give you a load of help with an error since it has the context available when it happened. For instance, Notes knows pretty damn well in which field is is evaluating the formula when it croaks. Why not just tell me too???

    This does not just go for Notes, many systems do this (Xerces XML parse, for instance, does not tell you in which line of your XML file it discovered the problem.
    • I once saw an error on a NT4 box when my supervisor was upgrading a piece of software on the server. The error?

      Imagine a small dialog, with a title of "Error", no close button, a small text questionmark in the middle (nothing else!) and an "OK" button.

      To this day we still don't know what it means (and if I was in charge, I would never buy another thing from that company again - but alas, not my decision).

      So, yeah - I agree - good error handling should be paramount. I would also add that the error handling should distinguish between errors that are minor annoyances, but processing can continue, and those which bring the software to a halt, and it must be terminated. Plus, you should ALWAYS trap for errors in every instance, even in those situations where you are positive an error can't happen - because that is where it WILL happen. So, use you error trapping everywhere you can. Finally, if the error is a missing field or something not entered right - in addition to explain what the error was, and where it is - highlight the field, and put the focus on that field so that the user can IMMEDIATELY change it to something more appropriate (maybe even change the tool tip if it exists to reflect what should be in the field)...
  • While I am ranting...

    I understand the thing with type vs. untyped programming languages. I now untyped languages have rapid protoyping advantages, but that does not mean you should check EVERYTHING at runtime.

    Some things CAN be checked at compile/save time and I want to know BEFORE I run the thing that I misspelled the one name of a routine or method or whatever.
  • Applications that look totally different to the rest of the OS bug me, this includes (but is not limited to)

    Windows Media player
    winamp
    trillian
    ICQ

    etc etc

    IMHO, all applications running under an OS, should look LIKE the OS, and work in a similar manner (from a GUI standpoint)
    • I totally agree.

      And as soon as one does it (read: the classic Macintosh philosophy of HCI), the Skinning Bitches rear their ugly heads and start complaining they they can't customize their new Appz with the 733t k3wl Hello Kitty theme or whatnot.

      It bears repeating: Interface first, candy later.
      • At the very least, if you MUST include per application skinning, also include a fallback mode where the applications gui is displayed in a normal manner.

        (NOT using a skin that looks like the default OS, but actually using the stock OS routines to draw the window)

        if they want to be so skinning-friendly, don't screw up the guys using Windowblinds :)

  • My personal preferences: (Score:3, Informative)

    by mfarah ( 231411 ) <`miguel' `at' `farah.cl'> on Thursday February 21, 2002 @10:30AM (#3044337) Homepage
    IMNAAHO, a good application must:
    • if it has a basic user mode, then it MUST have a power-user mode. I hate it when an app won't let me do what I want, forcing me instead through stupid menus.

    • Configuration files are GOOD. For a user who groks the app, it's much quicker to edit the .CFG (.ini, rc, whatever) than having to go to the configuration menu/window. Let him do so if he so wishes. Configuration files should be properly commented, too.

    • On-the-fly reconfiguration. This heavily depends on the type of app, but as few options as possible should require restarting.

    • Take the pain to write a GOOD help section. Windows apps, for example, have a well organized help system, with perfectly useless content. Have
      some friends that know nothing of the app come by and try it, and record whatever they ask. Have some power-users come, grok the app, and THEN record whatever they ask. Meaty help, please.

    • An app should do whatever it's supposed to do, and interface properly with other apps that do other stuff instead of trying to do it itself. For example, tin (the Usenet news client) doesn't have an internal text editor, but rather invokes your editor of choice (vi, EMACS, TSE, whatever). Bloat is bad.

    • Batch mode is good. Let me use an actual example: I once had to convert 300+ files from .GIF to .PNG. With an interactive app, this takes more or less 30 seconds of user input for EACH file, and it would have been tiring as hell. Instead, I decided to use some Unix utilites (gif2ppm, ppm2xpm and xpm2png in a chain), took some minutes writing a shell script to process each file, and left the job on its own while I got to do other stuff... and it took less overall time.

    • If you port your app to different OSs, they MUST behave in the same way in each system (obviously there's a limit held by an OS ability to do something). For example, "save file" can't be F2 in Windows and CTRL-S in Unix.

    • If yor app contains an internal scripting language or something like that, document the source and let the users access it. (The TSE editor [semware.com] is a great example of this).

    • If your app contains a lot of internal power (usually this is the case for apps with an internal scripting language), an internal command line sometimes helps solve easily some tasks. I kid you not.

    • Organize the app's files neatly into subdirectories. Having to search for a saved document in a 500+ files directory, especially when you don't know the exact name of the file, and there are internal ones that could be them, too, isn't pretty. A "saved documents" directory is good.



    That's all I can think of for now.

      • If you port your app to different OSs, they MUST behave in the same way in each system (obviously there's a limit held by an OS ability to do something). For example, "save file" can't be F2 in Windows and CTRL-S in Unix.


      I've got to disagree with you there. A user sitting at a computer shouldn't have to know that XYZ Pro was originally developed for the Florp2000 platform and not the Shebang Station, and therefore uses Control-Meta-Z to frobnicate. All of the other applications on her Shebang Station use Alt-Z for that common function.

      Ported programs should BE PORTED, NOT COPIED. Use whatever keystrokes are expected by the users of that environment.
  • I suspect those who frequent /. are not the people to ask about software that "sells well." Just a hunch.
    • I wonder what percentage of the people out there are actually real programmers or engineers?

      There are certainly a few people responding who seem to have "been there" to a greater or lesser degree.

  • Interface Hall of Shame (Score:5, Informative)

    by Masem ( 1171 ) on Thursday February 21, 2002 @10:52AM (#3044464)
    If you haven't already visited it, please go and bookmark The Interface Hall of Shame [iarchitect.com]. While it's unfortunate that they've not really added much to it, leaving most of their examples of programs that tried to bridge the GUI changed between 3.1 and 95, many of the examples of bad component use, dialog use, and error messages are certainly valid.

    And another tip that I've not yet seen posted - Always always have people beta test the interface for you, without supplying them help files or the like (making sure these people are sufficiently computer-experienced as to not make 'what's a right-click?' type statements). If possible watch them and take notes, or better, videotape them to review them. An excellent GUI will require no additional help files in order to understand, such that any help that is actually included would be supplimentary to understanding the more advanced features. (Of course, this does not mean to use Wizards for anything. GUIs should have minimal text on the screen to start).

    And also, never hard-code the colors for window/dialog backgrounds, fonts, or the like. I know of people that don't use the default grey for window or black text, and it's amazing how many programs are unusable because they try to draw (fixed) black text on (user-selected) black backgrounds. I know Win32, Classic MacOS (and would expect OSX to have it too), and both KDE and GNOME have the appropriate hooks that you can grab what the user-selected color scheme is instead of fixing it to your own colors.

  • One of the things I hate most is apps and web pages which screw up when running on a machine with a non-default colour scheme.

    I like my white-on-black colour scheme very much, thanks. Why do certain apps/web pages find it neccessary to set a foreground colour to black, but then leave the background colour alone? Great, now the only way for me to read that is to highlight the text or change my scheme back.

    Moral of the story: Either set BOTH foreground and background colours to what you want (and for goodness sake, make it user-configurable), or LEAVE THE COLOURS ALONE.
  • Check out Jakob Nielsen's Usability Website [useit.com]. Much of his current writing is on web design, but prior to that he spent alot of time researching application usability. Very insightful! Provides a consistent framework for approaching the usability problem.
  • My biggest pet peeve would be the one that would invlolve you writing software for the mac, however if you are writing for Windows. anything goes man. Think about it if the program sucks, someone will just hack it and fix it for you. It is such a lovely community!
  • There are UI guidelines for most OS's/Windowing systems. Some are fairly strict (MacOS), while others are more lenient (Windows). Above all: follow them. There is no reason why an app that works with documents should do anything other than give you an open dialog box when pressing Ctrl-O. Same thing for people who think it's "clever" to recreate exit and minimize buttons - use the tools that already exist, don't make up your own.

    Always remember, there are people with PhD's who have spent years studying this stuff. Even if you're a good programmer, don't think you can outdo most dialogs. They are two completely separate computer science fields.

  • I really, really hate it when an app isn't cross-platform and/or doesn't have a compatible implementation available under other platforms. My job entails switching back/forth between linux and windows many, many times; having patches of stability such as Mozilla, vim and (Win|G)cvs is great.

  • Lots of GUI stuff, but there's much more to a program then how it looks or what you click on. My pet peeve is network handling. Networked applications need to, at a minimum:
    1) Be secure. Check for buffer overflows, check it twice. If the other computer sends you a megabyte of As, what will your application do?
    2) Be ethical. I can't count the number of times an application has tried to leak confidental information out my internet connection. Unless your program has a legitiment reason to use it, it doesn't need to get my username, my owner info off my windows, the box's ID number, etc and send them out through the network connection.
    3) Be efficient. Plan ahead, how will your network application be affected if your usership grows 1000x? (Gnutella) Will it work over a VPN? Test it at different bandwidths, make sure it falls back gracefully if required. There are chunks of the world, even in north america where a 9600bps internet connection is a sign of a really good day.
    4) Be RFC complient. Nothing sucks more then to have your router taken out by an application that screws up and spews random info out the eth0 port. There should be no circumstances where your program can break any of the appropiate RFCs.
    5) Provide hooks. Sendmail is still in use for a reason. It does its job, and hands off subsequant tasks to external programs, allowing us to change out local delivery agents as we change our ways of storing mail, for instance.
    6) Include some sysadmins in your beta group. You'll sell more software if the IT dept doesn't commit ritual suicide each time a user buys a copy of your software.

    Just my .02 Orionan credits.
  • Always allow the user to pick the data directory. For example in Internet Exploder, (mis spelling intentional) the user can not choose where the bookmarks are saved, so when you reload Windows, you lose all of your bookmarls / favorites.

    Never ever assume that the user wants your program to run all of the time. Example: Real Audio

    Always allow the user to disable the program if he or she does not want it to run at startup.

    Do not make the user upgrade and do not assume that we want to be notified of upgrades.

    Do not just assume that your program will be the default program.

    Do not hide settings deep within the registry.

    Never
  • There is a lot of good feedback here. Some of it written in the best prose I have seen in a while. Almost every entry had something great in it.

    You began your entry with: In an effort to improve my coding skills, what are Slashdot readers' biggest pet peeves when it comes to software?

    First and foremost, remember you are writing code. Some of it will be great. A lot of it will be mediocre, dull, or poor. The biggest mistakes I see in developers, even "old" developers is an inability to admit they created something poorly. Part of it is pride, and part of it is the desire to avoid "fixing it".

    If you wish to be at the leading edge, get over the emotion. We are not calling your children ugly or discussing the virtue of your mother. It is code. Look for people to criticize and complain, bitch and moan. Then decide if they are right, or if you took a new direction on purpose. (Hey, someone thought Open office should open all the applications at one time.)

    Stand up and get out more. Hermits are unwilling to run an idea by anyone because they take everything personally. So they code, and code, and code and then we refit, retrofit, and enhance afterwards. Talk your boss into putting a white board in the aisle and run coding decisions, access questions, and design considerations past anyone willing to stick their head out. You will get garbage and gems. However, you will get more to think about and that will certainly improve your coding. (Especially if someone points out that opening all the office applications at once may be an issue.)

    [BTW - I picked on open office because it is an issue that has been beaten to death. Some would say this horse was whipped to death only to have us start on it's children. ;-) I strongly recommend everyone try the most recent stable version of Open Office. You may be very surprised, what OSS can get you.]
  • It appears that you are talking more about interface design than programming.

    For what it's worth, check out "Interface Design" by Peter Bickford ISBN 0-12-095860-0. Its a bit dated but provides a reasonably good introduction and foundation for interface design...

  • Networking (Score:2, Interesting)

    by tigersha ( 151319 )
    Hell, I love this thread.

    Netscape has this horrible habit of hanging ALL the open windows when ONE of them has problems with a TCP connection. This is because the windows share the event loop as far as I know. This is dumb. I think Galeon is the only browser that does this right, and you have to switch the behaviour on. (Someone correct me please).

    Another peeve: Programs are sometimes like annoying marketing types who think they own you. I am a customer and I will bloody well do what I want on my machines, so deal with it.

    Intrusive programs that install things in my Windows taskbar that pops up every 5 minute to ask for an update and (God forbid) install themselves as a taskbar on my desktop. (Hello, someone at Creative Labs!! Are you reading this???)

    The same goes for programs (Hello, Apple Quicktime!) that simply assumes that it is now the default handler for GIF, PNG, BMP and everything else in the universe, just because it can vaguely handle it (after asking me EVERY time if I want to upgrade to the "pro" version. NO I DONT. SO FSCKOFF NOW).

    To put in simple terms, MY DESKTOP DOES NOT BELONG TO YOU; AND I DO NOT THINK YOUR "!" PROGRAM IS THE END-ALL AND BE ALL OF EVERYTHING IN THE UNIVERSE.

    Programs that send out info over the net without my permission. MY DATA DOES NOT BELONG TO YOU EITHER!

    Capitalism is about the strong surviving. It is also about the weak going down and I fully intend to help the system by voting with my feet against programs that are written by power-hungry marketing types who want to take over my machine.

    More rants: Games that do not let me change the keyboard mappings. I live in Germany, where the keyboard is weird. I like my games in English. I will happily remap my bloody keys, but please MAY I? And on a Jerry keyboard the a key is NOT above the z key!

    And while we are on the subject, if you are going to do 3 language version of your program, just put ALL of them on the SAME CD from now on? Please? Few programs are so large that the multi-language stuff does not fit (possibly recorded speech in Games, I will give them that). I don't want to import all my games, and there are many expats here who like to play in good ol' Eengleesh.

  • Error handling (Score:2, Insightful)

    by tigersha ( 151319 )
    Some programs commits an action on a load of documents/entities. Sometimes this takes time. IT happens.

    So I just selected 9512 docs, and ran the script just before I went home in the expectation that it will be finished tomorrow morning when I come back because it takes 4 hours. Fair enough.

    Now at doc #1273 there was an error. Your program has 5 choices:

    a) Simply give up and crash/stop without telling me what you already finished.

    b) Pop up a dialog box to inform me, stopping the process.

    c) Mark the things that are finished and stop, so I can continue

    d) Mark the things that are in error and do the rest anyhow.

    e) Rollback ALL the changes (or better, give me choice AT THE END)

    So which do you pick? Here is a tip.

    a = very bad. If you do this, I hope you burn in hell.

    b = bad. VERY few things anny me as much as a program that stops in the middle for an innocuaous pice of crap with a dialog box. Pop up the thing AFTER the fact (if it is now serius and ask me if you should continue).

    c = Semi-annoying

    d = Good.

    e = Excellent.

    if you really want to goto the deepest level of hell, throw away my selection for a) and b) while you are at it, too. Really smart.

  • Probably all mentioned already, but here's a few of my suggestions:

    Don't change my window focus. Your program is not necessarily the most important one running. Besides I might have it running in the background for a purpose - like I don't want my boss to see it.

    Allow me to turn off (and permanently turn off) programs that run automatically. That includes turning them off via their icons in the system tray.

    Make sure that I can do things without a "wizard" to help me out. A wizard is nice for the unknowing, but is not for everyone.

    Let me choose whether or not I want to check for updates periodically on the web. I might not want the new version of your program for any number of reasons.

    Don't send data automatically from my computer back to your company - even for error reports.

    Don't make me register before being allowed to see the property settings. (Hey Real - this one's for you)

    Don't give errors with just code numbers. I don't know what error CC344 is or why it has occured and giving me the error number doesn't tell me anything. It might help you while developing, but change it to something meaningful before release.

  • Self-documenting code, etc. (Score:4, Interesting)

    by andaru ( 535590 ) <andaru2@onebox.com> on Thursday February 21, 2002 @02:11PM (#3045967) Homepage
    Programs which steal the input focus bug me, too. You should be able to operate your computer with the monitor turned off if you remember the right keystrokes without some program popping up and changing the context.

    Also, programs jumping to the front 50 times while they are starting up is really annoying. For a good laugh, start Word and VC++ at the same time and watch how many times they pull the "my splash screen is on top, "no, MY splash screen is on top" crap. If I start VC++ and then start another program right afterwords, I want to use the second program until I explicitly switch away. I do not want VC++ deciding that I need to see every step of startup - "Oops, the user has switched to another app, but never got to see me update this toolbar - better jump to the front, even though I am only 12% done starting up!"

    Some other things:

    1.) Favor self documenting code over separate comments when possible. Comments need to be maintained separately from code. Self documenting code does not get out of sync with the documentation, and is readable anywhere you use it. For example, if you are writing a function which converts an audio frequency to a wavelength, instead of calling the function CnvtFreqToWaveLen(), and documenting the fact that it takes KHz and returns inches, call it CnvtKHzToInches(). This way, any user of the function knows in what format to supply the input and in what format the return value will be, without relying on the docs being up to date.

    2.) Try to construct your variable and function names such that your code reads like English. Rather than "if(hardwareInstalledFlag)" which does not tell you the meaning of the two states of the flag, use "if(hardwareInstalled)" and make sure that hardwareInstalled is TRUE if the hardware is installed. There are few things more annoying than something like runningFlag, where 0 means running and 1 means not running. If that is the case, call it hwNotRunning so you can say, "if(hwNotRunning)".

    3.) Write stable code. The common myth that software is too complex to be truly stable is total BS. We have had extremely complex systems running out in the field for several years without a power cycle. Always check your assumptions (the hardest part can be identifying the assumptions you are making). If you find yourself saying that X or Y can never occur, then test for it.

    4.) Never assume that the software understands the situation better than the user. MS Word's assumption that it understands the English language better than you possibly could is one of the worst examples (I used to work at Orban - Word 97 by default would silently fix any occurances of "Orban" behind your back with NO confirmation, and change them to what you OBVIOUSLY meant to type, "organ"). Something MS does not understand is that I am the user, and I may happen to decide that I WANT to start a sentence with a lowercase letter ("cvGetStub() is a function which...."). I should not have to be an expert at reconfiguring Word just to get it to allow me to decide what I want to type.

    5.) Write self teaching programs. Instead of "Could not complete the requested operation," have your dialog explain what was missing, like, "one or more tracks must be enabled for RECORD in order to enter RECORD mode."

    6.) Use descriptive variable names. Even most uses of 'i' in a 'for' loop are inapropriate. Instead of 'i', call it what it is, like dbRecordNum, rather than relying on the context ("oh, this loops maxDbRecordNum times, therefore 'i' must be the record index").

    7.) Don't blame the user for your bugs. Never come across as condescending, as you do not know the context in which a message is actually going to be displayed. When the user can see that they are clearly running into a bug, but the software is chastising them for doing something wrong, that is very annoying. Dave Barry talks about the ScanDisk startup message in this context. "To avoid seeing this message in the future, behave, stupid user," is really annoying when you know that the problem was directly caused by the mistakes of the same programmers who are now blaming you. Sarcastically, it should read, "to avoid seeing this message in the future, run an OS which does not arbitrarily crash after having write-cached a bunch of crap that it never bothered to write back to the hard drive." Realistically, "This error could have been caused by turning off the computer without shutting down properly, or the system may have become too unstable to shut down properly."

    8.) Use the mouse cursor CONSISTENTLY to tell the user about the state of the app. If you have a mouse arrow, the program should respond to your input. If you have an hourglass cursor, the program should ignore your input, not save it up to deluge the system with when it becomes un-busy. If the program is processing user input while performing some other task (therefore it is honoring your input, but may not get to processing it right away), there is a pointer/hourglass cursor that says just that.

    9.) In general, get the user feedback right. This lets the user know that he really clicked the button that he thought he did, etc.. Don't mix control and status in general (some exceptions). It should be obvious which screen elements are used to do something, and which are used to report feedback.

    10.) Do not try to maintain multiple copies of the same state information; for example, if you have a dialog box with 10 settings, don't maintain the state of the dialog elements as one thing, and the state of the internal settings as another. Always maintain a master copy of the state and update everybody who cares from that. So when you open the dialog, you don't display the last state of the dialog, you recalculate the state of the dialog from the master state of the program. So if you are maintaining a field in a dialog which contains a username: a) when opening the dialog, update username from the master state. Do not try to keep the dialog state in sync with the master state as you go. b) when closing the dialog, update the master state from the contents of the dialog. c) When the username changes (as a result of the dialog or anything else), perform the appropriate action to respond to it. d) When your program needs username, get it from the master state.

    Enough rambling for now....

    • There is obviously an event that can be triggered that causes drop-down menus to disappear. Internet Explorer uses it whenever it finishes loading a page (or even a frame) but Mozilla does not. If I've got a batch of IE windows loading pages I can't use the menu in any other program because it keep disappearing. Don't do this. Whatever it is, don't do it. Assume that users will be running your program in the background and just as you shouldn't pop to the front and/or grab the focus, don't keep collapsing their menus.
    • Haha I'm afraid this one is partly my fault. The goal of running scandisk at startup was to reduce the number of product support calls with questions about how lost clusters got on the users harddrive. The main reason of course is people just turn the computer off without shutting down, which doesnt let the file system complete whatever task its performing. Now originally the idea was scandisk would run, clean up any 'problems' and continue boot.

      But then cold reality stepped in and two things happened: one, people didn't like seeing scandisk run, and didnt understand why it was running, and two, user Ed jumped in and decided to fix this problem with a message.

      So the message is for that segment of users who arbitrarily turn their computer off, rather than shutting down. But of course there is a bugaboo that if the system crashed, you still get the message, because there is no way to tell the difference between a crash and pulling the plug.

      In the big scheme of things, that message relieves more confusion than it causes.
  • The one thing that drives me crazy is programs and web applications that cheerfully discard 30 minutes of typing because there was a network error or I hit the wrong key.

    Programs that steal the focus from the current foreground program are also very annoying. I'm typing in a sentence, some program steals the focus, and it does random bad things when it interprets my keystrokes as commands.

  • Here are some tips. (Score:4, Insightful)

    by bedessen ( 411686 ) on Thursday February 21, 2002 @03:23PM (#3046584) Journal
    (these are assuming the platform is Windows)

    Do not steal the focus, neither on startup nor for any sort of dialog box.

    Respect my preferences. I do not have the default gray color scheme, so do not hardcode gray as your icon/toolbar/dialog background color, etc. Also recognise that I might have the taskbar docked on the lefthand side. I run across programs all the time that think that if they pop up a window at (1,1) it will be visible since the task bar is at the bottom of the screen.

    Do not go against the sound effects or window animations that I have configured. I have some sound effects enabled, some disabled. Some people have no speakers or are at work and have sounds disabled. Same thing for window animation. I have most of it disabled, so don't assume that I enjoy those stupid animated "unrolling" menus.

    Remember the window position/size and always open to the last state. I hate apps that are too dumb and must be resized/moved each time they are started. Usually this is related to the prior point about not having the standard windoze explorer configuration.

    Do not use any pauses. Don't pop up an error window for 3 seconds (with no ability to make it go away) or some such nonsense.

    Avoide the splash screen at startup. DO include a useful version number in the About dialog, with contact info and a website for updates. Avoid auto-detecting updates unless you are clear and upfront with the user before going out to the network.

    Any time you report a filename in a panel or status display, please test your app with long filenames or filenames with multiple spaces. Often when processing files that reside in the "My Documents" folder, programs will try to report the filename but only output "C:\Documents and" when the file was really named "C:\Documents and Settings\Administrator.BOOCH\My Documents\Recorded Shows\file.avi". A related point, if you must abbreviate filenames to fit in a limited space, consider only showing the trailing bits (i.e. the actual filename and as much path as can fit) rather than the other way around, showing the higher level directories first and cutting off the subdirectories and filename.

    Don't include the runtime if at all possible. I always respect a 500k install package over a 4MB one. Don't put any "common files" in my system32 directory if you can avoid it.

    Use an intelligent installer. I want the program's directory completely removed when I uninstall, not left empty or with some small derelict file that the installer didn't know about. Same deal with the registry. Don't leave an empty key when your program uninstalls. I will disagree with other posters here, there's absolutely nothing wrong with using the registry intelligently.

    I should not have to reboot to use your application, unless there are very special circumstances. Win2k is pretty good about this, actually. And for all that is holy, DO NOT make an installer that forces a reboot as the last step.

    Tell the user what's going to be changed during installation, and give him or her a choice. The default for icons should be a directory under Programs in the start menu. DO NOT install an icon on my desktop or in my quick-launch bar without asking. DO NOT put your app directly on the start menu "root" menu.

    Default install location should be Program Files, not a random directory off the root (like C:\MyApp) but in any case it should be presented as an option during install.

    Do not add anything to my startup without asking. If I like your program and want it to run automatically at boot then I will either use a checkbox in your config screen or I will put a shortcut in the startup folder.

    Don't litter my temp directory. Delete whatever temporary stuff you create.

  • Why?

    Program runs in xterm A, but not xterm B. Why? A missing slash in a variable somewhere.

    No problem, I'll just use my super powerful administration tools that I have for environment variables. Those tools are called "set" "export" and are used by typing out long strings by hand without making a mistake.

  • Make sure all your dialog boxes work with "Large Fonts". This helps two classes of people: one is people with poor vision, and the other is people with very high resolution monitors.

    Nothing is more annoying than having a non-resizable dialog box with two letters of a sentence in it because the font is too big.
    • Or, for that matter, the Windows desktop properties dialog box which, when the screen is set to 640x480 and large fonts, is larger than the screen so you can't see to click on the buttons... or, in some cases, see the fields where you change the resolution and font sizes. Of course, these values can't be changed in a text file, and finding them in the registry is like looking for pi in the output of /dev/random.
  • If you're putting functionality of any kind, whether core or UI, into your program that isn't already popular, with obvious "standards", then look around to see what other people are trying to do in the same field. Get to know other developers that are producing complimentary products and agree on small standards so that your products co-operate. Research emerging standards and incorporate them if you were going to do something similar anyway. Who knows, you might strike it lucky and be one of the first to include the next popular feature. I guess I'm saying, don't reinvent the wheel -- if even one person looks like they've come up with a workable solution, help evolve that rather than creating a new religion.

    Where possible.

  • My fastest computer is a 266MMX with 64MB of RAM. I rarely use more than 20% of the features of any given software product. Where possible, produce a software product that's modular such that features I'm not going to use can be removed. If this means you have a tiny little core product and most of your functionality lives in plug-ins, great.

    Keep things optimised. If possible, release your plug-in standards so that real zealots can rewrite some of your modules in assembler for better performance. Don't assume you can get anywhere near fully optimised the first time. Encourage a community where people write routines optimised for all the weird stuff out there. Look at D.net with it's MMX core v's it's 3Dnow! core.

    There is a huge user base out there with old PCs. For every 30MHz you shave off the requirements for your product you probably increase your potential market by 10%. A modular app properly optimised over time should find it's minimum system requirements go down not up. If MS worked like this you'd be able to run the core of Windows 2000 on a 386 and basic editing using Word 2000 would only need 4MB of RAM. Not everyone needs to play movies on their PC.

  • ok.. here's one of my pet-peeves: localization. I hate it. Causes all sorts of annoyances: menu-items translated differently across apps, english dialog and localized yes/no buttons (from the OS), urgh..

    //rdj
  • User: "The server is down."
    Me: "Could you describe in detail the nature of the problem you are experiencing?"
    User: "I can't get my mail. The server is down."
    Me: "And you are using the same username and password which you use to connect to the Internet?"
    User: "I don't want to be connected to the Internet. I want to download my mail."

    Rule #1 for entry-level users calling into tech support:

    1) "The server is not down. You are an idiot".

    In such circumstances as Rule #1 does not apply and the server is actually down, it being our fault:

    2) "The server is not down. You are an idiot".
    • Don't use a tabbed-window interface when multiple windows would do (and would allow more multi-tasking by the user)
    • Don't use a rooted-window interface EVER. I might have something in the background which didn't need obscuring.
    • Use OS standard interfaces and controls so I can make use of my system mods, scroll wheels, and alternate input devices, the way I want and expect to.
    • If you're displaying any amount of text, don't use an ugly san-serif font. Arial is unnacceptable.
    • If a function/feature of your app is useful globally, don't make it bound to the "main" window of your program; make it available from everywhere.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close