• Pingback: Tweets that mention The 7 signs your UI was created by a programmer -- Topsy.com

  • Callie

    I agree with you, and would even go one step farther on the dialog interference. Even for data loss, just make the deletion undo-able, instead of asking for confirmation. Most users just click “yes” or “okay” in confirmation dialogs – it’s after the three-second task completion time that they consciously think “wait – did I want to do that?” One author I read postulated that happens because when the confirmation dialog appears, the user is still focused on the task at hand (deleting their valuable data, for instance).

  • Juan Valdez

    Whoever those people were that did those things above, they weren’t programmers. There’s a lot of people in the business pretending to be what they are not.

    Anyway, a good list. I also have noticed the pattern of whenever I see an exclamation point in an error message, the rest of the code is usually crap. Full of bugs. The rest of your list also speaks to a uninvolved mentality. If you see any of those items in a program there are certainly far more other problems that you are not seeing.

  • Ben Smith

    Flip side of dialog boxes…

    I can’t explain the number of times that I’ve had to field a call about somebody doing something completely, utterly stupid, but occasionally necessary. It’s a juggling act!

    I write software for schools, so I’ll start with an example: taking attendance in class.

    On one hand, you want to allow teachers to correct a mistake. But on the other hand, administrators really want to know, months later, what the attendance was for the class on that day.

    Teachers are all-too-prone to delete records they no longer consider “relevant”. After they “claim” for the first week, they are very likely to want to “clear the deck” so that they don’t have to worry about the first week.

    So when a teacher goes to delete attendance in your attendance system, do you:

    1) Just do what they want, with happy green check marks and/or smiley face icons,

    2) Kick up a dialog box and make them click “OK”,

    3) Make them type something like “If I do this, I know I’ll probably be hung by my toenails in a dark, damp cave by my boss” before letting them do this, or

    4) Tell them to screw off and pound sand for pleasure.

    In many cases, the right answer falls somewhere between #3 and #4, despite all our desires to the contrary. People don’t *think* about what they are doing. I’ve had to take calls where people ACTUALLY TYPED “I want to delete this” only to complain later that our system “lost data”!

    Much, perhaps most, of annoying “bad design” comes from ignorant users, and engineers who somehow have to make it work, anyway.

    Yes, I want our stuff to be easy to use. But I have to deal with the results when I succeed, too.

  • Pingback: Pitfalls in User Interface Design « Orion Spur

  • doug

    My favorite was an interface (designed by a CS PhD) for entering in a bunch of values that had an “apply” button next to EVERY entry field. iiiiiick. I made him change it so that when you left the field it automatically applied the value.

  • kabdib

    @Juan Valdez: [on code containing exclamation marks being crap]

    There’s a high correlation between exclamation marks and garbage code; not only dialog boxes, but debug code and comments as well.

    I have a sinking feeling when Iopen up a source file and see something like:

    /* enter for-loop !!! */

    … because I know that I’ll either be living with crap, or re-writing it.

  • http://webdevelopment2.com Baz L

    what I *love* are the inconsistent warning dialogs (when closing a dialog for example).
    Dialog 1: Do you want to save your changes?
    Dialog 2: Your data hasn’t been saved, are you sure you want to exit?

    Besides the annoyance of the dialog, this forces you to read “every single” dialog to make sure “Yes” is the appropriate response.

  • http://rimantas.com/ Rimantas

    „Much, perhaps most, of annoying “bad design” comes from ignorant users, and engineers who somehow have to make it work, anyway.“

    Must of the bad design comes from programmers thinking this way. I did not completely understand your problem, but there should be much better ways to deal with it: some kind of archive function, which keeps records, but hides them from teachers, delete function only marking records as deleted, but still keeping them, and of course “undo”.

  • euromix

    well i don’t fully agree. I do write interfaces, my users beg me for everything excel like, and fight hard to have useless warning message all around.
    and you know what ? they pay me to get what they want. so it’s perfectly fine.

    if you pay someone to build your house and this person answer that your requests are stupid, how will you feel ? my bet: you will fire him…

    This being said, i agree about neutral tone and clear messages.

  • Dave Spillett

    @Ben: One method that mitigates this is to never really delete anything, and make sure the users know. Mark “deleted” information as such so it doesn’t show by default, or move it to an archive area, and audit the delete operation. The same with data updates: keep the old record somewhere in an archive/audit table and record which user made the change. And the most important bit: make sure the user can see their audit trail so they know what any admin “missing” data is reported too can see.

    If your app is web based, make sure you keep web server logs for a decent amount of time (this will help by providing useful extra evidence for/against when someone disputes the audit trail or reports a genuine fault (“I did X and it seems to have not recorded it”).

    If people can not really delete data then they can’t delete data you want kept. And if they know that an admin you can see their actions they are much less likely to waste your time with “I didn’t do anything, but all this info has gone” when they did actually do something. Likewise, the audit trail, logs and archived copies will support genuine reports of the system being at fault and allow restoration of lost/damaged data.

    Of course you need procedures in place for when things genuinely need deleting (at user/customer request, for instance, under the data protection act or your local equivalent).

    FYI: I work on software that is used in a certain high-profile regulated industry where not keeping accurate records can break a business if the regulator sends in the auditors or the company faces customer or public complaints, and there is sometimes great temptation for users to massage recorded information (to disguise a mistake for instance), so this sort of data management is essential to some of our clients.

  • http://debuggerman.blogspot.com Zaki

    Well to say that these kind of mistakes are made by ‘programmers’ is a truely understatement. I’d rather say its made my newbies. What you imply is that programmers are dumb coding machines and actual UX and all that is given by someone else? I doubt. You say yourself that professional applications tend to be more consistent – well those applications were never developed by someone who is ‘not’ a programmer – just a better ‘programmer’. So someone with incomplete knowledge of CS would do that.

  • Michael

    Hi!

    Don’t agree on the grid 5. On the current row selected better on the current cell selected it makes sense to provide a control. I agree a the wohle grid filled with edits makes no sense at all.

    Some people like this. I usually try to have a sepreated group for the detail in the same tab sequence as the column of the grid are arranged. Think this fists, no one complained.

    Editors in the grids are helpful when applying quick changes/corrections, especially status changes of records… or when reslution is low…

    Mike

  • http://blog.badera.us/ Andrew Badera

    “Signs your UI was created by an inexperienced programmer” maybe. Most educated IT and CS people have had usability classes. Most passionate developers, regardless of education, have read relevant works, be they blogs or books. I’m an engineer and a CTO, but I’ve known Norman, Nielsen and Tog since 1997. Lame title for an otherwise generally good piece on basic UI principles and gaffs.

    Will also disagree with grids — depends on the nature of the application. Some applications are very data-centric and/or large dataset-centric. Like anything else, you need to select the right tools for any given job. If you shy away from data grids as a rule, it’s probably because you’ve never dealt with heavier duty data-centric programming, particularly against disparate backends like legacy mainframes.

  • Pingback: REVUE DE PRESSE DU 2009-09-20 | Humour Publicite Humour Buzz Insolite

  • http://www.voyce.com voyce

    Hmm, I agree that passionate programmers – craftspeople, as I like to think of them – are likely to consider these issues. The problem is that the vast majority of “Joe programmers”, those working in a large corporation perhaps, pay absolutely no attention to, and have no interest in these kind of issues. They have a kind of UI blindness. The problem with a good UI is that you never notice it; so unless you’re actively looking, a good UI can pass many people by.

    I’ve got nothing against grids as such. A lean and mean grid can be a good way of editing lots of homogeneous data. I take issue with them being used as the sole means of interacting with the application.

  • http://www.voyce.com voyce

    On the contrary, I think there’s a negative correlation between programming skill and ability to create polished UX. Anyone who’s an expert in one area, like programming, probably got there by focusing on it to the exclusion of other things. And user interface design is more aligned to creative disciplines like graphic design than it is to programming, so there isn’t even a natural overlap.

  • Bassel Samman

    OK, most of the people that responded are clearly not programmers. Guys, if you don’t get it, no need to comment on it. Exclamation marks, for example, are not signs of bad code. It’s just that when we went to school to get our “Programming” degrees, most examples we saw had exclamation marks in them in the text books or on the blackboard. Here is a good one you may have to implement quite often, or when learning a new language, it’s called “Hello World!!!”. We just tend to put exclamation marks at the end of all of our printed lines. “This is an example!!!”. As for all the other signs, they come from a programmers logical thinking. If the program is logical working correctly, we don’t really care if it looks nice or not. Because logically speaking it’s working as we want it to work. It’s hard for us to really care about the visual stuff because we see it as makeup and is always the last of our worries. If anything it may tell you is that you have a good programmer on your hand because he cares more about the integrity of the application then the visual candy(in my logical programmer opinion :P ). All kidding aside though, we always strive to care about makeup, but our clear lack of interest in putting on makeup sometimes slips through and you get things like bad confirmation boxes or a not so fancy icon.

  • Bassel Samman

    Just so I don’t get attacked, I do agree that those are rookie mistakes in a professional application. It just happens from time to time that something will sneak by the sales guys and the designers and even the customer, and something we put in for testing actually goes to production and you might see a bad icon or a bad error message. Trust me, be happy that they caught all the other ugliness because if developers were allowed to do design, your virtual world would not be nearly as pretty.

  • Pingback: Christians dagbok – 2009-09-20 | En sur karamell

  • http://www.drucker.ca David Drucker

    I’m a UI designer and am sometimes called in to critique existing UIs. In the course of my work, I’ve seen a bunch of other signs that the UI was created by a programmer (inexperienced or not):

    1) Organization of the main screen of the program around something that looks vaguely like the Windows file manager, with a hierarchical folder list on the left, and either controls or form elements on the right. I can’t blame programmers for doing this because after all, it’s what they are most familiar with and use for programming apps themselves (it’s how most IDEs are designed). Unfortunately, not all programs have a hierarchy (the underlying metaphor behind them may be a graphic editor, or a book, or a chat application, etc. To make matters worse, a lot of programs that didn’t necessarily need to use this setup have embraced it as well: iPhoto and iTunes, several twitter clients, just about every FTP application, Powerpoint and even a bunch of text editors. I’m not against this layout, but the fact that its become so pervasive means that developers don’t necessarily think about whether or not there’s a need for it, or whether a hierarchy even exists in their application. Like this one: http://www.filebuzz.com/software_screenshot/full/62092-DU_Super_Controler.jpg or perhaps this one: http://www.filebuzz.com/software_screenshot/full/14688-ManageEngi.jpg, or this one: http://www.findmysoft.com/screen/5353.gif (boy, that last one is a doozy).

    In short, after a while, every UI uses that same layout, with large scale navigation at the left and then one or more panes at the right. Pretty soon, all apps look nearly identical, not matter what they do or need to manage. I think it shows a knee-jerk approach to application design where the task is forced into the layout, rather than the layout following the task.

    2) Putting many small icons in the taskbar or ribbon with no text associated with them and having them do vastly different things. Microsoft is responsible for a lot of these, particularly in the Office apps. There are so many toolbar icons, each with different kinds of behaviour (the alignment icons act like radio buttons, the table icon is a drop down menu for inserting a table, others invoke new windows).

    3) Many small dialog windows for preferences(or worse, preference dialogs nested 2 or 3 levels down). Rather than group things together logically, you get a discrete dialog for each preferences.

    4) Lack of progress indicators. Showing meaningful progress (with an estimate on the time left before finishing) on a lengthy task takes time and effort. Most programmers will merely resort to the hourglass/spinning ball/watch cursor.

    5) Input fields that are too short, even for typical data input. I can’t tell you how often I’ve seen that one.

    6) Menus with jargon in them (like ‘Turn on Verbose Logging” or “Clear Memory Cache’), which are certainly useful, but their functions should probably be put either on an ‘Advanced’ dialog box .

    7) Forms that have checkboxes acting like radio buttons. Believe it or not, I’ve seen that one quite a few times.

    I’ve probably got a bunch more, but these are a few that came to mind immediately.

  • Pingback: Tweets that mention The 7 signs your UI was created by a programmer -- Topsy.com

  • http://xceed.com Odi Kosmatos

    “And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.”

    Ah snap, I had great reasons for why your statement is wrong about screen redraw performance, but no matter what I say… I guess the case is closed!

  • http://www.bombaycrow.com/ Ben Morris

    There’s a big difference between UI design and programming – hence the fact that the two are generally regarded as separate disciplines these days. Programmers (well, the good ones) tend to approach things from the point of view of performance and maintenance – this is not necessarily the same as delivering a great user experience.

    Perhaps there should be a counter article – “7 signs your UX knows sweet diddly-squat about implementation issues”. My first item would certainly be “throws everything but the kitchen sink into a wire-frame”…

  • Pingback: UX is making me dumb | Doug McCune

  • http://www.godofbiscuits.com/blog Jeff Barbose

    Except that not all programmers are the same. Some of us pay attention to details; some of us are UE engineers. Some of us care about design.

    Some of us can architect software AND possess design skills.

    Some of us pay attention to the domain experts for the software we create *and* we bring to the table the ability to provide things those domain experts don’t know are possible and we do it in a way that follows good UI/UE principles.

    1 sign your article was created by a UI designer? He/she is dissing the engineers.

    And for the record, there’s a difference between a programmer and an engineer.

    And maybe you should have had a writer write your article for you. Designers can’t write and it shows–yes, that was tongue in cheek. Mostly. There *are* errors. Can you spot them? I can, and I’m just an engineer.

  • http://tewha.net Steven Fisher

    As a programmer, I’ve had all but #2 and #6 pushed on me over the years by designers. Each time, I’ve ignored the designer and delivered something usable instead.

    Although, frankly, I consider the pages of missing information a good substitute for #6.

    Don’t kid yourself. This isn’t a programmer vs. designer thing. This is people who have good taste vs. those who don’t.

    And I have to disagree with Bassel Samman. In my code I have not a single exclamation point. And I like it that way, thankyouverymuch. I take pride in my work, and the design of it is right up there with data integrity as the most important part of that.

  • Pingback: workspace » UI Problems

  • Paul Clark

    I find a lot of messages boxes from Excel confusing. They have a paragraph or two of text and Yes/No buttons at the bottom. They require your full understanding of the text before you click the button. I shouldn’t have to fully understand the text, just the gist of what they are saying.

    To overcome this kind of problem I try to get rid of the Yes/No buttons and use buttons with descriptions. So even with with a paragraph or two of text and two buttons “Save”/”Don’t Save” it is clear what to do, even if I don’t read all the text.

  • Pingback: programming.torensma.net

  • Pingback: QA Hates You » Blog Archive » You say “ArmageddON”, I Say “ArmageddEN”

  • http://www.mshams.ir MShamS

    Very nice! I think that, “Group boxes around everything” and “Excessive use of dialog boxes” are really true.

  • Pingback: Destillat KW39-2009 | duetsch.info - GNU/Linux, Open Source, Softwareentwicklung, Selbstmanagement, Vim ...

  • http://flossexperiences.wordpress.com shirish

    Hi there,
    I have been burned as a user enough times to not trust dialog boxes. Programmers do not think from user’s perspective.

    For an e.g. please look at this thread :-

    http://groups.google.com/group/chromium-discuss/browse_thread/thread/58ff66726acdd906/fa507ae8ba40a2b9?lnk=gst&q=The+site%27s+security+certificate+is+not+trusted!#fa507ae8ba40a2b9

  • http://www.godofbiscuits.com/blog God of Biscuits

    Is this a “no dissent allowed” blog?

    You promised that my email is never published or shared, but I guess my comments aren’t either.

    Not only are all engineers devoid of UI/UE sensibilities, there are a whole class of engineers whose specialization involves User Interface issues.

    If a dialog box whose text was a question to which the answer was “Yes” or “No” that appeared in buttons at the bottom, I’d sooner rewrite the copy that let it go out the door with “Yes” and “No” buttons under almost any circumstance. Those responses are too general and pull the user out of the tight contextual focus he/she is in when deciding the proper way to dismiss the dialog.

    For example.

    But what do I know? I’m just a programmer.

  • http://www.voyce.com voyce

    Thanks for taking the time to reply. I finally got around to approving your first comment (not at all related to your remarks in this one, of course)…

    I don’t know if you’ve realised – I didn’t think you had based on your other comment – but I am a programmer first and foremost, and a UX tinkerer second, so this post wasn’t intended as a sleight on programmers. Just on sloppy programmers who think “hey, UIs are easy, there’s nothing to ‘em”.

    And I found your “ooh, there are some mistakes” thing in your previous comment a bit tedious. I had enough “fun” with reddit commenters pointing out my misuse of apostrophes to want to spend any more time worrying about grammar. I’m not a professional writer or blogger… I’m a programmer.

    Ian

  • Mick

    Great article and guilty as charged!

  • Pingback: Dew Drop – November 3, 2009 | Alvin Ashcraft's Morning Dew

  • Pingback: Indicios de que tu interfaz de usuario fue creado por un programador | Spargo.Net

  • patrick91

    8) No progress bar on long processes :)

  • http://www.areox.net areox

    A lot of people should read Alan Cooper’s “About face”!

  • Pingback: Top posts 2009 en Variable Not Found - Variable not found en Geeks.ms

  • Pingback: 10 Resources for Design-Challenged Programmers

  • bob

    Lol, you said to force the programmer to not be a programmer. If the organization is need of something better, why not hire a UI designer? That kind of makes sense to me.

  • Rp10001

    Wow. This is a really funny article, and the responses were even better! Yep, we sure know ourselves well (programmers) we’re the ones feed life into your beautiful ui layout. You’re welcome.

  • Adam

    Word!

  • Karven Ferandez

    I really hate wiggle box UIs. For me, the wiggle box system is very hard to use.

Back to top
mobile desktop