Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software should convey a sense of calm

patrickjuchli.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Software should convey a sense of calm

#81

Post by lmm »

pc86 wrote: post #69
ysavir wrote: post #45

Earlier quoted context omitted.

I'm suggesting that if a company has designers that know their product, branding, team members, philosophies, values, and that have proven quality of work and ability to get along with the team, that they not eliminate their position because there isn't any design work needed _right now_. When you do need design work, you don't want to have to go through the trouble of hiring, on boarding, etc. The same applies for s…

Software requires maintenance and can benefit from refactoring. What's the equivalent for design?

Developers can certainly be guilty of doing refactoring that's just churn when the current code is actually fine, and that may partly be because they too have to justify their existence. The difference is that code churn and framework churn are less directly harmful to end users than design churn (because they don't mess with the end user's workflow so much).

Re: Software should convey a sense of calm

#82

Post by euroderf »

brundolf wrote: post #57

I agree with the goal, I have mixed feelings about the listed solutions I'd like to add one: using consistent metaphors. A user of software is constantly trying to form a mental model of how this ethereal, formless thing behaves. A state machine. What can and cannot happen, what will and will not happen after a given action, what can and cannot happen once we're in a different state. The shakier and less scrutable an…

Metaphor consistency (or lack thereof) is where a tech writer has to provide feedback / advice to UX people. Verbalize the metaphor and debug it.

Re: Software should convey a sense of calm

#83

Post by LukeShu »

jameshart wrote: post #77

Nonsense. Software should meet its design goals . A ground proximity warning software system should absolutely not “convey a sense of calm”. An online PvP battle arena game should not convey “a sense of calm”. I’m not sure a sense of calm is necessarily appropriate for a chat app, an ad blocker, or a to do list. Do you even want a sense of calm from your compiler? > calmc main.calm Compiling… please relax… Okay, now,…

> Software should meet its design goals.

OK, so interpret the title as "the design goals should include conveying a sense of calm".

> A ground proximity warning software system should absolutely not “convey a sense of calm”.

In the sense of "convey a sense of calm" described in the article, it absolutely should. The user shouldn't be freaking out because of the software, thinking "oh shit did I click the right thing?" or being confused about what is being indicated. If they're going to freak out, it should be because of the aircraft's situation, not because of the software. Moreover, in an emergency situation it is important to stay calm; the software should not make that harder to do; it should convey urgency, but not a sense of panic.

> I’m not sure a sense of calm is necessarily appropriate for a chat app, an ad blocker, or a to do list.

Again, you seem to be ascribing a different meaning to what the author describes. In the first paragraph, they describe calm as "I, as a user, should know what I can do with it and what I can’t do. I always know what’s happening, where I am and what is next. Everything comes easily to me. I don’t get stuck, never feel lost or stressed out." Regardless of what's said in the chat app, the app itself shouldn't convey non-calm; you wouldn't say that the user should be confused about what the app is doing, or that the chat app should be hard to use, or that they should feel lost navigating the app. Conveying a sense of calm absolutely is appropriate for each of those apps.

Re: Software should convey a sense of calm

#84

Post by selfhoster11 »

quelltext wrote: post #46
RcouF1uZ4gsC wrote: post #15

I actually think the mid 1990's Mac and Windows GUI programs were much better at fulfilling this ideal. We have regressed from there. I am most familiar with Windows, so I will speak from that perspective. Because software was an application, and the path of least resistance was to use the OS provided controls and menus, there was a sense of uniformity in how you accessed features. Keyboard shortcuts just worked and…

A lot of the user interfaces we use today are "better" than what we had in the old days. The old generic windows and buttons and whatnot don't work on a finger touch input. Switching apps via gestures, visual cues by animation, use of space, effects to bring things in and out of focus, a lot of things have been refined and evolved over the years. Yes, things are not perfect but claiming that designers are making ever…

I will not contest that a lot of new UI things have been figured out, but making desktop interfaces touch-friendly was a mistake.

Re: Software should convey a sense of calm

#86

Post by akacia »

It’s all about making money. Almost nobody in business department cares about the quality of software and its actual usefulness as long as its selling. It’s possible to sell shitty software and get high returns through manipulation and marketing.

Re: Software should convey a sense of calm

#87

Post by jameshart »

LukeShu wrote: post #83
jameshart wrote: post #77

Nonsense. Software should meet its design goals . A ground proximity warning software system should absolutely not “convey a sense of calm”. An online PvP battle arena game should not convey “a sense of calm”. I’m not sure a sense of calm is necessarily appropriate for a chat app, an ad blocker, or a to do list. Do you even want a sense of calm from your compiler? > calmc main.calm Compiling… please relax… Okay, now,…

