Software should convey a sense of calm | Hacker News Reader

Software should convey a sense of calm

patrickjuchli.com

236 pointspajuc87 comments

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 and/or reliable this mental model, the more anxiety is felt.

As programmers we're partly insulated from this effect. We may not know the exact inner-workings of a piece of software we didn't write, but we know some general things about software and the way it does and doesn't behave that soften the huge void of scary unknowns. This helps us form our mental model.

Physical metaphors of objects, continuity, permanence, locality, persistence, independence, are often used in GUIs for this reason. If I click a tab and then click back to the previous one, I expect to return to the same state I was in. If I change the text in one field, I expect that unrelated fields won't be impacted by that. Etc. This is a good starting point. Desktop platforms and then mobile platforms have built additional semi-consistent UX expectations on top of those largely physical intuitions. This helps too. But your application needs to go beyond that: it needs to present a simplified model of its internal state-machine to the user, and then it needs to hold to that. That mental model, once formed by the user, needs to have predictive power about the way the system behaves under different circumstances.

> If I click a tab and then click back to the previous one, I expect to return to the same state I was in. If I change the text in one field, I expect that unrelated fields won't be impacted by that. Etc. This is a good starting point.

This is such a huge fucking deal. I could not hope to overstate the importance of UI flow & proper state management.

It took us 7 years of mistakes & learning to figure out how to do this correctly. We had to learn to listen to the customer and not give in to our inner lazy developer.

We now have total confidence in our ability to back-navigate through complex workflows, or arbitrarily switch between instances of them. Without breaking things. It is so intuitive to our users to be able to think "oh wait no i need to go back and change XYZ" or "I need to put this on hold so I can help this customer real quick". In our target market, the work is very complex and error-prone, so you are usually editing your previous inputs and double checking the new output. Every screen in our application has a back button & next button in exactly the same spots on the screen. I watch some of our users go back by muscle memory 3-4 screens within a second or 2. Mapping the users' brains to your UI is crucial. Really helps if you don't play RNG with the coordinates.

It's really easy to paper over these things, especially if you are doubling down on a sub-par solution. Getting your users to want to use your app is really important in most situations. Even in a B2B setting, we hear our customers complain about bad UX in some of their other solutions and how this causes trouble for training & adoption. Even if you are getting paid for it, you still don't want to use trashy software. I have used software that you literally could not pay me to suffer with on a daily basis.

Well written and a nice way to conceptualise the problem and zoom out a bit.

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

> I want to find the same things in the same places

How else will designers justify their jobs?

I wonder if designer should be reworked to be a seasonal or consultancy job only, to only hire them when you're making a new product/big feature or there's a drastic need to change things but never otherwise. Having them as permanent staff leads to our present usability and accessability nightmare of everything constantly being redesigned and completely changed around for no good reason other than padding designers' resumes.

Design is misunderstood, often by designers, and it seems like you also may have some misunderstandings based on your assessments of what should designers do (vs what they do). Based on your comment it sounds like the designers you work with have an over-emphasis on visual UI design. I don't think you are to blame though - I have observed a consistent dumbing down of design discourse and practices among people that don't take the time to learn the depth of what is available. This includes most practicing designers. I have observed that designers are less interested in educating the world about their practices than perhaps they need to be in order to change this situation. Design in most cases is essentially a set of knowledge work processes, the best of which is built on solid research practices informed by psychology and cognitive science.

For anyone interested in up-leveling their own understanding of design I recommend the articles, videos, courses and other materials available from the Nielsen Norman Group https://www.nngroup.com/

This is such a great comment that adheres to exactly what my SO experiences. She is a UX designer, and she was the first one hired at her company. They had no idea what UX design is and all the processes, research, etc that takes place.

> I have observed that designers are less interested in educating the world about their practices than perhaps they need to be in order to change this situation.

She has found her job has become mostly informing and teaching others how to go about these practices, and if she has spare time does the work herself. But it was such an ordeal when they hired her because they didn't even know what she was supposed to do. She has acted very much like a consultant in this regard, but also does the work involved.

Visual UI "graphic" design, full of fleeting design trends and dark patterns, sure I agree, bundle them up and send them to the moon. UX =/ UI

