15 ms·

How to Design Software Good

512 points by davisr 8y ago

davisr 8y ago
I feel these conventions, while written about HaikuOS, apply equally to all domains of software authorship.
- yoz-y 8y ago
  Indeed, a lot of these conventions are part of most of the platforms' Human Interface Guidelines.
lostgame 8y ago
I absolutely love long articles like this. This is full of brilliant information. Fantastic.
olooney 8y ago
Wow, this is more like a master class on GUI application design than the usual guidelines you see. I don't see a byline but someone poured a lot of love and wisdom into this.
- waddlesplash 8y ago
  Seems the DocBook XML styler broke; there is a byline in the original source: https://github.com/haiku/haiku/blob/master/docs/interface_guidelines/index.xml#L13 https://github.com/haiku/haiku/blob/master/docs/interface_gu... DarkWyrm hasn't been active on Haiku for some years now (though I think he has an occasionally-updated Twitter account?), so it's a community-maintained document at this point.
dajohnson89 8y ago
Is the grammatical error in the title intentional?
- TulliusCicero 8y ago
  I blame English. That language is always up to no well: https://www.smbc-comics.com/comic/noun https://www.smbc-comics.com/comic/noun
  - deleted 8y ago
    [deleted]
- monitorman 8y ago
  no
- neogodless 8y ago
  ... and want to learn how to do other stuff good too!
- stevewilhelm 8y ago
  I wasn't going to be "that guy," but it's "well" to see the question.
- deleted 8y ago
  [deleted]
- lucideer 8y ago
  I believe it's a reference to https://www.youtube.com/watch?v=NQ-8IuUkJJc https://www.youtube.com/watch?v=NQ-8IuUkJJc
nixpulvis 8y ago
Given: > Good Software Uses Everyday Language I'm curious why keyboard shortcuts are called accelerators. Overall looks like a pretty good set of things to think about as a UX designer.
- Narishma 8y ago
  That's what keyboard shortcuts were called in some systems like BeOS, early Windows and probably others. I would guess it's because they provide faster access to a feature or function than going through menus.
rlanday 8y ago
> Haiku is an operating system which is known for its speed and being easy for anyone to use. That's a fairly bold claim. Haiku is an OS that basically no one uses for any purpose. Why should I take any sort of design advice from them?
- adamnemecek 8y ago
  Haha no one using it means they can go ham on trying good designs as they are unbound by legacy reasons.
  - Koshkin 8y ago
    Actually, looks like Haiku is a compatible reimplementation of a "legacy" OS.
    - waddlesplash 8y ago
      Depends what you mean by "compatible." We preserve binary compatibility on 32-bit x86 with BeOS, indeed. But it hasn't stopped us from re-arranging parts of the GUI, or adding new APIs, or experimenting with the kernel, or ... etc.
- waddlesplash 8y ago
  Being "known for its speed and ease of use" and "very low user base" are ... not mutually exclusive in the slightest, so I fail to see how your comment has relevance? By your logic, since macOS has ~1/10 the install base of Windows, clearly this means that "very few" people use it and we should not take Apple's advice on anything design-related.
  - oralty 8y ago
    >> Haiku is an OS that basically no one uses for any purpose. > By your logic, since macOS has ~1/10 the install base of Windows, Does not follow. MacOS use relative to Windows is not at all a fair comparison. Firstly "everybody" uses Windows, so 1/10 of huge number is still a huge number. Second, except for gaming and some particular areas like EDA, MacOS has a general software library with a broad-base of technical and non-technical users throughout the world. Haiku OS cannot claim to have anything like that.
