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

Come disabilitare il correttore automatico sui campi di ricerca

Non ci vuole molto, e non è neppure una cosa nuova: basta aggiungere un paio di attributi all’HTML (autocorrect="off" autocapitalize="off" spellcheck="false"). Facebook (ad esempio) non lo fa per il suo box di ricerca principale; ogni volta che digito un nome leggermente esotico mi viene corretto prima che riesca premere invio. È sorprendentemente diffusa come cosa, ed è fonte continua di frustrazioni.

Dici — e per quei casi in cui il correttore automatico serve, invece? Fate come Google: correggete la parola o la frase nella pagina dei risultati, non prima.

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.

Don Norman e Bruce Tognazzini, due persone abbastanza importanti nel campo dell’usabilità, il primo ad Apple fino al 1996, il secondo ad Apple durante i primi anni, hanno scritto un articolo molto critico nei confronti di Apple concentrandosi, soprattutto, su iOS:

Today’s Apple has eliminated the emphasis on making products understandable and usable, and instead has imposed a Bauhaus minimalist design ethic on its products.

Unfortunately, visually simple appearance does not result in ease of use, as the vast literature in academic journals on human-computer interaction and human factors demonstrates.

Apple products deliberately hide complexity by obscuring or even removing important controls. As we often like to point out, the ultimate in simplicity is a one-button controller: very simple, but because it has only a single button, its power is very limited unless the system has modes.

Condivido parti del pezzo, non tutto — ma è comunque una lettura interessante. Scrivendo di Apple spesso viene menzionato uno dei dieci principi per un buon design di Dieter Rams: “Good design is as little design as possible”. Ma, appunto, questo è solamente il decimo. Ci sono anche gli altri nove da ricordare:

  1. Innovative
  2. Makes a product useful
  3. Aesthetic
  4. Makes a product understandable
  5. Unobtrusive
  6. Honest
  7. Long-lasting
  8. Thorough down to the last detail
  9. Environmentally friendly
  10. As little design as possible

Parcheggiare le tab

Il Nielsen Norman Group descrive una pratica che ha riscontrato essere in uso soprattutto fra i millennials (che brutta parola), nel modo di navigare su internet: l’apertura in successione di un numero elevato di tab, durante una ricerca o in preparazione di un acquisto, che vengono parcheggiate nel browser per venire visitate con maggiore attenzione in seguito. Quindi elementi simili  — come i risultati più interessanti trovati a seguito di una ricerca — raccolti in una finestra del browser, organizzati per tab.

Ho letto l’articolo con interesse, perché sembra descriva il mio modo di navigare su internet. Che si tratti di un acquisto su Amazon, della scrittura di un articolo, di una semplice ricerca su dove passare la serata o cosa cucinare, apro una finestra del browser e in poco tempo mi ritrovo con una decina di tab aperte che in seguito — finita la fase di ricerca — visito una per una, con più calma, per valutarne la validità.

La navigazione viene così divisa in due fasi: una di ricerca, in cui l’utente scandaglia una lista di risultati — decidendo quali aprire in una tab e quali ignorare — e una di digestione dell’informazione, in cui l’utente visita e valuta ciascuna delle tab raccolte.

Questa pratica ha dei vantaggi — per esempio quello di non dovere aspettare che le pagine si carichino (tanto verranno visitate più tardi) ma, soprattutto, di potersi concentrare sulla ricerca e poi lettura dei risultati, invece che cambiare continuamente tipologia di attività.

I consigli del Nielsen Norman Group per venire incontro agli utenti? Eccoli:

  • Permettere l’apertura dei link in una tab. I siti che non lo fanno, sono maligni.
  • Avere una buona favicon e un buon titolo, affinché si capisca dalla tab di cosa si tratta.
  • Aiutare il visitatore a capire dove si trova in relazione al resto del sito, con breadcrumbs.