Did my sentence "...and most software engineers don’t understand the value of true human factors engineering — in particular the cognitive psychology and human-computer interaction expertise that human factors engineers bring to user interface design" not show that I am aware of HCI?
Most software engineers do not need a deep understanding of Human Factors as a working tool, it is a broad term covering multiple disciplines and mediums - particularly focused on physical forms. HCI is focused on computer interaction; you are discussing user interface design.
Citation needed. The only thing I've ever seen or heard of even /vaguely/ concerning cognitive psychology and user interfaces is bikeshedding about response time.
Usually it's just: some graphic design expertise, and WoW addict like dedication to smoothing out the details.
I dunno.. your article only has 2 links - 1) 'Websites that suck', 2) your own article about how 'incompetent individuals tend to overestimate their abilities'.
The last 6 paragraphs are fairly obvious points where you do not go into detail or give examples. How is the reader supposed to know what you mean in a way that is useful? Some links to examples or how to implement would be useful advice.
Also, I'm curious, why the snarkiness? Do you consider being critical of others to be part of your online persona? Is it for entertainment value? Is it an effort to improve something? I don't mean to pick on you - I'm actually curious.
I was honestly not trying to be snarky. Can you point out where I was? Seriously, I'm not trying to get defensive here - it would help me if you could point it out.
Perhaps snarky was not the right word - the article contains little/no sarcasm. I think myself and others are reacting to the general feeling of a largely negative criticism without any focus on good design done by engineers (or anyone).
Words like 'mad skillz' imply condescension towards some hypothetical group of developers. Words like 'self-serving', 'lack of', 'incompetence', etc are just negative - again targeting a straw-man group of developers.
Within your article there seems to be a paradigm of a) stuff that 'sucks', and b) the 'right' way (your way).
So, it leaves me thinking that you are targeting a negative generalization towards a group of developers. Effectively, you created an ad hominem argument against a straw-man. This comes off as negative, but more so it tells me as a reader that you spent energy evaluating the scenario from the standpoint of 'this is wrong', without fully understanding the point of view of your straw-man or pointing to examples of good design.
Instead of conveying 'these guys over here suck, they should do it my way' you could have conveyed 'these guys over here can suck, but when I have observed them doing x, y, z they definitely suck less' - same message without the ad hominem. Or, even better 'these guys over here are good at design vs average engineers because they do x, y, z' - same message with an emphasis on positive examples, not negative examples. That would convey that you have taken the energy to evaluate both the negative and the positive about the straw-man developer group you appear to be attacking.
As a general aside, I have been trying to understand why many smart / skilled people bias towards viewing others in a negative light - ie, does it have a benefit? I am generally interested to understand where this negatively comes from when skilled people evaluate their peers.
Thanks for the feedback. Negative criticism, I was certainly engaging in. I'm not sure that I'm attacking a "straw-man group of developers," though -- I certainly never meant to convey, for example, that all developers are bad at user interface design -- but I did say "most" so perhaps I was painting with too broad a brush. And agreed that I could have provided concrete examples -- perhaps a future post.
You tell the reader the very real/important fact that the mental model we use to solve the problem in code isn't the same metal model the user will have, even though the programmer is so accustomed to that model it will certainly heavily influence any UI they would design. Other than encouraging the reader to understand the use cases and use that as a starting point for an interface, you don't really explore where to go from there. It is a valuable starting point, but isn't much.
Well, if you ever do end up writing that follow-up post, I thought I'd share a game that I play with my brother, that I have found to help me enormously with interface design.
Some background - I'm a software engineer, with my true love being application design, though I have often worked in other fields. My brother is an architect, so he has had quite a bit of formal schooling in design technique, and well, he just enjoys doing it. Anyway, when we get together, we have a game we like to play where we pick an average every day device, and we try to design a better user interface for it.
There seems to be a very constant sequence of actions that we do when playing the game. The most important of all is to start playing the game - which is to say if you aren't trying to improve an interface, you never will. But once we start trying to improve an objects interface, we generally start by identifying flaws in the current design, the pain points. Once those have been found, we start tossing around ideas that might fix the flaw. It's at his stage that something interesting starts to happen - you get a deeper understanding of the problem the object was trying to solve, and that understanding frees you up to try something really different - the old smartphone to iPhone type of jump.
To give an example, the last time that we played the game, we were working on traffic lights. Some of the flaws that we found included:
Light bulbs that blow
Lights get lost in the background of dense cities such as Paris or London
The posts take up valuable street space, making them a hazard for pedestrians and dangerous if a vehicle loses control.
Inflexibility to changing conditions - for example, when I'm the only driver on the street for the last 10mins, why can I get stopped at lights for a minute waiting for it to go green?
Once the flaws are identified you can start tossing around solutions. In the case of the traffic lights, we started to understand that the object itself was the problem. Traffic lights are a solution that was designed before the advent of ubiquitous computers and wireless communications. These days you could design a system where your car receives a signal from any intersection saying whether it has tonstop or not. The traffic light itself can be moved inside the car, or even tied to the control system if you are about to run a red light. That would be a good first step, no more poles, no more distraction from blinking neon signwork. But ther would still be the problem of maintenance, the radios could blow. And it still doesn't stop you from getting stopped at an empty intersection.
Our next iteration required a deeper understanding of what traffic lights are actually trying to do, rather than just understand what they are doing. They are trying to control traffic flow. So, the final solution to traffic lights is to find a better traffic flow solution. In our game we eventually decided that ai cars, capable of driving themselves and connecting to a regional traffic control server, would be able to negotiate their passage at each intersection. No more traffic lights anywhere in the system, because at the end of the day they are a hack that was created as a stopgap solution at a time when we didn't have the technology to do any better, and which now continues on due to inertia.
Anyway, if you keep playing the game, you eventually get to the point where you really start to understand design as being an attempt to get to the heart of the problem you are trying to solve. This process helps you find the original solution to the problem that makes your object a plaesure to use rather than being something that you have to fight against