ASpring 8y ago
Looks like most of this is derivative of Molich and Nielsen's heuristic evaluation of user interfaces guidelines from 1990. https://dl.acm.org/citation.cfm?id=77486 https://dl.acm.org/citation.cfm?id=77486
GuiA 8y ago
...You can also make Tracker show a window for a particular folder in order to show the user where a particular file has been stored and give him access to it directly.... ...By removing unneeded items from the file navigation window, you are reducing the number of choices the user must pick from and also preventing him from opening the wrong kinds of files... ...Good feedback just means making sure that the user knows what your program is doing at any given time, especially if the program is busy doing something which makes him wait... ...An even better solution would be to select a good default choice for the user and give him the option to change it... ... In short, a user will learn only what he must in order to do his job... Ctrl-F "her", "she": 0 matches Another tip to design good software: don't assume all your users are male :) This is an okay stab at a HIG, although it is severely lacking in examples and screenshots, for a document that deals with graphical user interfaces. Good past attempts that are worth the read if you're into this kind of stuff include the original Macintosh HIG, as well as NextStep User Interface Guidelines. I also quite liked the Hypercard Stack Design Guidelines. Gnome once had an okay-ish HIG (which I contributed to), not sure how well up to date it's been kept through the years. KDE, despite being better on the eye candy front compared to Gnome, was always lacking behind in terms of actual concrete guidelines for developers.
- waddlesplash 8y ago
  This document was mostly written almost a decade ago, and by someone who I think went to a prestigious institution. So the "rules of style" back then aren't what they are today. You're right, we should update it, though.
  - JadeNB 8y ago
    > This document was mostly written almost a decade ago, and by someone who I think went to a prestigious institution. So the "rules of style" back then aren't what they are today. What does the second half of the first sentence have to do with the second sentence?
    - waddlesplash 8y ago
      That prestigious institutions up until the past few years used male pronouns to refer to generic individuals as being "proper English", which this document ostensibly is, and this explains the document's use of them?
kunthar 8y ago
at first, one will not start with generalized bullsh*te claim slogan to expose their own useless life to others. no matter how far they've gone, it is the point of everything ends.
emmelaich 8y ago
> Good Software Does Not Expose Its Implementation Excellent goal but way harder than people think. I would say it is not possible in the fullest.
- dmoy 8y ago
  http://www.hyrumslaw.com/ http://www.hyrumslaw.com/
- nine_k 8y ago
  Good software should expose its interface, not implementation. The implementation will shine through sometimes, or will be (easily) detectable via "side-channel attacks", e.g. an interface feature can be slow due to an implementation. OTOH this allows to upgrade and entirely change the implementation without affecting the user interface, or at least while keeping it largely backwards-compatible.
- Koshkin 8y ago
  Indeed. Software is just like a person: what you see is an "interface," but what you are actually dealing with is the "implementation."
- conradev 8y ago
  Definitely not possible. The implementation becomes the interface. Classic example from when iOS/macOS had manual reference counting: fixing an over-retain bug in the framework causes the app with an over-release bug to crash. Even more extreme example: https://twitter.com/gparker/status/1050903609142009856?s=20 https://twitter.com/gparker/status/1050903609142009856?s=20
