Tags: is

2367

sparkline

Tuesday, October 23rd, 2018

UX past, present, and future | Clearleft

This long zoom by Andy is right up my alley—a history of UX design that begins in 1880. It’s not often that you get to read something that includes Don Norman, Doug Engelbart, Lilian Gilbreth, and Vladimir Lenin. So good!

Monday, October 22nd, 2018

PWA Directory

Another directory of progressive web apps, this time maintained by Google.

I quite like the way it links through to a Lighthouse report. Here’s the listing for The Session, for example, and here’s the corresponding Lighthouse report.

Rehabilitating Google AMP: My failed attempt - socPub

Like banging your head against a proprietary brick wall.

To me this is all just another example of a company operating a closed process, not willing to collaborate openly as peers. The Ivory Tower development methodology.

Did I Make a Mistake Selling Del.icio.us to Yahoo?

For once, Betteridge’s law of headlines is refuted.

This is a fascinating insight into the heady days of 2005 when Yahoo was the cool company snapping up all the best products like Flickr, Upcoming, and Del.icio.us. It all goes downhill from there.

There’s no mention of the surprising coda.

CSS Border-Radius Can Do That? | IO 9elements

This is the trick that Charlotte used to get the nifty blobby effect on last year’s UX London site. Now there’s a tool to help you do the same.

Tuesday, October 9th, 2018

Uber, Lyft, Taxis, Design and the Age of Ambivalence + Subtraction.com

Design has disrupted taxis in a massive, almost unprecedented way. But good design doesn’t merely aim to disrupt—it should set out to actually build viable solutions. Designers shouldn’t look at a problem and say, “What we’re going to do is just fuck it up and see what happens.” That’s a dereliction of duty.

Monday, October 8th, 2018

Workplace topology | Clearleft

The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.

This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

That last part dovetails nicely with Jerlyn’s equally great piece.

Thursday, October 4th, 2018

Declaration

I like the robustness that comes with declarative languages. I also like the power that comes with imperative languages. Best of all, I like having the choice.

Take the video and audio elements, for example. If you want, you can embed a video or audio file into a web page using a straightforward declaration in HTML.

<audio src="..." controls><!-- fallback goes here --></audio>

Straightaway, that covers 80%-90% of use cases. But if you need to do more—like, provide your own custom controls—there’s a corresponding API that’s exposed in JavaScript. Using that API, you can do everything that you can do with the HTML element, and a whole lot more besides.

It’s a similar story with animation. CSS provides plenty of animation power, but it’s limited in the events that can trigger the animations. That’s okay. There’s a corresponding JavaScript API that gives you more power. Again, the CSS declarations cover 80%-90% of use cases, but for anyone in that 10%-20%, the web animation API is there to help.

Client-side form validation is another good example. For most us, the HTML attributes—required, type, etc.—are probably enough most of the time.

<input type="email" required />

When we need more fine-grained control, there’s a validation API available in JavaScript (yes, yes, I know that the API itself is problematic, but you get the point).

I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

Geolocation is a good example of an unbalanced feature. If you want to use it, you must use JavaScript. There is no declarative alternative. This doesn’t exist:

<input type="geolocation" />

That’s a shame. Anyone writing a form that asks for the user’s location—in order to submit that information to a server for processing—must write some JavaScript. That’s okay, I guess, but it’s always going to be that bit more fragile and error-prone compared to markup.

(And just in case you’re thinking of the fallback—which would be for the input element to be rendered as though its type value were text—and you think it’s ludicrous to expect users with non-supporting browsers to enter latitude and longitude coordinates by hand, I direct your attention to input type="color": in non-supporting browsers, it’s rendered as input type="text" and users are expected to enter colour values by hand.)

Geolocation is an interesting use case because it only works on HTTPS. There are quite a few JavaScript APIs that quite rightly require a secure context—like service workers—but I can’t think of a single HTML element or attribute that requires HTTPS (although that will soon change if we don’t act to stop plans to create a two-tier web). But that can’t have been the thinking behind geolocation being JavaScript only; when geolocation first shipped, it was available over HTTP connections too.

Anyway, that’s just one example. Like I said, it’s not that I’m in favour of declarative solutions instead of imperative ones; I strongly favour the choice offered by providing declarative solutions as well as imperative ones.

In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.

Previously, it was up to browser makers to think about these things. But now, with the advent of web components, we developers are gaining that same level of power and responsibility. So if you’re making a web component that you’re hoping other people will also use, maybe it’s worth keeping this design pattern in mind: allow authors to configure the functionality of the component using HTML attributes and JavaScript methods.

Infovore » Pouring one out for the Boxmakers

This is a rather beautiful piece of writing by Tom (especially the William Gibson bit at the end). This got me right in the feels:

