Tuesday, April 18th, 2017
A step-by-step guide to building progressive web apps. It covers promises, service workers, fetch, and cache, but seeing as it’s from Google, it also pushes the app-shell model.
This is a handy resource but I strongly disagree with some of the advice in the section on architectures (the same bit that gets all swoonsome for app shells):
Start by forgetting everything you know about conventional web design, and instead imagine designing a native app.
Avoid overly “web-like” design.
What a horribly limiting vision for the web! After all that talk about being progressive and responsive, we’re told to pretend we’re imitating native apps on one device type.
What’s really disgusting is the way that the Chrome team are withholding the “add to home screen” prompt from anyone who dares to make progressive web apps that are actually, y’know …webby.
Frank has published the (beautifully designed) text of his closing XOXO keynote.
Friday, March 24th, 2017
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.
Thursday, March 23rd, 2017
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
Incredibly impressive work from the CodePen team—you can now edit entire projects in your web browser …and then deploy them to a live site!
Monday, March 20th, 2017
The second part of Bruce’s excellent series begins by focusing on the usage of proxy browsers around the world:
But how!? Well, Bruce has the answer:
I call this amazing new technique “progressive enhancement.”
You heard it here first, folks!
We’ve gone through the invention step. The infrastructure came out of DARPA and the World Wide Web itself came out of CERN.
We’ve gone through the hobbyist step. Everyone now knows what the internet is, and some of the amazing things it’s capable of.
We’ve gone through the commercialization step. Monopolies have emerged, refined, and scaled the internet.
But the question remains: can we break with the tragic history that has befallen all prior information empires? Can this time be different?
The first part of this article is a great history lesson in the style of Tim Wu’s The Master Switch. The second part is a great explanation of net neutrality, why it matters, and how we can fight for it.
If you do nothing, we will lose the war for the open internet. The greatest tool for communication and creativity in human history will fall into the hands of a few powerful corporations and governments.
There’s something very endearing about this docudrama retelling of the story of the web.
Sunday, March 19th, 2017
Interesting ideas around front-end frameworks:
The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.
Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.
Friday, March 17th, 2017
This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:
- Figure out what [insert tool] does.
- Figure out what sucks right now
- Determine if it’s worth the investment
- Learn it (if it’s worth it)
- Differentiate opinions from facts
Wednesday, March 15th, 2017
Progressive Web App questions
I got a nice email recently from Colin van Eenige. He wrote:
For my graduation project I’m researching the development of Progressive Web Apps and found your offline book called resilient web design. I was very impressed by the implementation of the website and it really was a nice experience.
I’m very interested in your vision on progressive web apps and what capabilities are waiting for us regarding offline content. Would it be fine if I’d send you some questions?
I said that would be fine, although I couldn’t promise a swift response. He sent me four questions. I finally got ‘round to sending my answers…
1. https://resilientwebdesign.com/ is an offline web book (progressive web app). What was the primary reason make it available like this (besides the other formats)?
Well, given the subject matter, it felt right that the canonical version of the book should be not just online, but made with the building blocks of the web. The other formats are all nice to have, but the HTML version feels (to me) like the “real” book.
Interestingly, it wasn’t too much trouble for people to generate other formats from the HTML (ePub, MOBI, PDF), whereas I think trying to go in the other direction would be trickier.
As for the offline part, that felt like a natural fit. I had already done that with a previous book of mine, HTML5 For Web Designers, which I put online a year or two after its print publication. In that case, I used AppCache for the offline functionality. AppCache is horrible, but this use case might be one of the few where it works well: a static book that’s never going to change. Cache invalidation is one of the worst parts of using AppCache so by not having any kinds of updates at all, I dodged that bullet.
But when it came time for Resilient Web Design, a service worker was definitely the right technology. Still, I’ve got AppCache in there as well for the browsers that don’t yet support service workers.
2. What effect you you think Progressive Web Apps will have on content consuming and do you think these will take over the purpose of some Native Apps?
The biggest effect that service workers could have is to change the expectations that people have about using the web, especially on mobile devices. Right now, people associate the web on mobile with long waits and horrible spammy overlays. Service workers can help solve that first part.
If people then start adding sites to their home screen, that will be a great sign that the web is really holding its own. But I don’t think we should get too optimistic about that: for a user, there’s no difference between a prompt on their screen saying “add to home screen” and a prompt on their screen saying “download our app”—they’re equally likely to be dismissed because we’ve trained people to dismiss anything that covers up the content they actually came for.
It’s entirely possible that websites could start taking over much of the functionality that previously was only possible in a native app. But I think that inertia and habit will keep people using native apps for quite some time.
The big exception is in markets where storage space on devices is in short supply. That’s where the decision to install a native app isn’t taken likely (given the choice between your family photos and an app, most people will reject the app). The web can truly shine here if we build lightweight, performant services.
Even in that situation, I’m still not sure how many people will end up adding those sites to their home screen (it might feel so similar to installing a native app that there may be some residual worry about storage space) but I don’t think that’s too much of a problem: if people get to a site via search or typing, that’s fine.
I worry that the messaging around “progressive web apps” is perhaps over-fetishising the home screen. I don’t think that’s the real battleground. The real battleground is in people’s heads; how they perceive the web and how they perceive native.
After all, if the average number of native apps installed in a month is zero, then that’s not exactly a hard target to match. :-)
3. What is your vision regarding Progressive Web Apps?
For me, progressive web apps don’t feel like a separate thing from making websites. I worry that the marketing of them might inflate expectations or confuse people. I like the idea that they’re simply websites that have taken their vitamins.
So my vision for progressive web apps is the same as my vision for the web: something that people use every day for all sorts of tasks.
I find it really discouraging that progressive web apps are becoming conflated with single page apps and the app shell model. Those architectural decisions have nothing to do with service workers, HTTPS, and manifest files. Yet I keep seeing the concepts used interchangeably. It would be a real shame if people chose not to use these great technologies just because they don’t classify what they’re building as an “app.”
If anything, it’s good ol’ fashioned content sites (newspapers, wikipedia, blogs, and yes, books) that can really benefit from the turbo boost of service worker+HTTPS+manifest.
I was at a conference recently where someone was given a talk encouraging people to build progressive web apps but discouraging people from doing it for their own personal sites. That’s a horrible, elitist attitude. I worry that this attitude is being codified in the term “progressive web app”.
4. What is the biggest learning you’ve had since working on Progressive Web Apps?
Well, like I said, I think that some people are focusing a bit too much on the home screen and not enough on the benefits that service workers can provide to just about any website.
My biggest learning is that these technologies aren’t for a specific subset of services, but can benefit just about anything that’s on the web. I mean, just using a service worker to explicitly cache static assets like CSS, JS, and some images is a no-brainer for almost any project.
So there you go—I’m very excited about the capabilities of these technologies, but very worried about how they’re being “sold”. I’m particularly nervous that in the rush to emulate native apps, we end up losing the very thing that makes the web so powerful: URLs.
Monday, March 6th, 2017
The conference starts tomorrow so I’ve had a day or two to acclimatise and explore. Seeing as Google are footing the bill for travel and accommodation, I’m staying at a rather nice hotel close to the conference venue in Tribeca. There’s live jazz in the lounge most evenings, a cinema downstairs, and should I request it, I can even have a goldfish in my room.
Today I realised that my hotel sits in the apex of a triangle of interesting buildings: carrier hotels.
Looming above my hotel is 32 Avenue of the Americas. On the outside the building looks like your classic Gozer the Gozerian style of New York building. Inside, the lobby features a mosaic on the ceiling, and another on the wall extolling the connective power of radio and telephone.
The same architects also designed 60 Hudson Street, which has a similar Art Deco feel to it. Inside, there’s a cavernous hallway running through the ground floor but I can’t show you a picture of it. A security guard told me I couldn’t take any photos inside …which is a little strange seeing as it’s splashed across the website of the building.
I walked around the outside of 60 Hudson, taking more pictures. Another security guard asked me what I was doing. I told her I was interested in the history of the building, which is true; it was the headquarters of Western Union. For much of the twentieth century, it was a world hub of telegraphic communication, in much the same way that a beach hut in Porthcurno was the nexus of the nineteenth century.
For a 21st century hub, there’s the third and final corner of the triangle at 33 Thomas Street. It’s a breathtaking building. It looks like a spaceship from a Chris Foss painting. It was probably designed more like a spacecraft than a traditional building—it’s primary purpose was to withstand an atomic blast. Gone are niceties like windows. Instead there’s an impenetrable monolith that looks like something straight out of a dystopian sci-fi film.
Brutalist on the outside, its interior is host to even more brutal acts of invasive surveillance. The Snowden papers revealed this AT&T building to be a centrepiece of the Titanpointe programme:
They called it Project X. It was an unusually audacious, highly sensitive assignment: to build a massive skyscraper, capable of withstanding an atomic blast, in the middle of New York City. It would have no windows, 29 floors with three basement levels, and enough food to last 1,500 people two weeks in the event of a catastrophe.
But the building’s primary purpose would not be to protect humans from toxic radiation amid nuclear war. Rather, the fortified skyscraper would safeguard powerful computers, cables, and switchboards. It would house one of the most important telecommunications hubs in the United States…
Looking at the building, it requires very little imagination to picture it as the lair of villainous activity. Laura Poitras’s short film Project X basically consists of a voiceover of someone reading an NSA manual, some ominous background music, and shots of 33 Thomas Street looming in its oh-so-loomy way.
A top-secret handbook takes viewers on an undercover journey to Titanpointe, the site of a hidden partnership. Narrated by Rami Malek and Michelle Williams, and based on classified NSA documents, Project X reveals the inner workings of a windowless skyscraper in downtown Manhattan.
Absolute gold dust from Mike!
I think that having regular 1:1s is really important, but I’m sure I’m not doing them as effectively as I could—the advice in here is going to be invaluable.
There are three types of employees in the world when it comes to disclosing issues:
- Those who will always tell you about problems.
- Those who will never tell you about problems.
- Those who will tell you about problems when asked in the right way.
I love my ones and am frustrated by my twos, but I feel like at least 9 out of 10 people are actually threes.
Sunday, March 5th, 2017
This is really good fun! And thanks to service workers, it works offline too.
The rounds are:
- Dead or Not Dead,
- Number 1 or Not Number 1, and
- Oscar or Not Oscar.
Friday, March 3rd, 2017
The new Clearleft website is live! Huzzah!
Many people have been working very hard on it and it’s all looking rather nice. But, as I said before, the site launch isn’t the end—it’s just the beginning.
There are some obvious next steps: fixing bugs, adding content, tweaking copy, and, oh yeah, that whole “testing with real users” thing. But there’s also an opportunity to have some fun on the front end. Now that the site is out there in the wild, there’s a real incentive to improve its performance.
Off the top of my head, these are some areas where I think we can play around:
- Font loading. Right now the site is just using
@font-face. A smart font-loading strategy—at least for the body copy—could really help improve the perceived performance.
- Responsive images. A long-term solution will require some wrangling on the back end, but I reckon we can come up with some way of generating different sized images to reference in
I’m looking forward to tinkering with some of those technologies. Each one should make an incremental improvement to the site’s performance. There are already some steps on the back-end that are making a big difference: upgrading to PHP7 and using HTTP2.
Now the real fun begins.
Thursday, March 2nd, 2017
A really inspiring post by Jen outlining all the benefits of the new CSS layout features …and the problems with thinking framework-first.
I know a lot of people will think the “best” way to use CSS Grid will be to download the new version of Bootstrap (version 5! now with Grid!), or to use any one of a number of CSS Grid layout frameworks that people are inevitably going to make later this year (despite Rachel Andrew and I begging everyone not to). But I don’t. The more I use CSS Grid, the more convinced I am that there is no benefit to be had by adding a layer of abstraction over it. CSS Grid is the layout framework. Baked right into the browser.
Wednesday, March 1st, 2017
Surprisingly, it helps clients understand the HTML content prototype better. They now clearly see the difference and the relationship between content and design. In general it helps me explain the content-first process better and it helps them make more sense of it.
Saturday, February 25th, 2017
We don’t take our other valuables with us when we travel—we leave the important stuff at home, or in a safe place. But Facebook and Google don’t give us similar control over our valuable data. With these online services, it’s all or nothing.
We need a ‘trip mode’ for social media sites that reduces our contact list and history to a minimal subset of what the site normally offers.
Tuesday, February 21st, 2017
Mike lists five tool skills he looks for in a designer (not that every designer needs to have all five):
- Visual Design & Animation
- Interaction Design
- Getting Things Done
Swap the first one out for some markup and CSS skills, and I reckon you’ve got a pretty good list for developers too.