- fao_ 8y ago
  I kind of feel that you just read the title here. It's not talking about the 'fullest': An example of this would be if a music composition program has an easily-reached maximum song size because the code monkey who wrote it used a 16-bit variable instead of a 32-bit one. *While there are sometimes limitations that cannot be overcome*, the actual code written and the architecture used when it was written should have as little effect as possible on what the user sees and works with when using your software. (emphasis mine) I think it might be better rephrased as: 1) Don't add unnecessary constraints (or: Don't prioritise efficiency/etc. over the interface). and 2) A good interface abstracts away technical problems, rather than presenting them in a different form.
jrockway 8y ago
I am not sure I agree with all of this. I worry that the article encourages you to dumb-down software so that your users feel completely helpless. That is the opposite of what you should do. Your users should feel enabled and encouraged to explore and experiment. Sometimes they may encounter jargon, but if it ultimately helps them gain a better understanding if they choose to research it more, I think it's helpful. There is a difference between saying "the file is corrupted, and there is nothing you can do" and "the file is corrupted, and you are too dumb to fix it so there is nothing you can do". Omitting details in the error forces users into the second class; even if most users are unwilling to google for a solution, you need not remove their ability to do so. (And in fact, most of these cases are the developers projecting -- the problem is not that the user did something wrong, but that the programmer messed up the implementation. Why should a file be corrupted when reed solomon codes exist? Very rarely have I seen a case where something was so damaged that it could not be recovered; rather, the engineers chose not to design in proper error recovery. Then they blame the user for a disk sector going bad when the engineers know full well that disk sectors can go bad.) The other thing I think I agree with is the philosophy on designing complicated operations. Every operation a user performs should leave them with no question as to what the outcome will be when they click the Big Red Button. And they should be able to painlessly undo it. Imagine typing without a backspace key. Your words per minute would be near-zero because of the fear of making a mistake. Undo is essential. The lack of transparency around state changes is something that makes users hate software. Who will this share button share with? What does "make my YouTube comment publicly accessible" actually mean? Users don't know, then they make the wrong decision based on incorrect information, and get mad -- and rightfully so. We blame the user, but it's our fault for laying hidden traps. You can implement social media without tricking users, but we choose not to. I see a lot of people fall into the "great is the enemy of good" trap with regards to undo. They see some operation that creates some immutable effect on the Universe, so the only remedy offered to the user is "email the dev team and we'll try and fix it." This is a pain for the dev team and a pain for the user. Yes, there are certainly permanent changes that software can make. Send an email, launch the nukes. But those should not be barriers to letting users undo. If they want to undo something that sent an email, you'll just have to send another email apologizing. That is all the development team is going to do when they have to manually fix it. Nukes can be killed while they're in flight; better to have some fallout near the launch site than to start World War III. And yet, we consistently fail to offer undo in most applications, so users learn to be very scared of doing anything, and that fear prevents them from accomplishing their goals. That's our fault, not the user's. I have seen this all in action at work. We have something that is a "big red button" (we're an ISP, it's the "change service plan" button). People will not click this, and it's because they don't know what it will do. If we said "clicking this will cause the customer to pay $x a month, with the next invoice being sent on 12/01 (click here to see a preview), and their bandwidth profile will be set to XMbps in the next 30 seconds", then people would click the button, because they know it will solve their problem, rather than create a problem. Anyway, you have to give your users understanding and the ability to safely experiment (which is how you gain understanding). That is what makes software a tool to enhance productivity, rather than an annoyance that makes the user do extra work. Just dumbing down your error messages isn't going to cut it.
qwerty456127 8y ago
> depend only on the formats installed by default in the system. Funny fact I've actually "invented" this philosophy (drivers for every file format being installed, managed and exposed to applications and scripts by an OS) when I was a child. I was amazed to see somebody has actually went implementing this idea (as far as I understand it works approximately this way in Haiku) > As an aside, MP3 is a format which requires licensing for decoding and encoding to be legal,so depending on the MP3 format is not a good idea unless your program deals specifically with it. This is not true, the patent has expired AFAIK and every desktop Linux distribution can play it out-of-the box for quite a long time already (and even if it would not have, people living in countries that don't have software patenting should be let to make use of their advantage). In fact MP3 is a great format to depend on as this is the only lossy audio compression format that really plays everywhere. AAC is better and can be played on the majority of modern devices and OSes but still not really everywhere, OPUS is the best but there still are so many devices and apps that don't support it unfortunately.
- jenscow 8y ago
  This page is from 2006.
  - deleted 8y ago
    [deleted]
- waddlesplash 8y ago
  > as far as I understand it works approximately this way in Haiku Yep, it is indeed. You can of course write your own translators for custom file formats and install them along with your application; but then anything which already handled whatever representation they produced (e.g. PNG/JPG/etc. images -> BBitmap, Haiku's image buffer class) could then handle those filetypes also. > This is not true, the patent has expired AFAIK Only last year, and this document was mostly written a decade ago :) Haiku can now play MP3 out of the box also (and since the servers and buildbots are mostly in Germany, we don't really pay much attention to U.S. patents anyway at this point.)
  - 8y ago
alwaysreading 8y ago
Love the idea of starting with “what will the user be doing?” and prioritizing based on that question.
cronix 8y ago
With a title like that, at least it wasn't an article about "How to Speak English Good"
- stevenhuang 8y ago
  The title's intended, it's meant to poke fun and be light hearted.
- s3cur3 8y ago
  Whoosh!
- kochikame 8y ago
  Yeah, OP should have gone to The Derek Zoolander Center For Kids Who Cant Read Good
