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.

Ci sono segnali, cose, aspetti di un sito che uno sviluppatore web va a cercare per stabilire la qualità del sito in questione. Un po’ di tempo fa, ridimensionavo ossessivamente la finestra del browser a tutti i siti nuovi che incrociavo.

Adrian Holovaty nota come questi aspetti cambino nel tempo; com’è cambiato ciò ci aspettiamo da un sito:

In 18 years as a web developer, I’ve come to love these subtle hints: Oooh, nice URLs on this site. Or: Lovely job making the site responsive on smaller screens. If you’re a web developer or designer, how many times have you resized your browser window while looking at a site you didn’t make, just to admire the responsiveness?

Over time, technology stabilizes and the techniques become expected. 10+ years ago, in the era of .cgi and .asp, I remember geeking out with Simon Willison about beautiful URL structures we’d seen. No file extensions! Readable! Hackable!

To us, they were signals that a web development team sweated the small stuff. It’s like the famous Steve Jobs story about making the inside of the hardware look just as nice as the outside, even if nobody ever sees it, because you have pride in your work.

Zack Bloom ha riassunto le vicende attorno alla nascita del CSS, la cui prima specifica venne pubblicata nel Dicembre del 1996. Nei quattro/cinque anni precedenti, tuttavia, ci furono delle proposte alternative — che Zack presenta nel post, e che probabilmente a noi oggi appaiono astruse e innaturali:

When HTML was announced by Tim Berners-Lee in 1991 there was no method of styling pages. How given HTML tags were rendered was determined by the browser, often with significant input from the user’s preferences. It seemed, however, like a good idea to create a standard way for pages to ‘suggest’ how they might prefer to be rendered stylistically.

But CSS wouldn’t be introduced for five years, and wouldn’t be fully implemented for ten. This was a period of intense work and innovation which resulted in more than a few competing styling methods which just as easily could have become the standard.

While these languages are obviously not in common use today, I find it fascinating to think about the world that might have been. Even more surprisingly, it happens that many of these other options include features which developers would love to see appear in CSS even today.

Oliver Lindberg:

If CSS hadn’t been developed, designers might have gone elsewhere, explains Lie. HTML could have turned into more of a page description language, akin to PDF. Indeed, designers had already started making pictures out of their documents. “Because that meant you could control every pixel in there. So you could get the fonts, colours, you needed. You still see some of them around. If that had become the norm, we could have ended up with the web being a giant fax machine.”

Chris Thoburn:

It’s awesome that Chrome had this feature, right?

If that last thought was actually your last thought… congrats, you just mentally accepted years of torture doing exactly this to fix the other “most feature rich browsers”… IE6, 7, 8, and 9. …but “Standards!”. Yes, these features are on standards tracks, and thankfully far enough along they aren’t likely to be rejected. But guess what, a lot of IE’s ideas were proposals too, and a lot of them are only just now being accepted as standards today, just under different names and with improved APIs. Being first does not make you the best.

Safari è più lento nell’adottare feature che ancora sono in discussione e devono diventare standard. Chrome, nel frattempo, adotta tutto in un lampo preoccupandosi poco delle prestazioni.

Posto in altri termini: Safari è più preoccupato col soddisfare gli utenti, Chrome col soddisfare gli sviluppatori.

Un buon promemoria da Chris Coyer, di CSS Tricks:

There are two kinds of HTML:

  • HTML that makes up templates
  • HTML that is content

I feel like some discussions about HTML are clouded by not making this distinction. […]

It’s not impossible to change content, but it’s likely much harder and more dangerous.

Websites can last a long time. Content tends to grow and grow. For instance on CSS-Tricks there are 2,260 Posts and 1,369 Pages. Over the years I’ve sprinkled in classes here and there to do certain stylistic things and over time I always regret it.

Una presa in giro ai siti delle startup, che si somigliano un po’ tutti fra loro.

A List Apart ha pubblicato un estratto del nuovo libro di A Book Apart, Git for Humans:

The purpose of a commit message is to summarize a change. But the purpose of summarizing a change is to help you and your team understand what is going on in your project. The information you put into a message, therefore, should be valuable and useful to the people who will read it.

As fun as it is to use the commit message space for cursing—at a bug, or Git, or your own clumsiness—avoid editorializing. Avoid the temptation to write a commit message like “Aaaaahhh stupid bugs.” Instead, take a deep breath, grab a coffee or some herbal tea or do whatever you need to do to clear your head. Then write a message that describes what changed in the commit, as clearly and succinctly as you can.

Una libreria JavaScript per implementare Force Touch e 3D Touch in una pagina web.

Maciej Cegłowski:

