6 ms·

> Sometimes catering to how the machine works makes things better than going through hoops for marginal returns and complicating every part of the stack with th

> Sometimes catering to how the machine works makes things better than going through hoops for marginal returns and complicating every part of the stack with that technical debt. You might be interested in reading "the design of everyday things" by Norman. If you are developing something for your own use, who cares. But for something that users (even technical users) are going to use, these marginal returns are what makes the difference between a pleasant or a frustrating experience. It's the kind of things that Apple users (used to?) expect in Macs.

coldtea 9y ago
>You might be interested in reading "the design of everyday things" by Norman. I've read it 20+ years ago as suggested by a HCI class at the uni. The point still stands, regardless of whether it's something for "one's own use" or not. The technical debt from such decisions like a non-case-sensitive fs and the piles upon piles of kludges required to sustain it affect everybody, including the "non technical users". >these marginal returns are what makes the difference between a pleasant or a frustrating experience Users can be taught a simple, unambiguous rule, and they'll never think twice about it. "Pleasant experiences" that come with performance penalties, bugs and caveats on the other hand, make them suffer more, whether they know the cause or not. At some point the Clippy was somebody's idea to "delight the users" too. >It's the kind of things that Apple users (used to?) expect in Macs. And the kind of thing Apple itself decided it was not worth it.
- gattilorenz 9y ago
  I don't really see these piles of kludges, honestly. Windows and OS X do it without much fanfare (which is great, consistency between the two major desktop OSes), and it works as users expect. Now, if we take the example in this thread (INSTALL and install), WHY ON EARTH did the programmer think it was a great idea to do name files like that? Sure, INSTALL for a readme is a tradition in free/*nix software, but then s/he could rename the other file. It seems to me that what really affects users are these nonsensical decisions taken without ease of use and ergonomics in mind. In 99.9% of cases (no pun intended), case sensitivity is useless and needlessly confusing, which is why you don't use variables named buffer and Buffer in the same scope (I hope), even if you can. > And the kind of thing Apple itself decided it was not worth it. Well, I'm still using a Mac because I think the whole experienced is way more polished and consistent than any other Unix, or Windows. And I'm sure many here agree.
michaelmrose 9y ago
Good design is having the users mental model of how a thing works and the mechanics be as close as possible so that users aren't confused. Having afile and aFile be different files is clear and unambiguous. In languages other than english case insensitive characters aren't nearly as clear. Case insensitivity is bad design by the standards established by Norman whose book I have also read.
- gattilorenz 9y ago
  > Case insensitivity is bad design by the standards established by Norman whose book I have also read. Well, that's at least arguable. See for example https://www.nngroup.com/articles/readers-comments-on-url-as-ui/ https://www.nngroup.com/articles/readers-comments-on-url-as-... "We don't need any more case-sensitive computers . It is now several decades since research on human errors proved the prevalence of description errors where people easily confuse two situations that are virtually identical except for a small difference" That's from Jakob Nielsen, of the Nielsen-Norman group, in which the Norman is that Norman we both referred to.
  - michaelmrose 9y ago
    The context is case sensitivity in cookies in an article talking about urls. It includes no broader context although it might be suggestive of it. File systems pose different challenges than urls. Ambiguity in file systems is wholly unacceptable and its more important to be simple and correct than keep idiots from typing afile instead of Afile. Also it can be bad design in the sense that Norman described even if Norman himself disagrees.
    - gattilorenz 9y ago
      The context, but not the quote, which refers to computers and not cookies. Also the example that I didn't quote is referring to text editor commands, which clearly are not cookies, so the argument seems more general. Of course Norman and Nielsen could be wrong, even if they are renowned experts of this field. But please consider that you might be wrong, too :)

coldtea 9y ago

>You might be interested in reading "the design of everyday things" by Norman. I've read it 20+ years ago as suggested by a HCI class at the uni. The point still stands, regardless of whether it's something for "one's own use" or not. The technical debt from such decisions like a non-case-sensitive fs and the piles upon piles of kludges required to sustain it affect everybody, including the "non technical users". >these marginal returns are what makes the difference between a pleasant or a frustrating experience Users can be taught a simple, unambiguous rule, and they'll never think twice about it. "Pleasant experiences" that come with performance penalties, bugs and caveats on the other hand, make them suffer more, whether they know the cause or not. At some point the Clippy was somebody's idea to "delight the users" too. >It's the kind of things that Apple users (used to?) expect in Macs. And the kind of thing Apple itself decided it was not worth it.

gattilorenz 9y ago
I don't really see these piles of kludges, honestly. Windows and OS X do it without much fanfare (which is great, consistency between the two major desktop OSes), and it works as users expect. Now, if we take the example in this thread (INSTALL and install), WHY ON EARTH did the programmer think it was a great idea to do name files like that? Sure, INSTALL for a readme is a tradition in free/*nix software, but then s/he could rename the other file. It seems to me that what really affects users are these nonsensical decisions taken without ease of use and ergonomics in mind. In 99.9% of cases (no pun intended), case sensitivity is useless and needlessly confusing, which is why you don't use variables named buffer and Buffer in the same scope (I hope), even if you can. > And the kind of thing Apple itself decided it was not worth it. Well, I'm still using a Mac because I think the whole experienced is way more polished and consistent than any other Unix, or Windows. And I'm sure many here agree.

michaelmrose 9y ago

Good design is having the users mental model of how a thing works and the mechanics be as close as possible so that users aren't confused. Having afile and aFile be different files is clear and unambiguous. In languages other than english case insensitive characters aren't nearly as clear. Case insensitivity is bad design by the standards established by Norman whose book I have also read.

gattilorenz 9y ago
> Case insensitivity is bad design by the standards established by Norman whose book I have also read. Well, that's at least arguable. See for example https://www.nngroup.com/articles/readers-comments-on-url-as-ui/ https://www.nngroup.com/articles/readers-comments-on-url-as-... "We don't need any more case-sensitive computers . It is now several decades since research on human errors proved the prevalence of description errors where people easily confuse two situations that are virtually identical except for a small difference" That's from Jakob Nielsen, of the Nielsen-Norman group, in which the Norman is that Norman we both referred to.
- michaelmrose 9y ago
  The context is case sensitivity in cookies in an article talking about urls. It includes no broader context although it might be suggestive of it. File systems pose different challenges than urls. Ambiguity in file systems is wholly unacceptable and its more important to be simple and correct than keep idiots from typing afile instead of Afile. Also it can be bad design in the sense that Norman described even if Norman himself disagrees.
  - gattilorenz 9y ago
    The context, but not the quote, which refers to computers and not cookies. Also the example that I didn't quote is referring to text editor commands, which clearly are not cookies, so the argument seems more general. Of course Norman and Nielsen could be wrong, even if they are renowned experts of this field. But please consider that you might be wrong, too :)