nayuki 8y ago
I saw a quick flash of unstyled content (in Firefox) where all the text was jammed into one paragraph with no breaks. And then the page rendered normally. So I glanced at the source code, and it surprised me to see that it was not a typical HTML document, but instead an XML document with a stylesheet. It is very rare to see a non-HTML page on the web, whether it is the XHTML serialization of HTML, or fully custom XML.
- lemming 8y ago
  I agree this is very unusual. It's also somewhat annoying, for example I can't just send this to my Kindle to read it, and I can imagine other tools failing on this as well.
  - timClicks 8y ago
    Which is more the fault of the Kindle than the authors. It's Docbook, a standard that was invented for the purpose of writing books.
    - chipotle_coyote 8y ago
      It's great to use DocBook for writing books! (Actually, I don't think this is true for most books, but you do you.) But I would argue that processors that are designed to take HTML as input are not at fault for failing to process non-HTML documents. (Many, but not all) web browsers can render and style XML like this, but I'd argue that this is -- somewhat ironically given the article's subject -- probably not the best approach to putting DocBook files on the web.
      - deaddodo 8y ago
        The only way to build a fully conformant browser is to support rendering HTML as SGML with a DTD. Toy/specialty renderers skip over that step since you can assume 99.9999% of web documents will be HTML. However, they would completely fall apart on standard SGML, styled XML, etc.
    - 8y ago
bo1024 8y ago
I want to mention the classic book "The Design of Everyday Things" which shares a lot of points with this post, though not about software at all.
- war1025 8y ago
  I read this book a few years ago and was really disappointed by the content. Apparently the version I read was the "revised and expanded edition", so maybe it just got worse with the update...
  - rofo1 8y ago
    OT, but you are not alone - I also thought it wasn't that good as it was claimed. I've seen it recommended many times on HN.. I can't understand why. Now when I read the title, I immediately think of doors and handles.
CathyWest 8y ago
> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many niche industries are used to being shipped garbage, so they're just as happy too.
- lwansbrough 8y ago
  Seems like you kind of answered your own question. :)
- mathw 8y ago
  Nah they're not happy, they're just trained to think it's how things have to be.
  - CathyWest 8y ago
    You know that and I know that, but often it's easier said than done to convince them of it. I've had users get indignant because I dared criticise their favourite enterprise bloatware like I insulted their mothers. Even as they themselves were struggling with some misfeature keeping them from doing their actual work. But it does mean that it's easy to exceed their expectations, for example by making the browser back button take the user back to the previous view instead of crashing the entire user session. I tend to try to justify spending time solving technical debt by making development of new dazzling features faster and cheaper, but as long as the users (and more importantly their managers) are sufficiently dazzled if you only throw them a pittance once in a while, that becomes hard to sell.
- bengale 8y ago
  Pretty much my experience too. I don't think it's ever been worth the time or effort to spend time on writing quality software, the people that smash it out quickly are the ones rewarded. I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. It's maybe better for them to realise they are not artisans, they are bricklayers. To focus that creative energy on their own projects rather than getting burnt out fighting their managers over writing 'good software'.
doubletgl 8y ago
Sorry to be a pedant, but the grammar and capitalization in this guide do not instill confidence. "How to Design Software Good" <- design well? "How will Your Users Do Their Work?" <- Seriously?
- Antoninus 8y ago
  Maybe its meant to be tongue-in-cheek.
  - skohan 8y ago
    Or possibly a non-native english speaker.
  - heidar 8y ago
    I thought it was a vague zoolander reference.
    - lucideer 8y ago
      This is also what I assumed, and I'm fairly sure it is. Especially since the grammar in the article is relatively OK, whereas that title would be really terrible if it were not a pop-culture reference.
  - AznHisoka 8y ago
    Thats how I interpreted it. Sort of like when people say happy christmas instead of merry.
    - dionidium 8y ago
      "Happy Christmas" isn't tongue in cheek. It's just literally what people in England actually say.
      - AznHisoka 8y ago
        Everything people in England say is tongue in cheek though... but I get your point :)
manasirani 8y ago
hi
rwmj 8y ago
Slightly off topic, but has anyone tried Haiku? We recently ported nbdkit to Haiku and it was a pleasant experience dealing with the developer. However I never actually used Haiku (just reviewed and applied patches).
- Crestwave 8y ago
  I have. It was a joy to use; fast, cohesive but familiar due to partial POSIX compatibility, inspiration from other operating systems and a GNU command-line environment, with object-oriented design and unique concepts. One of which is its package manager, which installs into a filesystem image that is mounted read-only to ensure the files are incorruptible.
- mixmastamyk 8y ago
  It's easy to grab an .iso and run with Virtual Box. Every five years or so I do that with Haiku and ReactOS to see how they are progressing.
