For any single scenario you can name it’ll be easier to create a process for it than build a culture that handles it automatically. But each process is a tiny cut away from the freedom that you want your team to enjoy.
Everyone draws their lines in different ways and perhaps there is a spectrum of what is reasonable when implementing influential products. That’s exactly why technologists must seek to educate themselves on the patterns they are implementing in order to understand their psychological influence and other outcomes where intended use is not always the same as the reality of the user experience. Not only that, but we should feel empowered to speak up to authority when something crosses a line.
A good hands-on introduction to service workers from Mariko.
I’ve just come back from running a workshop at Webstock in New Zealand, followed by another one in Hong Kong. I heartily concur with Tim’s advice here. I’ve certainly migrated to having a more modular approach to workshops. In fact, these days I have little to no slides. Instead, it’s all about being flexible.
You can spend forever carefully crafting and refining your workshop and coming up with solid exercises but at the end of the day, you need to be ready to go with the flow.
Some sections you wanted to cover you may not get to. Some topics you hadn’t allotted a lot of time to may need to become more detailed. That’s all fine because the workshop is about helping them, not yourself.
We talk about complexity, but it’s all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don’t just break.
Mike pours his heart out on Ev’s blog.
I’m not entirely sure if I agree with him about licensing or certification for designers (and developers?), but I absolutely 100% agree on the need for unionisation.
We need to be held accountable for our actions. We’ve been moving fast. We’ve been breaking things. Sometimes on purpose. Sometimes out of ignorance. The effects are the same. The things we’re building are bigger than they used to be, and have more reach. The moment to slow down is here. Because what we’re breaking is too important and too precious. Much of it is irreplaceable.
Here’s a Github issue that turned into a good philosophical debate on how to build a progressive web app: should you enhance your existing site or creating a separate URL?
(For the record: I’m in favour of enhancing.)
In trying to decide on his indie web approach, Dries gives an excellent breakdown of the concepts of PESOS (Publish Elsewhere, Syndicate to Own Site) and POSSE (Publish to Own Site, Syndicate Elsewhere).
Harsh (but fair) assessment of the performance costs of doing everything on the client side.
Welcoming Progressive Web Apps to Microsoft Edge and Windows 10 - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog
It’s really great to hear about how Microsoft will be promoting progressive web apps as first-class citizens …but it’s really unhelpful that they’re using this fudgy definition:
Progressive Web Apps are just great web sites that can behave like native apps—or, perhaps, Progressive Web Apps are just great apps, powered by Web technologies and delivered with Web infrastructure.
Although they also give a more technical definition:
Technologically speaking, PWAs are web apps, progressively enhanced with modern web technologies (Service Worker, Fetch networking, Cache API, Push notifications, Web App Manifest) to provide a more app-like experience.
Nice try, slipping notifications in there like that, but no. No, no, no. Let’s not fool ourselves into thinking that one of the most annoying “features” of native apps is even desirable on the web.
If you want to use notifications, fine. But they are absolutely not a requirement for a progressive web app.
(A responsive design, on the other hand, totally is.)
Here’s an interesting insight on how WebKit is going to handle the cleanup of unused service workers and caches:
Service worker and Cache API stored information will grow as a user is browsing content. To keep only the stored information that is useful to the user, WebKit will remove unused service worker registrations after a period of a few weeks. Caches that do not get opened after a few weeks will also be removed.
I still find the landscape of build tools completely overwhelming, but I found this distinction to be a useful way of categorising the different kinds of build tools:
Build tools do two things:
- Install things
- Do things
So bower, npm and yarn install things, whereas grunt, gulp, and webpack do things.
I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times.
I saw Frank give this talk at Mirror Conf last year and it resonated with me so so much. I’ve been looking forward to him publishing the transcript ever since. If you’re anything like me, this will read as though it’s coming from directly inside your head.
In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant. Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that’s work, too). The second is to remain open-minded, patient, and willing to engage with what’s new, even if it resembles a new take on something you decided against a long time ago.
I could just keep quoting the whole thing, because it’s all brilliant, but I’ll stop with one more bit about the increasing complexity of build processes and the decreasing availability of a simple view source:
Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.
It’s ironic, isn’t it? Design is more important and respected than ever, which means we have more agency to affect change. But at the same time, our priorities have been subverted, pushed towards corporate benefit over human benefit. It’s hard to reconcile those things.
This is the rarely-seen hour-long version of my Resilience talk. It’s the director’s cut, if you will, featuring an Arthur C. Clarke sub-plot that goes from the telegraph to the World Wide Web to the space elevator.
A step-by-step account of trying to find a way to keep Sketch files in sync with the code in a pattern library. The solution came from HTML Sketchapp, a more agnostic spiritual successor to AirBnB’s React Sketchapp.
The contract was incredibly straightforward—as long as you generated HTML, you could import it into Sketch.
After some tinkering, Mark Dalgleish came up with a command line tool to automate the creation of Sketch libraries from HTML elements with
Paul is wondering why good people work for bad companies.
Maybe these designers believe that the respect and admiration they’ve garnered will provide leverage, and allow them to change how a company operates; better to be inside the tent pissing out, than outside pissing in, right? Well, short of burning down the entire piss-drenched campsite. To think you can change an organisation like Facebook – whose leadership has displayed scant regard for the human race beyond its eyeballs – you’re either incredibly naive, or lying to yourself.
It’s designed to read as a progressive enhancement when you look at the HTML it’s addressing.
Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.
That’s an impressive turnaround.
I still haven’t used React (I know, I know) but this looks like a nice explanation of React and Redux.