Jeremy Keith

Jeremy Keith

Making websites. Writing books. Speaking at conferences. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.

Journal 2422 sparkline Links 6980 sparkline Articles 68 sparkline Notes 3478 sparkline

Thursday, November 16th, 2017

The Burden of Precision | Daniel T. Eden, Designer

I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.

With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.

Wednesday, November 15th, 2017

What is a Progressive Web App?

It seems like any new field goes through an inevitable growth spurt that involves “defining the damn thing.” For the first few years of the IA Summit, every second presentation seemed to be about defining what Information Architecture actually is. See also: UX. See also: Content Strategy.

Now it seems to be happening with Progressive Web Apps …which is odd, considering the damn thing is defined damn well.

I’ve written before about the naming of Progressive Web Apps. On the whole, I think it’s a pretty good term, especially if you’re trying to convince the marketing team.

Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:

  1. A fluid layout,
  2. Fluid images, and
  3. Media queries.

Likewise, Progressive Web Apps consist of:

  1. HTTPS,
  2. A service worker, and
  3. A Web App Manifest.

There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.

Except, for some reason, that clarity is being lost.

Here’s a post by Ben Halpern called What the heck is a “Progressive Web App”? Seriously.

I have a really hard time describing what a progressive web app actually is.

He points to Google’s intro to Progressive Web Apps:

Progressive Web Apps are user experiences that have the reach of the web, and are:

  • Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
  • Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
  • Engaging - Feel like a natural app on the device, with an immersive user experience.

Those are great descriptions of the benefits of Progressive Web Apps. Perfect material for convincing your clients or your boss. But that appears on developers.google.com …surely it would be more beneficial for that audience to know the technologies that comprise Progressive Web Apps?

Ben Halpern again:

Google’s continued use of the term “quality” in describing things leaves me with a ton of confusion. It really seems like they want PWA to be a general term that doesn’t imply any particular implementation, and have it be focused around the user experience, but all I see over the web is confusion as to what they mean by these things. My website is already “engaging” and “immersive”, does that mean it’s a PWA?

I think it’s important to use the right language for the right audience.

If you’re talking to the business people, tell them about the return on investment you get from Progressive Web Apps.

If you’re talking to the marketing people, tell them about the experiential benefits of Progressive Web Apps.

But if you’re talking to developers, tell them that a Progressive Web App is a website served over HTTPS with a service worker and manifest file.

Relative Requirements – CSS Wizardry

I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”

By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.

Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.

Eric’s Archived Thoughts: Declining Complexity in CSS

I think Eric is absolutely right. The barrier to entry for accomplishing what you want with CSS is much lower now. It only seems more complicated if you’re used to doing things the old way.

I envy “the kids”, the ones just starting to learn front end now. They’re likely never going to know the pain of float drop, or wrestling with inline blocks, or not being able to center along one axis. They’re going to roll their eyes when we old-timers start grumbling about the old days and say, “Floats?!? Who ever thought floats would be a good way to lay out a page? That’s totally not what they’re for, anyone can see that! Were you all high as a kite, or just utterly stupid?” You know, the way “the kids” talked ten years ago, except then it was about using tables for layout.

Monday, November 13th, 2017

Sunday, November 12th, 2017

Overheard in Ireland: “Leave that poor statue alone!”

Saturday, November 11th, 2017

Checked in at Sirius Arts Centre. Steve Cooney, Dermot Byrne, Trevor Hutchinson. map

Checked in at Sirius Arts Centre. Steve Cooney, Dermot Byrne, Trevor Hutchinson.

Checked in at O'Shio. Hot pot for two — with Jessica map

Checked in at O’Shio. Hot pot for two — with Jessica

Reading Accessibility For Everyone by Laura Kalbag.

Foreword to Hello Web Design by Tracy Osborn

The foreword to the self-published short book about design for non-designers.

Whenever I dipped my toe in the waters of the semantic web, I noticed there were two fundamentally different approaches. One approach was driven by the philosophy that absolutely everything in the universe should be theoretically describable. The other approach was far more lax, concentrating only on the popular use-cases: people, places, events, and that was pretty much it. These few common items, so the theory went, accounted for about 80% of actual usage in the real world. Trying to codify the remaining 20% would result in a disproportionate amount of effort.

I always liked that approach. I think it applies to a lot of endeavours. Coding, sketching, cooking—you can get up to speed on the bare essentials pretty quickly, and then spend a lifetime attaining mastery. But we don’t need to achieve mastery at every single thing we do. I’m quite happy to be just good enough at plenty of skills so that I can prioritise the things I really want to spend my time doing.

Perhaps web design isn’t a priority for you. Perhaps you’ve decided to double-down on programming. That doesn’t mean foregoing design completely. You can still design something pretty good …thanks to this book.

Tracy understands the fundamentals of web design so you don’t have to. She spent years learning, absorbing, and designing, and now she has very kindly distilled down the 80% of that knowledge that’s going to be the most useful to you.

Think of Hello Web Design as a book of cheat codes. It’s short, to the point, and tells you everything you need to know to be a perfectly competent web designer.

Say hello to your little friend.