Products For People Who Make Products For People | Hacker News Reader

Products For People Who Make Products For People

sheddingbikes.com

281 pointsmichaelfairley79 comments

There is really no mystery about UI. Yes, it requires skill and a deep knowledge of how humans process information, and even a touch of design genius.

But the real problem is that most shops can't measure usability in a fine-grained way. And yet everyone does have some idea that it's really important. Consequently they are bamboozled by anyone who purports to have such expertise.

For the most part, so-called usability experts are really just graphic design snobs. They have a certain aesthetic they like, which is arguably "cleaner" and has more white space. So the page might be better organized but that's nowhere near what true usability is.

Real usability work is about trying to understand how the user is thinking. What their mental model is. What their goals are. In what context they are trying to achieve a task. Not just how their eye is scanning for information.

Anyway my point is, when it comes to real usability work, programmers are just as (un)qualified as graphic designers, marketers, or any other kind of "product" person. Arguably the designer is supposed to have a larger toolbox when it comes to possible graphic treatments, but the programmer also has a toolbox of quantitative methods, experimentation, and a deep understanding of how the system could work.

You know, I thought I had UI design mostly figured out, using a few simple rules:

* Minimise the total number of clicks needed to access the sum of the program's functionality.

* Make frequently-used functionality easier to reach than rarely-used functionality.

* Don't have more elements in the UI than is easy to parse quickly.

* No surprises.

However, after reading this article, I get the feeling that it's a more arcane art, which not many people know. What are some simple rules about good UI design, in your opinion?

In my opinion it isn't arcane, at least, no more arcane than other "soft" design fields. But the simple rules are complicated to follow.

Your first three principles are about efficiency. That's a big part of usability. When you reduce clutter, you make it easier to use by clarifying the next action the user should take.

But "No surprises" is rather complex. It means that you not only have to explain what you are doing, but also work with the user's mental model, which might be totally wrong.

Here's an example from my current project. We are designing a web form to upload images and video to Wikipedia. In 2010, the users' model of media uploads comes from Facebook, ImageBucket, and maybe Flickr. Even after you make them click on a box that says they give up their own rights before proceeding, they don't understand what they did. Apparently people's mental model just continues on blithely until it smacks against a major contradiction.

So we've tried various metaphors. "License your work" was replaced by "Release rights", and the next iteration is going to be "Donate your work". That wording was the suggestion of a usability testing and analysis firm we hired, by the way. So it does take a certain amount of inspiration to come up with alternatives, but recognizing where the problem areas are is just a matter of measurement.

Inspiration is aided by just having a bigger bag of tricks, too -- knowing common problems and solutions. For instance, if there is so much to do on one page that users are finding it overwhelming, it is helpful to break it into multiple steps (a "wizard"). That's another approach we have taken.

Anyway, I'm not sure if my expertise with usability is so deep that I could pronounce just a few principles. Maybe "reduce cognitive load to the minimum" is one, which has been more memorably distilled by Steve Krug as "Don't Make Me Think". Since we want to avoid onerous information transfer and cognition, there are some models of communication that might be helpful here; a classic text on human communication is The Responsive Chord, by Tony Schwartz. He argued that most communication is about activating stuff you already know (at the right moment), which you can see at play in the example I gave.

But ultimately it's about motivating human behavior, so it's only about as complex as the human heart. ;)

Thank you, that's very interesting. You can't get everything right the first time, but yes, it doesn't seem to be something magical that you don't have any control over (other than praying to some UX god), either.

One of the key things about UI design these days is that it's very easy to fall into the 'widget trap'. This is where you have some content you want to interact with, and instead of really analyzing what the best way to interact with it is, you just throw the data in a standard widget, like a listbox or textarea. It might be a really nice listbox or textarea, but there may also be a much better way of interacting with the content that wasn't explored. Widgets are the typical area where this happens, but it can be generalized to any situation where people just go with pre-established conveniences rather than try to find the best solution.