Everything we do to make it harder to create a website or edit a web page, and harder to learn to code by viewing source, promotes that consumerist vision of the web. Pretending that one needs a team of professionals to put simple articles online will become a self-fulfilling prophecy. Overcomplicating the web means lifting up the ladder that used to make it possible for people to teach themselves and surprise everyone with unexpected new ideas.

Let’s preserve the web as the hypertext medium it is, the only thing of its kind in the world, and not turn it into another medium for consumption, like we have so many examples of already.

L’ultimo talk di Maciej Cegłowski[1. Fondatore di Pinboard] è, come lo sono stati i precedenti talk di Maciej Cegłowski, meritevole di attenta lettura. Riguarda la corrente obesità di molti siti web principalmente testuali, siti di giornali ad esempio, dovuta a script, pubblicità invasiva, framework sopra framework, una decina di tracker, … Cose non necessarie che, oltre ad appesantirli, li complicano facendo credere che il web sia lento per natura e che serva qualcuno che l’aggiusti — Facebook e i suoi Instant Articles.

Mi piace la regola che nessuna pagina web testuale (un articolo, il post di un blog, un tweet, etc.) debba eccedere in MB le dimensioni di un’opera letteraria Russa. Regola che lo porta a criticare siti come Medium (400 parole = 1.2 megabyte) e a coniare per loro il termine “chickenshit minimalism“:

The illusion of simplicity backed by megabytes of cruft.

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.

Adobe ha presentato Project Comet, una promettente alternativa a Sketch che arriverà a metà del 2016. Khoi Vin:

They’ve [Adobe] shown terrific ingenuity in tackling problems that UX and UI designers encounter every day with clever, unexpected solutions. Project Comet’s Repeat Grid feature, which makes it practically effortless to create interfaces for structured data, is just the most prominent example. If you’ve ever designed an app or a web site, chances are good that you’ve had to make rows and columns of similarly constructed but still varied labels, images, avatars, text fields etc.

Jeff Atwood, lo sviluppatore di Discourse[1. Per alcuni mesi lo utilizzati su questo blog]:

It seems the Android manufacturers are more interested in slapping n slow CPU cores on a die than they are in producing very fast CPU cores. And this is quite punishing when it comes to JavaScript.

This is becoming more and more of a systemic problem in the Android ecosystem, one that will not go away in the next few years, and it may affect the future of Discourse, since we bet heavily on near-desktop JavaScript performance on mobile devices. That is clearly happening on iOS but it is quite disastrously the opposite on Android.

Chrome su desktop però mostra performance pari se non migliori di Safari. La ragione risiede piuttosto in Android, nel processore: il migliore device Android in circolazione ha una performance peggiore dell’iPhone 5.

Notava John Gruber, nella sua recensione dell’iPhone 6S:

Take a look at Geekbench’s aggregate results for Android devices. In terms of single-core performance, there isn’t a single Android phone that beats the two-year-old iPhone 5S. Android devices fare better in multi-core benchmarks, because they have more cores (some have eight, many have four — the iPhones 6S still have only two cores), but single-core performance is a better measure for the sort of things you can feel while using a device. Apple is literally years ahead of the industry.

Nielsen Norman Group:

Early pseudo3D GUIs and Steve-Jobs-esque skeuomorphism often produced heavy, clunky interfaces.Scaling back from those excesses is good for usability. But removing visual distinctions to produce fully flat designs with no signifiers can be an equally bad extreme. Flat 2.0 provides an opportunity for compromise—visual simplicity without sacrificing signifiers.

Maximiliano Firtman ha riportato tutto quello che c’è da sapere, di nuovo e utile, riguardo a Safari su iOS 9 per uno sviluppatore web.

Due cose interessanti: una libreria/API Javascript che permette ad una webapp di accedere ai dati dell’utente su iCloud, e App Search, che permette a chi ha un sito e un’app corrispondente al sito di far trovare e vedere i propri contenuti a Siri:

Apple has just entered the search market with its own web spider that we need to support to increase our visibility inside the new Spotlight iOS search and Siri. It’s also important when we have both a website and an app, because now Apple will index the content on our website but it might lead the user to the app instead.

While this will open a new chapter in SEO, it’s quite simple. You need to use markup standards, such as Web Schemas, AppLinks, OpenGraph or Twitter Cards with an App Banner with an app-argument if you have your own native app.

Apple has just released an App Search Validation Tool that will help you understand what do you need to add in your own website to support Apple Search

Mancano ancora — se non altro io ne sento la mancanza — le notifiche push per i siti web (contrariamente a Safari su Mac, che da tempo le supporta).