Human-centered design professionals who went to school for/taught themselves from the field of Human Computer Interaction, which involves a multitude of qualitative and quantitative research methodologies for assessing usability and bringing the voice of the user early into the development lifecycle on the otherhand... now that is sorely lacking and is historically underinvested in. Their job makes your job as a developer easier, not having to redo work and waste time if they are plugged into your dev team and focusing on your users.

Ask yourself, as a developer, do you feel you have the specialist skillset and expertise to truly validate designs with real people (users)? Is this something you would want to do, if only those pesky UX "design" professionals didn't take them over to justify their jobs?

Let's put you in front of 10 different users of your product for an hour each, give you a facilitator guide, and have you guide them through a task-based usability review of your product. Make sure you aren't asking leading questions or biasing their responses, then synthesize the essence of all the interviews into insights to improve the product design. Finally create a read out report that you have to present to senior leadership for another hour on what you learned and how to improve the product design. Oh yeah, you now have 0 hours to code in your fulltime 9-5 job. Good luck!

Note: I acknowledge a UX researcher is a full-time specialist role, however any UX designer worth a damn should be T-shaped and able to use qualitative research methods to interview users and evaluate their designs.. otherwise they are a UI designer and guessing at best.

> from the field of Human Computer Interaction

This is how you get death by a thousand A/B tests a la Google, Facebook, and other ultimately user-hostile interfaces that optimize for ad engagement.

Give me a compassionate, thoughtful, designer who isn't an ass hole any day of the week.

A/B tests are more of a thing in the ecommerce and ad-tech space and only a small aspect of the UX research methodology landscape, see: https://www.nngroup.com/articles/which-ux-research-methods/

The field of HCI (and Human Factors before it) pioneered the application of qualitative research methods from adjacent fields e.g. anthropology, cognitive/social sciences, etc. towards computers and information technology. Optimizing for 'ad engagement' seems to be a recent phenomenon in the timeline of HCI and arguably is being written by the likes of Google, Facebook, Amazon, etc. and the people on their payroll who sold their soul to make this their life's work.

Is this issue here how they optimise their interfaces or what they optimise them for?

Obviously the latter is a major issue but additionally I think great detriments are coming from an obsession to quantify and reduce everything into arbitrary models. sizzle is talking more about qualitative than quantitative studies, though.

The issue is that metrics are always imperfect, and so optimising for a metric always ends up damaging the thing you actually wanted to improve.

Assuming for the sake of argument that this is at all true, is the problem that designers are out to justify their jobs, and making changes as a consequence, or that designers are being put in a position where they have to justify their jobs, and are making changes to satisfy their managers?

If anything, the problem in this scenario is that culturally we need everyone to be contributing all of the time, even for positions that may experience occasional downtime. Let's not assign blame to a particular group when they're simply responding to the pressures put on them.

If this is the best argument one can come up with for not being critical here, for me it absolutely proves we need to be more critical here. Of course, I don't wish to see anyone suffer, but I'm seeing something like:

"Hey, we're paying a guy to dig holes and fill them back up with no value whatsoever, why are we doing that?"

"Hey, man, stop attacking hole-diggers, they're just trying to make a living."

Can you go into more detail of why you think we need to be critical of designers? The GP makes no effort to justify their criticism of designers, perhaps you can provide some reasons for it, and thereby allow people to respond to actual arguments.

A good example that was discussed recently: https://news.ycombinator.com/item?id=28504573

The justification isn't "It helps users" or anything like that. It's "This is not a new idea either — pretty much everyone else is doing it, e.g. macOS, Windows, iOS, Android, elementary OS, KDE.". Reducing usability and breaking habits to follow trends is a bad thing.

This is a purely aesthetic change, it doesn't break any habits. In this case, it probably also improves usability, because there's less visual noise connected to those buttons, which lets you draw attention to buttons the user might not already know about using the same technique while staying within a certain 'visual noise budget'. Users expect that icons on the header bar are buttons (what else would they be?), so there's no need to call attention to that fact with an extra visual indicator.

"Following trends" is a good thing because users appreciate when a piece of software looks like software they're already familiar with. It is maybe slightly annoying to people who already are used to the software, but every new user benefits from it.

> In this case, it probably also improves usability, because there's less visual noise connected to those buttons

Yes, because there are no buttons anymore, just icons. Icons are not button. Icons are icons, buttons are buttons