vitornovictor 8y ago
A great talk on the topic - John Ousterhout: "A Philosophy of Software Design": https://youtu.be/bmSAYlu0NcY https://youtu.be/bmSAYlu0NcY

512 points by davisr 8y ago

davisr 8y ago

I feel these conventions, while written about HaikuOS, apply equally to all domains of software authorship.

yoz-y 8y ago
Indeed, a lot of these conventions are part of most of the platforms' Human Interface Guidelines.

lostgame 8y ago

I absolutely love long articles like this. This is full of brilliant information. Fantastic.

olooney 8y ago

Wow, this is more like a master class on GUI application design than the usual guidelines you see. I don't see a byline but someone poured a lot of love and wisdom into this.

waddlesplash 8y ago
Seems the DocBook XML styler broke; there is a byline in the original source: https://github.com/haiku/haiku/blob/master/docs/interface_guidelines/index.xml#L13 https://github.com/haiku/haiku/blob/master/docs/interface_gu... DarkWyrm hasn't been active on Haiku for some years now (though I think he has an occasionally-updated Twitter account?), so it's a community-maintained document at this point.

dajohnson89 8y ago

Is the grammatical error in the title intentional?

TulliusCicero 8y ago
I blame English. That language is always up to no well: https://www.smbc-comics.com/comic/noun https://www.smbc-comics.com/comic/noun
- deleted 8y ago
  [deleted]
monitorman 8y ago
no
neogodless 8y ago
... and want to learn how to do other stuff good too!
stevewilhelm 8y ago
I wasn't going to be "that guy," but it's "well" to see the question.
deleted 8y ago
[deleted]
lucideer 8y ago
I believe it's a reference to https://www.youtube.com/watch?v=NQ-8IuUkJJc https://www.youtube.com/watch?v=NQ-8IuUkJJc

nixpulvis 8y ago

Given: > Good Software Uses Everyday Language I'm curious why keyboard shortcuts are called accelerators. Overall looks like a pretty good set of things to think about as a UX designer.

Narishma 8y ago
That's what keyboard shortcuts were called in some systems like BeOS, early Windows and probably others. I would guess it's because they provide faster access to a feature or function than going through menus.

rlanday 8y ago

> Haiku is an operating system which is known for its speed and being easy for anyone to use. That's a fairly bold claim. Haiku is an OS that basically no one uses for any purpose. Why should I take any sort of design advice from them?

adamnemecek 8y ago
Haha no one using it means they can go ham on trying good designs as they are unbound by legacy reasons.
- Koshkin 8y ago
  Actually, looks like Haiku is a compatible reimplementation of a "legacy" OS.
  - waddlesplash 8y ago
    Depends what you mean by "compatible." We preserve binary compatibility on 32-bit x86 with BeOS, indeed. But it hasn't stopped us from re-arranging parts of the GUI, or adding new APIs, or experimenting with the kernel, or ... etc.
waddlesplash 8y ago
Being "known for its speed and ease of use" and "very low user base" are ... not mutually exclusive in the slightest, so I fail to see how your comment has relevance? By your logic, since macOS has ~1/10 the install base of Windows, clearly this means that "very few" people use it and we should not take Apple's advice on anything design-related.
- oralty 8y ago
  >> Haiku is an OS that basically no one uses for any purpose. > By your logic, since macOS has ~1/10 the install base of Windows, Does not follow. MacOS use relative to Windows is not at all a fair comparison. Firstly "everybody" uses Windows, so 1/10 of huge number is still a huge number. Second, except for gaming and some particular areas like EDA, MacOS has a general software library with a broad-base of technical and non-technical users throughout the world. Haiku OS cannot claim to have anything like that.

ASpring 8y ago

Looks like most of this is derivative of Molich and Nielsen's heuristic evaluation of user interfaces guidelines from 1990. https://dl.acm.org/citation.cfm?id=77486 https://dl.acm.org/citation.cfm?id=77486

GuiA 8y ago

