Hacker News Reader

> 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.

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.

That's a fair point. My comment was imagining a project where the customer was the user/users.

I can't say I've ever seen one of those! (Except for B2C, but that's a different case)

"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.

Even if the customer is the user, these "move the button to the left by two pixels" type of requests are very common and really aren't important. I've seen users do this because it makes them feel like they have input and I've seen these types of requests turn into serious bikeshedding. They never actually make any difference to how they use the product, but these tasks end up taking a lot of time (that as GP said, the customer typically doesn't want to pay for because its a small change).

Actual workflow changes, where customers ask for UI changes that make some task easier or faster, are valuable and, at least in my experience, these are very different from the requests you get when a customer realises that UI changes are (by themselves) quick and easy. You can ask for ways that you can improve or speed up their work without them needing to know you can move a that label two pixels to the right in a matter of seconds (which in reality will take hours of back and forward as its never quite right).

> 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.

The types of UI changes GP talked about (moving a button a few pixels) is not the kind of thing that causes an end user task to be more or less frustrating.

> 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.

But talk to enough of them and you'll see that bikeshedding about pixel positioning is almost never something you want the customer to be doing.

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.

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.

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.

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

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.

"Bike shedding is a pointless contribution to something just to prove you thought about it."

Isn't that related to the famous "duck"? That is, something completely useless added to a project (like a UI widget that does not contribute to the functionality) still very noticeable so that it will act as a sacrifical goat, saving other stuff the developers don't want to be messed with by upper management bikeshedders.

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.

In interaction/UX design this is called progressive disclosure, and is explained on a strategic level here:

https://www.interaction-design.org/literature/topics/progres...

>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.

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.

You bring up a good point: it would be nice to be able to quickly see what options are different from defaults, whether in graphical or text form. I don't know of any UI (for a desktop environment) that does this, however, but I do like the idea. I do believe I have seen this kind of thing for more specialized products or programs. I will point out though that with Linux desktops, the defaults are different by distro, though still this shouldn't matter; it shouldn't be that hard to have a "master" config file and then be able to diff it, or have a UI panel that does this in a more user-friendly manner.

There's a medium to be reached. It's to give a clean starting point, and make options intuitive to discover and useful to implement. At the risk of drawing the ire of the anti crowd, Mac OS X does this marvelously well.

I'm very anti-Apple, but it's foolish to think that there isn't anything at all to be learned from how they do things. Same goes for Microsoft.

> 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.

> ...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.

> 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.

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.

For those who haven't seen it, I believe reacweb is referencing this [0].

[0]: https://www.folklore.org/StoryView.py?story=Calculator_Const...

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."

I might alter it slightly to say "If you work for someone that thinks they're Steve Jobs, let them do the designs".

Will definitely result in managerial approval of the design, but not necessarily a good design.

In all companies I’ve worked, managerial approval of a design (or feature) was far more important to obtain than a measurably good one. It’s called HIPPO: HIghest Paid Person’s Opinion.

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/

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

They tried this with KDE. It didn't go over well. Everyone just complained about all the configuration options.

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.

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?

>>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.

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.

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.