Web 2.0 really, truly, is over. The public APIs, feeds to be consumed in a platform of your choice, services that had value beyond their own walls, mashups that merged content and services into new things… have all been replaced with heavyweight websites to ensure a consistent, single experience, no out-of-context content, and maximising the views of advertising. That’s it: back to single-serving websites for single-serving use cases.

A shame. A thing I had always loved about the internet was its juxtapositions, the way it supported so many use-cases all at once. At its heart, a fundamental one: it was a medium which you could both read and write to. From that flow others: it’s not only work and play that coexisted on it, but the real and the fictional; the useful and the useless; the human and the machine.

Tuesday, October 2nd, 2018

Form Design Patterns Book by Adam Silver

Oh, this will be good! Adam has been working on, thinking and writing about forms for quite a while and he has distilled that down into ten patterns. You just know that progressive enhancement will be at the heart of this book.

By the end of the book, you’ll have a close-to exhaustive list of ready-to-go components, delivered as a design system that you can fork, contribute to and use immediately on your projects. But more than that, you’ll have the mindset and rationale behind when or when not to use each solution, which is just as important as the solution itself.

Monday, October 1st, 2018

Web Developer Representation in W3C · An A List Apart Article

This is an excellent initiative by the Dutch Fronteers group to have professional web developers represented in W3C working groups. In this particular case, they’re funding Rachel for the CSS working group. This sets a great precedent—I really hope the W3C goes for it!

Two-Bit History

An ongoing timeline of computer technology in the form of blog posts by Sinclair Target (that’s a person, not a timeslipping transatlantic company merger).

Peter Gasston | People don’t change - YouTube

This talk from Peter—looking at the long zoom of history—is right up my alley.

Peter Gasston | People don’t change

Friday, September 28th, 2018

Letterform Archive – From the Collection: Blissymbolics

The fascinating story of Charles K. Bliss and his symbolic language:

The writing system – originally named World Writing in 1942, then Semantography in 1947, and finally Blissymoblics in the 1960s – contains several hundred basic geometric symbols (“Bliss-characters”) that can be combined in different ways to represent more complex concepts (“Bliss-words”). For example, the Bliss-characters for “house” and “medical” are combined to form the Bliss-word for “hospital” or “clinic”. The modular structure invites comparison to the German language; the German word for “hospital ” – “krankenhaus” – translates directly to “sick house”.

Thinking about permissions on the web | Sally Lait

Sally takes a long hard look at permissions on the web. It’s a fascinating topic because of all the parties involved—browsers, developers, and users.

In order to do permissions well, I think there are two key areas to think about - what’s actually being requested, and how it’s being requested.

Is a site being intrusive with what they can potentially learn about me (say, wanting my precise location when it’s unnecessary)? Or is it being intrusive in terms of how they interact with me (popping up a lot of notifications and preventing me from quickly completing my intended task)? If one of those angles doesn’t work well, then regardless of whether the other is acceptable to someone, they’re likely to start opting out and harbouring negative feelings.

Jongert

Nick demonstrates the responsive power of variable fonts by recreating a lovely design from Jacob Jongert.

Grab that browser window and get squishin’!

Saturday, September 22nd, 2018

How To Kill Your Tech Industry

I’m currently making my way through Programmed Inequality by Marie Hicks. In that book and in this article, she describes how Britain squandered its lead in the field of computing through indemic sexism. There’s also the remarkable story of Dame Stephanie Shirley.

Tuesday, September 18th, 2018

Winston Hearn | What’s best for users

The incentives that Google technology created were very important in the evolution of this current stage of the web. I think we should be skeptical of AMP because once again a single company’s technology – the same single company – is creating the incentives for where we go next.

A thorough examination of the incentives that led to AMP, and the dangers of what could happen next:

I’m not sure I am yet willing to cede the web to a single monopolized company.

Sunday, September 16th, 2018

Your Public Library Is Where It’s At + Subtraction.com

Fuck yeah, libraries!

Even more radically, your time at the library comes with absolutely no expectation that you buy anything. Or even that you transact at all. And there’s certainly no implication that your data or your rights are being surrendered in return for the services you partake in.

This rare openness and neutrality imbues libraries with a distinct sense of community, of us, of everyone having come together to fund and build and participate in this collective sharing of knowledge and space. All of that seems exceedingly rare in this increasingly commercial, exposed world of ours. In a way it’s quite amazing that the concept continues to persist at all.

And when we look at it this way, as a startlingly, almost defiantly civilized institution, it seems even more urgent that we make sure it not only continues to survive, but that it should also thrive, too.

Color Leap - History’s Palettes

Colour palettes throughout the ages that you can copy and use.