> which lets you draw attention to buttons the user might not already know about using the same technique while staying within a certain 'visual noise budget'.

That "visual noice" is the zone where you can click on a button. I also don't believe that "visual noise budget" thing at all. Maybe it helps a bit first time users, but most software shouldn't optimize for first time users. I'll add that not everyone has a perfect eyesight or perfect mouse control. That new style is bound to be frustrating for a few people.

> Users expect that icons on the header bar are buttons (what else would they be?), so there's no need to call attention to that fact with an extra visual indicator.

Actually, having fallbacks and multiple ways to signal something is a great thing. For example, if you only use color to indicate something, colorblind users may have a hard time using it. Icons and tooltips when you hover over it is also a good way to achieve that.

> "Following trends" is a good thing because users appreciate when a piece of software looks like software they're already familiar with. It is maybe slightly annoying to people who already are used to the software, but every new user benefits from it.

So they're focusing on new users instead of people that actually use their software. I don't see how that is a good thing. If this was just one change, I may agree with you, but this is a sign of a larger trend of constantly changing interfaces for absolutely no benefit to the user.

"This is a purely aesthetic change, it doesn't break any habits."

This sort of wrong (or more precisely easily falsifiable) statement perfectly exemplifies why I have so little respect for "design" as it currently exists.

You shouldn't just be able to say things like this that are nearly provably wrong on their face (e.g. I certain I can find 5, or 20, or more people who will definitely get slowed down by this)

Add on top of this the sheer stupidity of not being able to keep the old way if you like, an increasingly common thing.

Try to find these people then! I seriously doubt you will for a change like this. The UI changes are good for the reason GP states.

Not necessarily of "designers," but perhaps of "design."

In my opinion, "design" does two things at the same time that are presently fundamentally incompatible without being honest about it -- namely "usability" and "fashion."

It's absolutely possible to do both, but you can't pretend you're doing one when you're doing the other. Architecture comes to mind. They do this right, most often by putting usability "first." You can make your design as pretty as you want, but if the damn wheelchair ramp doesn't work as intended, the whole design is broken and if that means your pretty thing must die because of it, then kill it and start over.

I think, then, that software devs need to be more critical of themselves, too. I see people in the comments often bemoan that we are too reluctant to call projects "feature complete" when adding new features stops adding value. Instead, we get new versions and features for no reason other than to justify the continued existence of a full-time development team.

Are you suggesting that designers keep getting paid for work they've already done?

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

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.

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.

Royalties, man, yeah.

Royalties don't really apply when you're being paid a wage for the work in the first place. The cognitive dissonance in both railing against spec work then demanding a piece of profit in perpetuity is, well... impressive.

I'm sure there are designers making parallel arguments about developers :)

Indeed, this is how game developers work: hired in legion strength to push a game to release, then laid off once it's released.

I've heard that DLC has made this less of a problem in recent years. Since there's a stable, predictable revenue stream and delivery channel for new content, iit's much easier to justify keeping devs, designers and artists on full time. Presumably this varies by studio / publisher / genre, but my impression is it's much better than it was.

Yeah, there is certainly a parallel argument to be made about constantly introducing new tech even if the currently used tech is GoodEnough.

You are essentially right. That's why I switched my focus from UX only to UI and front-end implementation.

Fighting for 20 years to educate programmers and investors on the importance of Human Centered Design and Function over Form approach, is hard. And I and everybody in the Design Industry have failed miserably.

Now when every startup has a boilerplate, templates and libraries in hand and "that's enough".

Designers (or I may say - Decorators) are "thousands a dime", they are racing themselves to the bottom of the pit. But I am cool with it. After all SaaS design software is here to collect and label enough data for big Neural Model to emerge and remove design from the picture. So your dream will come true, and you will be next in line of removal from production pipeline.

Having programmers as permanent staff when you need the same CRUD paradigm is unnecessary, and you can hire as a consultants when you're making a new product/feature but never otherwise.

Designers often have a much more intimate view of the application as an abstraction.

I don't think you want to be benching that knowledge very often.

Having extended research phases or personal development would be great to cycle in between major releases.

In the interim they might develop better tooling or A/B a subset of features, or strategize with the analytics dept.

We really all should have a designer mindset, but truly professional designers are product gurus.

