I agree with the goal, I have mixed feelings about the listed solutions<p>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.<p>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.<p>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 <i>hold to that</i>. That mental model, once formed by the user, needs to have predictive power about the way the system behaves under different circumstances.
> I want to find the same things in the same places<p>How else will designers justify their jobs?<p>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.
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.<p>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 <i>a lot</i> 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.<p>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.
I actually think the mid 1990's Mac and Windows GUI programs were much better at fulfilling this ideal. We have regressed from there.<p>I am most familiar with Windows, so I will speak from that perspective.<p>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).<p>OLE provided a uniform way to embed documents into other applications. Cut and paste worked consistently.<p>There were also a limited amount of frameworks (bare Win32, MFC, OWL, Visual Basic, and Delphi probably covered 95%+ of apps).<p>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.<p>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.<p>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.<p>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.<p>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.
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.<p>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.<p>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.
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.<p>0: <a href="http://quicksilver.be.washington.edu/courses/arch498cre/2.Readings/2.Theory/CalmTech(Weiser%20&%20Brown,%201996).pdf" rel="nofollow">http://quicksilver.be.washington.edu/courses/arch498cre/2.Re...</a>
> 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.<p>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'm not sure “software” is useful as a category in this context.<p>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.<p>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).
He's basically writing about discoverability in UI/UX.<p><a href="https://duckduckgo.com/?q=UI%2FUX+discoverability" rel="nofollow">https://duckduckgo.com/?q=UI%2FUX+discoverability</a><p>There's also the Calmtech movement, somewhat related to the post: <a href="https://calmtech.com/" rel="nofollow">https://calmtech.com/</a>
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.
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.
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.
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.<p>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)<p>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).
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.<p>Software should <i>meet its design goals</i>.<p>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.<p>Do you even want a sense of calm from your compiler?<p><pre><code> > 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</code></pre>