...You can also make Tracker show a window for a particular folder in order to show the user where a particular file has been stored and give him access to it directly.... ...By removing unneeded items from the file navigation window, you are reducing the number of choices the user must pick from and also preventing him from opening the wrong kinds of files... ...Good feedback just means making sure that the user knows what your program is doing at any given time, especially if the program is busy doing something which makes him wait... ...An even better solution would be to select a good default choice for the user and give him the option to change it... ... In short, a user will learn only what he must in order to do his job... Ctrl-F "her", "she": 0 matches Another tip to design good software: don't assume all your users are male :) This is an okay stab at a HIG, although it is severely lacking in examples and screenshots, for a document that deals with graphical user interfaces. Good past attempts that are worth the read if you're into this kind of stuff include the original Macintosh HIG, as well as NextStep User Interface Guidelines. I also quite liked the Hypercard Stack Design Guidelines. Gnome once had an okay-ish HIG (which I contributed to), not sure how well up to date it's been kept through the years. KDE, despite being better on the eye candy front compared to Gnome, was always lacking behind in terms of actual concrete guidelines for developers.

waddlesplash 8y ago
This document was mostly written almost a decade ago, and by someone who I think went to a prestigious institution. So the "rules of style" back then aren't what they are today. You're right, we should update it, though.
- JadeNB 8y ago
  > This document was mostly written almost a decade ago, and by someone who I think went to a prestigious institution. So the "rules of style" back then aren't what they are today. What does the second half of the first sentence have to do with the second sentence?
  - waddlesplash 8y ago
    That prestigious institutions up until the past few years used male pronouns to refer to generic individuals as being "proper English", which this document ostensibly is, and this explains the document's use of them?

kunthar 8y ago

at first, one will not start with generalized bullsh*te claim slogan to expose their own useless life to others. no matter how far they've gone, it is the point of everything ends.

emmelaich 8y ago

> Good Software Does Not Expose Its Implementation Excellent goal but way harder than people think. I would say it is not possible in the fullest.

dmoy 8y ago
http://www.hyrumslaw.com/ http://www.hyrumslaw.com/
nine_k 8y ago
Good software should expose its interface, not implementation. The implementation will shine through sometimes, or will be (easily) detectable via "side-channel attacks", e.g. an interface feature can be slow due to an implementation. OTOH this allows to upgrade and entirely change the implementation without affecting the user interface, or at least while keeping it largely backwards-compatible.
Koshkin 8y ago
Indeed. Software is just like a person: what you see is an "interface," but what you are actually dealing with is the "implementation."
conradev 8y ago
Definitely not possible. The implementation becomes the interface. Classic example from when iOS/macOS had manual reference counting: fixing an over-retain bug in the framework causes the app with an over-release bug to crash. Even more extreme example: https://twitter.com/gparker/status/1050903609142009856?s=20 https://twitter.com/gparker/status/1050903609142009856?s=20
fao_ 8y ago
I kind of feel that you just read the title here. It's not talking about the 'fullest': An example of this would be if a music composition program has an easily-reached maximum song size because the code monkey who wrote it used a 16-bit variable instead of a 32-bit one. *While there are sometimes limitations that cannot be overcome*, the actual code written and the architecture used when it was written should have as little effect as possible on what the user sees and works with when using your software. (emphasis mine) I think it might be better rephrased as: 1) Don't add unnecessary constraints (or: Don't prioritise efficiency/etc. over the interface). and 2) A good interface abstracts away technical problems, rather than presenting them in a different form.

jrockway 8y ago

I am not sure I agree with all of this. I worry that the article encourages you to dumb-down software so that your users feel completely helpless. That is the opposite of what you should do. Your users should feel enabled and encouraged to explore and experiment. Sometimes they may encounter jargon, but if it ultimately helps them gain a better understanding if they choose to research it more, I think it's helpful. There is a difference between saying "the file is corrupted, and there is nothing you can do" and "the file is corrupted, and you are too dumb to fix it so there is nothing you can do". Omitting details in the error forces users into the second class; even if most users are unwilling to google for a solution, you need not remove their ability to do so. (And in fact, most of these cases are the developers projecting -- the problem is not that the user did something wrong, but that the programmer messed up the implementation. Why should a file be corrupted when reed solomon codes exist? Very rarely have I seen a case where something was so damaged that it could not be recovered; rather, the engineers chose not to design in proper error recovery. Then they blame the user for a disk sector going bad when the engineers know full well that disk sectors can go bad.) The other thing I think I agree with is the philosophy on designing complicated operations. Every operation a user performs should leave them with no question as to what the outcome will be when they click the Big Red Button. And they should be able to painlessly undo it. Imagine typing without a backspace key. Your words per minute would be near-zero because of the fear of making a mistake. Undo is essential. The lack of transparency around state changes is something that makes users hate software. Who will this share button share with? What does "make my YouTube comment publicly accessible" actually mean? Users don't know, then they make the wrong decision based on incorrect information, and get mad -- and rightfully so. We blame the user, but it's our fault for laying hidden traps. You can implement social media without tricking users, but we choose not to. I see a lot of people fall into the "great is the enemy of good" trap with regards to undo. They see some operation that creates some immutable effect on the Universe, so the only remedy offered to the user is "email the dev team and we'll try and fix it." This is a pain for the dev team and a pain for the user. Yes, there are certainly permanent changes that software can make. Send an email, launch the nukes. But those should not be barriers to letting users undo. If they want to undo something that sent an email, you'll just have to send another email apologizing. That is all the development team is going to do when they have to manually fix it. Nukes can be killed while they're in flight; better to have some fallout near the launch site than to start World War III. And yet, we consistently fail to offer undo in most applications, so users learn to be very scared of doing anything, and that fear prevents them from accomplishing their goals. That's our fault, not the user's. I have seen this all in action at work. We have something that is a "big red button" (we're an ISP, it's the "change service plan" button). People will not click this, and it's because they don't know what it will do. If we said "clicking this will cause the customer to pay $x a month, with the next invoice being sent on 12/01 (click here to see a preview), and their bandwidth profile will be set to XMbps in the next 30 seconds", then people would click the button, because they know it will solve their problem, rather than create a problem. Anyway, you have to give your users understanding and the ability to safely experiment (which is how you gain understanding). That is what makes software a tool to enhance productivity, rather than an annoyance that makes the user do extra work. Just dumbing down your error messages isn't going to cut it.

qwerty456127 8y ago

> depend only on the formats installed by default in the system. Funny fact I've actually "invented" this philosophy (drivers for every file format being installed, managed and exposed to applications and scripts by an OS) when I was a child. I was amazed to see somebody has actually went implementing this idea (as far as I understand it works approximately this way in Haiku) > As an aside, MP3 is a format which requires licensing for decoding and encoding to be legal,so depending on the MP3 format is not a good idea unless your program deals specifically with it. This is not true, the patent has expired AFAIK and every desktop Linux distribution can play it out-of-the box for quite a long time already (and even if it would not have, people living in countries that don't have software patenting should be let to make use of their advantage). In fact MP3 is a great format to depend on as this is the only lossy audio compression format that really plays everywhere. AAC is better and can be played on the majority of modern devices and OSes but still not really everywhere, OPUS is the best but there still are so many devices and apps that don't support it unfortunately.