Pointlessly reworking software is the hallmark of a poor (or green) contributor. Designers can redesign features that work fine, engineers can refactor code that doesn't need optimization, PMs can come up with features that nobody needs. Designers might do this more often since there is a somewhat lower barrier to entry than the other two disciplines, but that doesn't mean the whole profession should be ditched. A good designer knows when to pull out the big design guns and when to leave em holstered.

Sounds like fairly bog-standard Usability. Folks like Jakob Nielsen have been calling this kind of thing out for decades. They have not always been popular.

I think a lot of this depends on the target audience. If it is a wide-distribution consumer application, then I like the "swimming duck" analogy, where it looks smooth and calm, above water, but is paddling like hell, underneath. That's what I strive for, myself, in my standard consumer-level apps. Many of my apps look quite "boring," but actually have a lot of moving parts, invisible to the user. Selecting a screen may result in multiple server transactions, and the user only sees a throbber for a half second. No progress report.

The other side, is that, if you are marketing to engineers, or specific types of professionals (not all "pros," though. That's a wide net), you may want to present a very complex and "raw" UI. I have done this for admin dashboards.

Adjusting information density to the desired audience is a very real thing. I've also had a lot of success (and fun!) with internal tools that display a lot of stuff but would be terrible for consumer software

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 were pretty much the save (Ctrl-S, saved the document, etc).

OLE provided a uniform way to embed documents into other applications. Cut and paste worked consistently.

There were also a limited amount of frameworks (bare Win32, MFC, OWL, Visual Basic, and Delphi probably covered 95%+ of apps).

It seemed that most user interfaces at the time were actually made by programmers and not graphic designers. In addition, for the most part there was a lot of continuity from version to version in how a program looked.

Now it seems that every web app wants to look different for the sake of looking different. People want to change how an app looks on a regular basis, often for no other reason than that it needs to look "fresh.". There are a myriad of every changing front-end JS frameworks.

It seems that UI is driven by graphic designers looking to make something unique and standout and not programmers that just want to make a standard, low friction way the user can access the functionality and be done with it.

Also, all you data is siloed a lot more because it is stored in the "cloud". Whereas before you could easily have access to the raw output from all your programs (and if they supported OLE embed documents from one program in a completely different one), now it is somewhat of a pain if you want to get raw access to your data.

Web based apps do have a lot of advantages, but I feel we have given up a lot when we went from native desktops apps to web based.

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 everything difficult while programmers would have just made everything better albeit not as pretty looking is really not a fair assessment. I mean, preference and general nostalgia, I get it, but it's a bit much.

Getting raw access to your data also wasn't a breeze in the past with program often having their own binary formats and not exposing any programmatic interface at all to get data in or out. Not sure how this relates to the cloud.

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

I remember decades ago building a menu system for a homebrew media center to launch game emulators and so on. I wanted it to have a loud arcade style feel. All menu text was rendered in 3d and would bounce and vibrate. Lots of flashing lights, noise, music and high energy. Functionally, it was just a simplified file explorer. It was very fun to use.

I agree with most of the opinions in this article, but I don't like the idea that all software should convey calm, or the conflation between a simplified intuitive interface and calm. Video games are a great example of simplified, intuitive interfaces which are often the polar opposite of calm.

Elements like calm and intuitive are also extremely subjective. I find emacs calm, intuitive and extremely accessible. People with different context will have a comically different response. Humans need interfaces that cater to their different experiences.

> Video games are a great example of simplified, intuitive interfaces which are often the polar opposite of calm.

Video games are interesting in terms of usability. I thought a lot about this the past couple years after a UX course. A lot of UX principles are about making things easier, like large clickable areas, not moving clickable areas, contrasting colors, proving plenty of time to react or undo, and making things obvious and as easy as possible. But in a game, many of those principles are flipped. In a shooter, the enemies are smaller and move. They may be difficult to see. Solutions are not always obvious, especially if they are extras or hidden power ups.

But at the same time, a lot of the UX principles are very important. An enemy about to attack should telegraph that attack so you have time to react. Menus should be very clear and obvious. Inventory management should not be a chore, the map and HUD should be easy to use.

Valve (in particular) even pioneered UX in level design—if it doesn't improve gameplay, why let the player wander around trying to find the way they're supposed to go (a situation common even in relatively on-rails shooters of the past)? And just putting in HUD arrows sucks, and those can be misleading. Instead, they use lighting, color choices, and level layout to direct the player's attention and direction of movement, while maintaining the illusion that the levels are part of a larger space.

I've heard that Ghost of Tsushima does this well with the direction of the wind. But I don't have a PS4/5 to play.

I've also heard about of platformers giving a couple pixels after walking off a platform to jump, like Celeste. It is very small thing to give better feel to the controls and make up lack of precise timing.

There's also the idea of the tutorial level masquerading as a regular level, so it doesn't feel like a tutorial. Earliest example I know of is Super Mario Brothers 1:1, but it may not be the first. It's distinct from simply ramping up difficulty, because it involves things like deliberately presenting challenges & opportunities in a certain order, and, at first, in isolation.

[EDIT] incidentally, here (many) games have an advantage over other software, because they play linearly rather than presenting a large space of possible actions all at once. Games that are more similar to productivity software (city builders, say, or grand strategy games) have trouble doing this without it being obvious that you're in a tutorial.

Portal was designed so that nearly the entire game was "the tutorial level". The gradual introduction of novel elements such as beams, turrets, and more advanced movement challenges kept up the interest, but it also had the hidden agenda of preparing the user for the climactic finale which brought all of those elements together.

> Video games are interesting in terms of usability. I thought a lot about this the past couple years after a UX course. A lot of UX principles are about making things easier, like large clickable areas, not moving clickable areas, contrasting colors, proving plenty of time to react or undo, and making things obvious and as easy as possible. But in a game, many of those principles are flipped. In a shooter, the enemies are smaller and move. They may be difficult to see. Solutions are not always obvious, especially if they are extras or hidden power ups.

The goal of usability is to be able to accomplish your goal. In a lot of games, the feeling of getting better or overcoming an obstacle is part of the goal. So the UX is not surprising, it's following the goal of the product.

I think "calm" might refer to the user in that context, as the opposite of "frustrated to the brink of violence".

A game UI might be wacky and as twitchy as a rodent dosed with recreational stimulants, but the user feels calm, capable of navigating through it and never doubting they can accomplish what they set out to do.

Going back a bit further, Mark Weiser came up some principals around 'calm computing' [0]. As we transitioned into the ubiquitous computing age, computers were supposed to disappear. I wish that were the case but we seemed to have designed them to need more attention than ever.

0: http://quicksilver.be.washington.edu/courses/arch498cre/2.Re...

"The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it."

Calm Technology is "that which informs but doesn't demand our focus or attention."

for those unfamiliar with Weiser/"Calm Technology":

https://en.wikipedia.org/wiki/Calm_technology

http://web.archive.org/web/20180604010109/http://www.ubiq.co...

https://people.csail.mit.edu/rudolph/Teaching/weiser.pdf

https://web.archive.org/web/20141022035044/http://www.ubiq.c...

https://en.wikipedia.org/wiki/Mark_Weiser

https://www.youtube.com/watch?v=7jwLWosmmjE

https://web.archive.org/web/20080905233018/http://www-sul.st...

https://www.microsoft.com/buxtoncollection/detail.aspx?id=51

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

Identifying intuitiveness as something you can optimize for or not is not pointless. I'd also argue that intuitiveness can be measured and strategies for more intuitive designs/patterns can be formed.

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

I'm not sure “software” is useful as a category in this context.

If you're trying to make a useful tool these principles apply, but if you're trying to farm users for ad money they don't.

People will say they want the former, but in practice they often choose the latter (and then grumble about it not being more like the former).

I think it's less users choosing it, but market forces pressuring most tools to turn into ad-ridden nightmares.

There are secondary effects like the ad-ridden product may have more money for development and deliver better features. But at this point we're all wondering if there isn't a better funding model that can deliver both good experience and sufficient development funds.

He's basically writing about discoverability in UI/UX.

https://duckduckgo.com/?q=UI%2FUX+discoverability

There's also the Calmtech movement, somewhat related to the post: https://calmtech.com/

I absolutely believe the importance of this specifically because the desktop is failing at that in todays standard. In other words, maybe there is an apple or microsoft to be created around turning android or ios devices into work stations. I think that would require a new vm, i dont think you can code html 5 app on such a device for example.

The thing is, most software starts simple and easy to use. It's the introduction of new features and edge cases which slowly kills usability over time.

And this applies to desktop, web, mobile and commandline applications as well.

A tool needs a strong focus of it's maintainers and the courage to say 'No!' to things which are out of scope or not user friendly. This seems to be quite rare.

- https://en.wikipedia.org/wiki/Calm_technology

- https://calmtech.com/book.html

Does the "calm tech" movement have much to say? I feel like a theory of learning for software is more important. Of course it should be done in a pleasant way but I wasn't able to get much actionable insight out of calm tech writings.

First, there are parallels to some Software Design heuristics. The focus on simplicity, complexity hiding, graceful error handling, generalizing and reducing the surface of interfaces etc. come to mind.

So the way you structure and write your code has very much to do with wanting to reduce the mental taxation of the reader (you included).

In the UI, UX and HCI world the concept has obviously a lot to say as well.

A lot of modern software makes me feel stressed, confused and aggravated. When I open Youtube Music I never know what I'm going to get - sometimes Your Favourites is at the top, sometimes Mixed for You, sometimes something else. When I open Netflix it's almost always the case that I want to continue watching something, but will I find that in row 1 or row 4? How long will I need to scroll to find it?

This just reminds me of the composer Soyo Oka, who did the music for some great games, like SimCity (SNES), SimCity (NES, unreleased), Super Mario Kart (SNES), Pilotwings (SNES), etc. She said that in making the SimCity music she wanted it to feel comfy while building the city, not hectic or frustrating. And god, what a masterpiece of a game and music. I still play it 30 years later.

I'd prefer a sense of trustworthiness.

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.

Ideally, software should help you to enter and maintain an activity flow state.

I don't know if I'm old and bitter, or that software becomes harder to use, but so many software seems to degrade in user experience.

HTTP is a relatively easy thing, let's replace it by an overengineered clusterfuck called HTTPS. Good luck implementing THAT on your homebrew OS. (don't get me wrong, it's good thing that it exists, I just don't see why all the sites have to use it)

