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.

Unexpectedly, reading a webpage on the Apple Watch isn’t as painful as I imagined it being. I’ll have to update my websites to render properly on it. It seems fairly simple: all it’s needed is yet another meta tag and some adjustments to the images.

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.

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.

Dal blog di WebKit, una guida su come evitare che il contenuto di una pagina web venga oscurato dal famigerato “notch”:

WebKit in iOS 11 includes a new CSS function, constant(), and a set of four pre-defined constants, safe-area-inset-left, safe-area-inset-right, safe-area-inset-top, and safe-area-inset-bottom. When combined, these allow style declarations to reference the current size of the safe area insets on each side.

Un po’ una cosa triste, che un sito vada ottimizzato per funzionare al meglio su un singolo device.

Webmentions: il futuro dei commenti

Inizio a inciampare su blog che hanno adottato Webmentions, a volte al posto dei commenti. Webmentions è una specifica del W3C, uno standard per conversazioni e menzioni sul web — immaginate replies e retweet ma in formato standard, quindi che funzionano su domini, siti e piattaforme diverse. Webmentions è molto simile al vecchio Pingback, ma supporta anche altri tipi di risposta.

Volendo Twitter, Facebook & co. potrebbero adottare lo standard, ma ovviamente non lo fanno. Se lo adottassero sarebbe possibile mostrare i loro contenuti come risposte a un post — e ricostruire una parte del web che è andata a finire dentro piattaforme.

Nel frattempo, se volete implementarlo, Brid.gy offre un ponte fra questi servizi e il proprio blog.

La risposta è sì, anche se non contiene dati confidenziali, non raccoglie password, non ha form, o è uno stupido sito con nulla d’interessante dentro. I browser si stanno già attrezzando per screditare i siti senza HTTPS — presto Chrome mostrerà un alert ai visitatori avvisandoli che il sito non è sicuro, e lo farà per ciascun form. Anche per quei form che servono ad iscriversi a una semplice newsletter.

Una fra le molte ragioni a favore dell’HTTPS è che preserva l’integrità di un sito. Avete mai notato come da WiFi pubblici — aeroporti, hotel, etc. — certe pagine web appaiano modificate con pubblicità aggiuntive? Questo perché inseriscono script, contenuti, iframe. Volete che terze entità modifichino a vostra insaputa il layout e il contenuto del vostro sito? Volete che un visitatore pensi che quell’odiosa pubblicità sia stata messa lì da voi?

No, appunto — e con HTTPS non possono farlo.

Technology Review ricorda che non tutti hanno connessioni iper veloci e dati illimitati:

Ma’Niyah has a special-education plan for math; to help her, she’s been assigned problems to do online through Khan Academy. But her mother says she cannot afford broadband from Time Warner Cable, which would begin at around $50 a month, even for an entry-level offering, plus modem and taxes (and the price would rise significantly after the 12-month teaser rate expired). The family has a smartphone, but it’s harder for Ma’Niyah to use the small screen, and Marcella watches her data caps closely; just a few hours of Khan Academy videos would blow past monthly limits. Fast Internet access is available in a library a few blocks away, but “it’s so bad down here that it’s not really safe to walk outside,” Marcella Larry says. […]

A survey by Pew Research shows that fully one-third of American adults do not subscribe to any Internet access faster than dial-up at their home.

La questione sembra venire ignorata presso gli sviluppatori web che conosco, abituati a disegnare su schermi retina e a testare il loro lavoro da connessioni su fibra ottica. La performance di un’app o un sito, per molti, viene dopo la convenienza dello sviluppatore.

La pubblicità è un problema non perché sia brutta da vedere o dia fastidio, ma perché sta rovinando una tecnologia (il web) attribuendogli difetti che in realtà sono dovuti a cattive pratiche. Questa situazione ci ha portato tecnologie e soluzioni completamente futili (per dirne due: Google AMP, Instant Articles) che mettono una pezza a un problema che ci siamo creati da soli. Bloccare la pubblicità — quelle istanze di pubblicità che rovinano il web — è giusto e direi anzi doveroso: si può fare di meglio, ed é giusto penalizzare chi ricorre a behavioural tracking e cattive pratiche senza un minimo ritegno per l’utente finale.