> Software should meet its design goals. OK, so interpret the title as "the design goals should include conveying a sense of calm". > A ground proximity warning software system should absolutely not “convey a sense of calm”. In the sense of "convey a sense of calm" described in the article, it absolutely should. The user shouldn't be freaking out because of the software, thinking "oh shit did I click the right thing?…

I just find the entire post reductive and limiting in terms of its view of what software is or should be capable of. It is describing a philosophy applicable for software that has a particular purpose - mostly productivity desktop applications, it seems - which is just a very long way from all software.

"I, as a user, should know what I can do with it and what I can’t do. I always know what’s happening, where I am and what is next. Everything comes easily to me. I don’t get stuck, never feel lost or stressed out."

This is clearly not a reasonable design goal for a puzzle game. It’s not a good goal for a call center queue management system. It’s not even a reasonable design goal for a search engine!

Oh, but you’ll say the author only means within the bounds of the tool’s interface the user should understand what options they have, not be burdened with additional stress of trying to figure out how to interact with it, etc.

Which is just.. yes, obviously, you shouldn’t build software to just screw with people (oh, but… puzzle game?). But overall, taking responsibility for a user’s stress/calm and placing the burden on all software to try to “exude calm” into any situation is… it’s an opinion, but it’s not a particularly interesting one?

Re: Software should convey a sense of calm

#88

Post by pc86 »

lmm wrote: post #81
pc86 wrote: post #69

Earlier quoted context omitted.

Software requires maintenance and can benefit from refactoring. What's the equivalent for design?

Developers can certainly be guilty of doing refactoring that's just churn when the current code is actually fine, and that may partly be because they too have to justify their existence. The difference is that code churn and framework churn are less directly harmful to end users than design churn (because they don't mess with the end user's workflow so much).

My point was you can do a lot of technical work that is 100% invisible to end users (except maybe performance gains) but results in a better or more stable product. So things that may not provide direct business value but provide it tangentially through more maintainable software, fewer and/or shorter maintenance windows, less unexpected downtime, etc. There is no corollary on the design side. Once the design is done, there's little reason for the designers to hang around.

Re: Software should convey a sense of calm

#89

Post by phailhaus »

quelltext wrote: post #44
phailhaus wrote: post #10

> Words like simple or intuitive are misleading here. They can be attributed to a solution in retrospect, but they don’t form a principle from which clear recommendations for action can be derived. Fantastic nugget of wisdom here. Saying that you want a product to be "intuitive" or "simple" is as useful as saying that you want it to be "good, not bad."

I disagree. A product might be visually appealing, serve hundreds of functions, be inexpensive, be sturdy, etc. These are all things that affect whether a product could be perceived as good vs. bad. Importantly, intuitiveness is not relevant for some products, or not what makes it good or bad. The tradeoffs between other aspects of your product could be such that trying to achieve intuitiveness would actively reduce…

> These are all things that affect whether a product could be perceived as good vs. bad.

Yes, and it is actually useful to say "I need this product to be inexpensive", rather than "I want this product to be good."

That's what the author is getting at. Just saying "I want the product to be intuitive and simple" is worthless. You have to actually define what that means and what properties the product has to be considered "intuitive". But too often, "I want it to be intuitive" is about as far as they get.

Re: Software should convey a sense of calm

#90

Post by jimmyspice »

pc86 wrote: post #88
lmm wrote: post #81

Earlier quoted context omitted.

Developers can certainly be guilty of doing refactoring that's just churn when the current code is actually fine, and that may partly be because they too have to justify their existence. The difference is that code churn and framework churn are less directly harmful to end users than design churn (because they don't mess with the end user's workflow so much).

My point was you can do a lot of technical work that is 100% invisible to end users (except maybe performance gains) but results in a better or more stable product. So things that may not provide direct business value but provide it tangentially through more maintainable software, fewer and/or shorter maintenance windows, less unexpected downtime, etc. There is no corollary on the design side. Once the design is done…

This assumes that once the design is done it should not, or does not have to change. Like anyone, designers can be wrong, customers can end up using certain features in ways not intended, and using software in ways that are not ergonomic.

So in that sense, design can and should be fluid. Where I work, designers often meet with customers (some external, some not) and continually get feedback, which the developers act on. IMO stopping design as soon as development starts increases the chance of having a poor design, forever.

Sometimes it's not known that a design has flaws until things start coming together during a project and some workflows become more prominent (and painful) than others.

Post reply on HN