The problem with that is that widgets are your language, so you tend to think in them and analyse the problem in terms of widgets. It's sort of the Sapir-Whorf hypothesis applied to UX, it's hard for someone to think in widgets they don't have.

Right, but that's what I'm talking about. Widgets should never be your language. If you think widgets are your language then you've fallen into the widget trap.

Solid list.

Personally, I spend a great deal of time putting myself in the mind of the user, trying to figure out how we as humans visualize things and simplifying the actual underlying task at hand.

The list you summed up does work for 95% of all cases - especially if you're just thinking about a "website". However when you're trying to create something new or working with some new concepts you have to imagine how the user pictures things so that it matches his thought pattern as much as possible.

This also includes placing things were the user is most likely to look for them etc.

ISO defines usability as "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

So your right with the number of clicks, but you also have to make sure that the user can complete the task (effectiveness), and that they are happy (satisfaction). From our own research the three; effectiveness, efficiency and satisfaction are very highly correlated together.

If you nail all the things you mention, you'll probably be far ahead of most software out there.

Please don't take offense, but that's a very programmer-like approach to usability.

Usability is so much more about mental models than it is about efficiency, about helping the user feel confident & safe, than about a lack of surprises. Sensible hierarchy and visual relationships are a big thing that most people seem to forget.

Workflow, too, is critical. I've used a lot of software where every screen is mathematically, scientifically "usable" but the software overall was crummy because it duplicated a workflow from another piece of software which had got it wrong initially.

For example: 100% of email clients. Feed readers. Project management tools. They're all the same.

Surprises are actually very good in many cases. Even "ease of use" is something you don't actually always want.

My interfaces break all sorts of rules like "use standard widgets" and "conform to expectations" and "no surprises" -- but that surprise then results in an "AHA!", great enjoyment and power, and that's why people write love letters to our customer support account.

You are exactly right. Making usability and user design into a science is difficult because we'd be trying to model the human mind, which is, well, pretty much impossible.

For example, in the information retrieval community, companies like Google continue to employ a lot of people to mark search results as relevant or not. Even with all this data, it's still hard for us to quantify what is "relevant" to a user. Likewise, it is hard for us to quantify what is "usable."

But even though the programmer may own this toolbox of quantitative methods and whatnot, most of them do not use it when it comes to usability. Why? Because the toolbox is quite empty. The advantage that these "snobby" designers (just like how programmers are "snobby" about their choice of programming languages and tools) have over programmers is that designers have more empathy towards the everyday man. So there is some emotion involved. Sure, there might be a science behind all of this, but since no one figured it out yet, we'll have to go use our intuition of what a good design is.

Fortunately I think this is changing: tools are coming out that make running quantitative UX studies easier. Services like Optimizely, GazeHawk (disclaimer: that was a shameless plug for my company), UserTesting.com, etc are becoming more commonplace, bringing the barrier to entry for a UX consultant who is actually useful down.

In the future I imagine there being plenty of UX consultants who, rather than having a strong education in the psychology of websites, instead is experienced with the tools necessary to evaluate a design and make recommendations. Then there will be graphic designers, marketers, etc who are actually qualified to work with usability.

The problem here is that good UX isn't borne of qualitative analysis -- you have to build something worth analyzing to begin with.

Once you do start analyzing, what do you do with the results? You can try to make small tweaks -- it can be worthwhile if what you have is already good. If what you have is bad however, no amount of rigorous analysis is going to solve the artistic problem of coming up with a cohesive vision of something better.

Yesss.

The way I describe this to people is: "Usability science can only test a hypothesis. It doesn't give you a hypothesis to test."

Not to mention the problem of hill-climbing… you may think your test results are amazing, but you can't tell if you're really at a peak or in a valley with a lot of mist obscuring a potentially even higher peak..

UI designer = "white space"

UX designer = "mental space"

It's easy to redefine the meaning of a term if it's rendered as an acronym.

    User Interface Designer = "white space"
    User Experience Designer = "mental space"

Now how arbitrary is that? What is it about "Experience" that implies thinking and "Interface" that implies a lack thereof? What about all the designers unfortunate enough to come before the term "UX" was invented? I suppose Jef Raskin was only ever about white space.

