Redmonk:

Most toolchains, from where the first lines of code are written through test, build, integration and deployment all the way out to production, are made up of a patchwork quilt of products and services from different suppliers. […] In order to make the life of a developer easier, rather than harder, a quality developer experience is focused on allowing developers to use the tools they’re familiar with, or at least closely mimicking them. Whether that’s the out of the box support for VS Code that is a common feature of today’s platforms or the Git-like syntax Heroku pioneered in its CLI, the less that developers have to context switch between tools and steps the less friction there is in usage.

A reminder that the best emails are plain text and nothing else. Not only they read well on any screen (even on a watch), they actually perform better:

The plain email—which took no time to design or code—was opened by more recipients and had 3.3x more clicks than the designed email. The plain, unstyled emails resulted in more opens, clicks, replies, and conversions, every time. […] Replies to welcome emails were tripled. Cold emails were getting 30-35% open rates and 3% conversion rates, which is incredible.

Besides, every HTML email looks like an ad.

I am pleased to find out I am not the only one frustrated by the behaviour of the back button in Photos or bewildered by where it will take me in Music. There’s a growing list of apps, developed directly by Apple, that would benefit from having proper navigation but have opted for an erratic and lazy back button:

The more common apps that have long featured back and forward buttons do not function in these peculiar ways. Web browsers do not; Finder doesn’t; neither does System Preferences. And, as I was writing this article, I was worried that it would be made obsolete by the forthcoming release of MacOS Big Sur, but everything is pretty much identical as of the latest beta. If the back buttons in the apps listed at the top of this post do not conform to the system standard in any way, the obvious question is something like: “why do these apps have a back button at all?”

In every instance, it seems to be a catch-all attempt to solve complex UI design problems. In Catalyst apps, it kind of works like the iOS system back button. In the App Store and in Music, it is a way to display web-based pages without having to implement a hierarchical navigation structure. In Photos, I suppose it is a way to reduce the amount of toolbars and buttons onscreen compared to iPhoto, and to make it conform closer to its iOS counterpart.

And they were very meticulous about it (via Benjan Mayo)

I kind of hate messaging these days.

Over the years different software have imposed on their users FOMO inducing features that lead us to this ridiculous reality in which we all collectively agreed that a response to a text needs to be returned within minutes, no matter the content nor the urgency.

I sometimes choose emails over texts for this reason. I know — I am weird. BUT! Expectations are different with emails. We read less into it if someone takes a day or longer to get back to us (even though some people are trying to make emails obnoxious too).

The online status (last seen at), the typing indicator (is typing), and — worst of all — read receipts somehow ended up being our default, with all which that entails (mostly anxiety). It’s all working exactly as we designed it, as in: it’s all quite shitty:

Privacy remains one of the big and unresolved issues in our industry and while we often worry about data leaks and agonize over how much companies know about us, we often forget that it’s the small and barely noticeable losses of end-to-end user privacy that affect us socially the most. And while turning every privacy related decision into a setting might be enticing, it’s ultimately shortsighted. Designers are well aware that most users won’t bother changing a default. And the act of changing a default ironically always inadvertently reveals something about users, whether they want or not.

So what does a future that respects people’s micro-privacy feel like?

It’s knowing you can go online without having to fear what our online status may reveal about you. It’s about liking someone’s photo without the anxiety of being called out for it. And above anything, it’s about reading a message, without feeling guilty of not sending an immediate response.

Max Rudberg propone diversi accorgimenti per gestirlo al meglio, e farsene una ragione. Perché, del resto, Apple non vuole che lo si nasconda:

Apple writes in the HIG: “Don’t attempt to hide the device’s rounded corners, sensor housing, or indicator for accessing the Home screen by placing black bars at the top and bottom of the screen.

In the Designing for iPhone X video, posted by Apple after the X’s announcement, Mike Stern says: “Your app or game should always fill the display that it runs on. Placing black bars at the top or bottom of the screen makes your app feel small, cramped, and inconsistent with other apps on iPhone X”.

Roman Cheplyaka le elenca in un articolo — dal ‘qualcuno ha appena prenotato questa stanza’ alla super offerta, Booking manipola i visitatori generando un senso d’urgenza che spesso non esiste.

Interessante come esempio e lunga lista di cose da non fare se volete essere rispettati dai vostri utenti.

Chris Coyer ha raccolto alcune opinioni sulla direzione che sta prendendo il web, per chi il web lo fa. Ideare, strutturare e sviluppare un sito web per ‘pagine’ è per esempio un modus operandi che abbiamo ereditato dal lavorare su carta — riviste, giornali, etc.

La fluidità del web, la necessità di funzionare su device e schermi completamente diversi, ci sta obbligando a lavorare con pattern. Il layout finale di una pagina web serve a farsi un’idea e a mostrare al cliente come verrà il sito, ma non dovrebbe essere il prodotto finale del lavoro:

Style guides. Design systems. Pattern libraries. These things are becoming a standard part of the process for web projects. They will probably become the main deliverable. A system can build whatever is needed. The concept of “pages” is going away. Components are pieced together to build what users see. That piecing together can be done by UX folks, interaction designers, even marketing.

