Go deep, deep down the rabbit hole of Rob’s brain in all its colourful glory. Seriously, this is simultaneously a great write-up of how he came up with his site’s lovely colour scheme(s), and it’s a terrific primer on colour theory and why the HSL value in CSS is so, so wonderful!
Wednesday, February 28th, 2018
A collection of weird and wonderful design fiction.
This collection of “Souvenirs from the Future” envisions what the future looks like through the eyes of young and talented art, design and architecture students living in different parts of the world. Some are speculations on ideal tomorrows; others are projections and critiques on the present. Some reveal beautiful aesthetics, alternatives to the high tech; others bravely question critical issues around politics, religion or tradition.
An up-to-date list of Brighton design and dev meet-ups. There’s quite a few!
Offline itineraries with service workers
The Trivago website is a progressive web app. That means it
The service worker provides an opportunity for a nice bit of fun branding—if you lose your internet connection, the site provides a neat little maze game you can play. Cute!
That’s a fairly simple example of how service workers can enhance the user experience when the dreaded offline situation arises. But it strikes me that the travel industry is the perfect place to imagine other opportunities for offline enhancements.
Travel sites often provide itineraries—think airlines, trains, or hotels. The itineraries consist of places, times, and contact information. This is exactly the kind of information that you might find yourself trying to retrieve in an emergency situation, like maybe in a cab on the way to the airport or train station. Perhaps you’re stuck in traffic, in a tunnel. Or maybe you don’t have a data plan for the country you’re currently in. Either way, wouldn’t it be great if you could hit the website for your airline or hotel and get your itinerary, even if you’re offline.
Alright, let’s think this through…
Let’s assume that an individual itinerary has its own URL. That URL is a web page of information, mostly text, with perhaps an image or two (like a map). Now when you make your booking, let’s have the service worker cache that URL (and its assets) for offline access.
Hmm …but there’s a good chance that the device you make the booking on is not the same device that you’d have with you out and and about. Because caches are local to the browser, that’s a problem.
Okay, but of these kinds of sites have some kind of log-in mechanism. So we could update the log-in flow a bit: when a user logs in, check to see if they have any itineraries assigned to them, and if they do, fire off an event to the service worker (using
postMessage) to cache the URLs of the itineraries.
Now that the itineraries are cached, the final step is to create a custom offline page. As well as the usual “Sorry, the internet’s down” message, we can say “Sorry, the internet’s down …but here are your itineraries”. (This is kind of like the pattern you see on blogs like mine, Ethan’s, or Mike’s—a custom offline page that lists cached URLs of articles you’ve previously visited).
That’s just one pattern off the top of my head. It’s fun to imagine the different ways that service workers could be used to enhance the experience of just about any site, but they seem particularly relevant to travel sites—dodgy internet connections and travelling go hand-in-hand. At Clearleft, we’ve been working with quite a few travel-related clients lately so that’s why these scenarios are on my mind: booking holidays, flights, and so on. But, as I’ve said before and I’ll say again, every website can benefit from becoming a progressive web app.
Tuesday, February 27th, 2018
A thoroughly entertaining talk by Andy looking at the past, present, and future of robots, AI, and automation.
A catalogue of design decisions that have had harmful effects on users. This is a call for more inclusive design, but also a warning on the fetishisation of seamlessness:
The focus on details and delight can be traced to manifestos like Steve Krug’s Don’t Make Me Think, which propose a dogmatic adherence to cognitive obviousness and celebrates frictionless interaction as the ultimate design accomplishment.
Although design gets conflated with creation, its the act of improving what already exists — organising a room, editing a text, refining an interface, refactoring a codebase — that I enjoy the most.
Here’s a really smart approach to creating container queries today—it uses
ResizeObserver to ensure that listening for size changes is nice and performant.
There’s a demo site you can play around with to see it in action.
While the strategy I outline in this post is production-ready, I see us as being still very much in the early stages of this space. As the web development community starts shifting its component design from viewport or device-oriented to container-oriented, I’m excited to see what possibilities and best practices emerge.
This post goes into specifics on Django, but the broader points apply no matter what your tech stack. I’m relieved to find out that The Session is using the tripartite identity pattern (although Huffduffer, alas, isn’t):
What we really want in terms of identifying users is some combination of:
- System-level identifier, suitable for use as a target of foreign keys in our database
- Login identifier, suitable for use in performing a credential check
- Public identity, suitable for displaying to other users
Many systems ask the username to fulfill all three of these roles, which is probably wrong.
A great new seven-part series of short videos from Jen on writing resilient CSS—really understanding the error-handling model of CSS and how you can use that to use the latest and greatest features and still have your site work in non-supporting browsers.
Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.
It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.
Monday, February 26th, 2018
Ends and means
The latest edition of the excellent History Of The Web newsletter is called The Day(s) The Web Fought Back. It recounts the first time that websites stood up against bad legislation in the form of the Communications Decency Act (CDA), and goes to recount the even more effective use of blackout protests against SOPA and PIPA.
I remember feeling very heartened to see WikiPedia, Google and others take a stand on January 18th, 2012. But I also remember feeling uneasy. In this particular case, companies were lobbying for a cause I agreed with. But what if they were lobbying for a cause I didn’t agree with? Large corporations using their power to influence politics seems like a very bad idea. Isn’t it still a bad idea, even if I happen to agree with the cause?
Cloudflare quite rightly kicked The Daily Stormer off their roster of customers. Then the CEO of Cloudflare quite rightly wrote this in a company-wide memo:
Literally, I woke up in a bad mood and decided someone shouldn’t be allowed on the Internet. No one should have that power.
There’s an uncomfortable tension here. When do the ends justify the means? Isn’t the whole point of having principles that they hold true even in the direst circumstances? Why even claim that corporations shouldn’t influence politics if you’re going to make an exception for net neutrality? Why even claim that free speech is sacrosanct if you make an exception for nazi scum?
Those two examples are pretty extreme and I can easily justify the exceptions to myself. Net neutrality is too important. Stopping fascism is too important. But where do I draw the line? At what point does something become “too important?”
There are more subtle examples of corporations wielding their power. Google are constantly using their monopoly position in search and browser marketshare to exert influence over website-builders. In theory, that’s bad. But in practice, I find myself agreeing with specific instances. Prioritising mobile-friendly sites? Sounds good to me. Penalising intrusive ads? Again, that seems okey-dokey to me. But surely that’s not the point. So what if I happen to agree with the ends being pursued? The fact that a company the size and power of Google is using their monopoly for any influence is worrying, regardless of whether I agree with the specific instances. But I kept my mouth shut.
Now I see Google abusing their monopoly again, this time with AMP. They may call the preferential treatment of Google-hosted AMP-formatted pages a “carrot”, but let’s be honest, it’s an abuse of power, plain and simple.
By the way, I have no doubt that the engineers working on AMP have the best of intentions. We are all pursuing the same ends. We all want a faster web. But we disagree on the means. If Google search results gave preferential treatment to any fast web pages, that would be fine. But by only giving preferential treatment to pages written in a format that they created, and hosted on their own servers, they are effectively forcing everyone to use AMP. I know for a fact that there are plenty of publications who are producing AMP content, not because they are sold on the benefits of the technology, but because they feel strong-armed into doing it in order to compete.
If the ends justify the means, then it’s easy to write off Google’s abuse of power. Those well-intentioned AMP engineers honestly think that they have the best interests of the web at heart:
We were worried about the web not existing anymore due to native apps and walled gardens killing it off. We wanted to make the web competitive. We saw a sense of urgency and thus we decided to build on the extensible web to build AMP instead of waiting for standard and browsers and websites to catch up. I stand behind this process. I’m a practical guy.
There’s real hubris and audacity in thinking that one company should be able to tackle fixing the whole web. I think the AMP team are genuinely upset and hurt that people aren’t cheering them on. Perhaps they will dismiss the criticisms as outpourings of “Why wasn’t I consulted?” But that would be a mistake. The many thoughtful people who are extremely critical of AMP are on the same side as the AMP team when it comes the end-goal of better, faster websites. But burning the web to save it? No thanks.
: seriously, just give me a bloody opt-out from this knock-off web— Alex Russell (@slightlylate) January 14, 2017
Ben Thompson goes into more detail on the tension between the ends and the means in The Aggregator Paradox:
The problem with Google’s actions should be obvious: the company is leveraging its monopoly in search to push the AMP format, and the company is leveraging its dominant position in browsers to punish sites with bad ads. That seems bad!
And yet, from a user perspective, the options I presented at the beginning — fast loading web pages with responsive designs that look great on mobile and the elimination of pop-up ads, ad overlays, and autoplaying videos with sounds — sounds pretty appealing!
From that perspective, there’s a moral argument to be made for wielding monopoly power like Google is doing. No doubt the AMP team feel it would be morally wrong for Google not to use its influence in search to give preferential treatment to AMP pages.
Going back to the opening examples of online blackouts, was it morally wrong for companies to use their power to influence politics? Or would it have been morally wrong for them not to have used their influence?
When do the ends justify the means?
Here’s a more subtle example than Google AMP, but one which has me just as worried for the future of the web. Mozilla announced that any new web features they add to their browser will require HTTPS.
This is a step too far. Again, I am in total agreement that we should be encouraging everyone to switch to HTTPS. But requiring HTTPS in order to use CSS? The ends don’t justify the means.
If there were valid security reasons for making HTTPS a requirement, I would be all for enforcing this. But these are two totally separate areas. Enforcing HTTPS by withholding CSS support is no different to enforcing AMP by withholding search placement. In some ways, I think it might actually be worse.
There’s an assumption in this decision that websites are being made by professionals who will know how to switch to HTTPS. But the web is for everyone. Not just for everyone to use. It’s for everyone to build.
One of my greatest fears for the web is that building it becomes the domain of a professional priesthood. Anything that raises the bar to writing some HTML or CSS makes me very worried. Usually it’s toolchains that make things more complex, but in this case the barrier to entry is being brought right into the browser itself.
I’m trying to imagine future Codebar evenings, helping people to make their first websites, but now having to tell them that some CSS will be off-limits until they meet the entry requirements of HTTPS …even though CSS and HTTPS have literally nothing to do with one another. (And yes, there will be an exception for
localhost and I really hope there’ll be an exception for
file: as well, but that’s simply postponing the disappointment.)
No doubt Mozilla (and the W3C Technical Architecture Group) believe that they are doing the right thing. Perhaps they think it would be morally wrong if browsers didn’t enforce HTTPS even for unrelated features like new CSS properties. They believe that, in this particular case, the ends justify the means.
I strongly disagree. If you also disagree, I encourage you to make your voice heard. Remember, this isn’t about whether you think that we should all switch to HTTPS—we’re all in agreement on that. This is about whether it’s okay to create collateral damage by deliberately denying people access to web features in order to further a completely separate agenda.
This isn’t about you or me. This is about all those people who could potentially become makers of the web. We should be welcoming them, not creating barriers for them to overcome.
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.
A terrific piece by Maria Bustillos on digital preservation and the power of archives, backed up with frightening real-world examples.
Because history is a fight we’re having every day. We’re battling to make the truth first by living it, and then by recording and sharing it, and finally, crucially, by preserving it. Without an archive, there is no history.
Really smart thinking from Stuart on how the randomised response technique could be applied to analytics. My only question is who exactly does the implementation.
The key point here is that, if you’re collecting data about a load of users, you’re usually doing so in order to look at it in aggregate; to draw conclusions about the general trends and the general distribution of your user base. And it’s possible to do that data collection in ways that maintain the aggregate properties of it while making it hard or impossible for the company to use it to target individual users. That’s what we want here: some way that the company can still draw correct conclusions from all the data when collected together, while preventing them from targeting individuals or knowing what a specific person said.
Sunday, February 25th, 2018
Recipes inspired by The Left Hand Of Darkness.
I mostly stuck to Le Guin’s world-building rules for Winter, which were “no large meat-animals … and no mammalian products, milk, butter or cheese; the only high-protein, high-carbohydrate foods are the various kinds of eggs, fish, nuts and Hainish grains.” I did, however, add some hot-climate items found in Manhattan’s Chinatown for their space-age looks and good flavors (dragonfruit, pomelo, galangal, chilis, and kaffir limes).
Serve with hot beer.
A collection of essays on cities and technology. Contributors include Bruce Sterling, James Bridle, and Adam Greenfield.
Happy, happy birthday, @Han!
Saturday, February 24th, 2018
As installation begins, it feels like a good time to revisit this twelve year old essay by Michael Chabon on The Clock Of The Long Now. It’s a remarkable piece of writing about our relationship to the very idea of The Future, and how that relationship has changed in just one lifetime.
Ten thousand years from now: can you imagine that day? Okay, but do you? Do you believe “the Future” is going to happen? If the Clock works the way that it’s supposed to do—if it lasts—do you believe there will be a human being around to witness, let alone mourn its passing, to appreciate its accomplishment, its faithfulness, its immense antiquity? What about five thousand years from now, or even five hundred? Can you extend the horizon of your expectations for our world, for our complex of civilizations and cultures, beyond the lifetime of your own children, of the next two or three generations? Can you even imagine the survival of the world beyond the present presidential administration?
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.
Philosophically, I’m completely against Google’s AMP project and AMP for Email, too. I will always side with the open web and the standards that power it, and AMP is actively working against both. I’m all-in on a faster web for everyone, but I just can’t get behind Google’s self-serving method for providing that faster web.
Luke Stevens is trying to get untangle the very mixed signals being sent from different parts of Google around AMP’s goals. The response he got—before getting shut down—is very telling in its hubris and arrogance.
I believe the people working on the AMP format are well-intentioned, but I also believe they have conflated the best interests of Google with the best interests of the web.
I love, love, love Sam’s comparison’s between cooking and front-end development.
We should embrace the tools we have access to and appreciate our ability to learn, but also realize that maybe a gas stove or a certain design tools might not be for everyone. We have to find what works for our cooking or designing/coding style or the project/meal at hand.
Friday, February 23rd, 2018
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.
Thursday, February 22nd, 2018
Wednesday, February 21st, 2018
Monday, February 19th, 2018
Going to Hong Kong. brb
That’s the web I want; a place with spare corners where un-monetisable enthusiasms can be preserved, even if they’ve not been updated for seven years.
Sunday, February 18th, 2018
Going to Sydney. brb
Reading Provenance by Ann Leckie.
Goodbye, Willingten! Goodbye, Wibstock! Sweet ezz.
Saturday, February 17th, 2018
From a consumer’s point of view, less intrusive ad formats are of course desirable. Google’s approach is therefore basically heading in the right direction. From a privacy perspective, however, the “Better Ads” are no less aggressive than previous forms of advertising. Highly targeted ads based on detailed user profiles work subtle. They replace aggressive visuals with targeted manipulation.
Maybe I’m weird, but it just feels good. It feels good to reclaim my turf. It feels good to have a spot to think out loud in public where people aren’t spitting and shitting all over the place.
Friday, February 16th, 2018
Perhaps when Bush prophesied lightning-quick knowledge retrieval, he didn’t intend for that knowledge to be footnoted with Outbrain adverts. Licklider’s man-computer symbiosis would have been frustrated had it been crop-dusted with notifications. Ted Nelson imagined many wonderfully weird futures for the personal computer, but I don’t think gamifying meditation apps was one of them.
Another brilliant talk from Frank, this time on the (im)balance between the commercial and the cultural web.
Remember: the web is a marketplace and a commonwealth, so we have both commerce and culture; it’s just that the non-commercial bits of the web get more difficult to see in comparison to the outsized presence of the commercial web and all that caters to it.
This really resonates with me:
If commercial networks on the web measure success by reach and profit, cultural endeavors need to see their successes in terms of resonance and significance.
Thursday, February 15th, 2018
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.)
I think Khoi might be on to something here …but I also think this change in priorities is no bad thing:
Consider the macro trend of these brands all visually converging alongside the industry’s current mania for design systems. That juxtaposition suggests that we’re far more interested in implementing ideas than we are in ideas themselves.
Wednesday, February 14th, 2018
AMP pages aren’t fast because of the AMP format. AMP pages are fast when you visit one via Google search …because of Google’s monopoly on preloading:
Technically, a clever trick. It’s hard to argue with that. Yet I consider it cheating and anti competitive behavior.
Preloading is exclusive to AMP. Google does not preload non-AMP pages. If Google would have a genuine interest in speeding up the whole web on mobile, it could simply preload resources of non-AMP pages as well. Not doing this is a strong hint that another agenda is at work, to say the least.
As of this moment, the power dynamics are skewed pretty severely in favor of Google’s proprietary AMP standard, and against those of us who’d ask this question:
What can I do about AMP?
So, to recap, the web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.
This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.”
Spot on, Tim. Spot on.
If AMP is truly for the open web, de-couple it from Google search entirely. It has no business there.
Look, AMP, you’re either a tool for the open web, or you’re a tool for Google search. I don’t mind if you’re the latter, but please stop pretending you’re something else.
Tuesday, February 13th, 2018
XML 1.0 was released on February 10th, 1998. I remember the hype around XML at the time—it was our saviour, the chosen one, prophesied to bring balance to data exchange. Things didn’t quite work out that way, but still…
Twenty years later, it seems obvious that the most important thing about XML is that it was the first. The first data format that anyone could pack anything up into, send across the network to anywhere, and unpack on the other end, without asking anyone’s permission or paying for software, or for the receiver to have to pay attention to what the producer thought they’d produced it for or what it meant.
Monday, February 12th, 2018
Sharing an experience without asking you to install software is something only the web can do.
Always mark-up first. Regardless of what the kids are doing these days, I stick by my guns and start with mark-up first. A fun experiment (maybe not for you, but definitely for me) is to see how your site reads on Lynx. It does serve as a good gauge of whether the content on the site is structured properly or not.
047: The Web is Neither Good or Bad…nor is it Neutral. It’s an Amplifier with Jeremy Keith – User Defenders podcast : Inspiring Interviews with UX Superheroes.
This podcast interview I did went on for quite and while and meanders all over the place, but it sure was a lot of fun. I’ve huffduffed it, and so can you. Hope you like it.
Language is imperfect; poetry, perfectly imperfect.
Sunday, February 11th, 2018
Going to Wellington. brb
In this terrific essay by Marina Benjamin on the scientific and mathematical quest for ever-more dimensions, she offers this lovely insight into the mind-altering effects that the art of Giotto and Uccello must’ve had on their medieval audience:
By consciously exploring geometric principles, these painters gradually learned how to construct images of objects in three-dimensional space. In the process, they reprogrammed European minds to see space in a Euclidean fashion.
In a very literal fashion, perspectival representation was a form of virtual reality that, like today’s VR games, aimed to give viewers the illusion that they had been transported into geometrically coherent and psychologically convincing other worlds.
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.
There’s something quite Bridlesque about these lovely books that Brendan is generating from git commits.
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.)
A terrific piece by Dan Hon on our collective responsibility. This bit, in particular, resonated with me: it’s something I’ve been thinking about a lot lately:
We are better and stronger when we are together than when we are apart. If you’re a technologist, consider this question: what are the pros and cons of unionizing? As the product of a linked network, consider the question: what is gained and who gains from preventing humans from linking up in this way?
Saturday, February 10th, 2018
I had a chat with some people from Name.com while I was in Denver for An Event Apart. Here’s a few minutes of me rambling on about web development and the indie web.
Maybe being able to speak a foreign language is more fun than using a translation software.
Whenever we are about to substitute a laborious activity such as learning a language, cooking a meal, or tending to plants with a — deceptively — simple solution, we might always ask ourselves: Should the technology grow — or the person using it?
See, this is what I’m talking about—seamlessness is not, in my opinion, a desirable goal for its own sake. Every augmentation is also an amputation.
Some questions for us to ask ourselves as we design and build:
- Empowerment: Who’s having the fun?
- Resilience: Does it make us more vulnerable?
- Empathy: What is the impact of simplification on others?
Friday, February 9th, 2018
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.
Thursday, February 8th, 2018
I enjoyed chatting to Larry Botha on the Fixate On Code podcast—I hope you’ll enjoy hearing it.
Wednesday, February 7th, 2018
Going to Sydney. brb
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.
Tuesday, February 6th, 2018
Monday, February 5th, 2018
Sunday, February 4th, 2018
Why Haven’t We Seen A Photograph Of The Whole Blockchain Yet?
Going to Hong Kong. brb
Saturday, February 3rd, 2018
I love these kinds of deep dives into one seemingly simple pattern; in this case it’s a download link with the humble
Friday, February 2nd, 2018
On slow 3G, the first visit can take up to six seconds to fully load.
On subsequent visits—with or without an internet connection—it’s about a second.
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
There’s a running joke at just about any gathering at Clearleft where we measure TTPL—Time To Pace Layers—a measurement of how long we can discuss anything before making an inevitable reference to Stewart Brand’s framing.
It’s one of those concepts that, once your brain has been exposed, you start seeing everywhere. Like bad kerning or sexism.
A brilliant talk by Stuart on how privacy could be a genuinely disruptive angle for companies looking to gain competitive advantage over the businesses currently in the ascendent.
How do you end up shaping the world? By inventing a thing that the current incumbents can’t compete against. By making privacy your core goal. Because companies who have built their whole business model on monetising your personal information cannot compete against that. They’d have to give up on everything that they are, which they can’t do. Facebook altering itself to ensure privacy for its users… wouldn’t exist. Can’t exist. That’s how you win.
The beauty of this is that it’s a weapon which only hurts bad people. A company who are currently doing creepy things with your data but don’t actually have to can alter themselves to not be creepy, and then they’re OK! A company who is utterly reliant on doing creepy things with your data and that’s all they can do, well, they’ll fail. But, y’know, I’m kinda OK with that.
Thursday, February 1st, 2018
Waving to the International Space Station from the top floor balcony of the @Clearleft HQ.
Global Diversity CFP Day—Brighton edition
There are enough middle-aged straight white men like me speaking at conferences. That’s why the Global Diversity Call-For-Proposals Day is happening this Saturday, February 3rd.
The purpose is two-fold. One is to encourage a diverse range of people to submit talk proposals to conferences. The other is to help with the specifics—coming with ideas, writing a good title and abstract, preparing the presentation, and all that.
If you’ve ever thought about submitting a talk proposal to a conference but just don’t know where to start, or if you’re just interested in the idea, please do come along on Saturday. It’s starts at 11am and will be all wrapped up by 3pm.
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.
Remy outlines the process he uses for POSSEing to Medium now that they’ve removed their IFTTT integration.
At some point during 2017, Medium decided to pull their IFTTT applets that allows content to be posted into Medium. Which I think is a pretty shitty move since there was no notification that the applet was pulled (I only noticed after Medium just didn’t contain a few of my posts), and it smacks of “Medium should be the original source”…which may be fine for some people, but I’m expecting my own content to outlast the Medium web site.