Let me suggest an improvement

    Mediocre Designer = "white space"
    Good Designer = "white space and mental space"

Well, there's also the fact that some "UX" guys don't have any great ability in graphic design, but are great when designing the use and flow of an interface. It's not necessary that an ability in the latter implies similar ability in the former.

Which "UX guys" are these you’re thinking of, who don't have a competent understanding of graphic design? I posit that it is irresponsible to claim to be a "UX guy" and not try to learn quite a bit about spatial hierarchies, data presentation, human response to colors and visual relationships, etc.

Though graphic design surely includes all those things you've mentioned, I was using it in the sense that most "web designers" might use it, as in the ability to make pretty stuff in photoshop. I'm not sure that someone who can, for instance apply Tufte's advice on data representation, necessarily also makes nice looking logos.

Equating “don't have any great ability in graphic design” with “can’t draw logos” is applying a pretty narrow definition. Someone who just “makes pretty stuff in photoshop” should probably be called a “digital illustrator” or a “photo retoucher”, or a “digital imaging expert”, not a “graphic designer”.

I hear a lot of "programmers don't do good Ui" as well as "marketers dictate bad UI" in my travels. I used to try to work out some sort of theory about which statement is true, and why. But then I experienced a revelation, Sturgeon's Revelation:

90% of everything is crap.

Therefore, if handed ten UIs designed by programmers, nine will be crap. If handed ten UIs designed by marketers, nine will be crap. Perhaps there is a characteristic way in which the nine programmer crap UIs are crap, but the observation that most programmer UIs are crap is not insightful and doesn't magically justify the idea of turning UI design over to product management.

That's a really good point - but I think a really big issue is that a lot of programmers (and I don't know why) seem to think that a good User Interface (API, Visual, Docs, etc) is just not needed.

That; and the attitudes range from "who cares" to downright hostile "if you can't understand it, you're stupid". I say this as a programmer (who spends a lot of time on the "user" facing components), not as a business person.

That attitude has to change - I don't care that the business people think hackers are Eloi fit for the slaughter while they are the Morlocks - the intelligent ones. Good business people don't have that attitude, good business and product people do care about scalability, supportability and quality. Those that don't will fail.

On the other hand, the constant refrain I hear from people in my own community and profession about making something usable and intuitive just makes me upset. I can't change the broken business people - I can try to make my corner of the world better.

Interesting that you compare "a lot of programmers" to "good business people." It is no surprise that the programmers fare poorly in comparison. What do you have to say about Good Programmers? Or A Lot of Business People?

May I attempt to find common ground between our points of view by suggesting that 90% of programmers have this attitude? And that by the same token, 90% of business people are busy demanding flash web site intros and banners that SCREAM without doing the A/B testing or other quantified analysis to know whether they are generating higher conversions?

But your last statement is absolutely spot on: making what we do better is what matters most. Upmod gladly given.

Well, the larger HN community seemed to not take kindly to my comment, which seems odd in and of itself.

Regardless, I concur with you - I can't speak to business people directly as it's not my particular domain, but yes - I've seen the same behavior that you have.

As a software developer who has at times thought that as long as the user interface is functional by the engineering definition that it is good enough, I've found it enlightening and interesting to go to local CHI (Computer Human Interaction) meetings where UX professionals present to one another. Programmers are a commodity but programmers who can understand and create user-friendly interfaces are less of one.

http://www.sigchi.org/connect/local-sigs

Take this a step further and join! I was an active member of ToRCHI for a few years and it was an amazing experience. Alas, it didn't make me a fully functional UX professional or even competent, but it did make me consciously incompetent, and that was valuable early in my career.

http://torchi.org/

Now that I think about it, what was valuable then that isn't valuable now? I just rejoined!

You know Zed - this was a really good read. There's not much I can personally disagree with here, especially your final point (which I won't give away so people will read it).

Very well written; and some great advice. I much prefer this to ranty-zed :)

