Pina Bausch ballet in London during the day, and Ghost In The Shell (the original) in Brighton the same evening—that was a busy Sunday.
Jeremy KeithMaking websites. Writing books. Speaking at conferences. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.
Journal 2375 Links 6502 Articles 66 Notes 2981
Sunday, March 26th, 2017
A lot has been written about the future of journalism, the importance of businesses like the LA Times being profitable as a way to protect American democracy. I agree with that in theory. But this sort of incompetence and contempt for readers makes me completely uninterested in helping their business.
Like Craig says…
between personal data suction and total disrespect of bandwidth, I'm not sure how you can *not* run ad blockers and browse the web— A Walkin' Dude (@craigmod) March 26, 2017
Friday, March 24th, 2017
A ludicrously deep dive by Nolan into how scrolling works in web browsers. No, wait, come back! It’s more interesting than it sounds …and it certainly isn’t as simple as you might think.
For instance, do you know the difference between the following scenarios?
- User scrolls with two fingers on a touch pad
- User scrolls with one finger on a touch screen
- User scrolls with a mouse wheel on a physical mouse
- User clicks the sidebar and drags it up and down
- User presses up, down, PageUp, PageDown, or spacebar keys on a keyboard
If you ask the average web user (or even the average web developer!) they might tell you that these interactions are all equivalent. The truth is far more interesting.
This comes complete with lovely animated illustrations by Rachel.
If we describe patterns also in terms of content, context, and contrast, we are able to define more precisely what a specific pattern is all about, what its role within a design system is, and how it is defined and shaped by its environment.
Mind you, the real issue is not finding the right words to describe what I do, but rather figuring out just what the heck it is that I actually do in the first place.
Instead, I try to make sure that the people doing the actual coding—Mark, Graham, and Danielle—are happy and have everything they need to get on with their work. From outside, it might look like my role is managerial, but I see it as the complete opposite. They’re not in service to me; I’m in service to them. If they’re not happy, I’m not doing my job.
There’s another aspect to this role of technical director, and it’s similar to the role of a creative director. Just as a creative director is responsible for the overall direction and quality of designs being produced, I have an oversight over the quality of front-end output. I don’t want to be a bottleneck in the process though, and to be honest, most of the time I don’t do much checking on the details of what’s being produced because I completely trust Mark, Graham, and Danielle to produce top quality code.
But I feel I should be doing more. Again, it’s not that I want to be a bottleneck where everything needs my approval before it gets delivered, but I hope that I could help improve everyone’s output.
Now the obvious way to do this is with code reviews. I do it a bit, but not nearly as much as I should. And even when I do, I always feel it’s a bit late to be spotting any issues. After all, the code has already been written. Also, who am I to try to review the code produced by people who are demonstrably better at coding than I am?
Instead I think it will be more useful for me to stick my oar in before a line of code has been written; to sit down with someone and talk through how they’re going to approach solving a particular problem, creating a particular pattern, or implementing a particular user story.
I suppose it’s really not that different to rubber ducking. Having someone to talk out loud with about potential solutions can be really valuable in my experience.
So I’m going to start doing more code previews. I think it will also incentivise me to do more code reviews—being involved in the initial discussion of a solution means I’m going to want to see the final result.
But I don’t think this should just apply to front-end code. I’d also like to exercise this role as technical director with the designers on a project.
All too often, decisions are made in the design phase that prove problematic in development. It usually works out okay, but it often means revisiting the designs in light of some technical considerations. I’d like to catch those issues sooner. That means sticking my nose in much earlier in the process, talking through what the designers are planning to do, and keeping an eye out for any potential issues.
So, as technical director, I won’t be giving feedback like “the colour’s not working for me” or “not sure about those type choices” (I’ll leave that to the creative director), but instead I can ask questions like “how will this work without hover?” or “what happens when the user does this?” as well as pointing out solutions that might be tricky or time-consuming to implement from a technical perspective.
What I want to avoid is the swoop’n’poop, when someone seagulls in after something has been designed or built and points out all the problems. The earlier in the process any potential issues can be spotted, the better.
And I think that’s my job.
Steps you can take to secure your phone and computer. This is especially useful in countries where ubiquitous surveillance is not only legal, but mandated by law (such as China, Australia, and the UK).
I know it’s just a landing page for YouTube channel of movie reviews but I really like the art direction and responsiveness of this.
Thinking up marketing taglines for Google:
Accelerated Mobile Pages — “Not just for mobile”
Progressive Web Apps — “Not just for apps”
Thursday, March 23rd, 2017
Flags are not languages – A blog about designing global user experiences: beyond language, location & culture.
It’s a bit finger-pointy but this blog should be useful for anyone working on internationalisation.
This blog has two general aims: to show the fundamental flaws in using flags to represent languages and how to create good experiences when dealing with multilingual and multi-regional content.
That library was a Pandorica of fabulous, interwoven randomness, as rich as plum cake. Push a seed of curiosity in between any two books and it would grow, overnight, into a rainforest hot with monkeys and jaguars and blowpipes and clouds. The room was full, and my head was full. What a magical system to place around a penniless girl.
Chapter 3 of Resilient Web Design, republished in Smashing Magazine:
In the world of web design, we tend to become preoccupied with the here and now. In “Resilient Web Design“, Jeremy Keith emphasizes the importance of learning from the past in order to better prepare ourselves for the future. So, perhaps we should stop and think more beyond our present moment? The following is an excerpt from Jeremy’s web book.
Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:
The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.
Turning your existing website into a progressive web “app”—a far more appealing prospect than trying to create an entirely new app-shell architecture:
…they are an enhancement of your existing website which should take no longer than a few hours and have no negative effect on unsupported browsers.
Wednesday, March 22nd, 2017
Writing on the web
Here’s a crazy idea: threaded tweets, but logged together, on a single webpage. A ‘weblog’, if you will.— Paul Lloyd (@paulrobertlloyd) March 21, 2017
Some people have been putting Paul’s crazy idea into practice.
- Mike revived his site a while back and he’s been posting gold dust ever since. I enjoy his no-holds-barred perspective on his time in San Francisco.
- Garrett’s writing goes all the way back to 2005. The cumulative result is two fascinating interweaving narratives—one about his health, another about his business.
- Charlotte has been documenting her move from Brighton to Sydney. Much as I love her articles about front-end development, I’m liking the slice-of-life updates on life down under even more.
- Amber has a great way with words. As well as regularly writing on her blog, she’s two-thirds of the way through writing 100 words every day for 100 days.
- Ethan has been writing about responsive design—of course—but it’s his more personal posts that make me really grateful for his site.
- Jeffrey and Eric never stopped writing on their own sites. Sure, there’s good stuff on their about web design and development, but it’s the writing about their non-web lives that’s so powerful.
There are more people I could mention …but, to be honest, not that many more. Seems like most people are happy to only publish on Ev’s blog or not at all.
I know not everybody wants to write on the web, and that’s fine. But it makes me sad when people choose not to publish their thoughts because they think no-one will be interested, or that it’s all been said before. I understand where those worries come from, but I believe—no, I know—that they are unfounded.
It’s a world wide web out there. There’s plenty of room for everyone. And I, for one, love reading the words of others.