jenscow 8y ago
This page is from 2006.
- deleted 8y ago
  [deleted]
waddlesplash 8y ago
> as far as I understand it works approximately this way in Haiku Yep, it is indeed. You can of course write your own translators for custom file formats and install them along with your application; but then anything which already handled whatever representation they produced (e.g. PNG/JPG/etc. images -> BBitmap, Haiku's image buffer class) could then handle those filetypes also. > This is not true, the patent has expired AFAIK Only last year, and this document was mostly written a decade ago :) Haiku can now play MP3 out of the box also (and since the servers and buildbots are mostly in Germany, we don't really pay much attention to U.S. patents anyway at this point.)
- 8y ago

alwaysreading 8y ago

Love the idea of starting with “what will the user be doing?” and prioritizing based on that question.

cronix 8y ago

With a title like that, at least it wasn't an article about "How to Speak English Good"

stevenhuang 8y ago
The title's intended, it's meant to poke fun and be light hearted.
s3cur3 8y ago
Whoosh!
kochikame 8y ago
Yeah, OP should have gone to The Derek Zoolander Center For Kids Who Cant Read Good

nayuki 8y ago

I saw a quick flash of unstyled content (in Firefox) where all the text was jammed into one paragraph with no breaks. And then the page rendered normally. So I glanced at the source code, and it surprised me to see that it was not a typical HTML document, but instead an XML document with a stylesheet. It is very rare to see a non-HTML page on the web, whether it is the XHTML serialization of HTML, or fully custom XML.