I was thinking the same thing, "Well reasoned with 75% less hyperbolic rant". Good stuff Zed, keep it up.

Colophon:

The Long Beards, (Latin Langobardi, later "Lombards") were a tribe of Germanic "barbarians" who settled in Northern Italy in the late 500s AD. They were primarily responsible for thwarting the Byzantine Emperor Justinian's campaign to reconquer Italy and re-establish the Western Empire.

http://historyofscience.com/G2I/timeline/images/alboin.jpg

Today Lombardy is the most populous of Italy's 20 regions and Milan, the capital, is Italy's leading financial center.

That's interesting; I didn't know the origin of "Lombard". Justinian's attempt to conquer Italy was one of the bloodiest periods of European history.

Another word for programmers who "make products for people who make products" are systems programmers.

I'm sure Apple values systems programmers. And Google. And Oracle (at least they certainly should). Microsoft could not possibly build their products without systems programmers. Amazon could not have created its cloud products without systems programmers.

In Apple's case, their products would be impossible without the capabilities that the systems people build. Without an operating system that they could strip down and fit on a phone, while keeping much of its core functionality, no iPhone. Likewise if they didn't have the technology underlying Safari under their control.

Much of the eye candy that wowed people in Mac OS X came as a thin layer on top of the technology built by systems programmers. Like the graphics APIs underlying Expose. And the fast, system wide indexing behind Spotlight.

So, if you want to be appreciated as someone who "makes products for people who make products," work for a software company that makes products requiring innovation in systems software.

I agree with many of the things said in the article.

I'm so annoyed with people who make open source projects that don't comply to the principles that Zed listed. (Clear code, documentation, easy to get started, reasonable defaults, support, etc.) It happens so often that I interact with such OSS projects and it's so hard to work with them.

I feel bad for all the honest effort that these people put into the core parts of their OSS projects, without realizing that if they concentrated a bit more on the things that Zed mentioned, their project would become so much easier and fun to work with, and they'd have a bigger healthier community around it.

<Sociopathic rant> Sometimes when I see one of these projects, (let's call it, as an example, project FooBar and say that it converts between image formats,) I fantasize about forking the project, fixing up all the documentation to be good, make a good UI, give installers, make a nice logo, etc. Then rename it, sell it as a commercial project and become a millionaire, without crediting the authors of FooBar. Then I will drive in my fancy car to visit the core developers, and I will show them a wad of $100 notes and tell them: "You see this? This could have been yours. This could have been yours if only you documented your freaking code. You worked so hard on this code, and if you would have only taken care of the things around it, like documentation and binaries and design and UX, you could have made a lot of money. But you didn't. You suck." Then maybe for their next project they'll write freaking documetation. </Sociopathic rant>

Sounds like an xkcd comic involving the guy with the hat.

Except the implicit intellectual theft. What you are describing is pretty close to the music industry's original purpose - bridging the gap between creators and buyers - and see how often that gets criticised (perhaps rightfully now) as vampiric.

"let's say you can pull this off and you have permission to really make the UI sexy. Alright, where's your designer? In every mega-corp and government agency I've worked for there has never been a staff designer of any kind."

Amen to that. I'm working on a project to boost a new product line for my megacorp that competes against the established leader. So I asked to really boost the UI. And it was approved, provided of course, I made it myself :( . All my pleas for a designer were unheard or shrugged off.

With some help from the Internet, I've come up with a design that doesn't suck, but it's still a far cry from what a designer would have done in a tenth of the time (in effect, they hired me as a crappy designer and spent far too much of my time aka their money, but they don't see it that way)

Excellent read. I found myself relating this to the division between hacker types and the MBA types. I think the comparison is close as sometimes the product people are the MBA people.

As a hacker, I enjoy having large blocks of time to create what I think is good and not coding some autocratic vision of a product. As I've grown older though, I have come to appreciate and value the interaction between MBA types and myself. In one particular project an MBA type brought me valuable information about what we were doing well, how we compared against competitors, and what he thought our customers wanted. He then told me to run with it and stepped out of the way. I thought that was pretty neat.

