Love the idea of starting with “what will the user be doing?” and prioritizing based on that question.
How to Design Software Good
31–40 of 191 posts
Re: How to Design Software Good
#32> 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?
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.
>> 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.
Re: How to Design Software Good
#33Earlier quoted context omitted.
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.
>> 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…
> 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.
That was the second half of my comment. Please re-read the first half.
My point in that part, though, was that macOS has ~1/10 the users of Windows, but Windows' UI/UX was/is widely regarded as absolutely atrocious, and macOS' as being pretty good to great, depending on who you ask. So "if it has less users, their thoughts on design are irrelevant" is ... not a good argument.
Re: How to Design Software Good
#34> 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.
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
Re: How to Design Software Good
#35I 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. T…
> 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.
Aside from the fact that it's a minefield of dark patterns, how did social media get into this discussion?
Re: How to Design Software Good
#36...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 kno…
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.
> 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?
Re: How to Design Software Good
#37With a title like that, at least it wasn't an article about "How to Speak English Good"
Re: How to Design Software Good
#38I 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. T…
> 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. Aside from the fact that it's a minefield of dark patterns, how did social media get into this discussion?
> Aside from the fact that it's a minefield of dark patterns, how did social media get into this discussion?
"Aside from [the thing that makes it relevant to this discussion], how is [x] relevant to this discussion?".
Re: How to Design Software Good
#39With a title like that, at least it wasn't an article about "How to Speak English Good"
The title's intended, it's meant to poke fun and be light hearted.
Re: How to Design Software Good
#40> 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.
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.
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.