lemming 8y ago
I agree this is very unusual. It's also somewhat annoying, for example I can't just send this to my Kindle to read it, and I can imagine other tools failing on this as well.
- timClicks 8y ago
  Which is more the fault of the Kindle than the authors. It's Docbook, a standard that was invented for the purpose of writing books.
  - chipotle_coyote 8y ago
    It's great to use DocBook for writing books! (Actually, I don't think this is true for most books, but you do you.) But I would argue that processors that are designed to take HTML as input are not at fault for failing to process non-HTML documents. (Many, but not all) web browsers can render and style XML like this, but I'd argue that this is -- somewhat ironically given the article's subject -- probably not the best approach to putting DocBook files on the web.
    - deaddodo 8y ago
      The only way to build a fully conformant browser is to support rendering HTML as SGML with a DTD. Toy/specialty renderers skip over that step since you can assume 99.9999% of web documents will be HTML. However, they would completely fall apart on standard SGML, styled XML, etc.
  - 8y ago

bo1024 8y ago

I want to mention the classic book "The Design of Everyday Things" which shares a lot of points with this post, though not about software at all.

war1025 8y ago
I read this book a few years ago and was really disappointed by the content. Apparently the version I read was the "revised and expanded edition", so maybe it just got worse with the update...
- rofo1 8y ago
  OT, but you are not alone - I also thought it wasn't that good as it was claimed. I've seen it recommended many times on HN.. I can't understand why. Now when I read the title, I immediately think of doors and handles.

CathyWest 8y ago

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many niche industries are used to being shipped garbage, so they're just as happy too.

lwansbrough 8y ago
Seems like you kind of answered your own question. :)
mathw 8y ago
Nah they're not happy, they're just trained to think it's how things have to be.
- CathyWest 8y ago
  You know that and I know that, but often it's easier said than done to convince them of it. I've had users get indignant because I dared criticise their favourite enterprise bloatware like I insulted their mothers. Even as they themselves were struggling with some misfeature keeping them from doing their actual work. But it does mean that it's easy to exceed their expectations, for example by making the browser back button take the user back to the previous view instead of crashing the entire user session. I tend to try to justify spending time solving technical debt by making development of new dazzling features faster and cheaper, but as long as the users (and more importantly their managers) are sufficiently dazzled if you only throw them a pittance once in a while, that becomes hard to sell.
bengale 8y ago
Pretty much my experience too. I don't think it's ever been worth the time or effort to spend time on writing quality software, the people that smash it out quickly are the ones rewarded. I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. It's maybe better for them to realise they are not artisans, they are bricklayers. To focus that creative energy on their own projects rather than getting burnt out fighting their managers over writing 'good software'.

doubletgl 8y ago

Sorry to be a pedant, but the grammar and capitalization in this guide do not instill confidence. "How to Design Software Good" <- design well? "How will Your Users Do Their Work?" <- Seriously?

Antoninus 8y ago
Maybe its meant to be tongue-in-cheek.
- skohan 8y ago
  Or possibly a non-native english speaker.
- heidar 8y ago
  I thought it was a vague zoolander reference.
  - lucideer 8y ago
    This is also what I assumed, and I'm fairly sure it is. Especially since the grammar in the article is relatively OK, whereas that title would be really terrible if it were not a pop-culture reference.
- AznHisoka 8y ago
  Thats how I interpreted it. Sort of like when people say happy christmas instead of merry.
  - dionidium 8y ago
    "Happy Christmas" isn't tongue in cheek. It's just literally what people in England actually say.
    - AznHisoka 8y ago
      Everything people in England say is tongue in cheek though... but I get your point :)

manasirani 8y ago

rwmj 8y ago

Slightly off topic, but has anyone tried Haiku? We recently ported nbdkit to Haiku and it was a pleasant experience dealing with the developer. However I never actually used Haiku (just reviewed and applied patches).

Crestwave 8y ago
I have. It was a joy to use; fast, cohesive but familiar due to partial POSIX compatibility, inspiration from other operating systems and a GNU command-line environment, with object-oriented design and unique concepts. One of which is its package manager, which installs into a filesystem image that is mounted read-only to ensure the files are incorruptible.
mixmastamyk 8y ago
It's easy to grab an .iso and run with Virtual Box. Every five years or so I do that with Haiku and ReactOS to see how they are progressing.

vitornovictor 8y ago

A great talk on the topic - John Ousterhout: "A Philosophy of Software Design": https://youtu.be/bmSAYlu0NcY https://youtu.be/bmSAYlu0NcY