Another thought - A quote from the article:

"A sudden rise in Long Beards simply copying Product People Products but doing it cheaper using their cost reducing backend skills."

reminded of the Paul Graham essay "Copy What You Like"

http://paulgraham.com/copy.html

... and copying something you like is probably a good way to bridge the gap between back end "long beard" and product designer.

"I think the comparison is close as sometimes the product people are the MBA people."

One of the founding principles of Y Combinator is to make the Hackers the product people.

Here's what I do to plan my code based on user experience. I use Free Mind http://freemind.sourceforge.net/wiki/index.php/Main_Page and write in the middle of the home node "Things A User Can Do"

I end up with things like "arrive at site", "create objectX", "view & edit objectY" as the next level nodes and keep going down levels from there. Since a mind map is a tree structure, it really helps to visually map out decisions a user will make. Following a branch is the user making a decision of what to spend their limited attention on. If you are improperly the distributing number of decisions a user must juggle at a particular node or repeating a lot of functionality in different areas, you will instantly visually see it.

Then when you start translating to code, if it's M-V-C architecture like most webapps, the first order nodes are the names of your controller functions.

What methodologies do other people use?

Just one point on Cooper and the Inmates book... it was written 11 years ago. Cooper being a vaguely smart guy has learned stuff since then and has quite a different view on the way development and ux folk fit together now.

Folks interested in a look into his more current thinking might want to take a look at his keynote for Agile 2008 http://www.cooper.com/journal/2008/08/alans_keynote_at_agile..., and his keynote at Interaction 08 http://interaction08.ixda.org/Alan_Cooper.php.

And from his involvement in things like the http://www.andersramsay.com/2010/02/04/notes-from-the-agile-... things are moving on from there too.

There's a large chunk of the UX community that's moving away from the developers-as-enemy attitude. And vice versa for the developer community I hope :-)

In my opinion usability requires a lot of grunt work. You have to craft error messages for any and all user input. You have to degrade gracefully if the user's interface (no JS, IE6, small screen on a phone, etc) doesn't meet the ideals for which you've designed the interface. Usable is much more work than functional.

Most programmers are aware of that, and are willing to put the time and effort in to making what's required. But often the product people, besides deciding what things should look like overall, are also in control of the budget and schedule, and they expect all those kinds of things to just magically appear.

Couldn't agree more about how a poorly designed backend can increase costs, however pretty and well-designed the frontend is.

We have a situation at work just like this: the inherited backend code is dreadful, full of WTFs due to poor implementation, lack of knowledge and lack of planning and design. It's eating away our profit margins. New features and customization take far longer than they should, and time estimates are impossible. Bugs, from simple UI stuff to server issues, are numerous and end up adding to customer support costs, not to mention reputation.

Do the management understand this ? Nope, they just consider these costs to be the normal cost of doing business in this sector. We have pleaded time and again to rewrite and refactor the code, but never given the time or leeway because the sales team want the latest shiny feature to sell to the client.

The irony is that we have a healthy and growing user base and top-rank clients. An outside competitor (of which the developers are aware, but about which the management are oblivious) are about to eat our lunch because they can simply execute better and faster.

I think his "longbeards" actually do quite well on iOS where it says "Do X just SO" and you get a pretty decent design if you just follow the 1-2-3s

I don't know - they probably do, god knows it allows me to make something that doesn't look like a series of cat turds, but formulaic designs don't last long term. You need something which really differentiates you from the pack.

I think it could be argued that formulaic design/experience HELPS long term, if you have some functionality that the user needs. If your app looks/acts/feels like the rest of the OS or environment, the user will (in theory) learn it faster and use it more fluently.

A 'revolutionary' design may be awesome, and may increase the productivity or ease of use of your specific application, while causing some serious friction between your app and it's environment in the users mind.

It's very refreshing to see someone write about their ideas and at the same time, demonstrate them with a real product. It's more than most people do when they proclaim things like what he has in his essay. Zed is someone worth listening to.

