7 ms·

I know where this ends; been there done that. The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too compl

I know where this ends; been there done that. The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated" (0), shuts down and uninstall the software then chooses an easier one that forces mostly predefined options on a dumbed down panel, only to complain later that it can't do this and that therefore a more powerful one is needed. Rinse, repeat:^) Also, if anyone is using a RAD for developing the software for a customer, never, ever, ever, show the customer that a button or any other widget can be easily shown or not, moved, resized etc. on the panel, or be prepared to be asked a layout change like twice a day, of course for free since it's just 5 seconds of clicking. Seriously, sometimes it's much better for users to believe that the UI is some sort of black magic that cannot be touched otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of. (0) Some good research has been done in the past about how much information the user can be shown before the amount of it ends up distracting from the problem; iirc probably IBM was involved; I was told about that in the mid-end 90s but it likely dates from the previous decade.

irq11 7y ago
Well, yes: if you design something badly, users don’t want it. So let’s add “thoughtful design” to the list of things that users want, but which programmers don’t care about. And before anyone says it: there’s nothing on the list that is unreasonable to implement, or that requires a messy/confusing control panel. Apple software has most/all of these features, and more. You have to be willing to iterate on the interaction design of features. If your first instinct is to cram it all into a single config to close the ticket, that’s an okay starting point, but it isn’t where you want to end up.
- loxs 7y ago
  Apple's software is the worst when you need to configure something. Especially on iOS. Most people tend to use the default because usually they can't find, let alone configure the settings.
  - irq11 7y ago
    Right, so one programmer says features are confusing and shouldn’t be done because they’re in the user’s face. Another says that it’s confusing to hide them. Sense a pattern here?
    - Kaiyou 7y ago
      Not all users are the same, is the moral of the story here.
  - deergomoo 7y ago
    I think generally their mantra is to choose sensible (though that's debatable) defaults, and minimise the ability to configure at all. Of course, that drives some people insane, and even if you generally like it, you're totally stuck if they make a choice you don't like. Same goes for hardware -- I really like macOS, but if Apple started, oh I don't know, releasing laptops with non-functional keyboards, I have nowhere else to go. I get more frustrated by the lack of communication of activity/failure states though. So much of their software on both iOS and macOS will give you nothing more than a spinner to indicate activity, then if something goes wrong will just...fail silently. Even informing the user that something failed is despairingly rare.
    - mpweiher 7y ago
      > minimise the ability to configure at all Yep. What users want is "Freedom from Choice". See also: The Paradox of Choice. And that's one of the fundamental value propositions of the Apple brand: we have fussed the details so you don't have to. And that approach has interesting failure modes.
- asjw 7y ago
  Apple software is simply dumbed down defaults with hidden settings (most of the time settings are also not that useful)
chme 7y ago
Well some applications have a 'simple' mode per default and then let the user switch to 'advanced'. That would probably also something for this list.
- savolai 7y ago
  In interaction/UX design this is called progressive disclosure, and is explained on a strategic level here: https://www.interaction-design.org/literature/topics/progressive-disclosure https://www.interaction-design.org/literature/topics/progres...
ehnto 7y ago
> otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of. I think if you're having trouble managing the workload of UI changes it's a project management/process problem, your client should know how much it interrupts feature development, so that they can weigh up the cost. While I understand where you're coming from as I've been there, the article was about exactly this line of thinking. You don't care about the minor UI change but the customer does, and they're the ones using the software. Who's issues are really more important? I am sure you can come up with an example of a pressing development issue that would trump the UI change, but is that really 100% of your time? I'm sure tonnes of UI changes seem trivial to developers, but would be the difference between hours a day of a task being frustrating versus a task being easy for the end user. We don't use the end product like they do, so we can't really know which one's are trivial and which aren't.
- icebraining 7y ago
  The assumption that the client is the user doesn't hold true in many projects. In fact, letting the client mess up the layout may ruin a UI that was carefully validated with the the user.
  - ehnto 7y ago
    That's a fair point. My comment was imagining a project where the customer was the user/users.
    - icebraining 7y ago
      I can't say I've ever seen one of those! (Except for B2C, but that's a different case)
  - squarefoot 7y ago
    "The assumption that the client is the user doesn't hold true in many projects." True, the discussion brought to mind a couple projects where the customer/user were the same person. I should have mentioned that, sorry.
reacweb 7y ago
Once, I had to organize a meeting to propose a big reorganization of the supervision of our main software. There were some functional changes et some UI changes. I was inpired by the story about Steve Jobs and the calculator. I have brought a prototype where I could change fonts (size, boldness, italics, color), some text and tooltips. This meeting was a success. The stakeholders were happy to have influenced the UI. All the functional changes were accepted. No further roundtrip.
- JoshMcguigan 7y ago
  For those who haven't seen it, I believe reacweb is referencing this [0]. [0]: https://www.folklore.org/StoryView.py?story=Calculator_Construction_Set.txt https://www.folklore.org/StoryView.py?story=Calculator_Const...
  - deleted 7y ago
    [deleted]
  - huffmsa 7y ago
    But in the end it doesn't sound like they shipped the configurability features, just the Jobs UI. So the the moral here is "if you work for Steve Jobs, let him do the designs."
    - blowski 7y ago
      I might alter it slightly to say "If you work for someone that thinks they're Steve Jobs, let them do the designs".
      - huffmsa 7y ago
        Will definitely result in managerial approval of the design, but not necessarily a good design.
        ryandrake 7y ago
bartread 7y ago
> ...or be prepared to be asked a layout change like twice a day, of course for free since it's just 5 seconds of clicking. ... otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of. No joke: I've retired a product where this kind of support was a substantial enough issue to negate profitability when all other factors were taken into consideration. This wasn't a project management issue (as other posters have suggested), but a problem with the commercial model of the product: fundamentally the pitch over-promised to a degree that the product couldn't be run profitably. Beyond this it also damaged our ability to work on more profitable and strategic areas. Opportunity cost is harder to quantify but it was obviously still a factor in the decision to retire the product.
YeGoblynQueenne 7y ago
Isn't this a matter of communicating well with the customer? You make a very reasonable point here and it's clear to me that applying minor tweaks too often is disruptive and ends up accumulating costs. Surely the customer can be made aware of that? In the worst case you can even bill them about it - or even impose a limit to the number of times they can apply minor changes within a day etc. I agree that sometimes good communication (or good results anyway) means keeping some things from customers who are not technical because they might misunderstand them, but obfuscation of every detail of development is probably not the best way to work with someone who isn't a developer, no?
tarsinge 7y ago
> the user looks at it saying "uh... too complicated" The context is really important, otherwise Photoshop, Logic, or any ERP wouldn’t have users. Also I disagree with the part regarding the UI. It’s the customer money. If they want to prioritize futile details it’s their choice, just bill accordingly. It’s your job to inform them what it’s important to keep there project on track and that changing the UI will move the deadline for example.
holri 7y ago
Yeah, but showing the user the GUI early is important because otherwise you are risking to build the wrong tool. End users usually only understand the GUI not a specification.
deaps 7y ago
>>The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated" A good example of this is: Reflection Workspace vs Putty I know which one i'd choose (between the two, assuming cygwin wasn't an option). There absolutely is such a thing as too much. Although with Putty, I'd never complain about its simplicity -- it has just enough. Just google the user docs for "Reflection Workspace" if you've never used it. Maybe there are more uses to it, but for the work place I mentioned above, it was 100% just a means of connecting with ssh.
ken 7y ago
> all those options in a configuration panel I think this is the classic example of "things programmers think users want but don't". There's a literal translation from if-statements -> command-line flags -> checkboxes/radiobuttons. It's easy to implement, and users don't want it, because users don't use applications by thinking about the if-statements used to implement them. Half of these items should simply be fixed or implemented, and don't correspond to "options" at all.
mmcgaha 7y ago
Create a separate "Power Users" configuration program. Everyone loves being a power user.
- magduf 7y ago
  They tried this with KDE. It didn't go over well. Everyone just complained about all the configuration options.
- andrewflnr 7y ago
  So that's how gnome-tweaks happened. I was always confused why there were a bunch of settings you had to install another package to change.
magduf 7y ago
>I know where this ends; been there done that. The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated" (0), shuts down and uninstall the software then chooses an easier one that forces mostly predefined options on a dumbed down panel, only to complain later that it can't do this and that therefore a more powerful one is needed. This is exactly correct, except maybe for the very last phrase (usually, I think users just put up with the dumbed-down software and just complain about how it doesn't do exactly what they want, and when someone suggests an alternative that has more configuration options, they reject it, saying that they don't want to deal with all those configuration options). We saw this on Linux desktops with the KDE-GNOME war, and this is with users who are generally considered to be more technically inclined than your average Windows user. Gnome users would complain about options and features being removed, KDE users would point out that KDE has all these features and lots of configurability, and complaining Gnome users would reject it saying it's too complicated and they don't want to deal with all those configuration options. Somehow, the idea of simply leaving the options at the defaults (except the one or two they wanted to change) was completely incomprehensible to them. Users don't really want freedom of choice. They want something that reads their mind.
- doubleunplussed 7y ago
  For me I don't like having to keep track of what's default and what's not. What if I change a default, things change unexpectedly somewhere as a result, and I'm not able to work out what change it was due to? Fewer options decreases the odds of this happening. Other good approaches are highlighting settings that are different from the default. Many UIs do this, but unfortunately it's hard to get a birds-eye-view. Now, config files! Thousands of options, quite happy to hack on that. You know why? Because I can diff against the default and get a birds-eye-view of what's different. I'm not sure if KDE's settings are all text files underneath, but that's the issue. If there were a settings dialog somewhere saying "here's what's different to the default, out of all the KDE settings", that would help a lot. Otherwise it's just too hard to keep track of. This would help on GNOME too, but in the absence of that, simply having fewer settings is a kind of reassurance that there aren't many you've changed and forgotten about. A separate point, but running default settings is also sticking to the "happy path". It's more well-tested, and I've learned I shouldn't change too many settings different from the defaults, even if they are officially supported, because things aren't as well tested - even if everything official works, third-party things tend to make assumptions that are violated.
bluGill 7y ago
As I recall - from the mid-90's so my memory is probably a bit wrong... IBM discovered that the level of details changes the type of information they got. A couple pieces of paper with hand drawn UI would get great comments on work flow. If you move to more and more realistic simulations of the real environment the comments focused more and more on trivial details and less on the big picture - if the UI looked like it was complete and ready to ship the comments would be about moving things a pixel (never to a different part of the screen even if the screen was designed to put things that belong together apart), or changing the shade of colors.
- sli 7y ago
  What you're describing is called bikeshedding. I'd bet people generally feel like it's easier to "contribute" to a drawing than to something that looks more concrete, like a demo or semi-functional mockup.
  - bluGill 7y ago
    No, bike shedding is different. Bike shedding is a pointless contribution to something just to prove you thought about it. This is about a situation where you are being asked to contribute, but not giving the contribution wanted.
    - Rychard 7y ago
      This is incorrect. Bikeshedding[1] applies when people prefer to discuss less complicated issues rather than those of a higher priority (which are more complicated). It's not that discussions on such topics are pointless, but rather that they are of relatively minor importance in the grand scheme of things. [1] https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding
      - bluGill 7y ago
        Bike shedding is when you discussion irrelevant issues. If I ask you what do you think of about this shade of red for my bike shed your answer isn't bike shedding. If I ask you if I can build a bike shed and you tell me only if it is red that is bike shedding. When I ask someone for an opinion on my mock up and they give one it isn't bike shedding. That different mock ups will get a different response is interesting, but no response is bike shedding even if some responses are useless.
mixmastamyk 7y ago
There are ways of supporting extensive configuration without showing all options at once. Firefox config is one good example, vlc’s strategy is not my favorite but it works, “advanced…” buttons are another.
alexhutcheson 7y ago
In addition, every additional setting multiplies the number of states your application can be in, and the combinatorial explosion of states is mostly not well-tested. If you set even a handful settings to non-default values, it's likely that you are running the application in a totally unique configuration that's not used by any other developer or user. If you encounter bugs, you're liable to get the "Idk, it works on my machine" response. This blog post also covers other good reasons why user options are often not the right choice: https://garethrees.org/2013/06/13/options/ https://garethrees.org/2013/06/13/options/

irq11 7y ago

Well, yes: if you design something badly, users don’t want it. So let’s add “thoughtful design” to the list of things that users want, but which programmers don’t care about. And before anyone says it: there’s nothing on the list that is unreasonable to implement, or that requires a messy/confusing control panel. Apple software has most/all of these features, and more. You have to be willing to iterate on the interaction design of features. If your first instinct is to cram it all into a single config to close the ticket, that’s an okay starting point, but it isn’t where you want to end up.

loxs 7y ago
Apple's software is the worst when you need to configure something. Especially on iOS. Most people tend to use the default because usually they can't find, let alone configure the settings.
- irq11 7y ago
  Right, so one programmer says features are confusing and shouldn’t be done because they’re in the user’s face. Another says that it’s confusing to hide them. Sense a pattern here?
  - Kaiyou 7y ago
    Not all users are the same, is the moral of the story here.
- deergomoo 7y ago
  I think generally their mantra is to choose sensible (though that's debatable) defaults, and minimise the ability to configure at all. Of course, that drives some people insane, and even if you generally like it, you're totally stuck if they make a choice you don't like. Same goes for hardware -- I really like macOS, but if Apple started, oh I don't know, releasing laptops with non-functional keyboards, I have nowhere else to go. I get more frustrated by the lack of communication of activity/failure states though. So much of their software on both iOS and macOS will give you nothing more than a spinner to indicate activity, then if something goes wrong will just...fail silently. Even informing the user that something failed is despairingly rare.
  - mpweiher 7y ago
    > minimise the ability to configure at all Yep. What users want is "Freedom from Choice". See also: The Paradox of Choice. And that's one of the fundamental value propositions of the Apple brand: we have fussed the details so you don't have to. And that approach has interesting failure modes.
asjw 7y ago
Apple software is simply dumbed down defaults with hidden settings (most of the time settings are also not that useful)

chme 7y ago

Well some applications have a 'simple' mode per default and then let the user switch to 'advanced'. That would probably also something for this list.

savolai 7y ago
In interaction/UX design this is called progressive disclosure, and is explained on a strategic level here: https://www.interaction-design.org/literature/topics/progressive-disclosure https://www.interaction-design.org/literature/topics/progres...

ehnto 7y ago

> otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of. I think if you're having trouble managing the workload of UI changes it's a project management/process problem, your client should know how much it interrupts feature development, so that they can weigh up the cost. While I understand where you're coming from as I've been there, the article was about exactly this line of thinking. You don't care about the minor UI change but the customer does, and they're the ones using the software. Who's issues are really more important? I am sure you can come up with an example of a pressing development issue that would trump the UI change, but is that really 100% of your time? I'm sure tonnes of UI changes seem trivial to developers, but would be the difference between hours a day of a task being frustrating versus a task being easy for the end user. We don't use the end product like they do, so we can't really know which one's are trivial and which aren't.

icebraining 7y ago
The assumption that the client is the user doesn't hold true in many projects. In fact, letting the client mess up the layout may ruin a UI that was carefully validated with the the user.
- ehnto 7y ago
  That's a fair point. My comment was imagining a project where the customer was the user/users.
  - icebraining 7y ago
    I can't say I've ever seen one of those! (Except for B2C, but that's a different case)
- squarefoot 7y ago
  "The assumption that the client is the user doesn't hold true in many projects." True, the discussion brought to mind a couple projects where the customer/user were the same person. I should have mentioned that, sorry.

reacweb 7y ago

Once, I had to organize a meeting to propose a big reorganization of the supervision of our main software. There were some functional changes et some UI changes. I was inpired by the story about Steve Jobs and the calculator. I have brought a prototype where I could change fonts (size, boldness, italics, color), some text and tooltips. This meeting was a success. The stakeholders were happy to have influenced the UI. All the functional changes were accepted. No further roundtrip.

JoshMcguigan 7y ago
For those who haven't seen it, I believe reacweb is referencing this [0]. [0]: https://www.folklore.org/StoryView.py?story=Calculator_Construction_Set.txt https://www.folklore.org/StoryView.py?story=Calculator_Const...
- deleted 7y ago
  [deleted]
- huffmsa 7y ago
  But in the end it doesn't sound like they shipped the configurability features, just the Jobs UI. So the the moral here is "if you work for Steve Jobs, let him do the designs."
  - blowski 7y ago
    I might alter it slightly to say "If you work for someone that thinks they're Steve Jobs, let them do the designs".
    - huffmsa 7y ago
      Will definitely result in managerial approval of the design, but not necessarily a good design.
      - ryandrake 7y ago

bartread 7y ago

> ...or be prepared to be asked a layout change like twice a day, of course for free since it's just 5 seconds of clicking. ... otherwise they'll waste all your time rearranging the layout instead of concentrating on more important issues they're not aware of. No joke: I've retired a product where this kind of support was a substantial enough issue to negate profitability when all other factors were taken into consideration. This wasn't a project management issue (as other posters have suggested), but a problem with the commercial model of the product: fundamentally the pitch over-promised to a degree that the product couldn't be run profitably. Beyond this it also damaged our ability to work on more profitable and strategic areas. Opportunity cost is harder to quantify but it was obviously still a factor in the decision to retire the product.

YeGoblynQueenne 7y ago

Isn't this a matter of communicating well with the customer? You make a very reasonable point here and it's clear to me that applying minor tweaks too often is disruptive and ends up accumulating costs. Surely the customer can be made aware of that? In the worst case you can even bill them about it - or even impose a limit to the number of times they can apply minor changes within a day etc. I agree that sometimes good communication (or good results anyway) means keeping some things from customers who are not technical because they might misunderstand them, but obfuscation of every detail of development is probably not the best way to work with someone who isn't a developer, no?

tarsinge 7y ago

> the user looks at it saying "uh... too complicated" The context is really important, otherwise Photoshop, Logic, or any ERP wouldn’t have users. Also I disagree with the part regarding the UI. It’s the customer money. If they want to prioritize futile details it’s their choice, just bill accordingly. It’s your job to inform them what it’s important to keep there project on track and that changing the UI will move the deadline for example.

holri 7y ago

Yeah, but showing the user the GUI early is important because otherwise you are risking to build the wrong tool. End users usually only understand the GUI not a specification.

deaps 7y ago

>>The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated" A good example of this is: Reflection Workspace vs Putty I know which one i'd choose (between the two, assuming cygwin wasn't an option). There absolutely is such a thing as too much. Although with Putty, I'd never complain about its simplicity -- it has just enough. Just google the user docs for "Reflection Workspace" if you've never used it. Maybe there are more uses to it, but for the work place I mentioned above, it was 100% just a means of connecting with ssh.

ken 7y ago

> all those options in a configuration panel I think this is the classic example of "things programmers think users want but don't". There's a literal translation from if-statements -> command-line flags -> checkboxes/radiobuttons. It's easy to implement, and users don't want it, because users don't use applications by thinking about the if-statements used to implement them. Half of these items should simply be fixed or implemented, and don't correspond to "options" at all.

mmcgaha 7y ago

Create a separate "Power Users" configuration program. Everyone loves being a power user.

magduf 7y ago
They tried this with KDE. It didn't go over well. Everyone just complained about all the configuration options.
andrewflnr 7y ago
So that's how gnome-tweaks happened. I was always confused why there were a bunch of settings you had to install another package to change.

magduf 7y ago

>I know where this ends; been there done that. The programmer implements all those options in a configuration panel, the user looks at it saying "uh... too complicated" (0), shuts down and uninstall the software then chooses an easier one that forces mostly predefined options on a dumbed down panel, only to complain later that it can't do this and that therefore a more powerful one is needed. This is exactly correct, except maybe for the very last phrase (usually, I think users just put up with the dumbed-down software and just complain about how it doesn't do exactly what they want, and when someone suggests an alternative that has more configuration options, they reject it, saying that they don't want to deal with all those configuration options). We saw this on Linux desktops with the KDE-GNOME war, and this is with users who are generally considered to be more technically inclined than your average Windows user. Gnome users would complain about options and features being removed, KDE users would point out that KDE has all these features and lots of configurability, and complaining Gnome users would reject it saying it's too complicated and they don't want to deal with all those configuration options. Somehow, the idea of simply leaving the options at the defaults (except the one or two they wanted to change) was completely incomprehensible to them. Users don't really want freedom of choice. They want something that reads their mind.

doubleunplussed 7y ago
For me I don't like having to keep track of what's default and what's not. What if I change a default, things change unexpectedly somewhere as a result, and I'm not able to work out what change it was due to? Fewer options decreases the odds of this happening. Other good approaches are highlighting settings that are different from the default. Many UIs do this, but unfortunately it's hard to get a birds-eye-view. Now, config files! Thousands of options, quite happy to hack on that. You know why? Because I can diff against the default and get a birds-eye-view of what's different. I'm not sure if KDE's settings are all text files underneath, but that's the issue. If there were a settings dialog somewhere saying "here's what's different to the default, out of all the KDE settings", that would help a lot. Otherwise it's just too hard to keep track of. This would help on GNOME too, but in the absence of that, simply having fewer settings is a kind of reassurance that there aren't many you've changed and forgotten about. A separate point, but running default settings is also sticking to the "happy path". It's more well-tested, and I've learned I shouldn't change too many settings different from the defaults, even if they are officially supported, because things aren't as well tested - even if everything official works, third-party things tend to make assumptions that are violated.

bluGill 7y ago

As I recall - from the mid-90's so my memory is probably a bit wrong... IBM discovered that the level of details changes the type of information they got. A couple pieces of paper with hand drawn UI would get great comments on work flow. If you move to more and more realistic simulations of the real environment the comments focused more and more on trivial details and less on the big picture - if the UI looked like it was complete and ready to ship the comments would be about moving things a pixel (never to a different part of the screen even if the screen was designed to put things that belong together apart), or changing the shade of colors.

sli 7y ago
What you're describing is called bikeshedding. I'd bet people generally feel like it's easier to "contribute" to a drawing than to something that looks more concrete, like a demo or semi-functional mockup.
- bluGill 7y ago
  No, bike shedding is different. Bike shedding is a pointless contribution to something just to prove you thought about it. This is about a situation where you are being asked to contribute, but not giving the contribution wanted.
  - Rychard 7y ago
    This is incorrect. Bikeshedding[1] applies when people prefer to discuss less complicated issues rather than those of a higher priority (which are more complicated). It's not that discussions on such topics are pointless, but rather that they are of relatively minor importance in the grand scheme of things. [1] https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding
    - bluGill 7y ago
      Bike shedding is when you discussion irrelevant issues. If I ask you what do you think of about this shade of red for my bike shed your answer isn't bike shedding. If I ask you if I can build a bike shed and you tell me only if it is red that is bike shedding. When I ask someone for an opinion on my mock up and they give one it isn't bike shedding. That different mock ups will get a different response is interesting, but no response is bike shedding even if some responses are useless.

mixmastamyk 7y ago

There are ways of supporting extensive configuration without showing all options at once. Firefox config is one good example, vlc’s strategy is not my favorite but it works, “advanced…” buttons are another.

alexhutcheson 7y ago

In addition, every additional setting multiplies the number of states your application can be in, and the combinatorial explosion of states is mostly not well-tested. If you set even a handful settings to non-default values, it's likely that you are running the application in a totally unique configuration that's not used by any other developer or user. If you encounter bugs, you're liable to get the "Idk, it works on my machine" response. This blog post also covers other good reasons why user options are often not the right choice: https://garethrees.org/2013/06/13/options/ https://garethrees.org/2013/06/13/options/