Un sito più veloce è conveniente anche per il business. WPO Stats è un buon sito che raccoglie statistiche e dati che lo dimostrano: se non siete ancora riusciti a convincere il vostro capo, indirizzatelo lì.

(via Ethan Marcotte)

Sonnie Sedge ha provato a navigare senza Javascript per una giornata intera, segnandosi le difficoltà incontrate in diversi luoghi della rete.

Mentre è normale e accettabile che web app complesse non funzionino con Javascript disabilitato (Google Maps), è giusto che siti di informazione (come la BBC, o Wikipedia) risultino accessibili anche senza, e che Javascript non ne comprometta la velocità di accesso:

I maintain that it’s perfectly possible to use the web without javascript, especially on those sites that are considerate to the diversity of devices and users out there. And if I want to browse the web without javascript, well fuck, that’s my choice as a user. This is the web, not the Javascript App Store, and we should be making sure that things work on even the most basic device.

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.

Nick Heer:

Consider this: Google owns the most popular search engine and the biggest video hosting platform in most countries, operates one of the most-used email services on Earth, has the greatest market share of any mobile operating system, makes the most popular web browser in many countries, serves the majority of the targeted advertising on the web, provides the most popular analytics software for websites, and is attempting to become a major internet service provider. And, to cap it all off, they’re subtly replacing HTML with their own version, and it requires a Google-hosted JavaScript file to correctly display.

Google AMP è una pessima idea che doveva morire sul nascere:

L’applicazione per Mac di Slack è basata su Electron, il che significa che non è nativa e che ogni volta che scaricate Slack scaricate, anche, una copia di Google Chrome. Lo stesso vale, fra le tante, per il client di posta Nylas, l’applicazione per prendere appunti Simplenote, e l’editor di codice Atom (per Spotify il discorso è un po’ diverso, ma il risultato lo stesso). Chrome è fatto da circa 15 milioni di linee di codice, non è proprio piccolo insomma: per dimensioni è simile al kernel di Linux.

Questo significa che ogni volta che scaricate un’applicazione basata su Electron scaricate anche un sacco di roba che non serve a nulla, ma che l’applicazione si porta appresso:

You can think of slack as a small javascript program running inside another operating system VM (chrome), that you have to run in order to essentially chat on IRC. Even if you’ve got the real chrome open, each electron app runs its own, extra copy of the whole VM.

And its not a stretch to call chrome an OS. By lines of code, chrome is about the same size as the linux kernel. Like the linux kernel it has APIs for all sorts of hardware, including opengl, VR, MIDI. It has an embedded copy of SQLite, memory management and its own task manager. On MacOS it even contains a userland USB driver for xbox360 controllers. (I know its there because I wrote it. Sorry.)

Does slack contain my code to use xbox controllers? Does the slack team know? Does anyone know? I mean, the slack app is 160 megs on disk.

La conseguenza è che queste applicazioni — nonostante alcune siano semplici: una chat, un editor di testi, etc. — pesano molto, sono lente, consumano tanta batteria e risorse per funzionare.

Per modificare sul momento un design, direttamente nel browser, CSS-Tricks suggerisce alcune funzionalità parte degli strumenti per sviluppatori di Firefox che potrebbero esservi sfuggite. Come document.designMode, che rende il testo della pagina web editabile, o la possibilità di scattare uno screenshot a un nodo del documento.

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.

Perhaps more interesting is Gmail’s added support for embedded CSS and element, class, and ID selectors. With this one change, embedded styles will be nearly universally supported—meaning that email designers will no longer be bound to inline styles and all the headaches they bring. Emails will now be easier to design, develop, and maintain. The lighter code base and more familiar style of writing CSS means that many of the blockers for web developers taking email seriously will be removed.