Steve Jobs on design: "It's not just what it looks like and feels like. Design is how it works"

This applies just as much to infrastructure as it does to anything customer-facing. To a non-programmer, for example, sendmail, nginx, and mongrel2 may all look like user-hostile crap. To a developer or administrator, it's easier to discern the differences in the design of this part, which is itself a major part of the usability of a webserver.

I have been a "product person" for 15 years and I believe that product people like Michael describes are bad product people. A good product manager knows the UI and the guts behind it. I am not an engineer by training but I wouldn't be a good product manager in this field if I didn't know how to build a web server either. For the "Jeep Cherokee made from iron ore": I give up. ;-)

I want to believe, but I'm dubious.

I'm almost certain when he says he can "make a web server", he means that he can sit down with a text editor, a compiler, and a standard C library, and produce a program that will serve HTTP requests. There's some gray area beyond this, but he definitely does not mean that he can download, configure, and run a premade piece of software.

Is this what you mean too? Is there really a population of self-described "product people" who have this knowledge? Or did you interpret his statement differently? I certainly agree that such people exist, but I would be surprised that their luxurious gray beards don't blow their cover. Which is to say, do they really work as product managers?

Agreed. The best product people are those who can understand the back end--even if they couldn't code it themselves, they have a respect and basic understanding for what's going on.