Well, git+github seems to work nicely, lets disable logins using your password! Took me about an hour to take care of this (there is a nice guide for it, but that doesn't mention what your 'github email' is -- there is no such thing, and it doesn't mention that you have to change your remote to an ssh connection, and it also teaches you to copy-paste commands from the browser to your terminal).

> I just don't see why all the sites have to use it

https://www.techdirt.com/articles/20140908/07191228453/comca...

> (don't get me wrong, it's good thing that it exists, I just don't see why all the sites have to use it)

Because regular users don't know how to distinguish between the level of trust they need for visiting "Justin's travel blog" vs. their online banking website. If we don't display red error messages if a site they visit has an invalid certificate, they don't know how to tell it's not safe to enter their credentials there.

The web was once mainly used by academics, programmers and other geeks, now it's used by marketers, scammers, hackers, and a bunch of other malicious actors. I wish we could go back but that ship has sailed.

Even Headspace has gotten this 100% wrong. It's so sad.

I'd be glad to check out any examples of software that come close to this ideal.

The Windows 2000 user interface. Uniform look and behavior, very discoverable, clearly identifyable controls, “boring” gray.

Contrast with Windows 11 - inconsistent UI, and adverts and notifications/nags blasting at you from every place they could fit one in. The exact opposite of calm.

Maybe Tempo comes to mind? a Minimal and calm email app for Mac OS https://www.yourtempo.co/

Looks good, thanks.

iOS multi-tasking by dragging the “home-bottom-bar” is great. Manipulating “cards” of apps with ease and discarding them by swiping them up. It’s very nice, but could be better.

Unless it's DOOM, in which case if the user is calm, you've failed. :)

That's probably why we get a blue screen, as opposed to a red screen.

Calm Oriented Development, why not

In festina lente

I find reading this in a web browser to be ironic. But then I immediately shared it with people via Slack, too, so...

Absolutely agree. We probably spend more time looking at and interacting with software than the real world! Love apps like Superhuman which prioritize calmness and serenity in the user's experience

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, are you sitting down?
    Y/n> Y
    Okay, I have some bad news about line 27, but I don’t want you to panic

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

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?

Reply on news.ycombinator.com