Rands in Repose:

In the history of keyboards, I have never been as inept as I’ve been with the Touch Bar keyboard. I’ve been finishing this piece for the last hour and I’ve been keeping track of the number of times I’ve accidentally hit a Touch Bar button, and that number is nine. The total number for this article is likely 5x the number.

Stoo Sepp:

From a cognitive perspective, the Touch Bar by its very design adds a cognitive burden on the user. Regardless of how ‘delighted’ users might be, or how it may speed up workflows, when it comes to our brain, looking away from what we’re focusing on even if it’s to something related, leads to a loss of information, making it harder to integrate and process that information.

A circa quattro mesi dall’acquisto del nuovo MacBook Pro con Touch Bar, il mio uso di quest’ultima — sia in termini di quantità che di tipologia d’uso — si è ridotto al punto da non giustificarne l’esistenza. Utilizzo sempre i soliti tasti (volume, luminosità dello schermo, blocco del computer e tasto per mostrare la scrivania), con poche eccezioni (con Sketch a volte, raramente, torna utile).

Essendo dinamica e fornendo zero feedback al tocco, è semplicemente impossibile memorizzare la posizione dei tasti — e rendersi conto di quando per errore se ne è premuto uno (haptic feedback potrebbe, in parte, migliorare la situazione). In altre parole, per usarla bisogna guardarla, ovvero togliere gli occhi dallo schermo e quello che si sta facendo e focalizzarsi sulla tastiera.

Provate a visitare il sito di Ryanair con javascript disabilitato e, sorpresa — non solo non funzionerà nulla, ma nemmeno apparirà nulla. La ragione è che il sito di Ryanair è stato rifatto, due anni fa circa, completamente in Angular ignorando buone pratiche come il progressive enhancement: javascript, invece di migliorare le funzionalità del sito, è essenziale affinché funzioni. La stessa cosa succede a molte web app, e per certe né è facilmente evitabile e nemmeno è un problema — il discorso è a mio parere diverso per dei siti web come quello i Ryanair che probabilmente, facilmente, vengono utilizzati in viaggio, con connessioni limitate e poco affidabili, di fretta, e che contengono informazioni alle quali l’utente deve accedere.

Nell’ambiente in cui lavoro, sembra quasi che di recente la convenienza, rapidità e facilità di sviluppo per lo sviluppatore siano diventate più importanti dell’usabilità finale del prodotto per l’utente. Si scelgono così tecnologie, librerie, framework e scorciatoie che facilitano la vita allo sviluppatore, ma finiscono anche con l’appesantire il prodotto finale per tutti gli utenti.

L’articolo di Smashing Magazine, World Wide Web, Not Wealthy Western Web, ci ricorda — assieme a varie buone pratiche da adottare — che il web è globale: ad utilizzarlo non siamo solamente noi con iPhone di ultima generazione, Mac recenti e connessioni illimitate e veloci, con Chrome e supporto alle ultime tecnologie. Quando prendiamo decisioni come quella presa da Ryanair tagliamo fuori un enorme pezzo del mercato — che, probabilmente, se ne avesse l’opportunità, utilizzerebbe a sua volta il nostro prodotto:

Across the world, regardless of disposable income, regardless of hardware or network speed, people want to consume the same kinds of goods and services. And if your websites are made for the whole world, not just the wealthy Western world, then the next 4 billion people might consume the stuff that your organization makes.

Big Medium:

Only 2 out of every 1000 mobile web users ever tap a custom share button—like even once—according to a Moovweb study. We found similarly tiny numbers during our research designing Philly.com and verticals for About.com. That means people are over 11 times more likely to tap a mobile advertisement than a mobile share button for Facebook, Twitter, Pinterest, etc.

A meno che non abbiano raggiunto la pagina tramite un social network: in quel caso sono venti volte più propensi a farne uso.

Ho rinunciato alle stampanti anni fa, perché non ne esiste una che, come si direbbe da certe parti, just works. Però, c’é chi ancora non ha desistito e ne fa uso; queste persone, a volte, stampano anche cose da internet.

UX Design ha raccolto alcuni suggerimenti e accorgimenti da mettere dentro @media print, per rendere i nostri siti stampabili.

Le icone senza testo sono incomprensibili, ma il testo senza un’icona risulta noioso. Il suggerimento di iA è di utilizzarli entrambi nelle interfacce, ricordandosi che un’icona ha più una funziona “emotiva” che esplicativa:

Humans are both rational and emotional beings: “Your brain does not process information, retrieve knowledge or store memories. In short: your brain is not a computer.” If anything on the subject of icon usability has been proven again and again it is: “Icon plus label works better than icon or label alone.” […]

Do not look for reasons to use an icon because your design feels empty or cold or doesn’t work as well as you expected. Icons do not fix a structurally broken design. Add icons at the very end of the design process, do not play with icons while working on your wireframes. Pictures can stand for 1,000 different words; strong information architecture finds the right notions and puts them in the right context. Get your rationale straight before appealing to emotion.