The comments here are very UI-centric, but what I found interesting was first the reminder to invest in fad-resistant skills (and don't forget, he drew a distinction between UI and hardcore design skills!).

And second the stuff about parsers in the section about making usable infrastructure software. Every time I peek at the mongrel2 source, there's one or two more Ragel files in there, some of them generating token streams to be consumed by a Lemon parser. I figured there was a good reason for that (although I shot a quizzical glance at the one that just parses "--a --b b" CLI args into key/value pairs). What I didn't realize was how much that's an integral tenet of his software design philosophy.

You know there are entire disciplines dedicated to the study of usability and user experience. Zed seems shocked that someone would claim that programmers (who generally have no training or interest usability) aren't good at making usable products. It's about as controversial as saying that construction workers don't make good architects.

Good to be reminded once in a while that code is written for people and not machines.

English is written for people and not machines. Code needs to be written for both. It's too bad that coders often forget that someone is going to need to be able to read it later.

On a side note, Heroku's web site is really, really pretty.

Check out their documentation for the new Addon program: http://addons.heroku.com/provider/

Click some of the links at the bottom. It's so gorgeous.

Well Copper designed the first prototype of Visual Basic. I think that explains lots. When you combine Zed's argument that "Nope, because the tools they've given you are again controlled by some corporation with a certain design ideal. If it's Microsoft then the things you have to work with are Microsoft looking and feeling. "

How many unusable software products came about because of Visual Basic? I can rant and rant about Copper.

I would kill for nicely designed API's for the things I work with.

Then maybe I can stop writing stupid shell script wrappers.

Frontend - Backend = Profit

Awesome

Great stuff. I think I'm developing a severe case of nerd crush on Zed.

The part about linguistic experience was especially good. I have thought for some time now that all configuration files, command-line options etc. should have simple and clearly defined syntax. Some already do. My dislike of weird, inconsistent and complex syntax (and semantics) is so severe that I've semi-intentionally not learnt shell-scripting, Perl or Ruby.

Sadly, there are very few systems that I feel I get a good linguistic experience(TM)(R) out of. I have come to think that GUIs as we know them are based on fundamentally flawed ideas - pointing and grunting - instead of using a language, the feature that separates humans from other animals.

I really wish good textual UIs (there aren't many that I know, but I'm using one for writing this comment: GNU/Emacs) became the norm, instead of the randomness of the contemporary GUIs or the bass-arckwardness of shell-like languages. I think UIs should aim to become Turing-complete, completely self-documenting and reflective. The distinction between a function, a program and an user interface is in my opinion mostly arbitrary and harmful, creating an unnecessary wall of misunderstandings between the author of a program and its users.

"I have come to think that GUIs as we know them are based on fundamentally flawed ideas - pointing and grunting - instead of using a language, the feature that separates humans from other animals."

The dilemma is that human language is staggeringly ambiguous. This works because human beings have an extremely sophisticated model of other human beings in their head and a really good pattern matching facility, which makes us really good at selecting the intended interpretation without even noticing the ambiguities. Presented with the languages we use to instruct computers, designed to be perfectly unambiguous, normal humans quickly get upset that the computer doesn't understand them if they veer the slightest bit from the tightrope of a language they're given to use.

In other words, if you have a computer that faithfully and consistently passes the Turing Test, you may have something. Otherwise, pointing and grunting might be less frustrating for normal people.

Another aside: pointing or at least gesturing is much better than even the perfect language interface for editing a photo or playing a video game. So it depends on the application.

One of the issues is that current UIs for computers have very little context information about whats on screen, which would make language based interaction much more convenient.

Also, editing a photo is a perfect example of where language interface would be useful: instead of hunting through Photoshop's millions of menus for the graphic effect you want, you could just say/type things like:

  Scale to 200%
  Increase contrast 10%
  Resize to 400 by 600

I'm pretty sure that language based interaction for photo-editing would increase productivity by huge amounts.

The other thing is that we've somehow locked onto the idea that the computer should be able to understand everything immediately or else it's not even worth it. But in the real world human's constantly miscommunicate, and we solve that problem very simply: ask more questions. So if the user says something like:

  Adjust contrast by 10%

The computer could respond:

  Do you want to increase by 10% or decrease by 10%?

This is how autocad works. (at least it used to - I haven't used it in several versions). An interactive command line complimented by a graphical ui is a beautiful thing.

But then you need to know the magic words (scale as opposed to "make bigger" or "zoom" or some other combination). Point and click context menus try to fix this -- "oh, it's 'scale'"

Or you could just allow all of them. If they serve different functions in different situations, the program can just ask which function the user meant. The point is that rather than view the program as a slave that is expected to follow orders unflinchingly, the program can be viewed as something to be conversed with, and capable of asking questions of the user.

Graphic UIs show you what actions are available right there, linguistic UIs rely on you to think up a valid expression in that program's particular language to do what you need. GUIs will always be easier for simpler stuff, but less expressive than LUIs.

Not sure I understand correctly "LUI" but if it means something near command line, I dare disagree. Two examples of "simple stuff" that are way easier in CLI than GUI: redo last action (up - enter), list actions done recently (history).

LUI = "Linguistic" UI, including CLI

You're right it can be easier once you are familiar with it, but there's nothing to suggest how/if "up" works if you are not.

Yet another blog post for the sake of a blog post.

Every educated software engineer know, that by respecting and following a fundamental programming methodologies, such as data-abstraction, modularity, encapsulation of details, and other basic techniques for managing the complexity of large systems, you will get maintainability and programmer-friendliness for free.

The problem is - most of in-house back-end developers and their public teachers doesn't have a even a basic engineering education.

People who have managed to understand the ideas on which the SICP book is based upon, let alone MIT graduates, never write such long but empty posts.

It's one thing for a random comment, but to see it on an actual, real live blog post by the likes of Zed is irritating.

"couldn't care less", please. How can you be hackers if you can't get some basic logic right?

If there were Zed Shaw fanboys I would be one.

Looks like Zed got some different Cooper's book than I did. Or misread it completely. "Inmates are running the asylum“ was one of the most useful books I ever read, it completely changed my attitude. It's not "don't let programmers to do interfaces", it is "build interfaces for intended users and intended usage". If Zed thinks that Cooper's book is idiotic then he is just unable to get what it's all about (like many other nerds — and that explains why open-source is good for servers and sucks in UI department). I hope he sticks to building awesome web servers nobody needs.

I don't know what book you read but the title alone, "The Inmates Are Running The Asylum" is offensive since it implies I'm the inmate. But take this quote just from the product description at Amazon:

"The Inmates are Running the Asylum argues that, despite appearances, business executives are simply not the ones in control of the high-tech industry. They have inadvertently put programmers and engineers in charge, leading to products and processes that waste money, squander customer loyalty, and erode competitive advantage. Business executives have let the inmates run the asylum!"

Don't get much clearer than that, but let's talk about the damage the book caused. For a book that purports to try to improve things for humans it sure caused a ton of damage to humans. It was lacking in almost any real substance and was effectively a thinly disguised rant about coders. It was used to fire programmers, boost fake ass business guys, and created the plague of crappily implemented products that may look slick, but fail in horrible ways.

In my own personal experience with the book I have had numerous executives and biz people toss it on my desk and say they read it and they agree. I've had friends fired or demoted because of this book. It also spawned whole generations of "UX consultants" who fleeced people using the phrasing and words in the book. I personally had to deal with consultant after consultant who would come in, looked at the best we could do, and then insult us. And any time a programmer tried to show who was really in charge and to blame, out came this damn book to prove us wrong.

I could go on, but no matter what little snippets of text you remember, the impact of the book the way I remember it is one of negativity toward a group of people who were not to blame: programmers.

Then it sounds like you've known some asshole executives and consultants that have completely misread this book.

Cooper's point was that, sans any other guidance, programmers naturally tend to create interfaces that reflect the structure of the code (since that is what they are immersed in) rather than the structure of their user's goals. And the reason they don't have any other guidance is that people running technology companies didn't have any kind of design phase other than sending salesmen out to get pointless checklists of features.

If anything, the book is a criticism of the way tech companies are (or at least used to be) run rather than a criticism of diligent programmers doing their best with incomplete information. In fact Cooper says this several times during the book. Unfortunately, it seems easier for a lot of business guys to use the book to transfer blame to programmers rather than implement what it actually says.

Really bad Amazon summary too.

Don't judge the book by the cover and description on Amazon. How about subtitle of the book: "Why High-Tech Products Drive Us Crazy and How to Restore the Sanity".

  It was lacking in almost any real substance and was
  effectively a thinly disguised rant about coders.

Looks like you were not able to understand the essence of the book (hint: it was not about programmers). And also looks like Cooper was right in his description of a typical programmer that he calls Homo Logicus.

It is sad and weird that many programmers don't like the book or, like you, see it as an attack on them. It's far from the truth. The book gives very accurate description how our (programmers') way of thinking differs from that of "ordinary" people. If you are a programmer writing software for other programmers it may be ok not to care how Joe User thinks, but if you are making product for general audience you better pay attention what Cooper says. I see a lot of his ideas in many successful products: Google Search, GMail, Apple products.

Just recall all the comments after Apple introduced iPad; look at the report that iPad now is the highest-scoring product that a leading consumer satisfaction index has ever tracked; and then go read chapter 7 "Homo Logicus". After that it should be clear how such a lame and purposeless device in the eyes of geeks can be so wildly successful product among consumers.

For me the takeaway from the book was not that "programmers are to blame" but "design for your user, not for you".

I had actually misinterpreted the title as implicating that the users are the inmates.

That is, I assumed it means the following: when you're building software, you have to accept that the users are the ones "living" in it. Even if the users are bat-crazy, you need to build them an asylum that makes them feel like they're running the show, rather than treat them like inmates to be subdued.

Not sure why you're being down voted but I got exactly the same impression. I'm usually a big Zed fan, and Mongrel2 looks great, but I think he's totally misread Cooper's book here.

> Not sure why you're being down voted

Two reasons:

> then he is just unable to get what it's all about (like many other nerds

Extremely flamebaity, abusive 'nerds,' and No True Scotsman-ish.

> I hope he sticks to building awesome web servers nobody needs.

Insulting.

Hey, I called Mongrel2 awesome, how is that insulting? ;) The first mongrel (I used and liked it), it solved the very real problem at the time. Mongrel2 may be 10x as awesome but now there is no unsolved problem for it to be as successful. Ok, I admit, it may be insulting, but calling that book idiotic is even more so.

Reply on news.ycombinator.com