A Voight-Kampff machine for uncovering infiltrators in the ranks.
Tuesday, March 20th, 2018
Saturday, January 20th, 2018
Google won the analytics war because dropping one line of JS in the footer and handing a tried and tested interface to customers is an obvious no brainer in comparison to setting up an open source option that needs a cron job to parse the files, a database to store the results and doesn’t provide mobile interface.
Given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time.
It’s true that this often means doing more work. That’s why it’s called work. This is literally what our jobs are supposed to entail: we put in the work to make life easier for users. We’re supposed to be saving them time, not passing it along.
I’ve often thought the HTML design principle called the priority of constituencies could be adopted by web developers:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors.
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
Now I’m wondering if I should’ve clarified that second step further. When I talk about choosing “the simplest possible technology”, what I mean is “the simplest possible technology for the user”, not “the simplest possible technology for the developer.”
Time and time again, I see decisions that favour developer convenience over user needs. Don’t get me wrong—as a developer, I absolutely want developer convenience …but not at the expense of user needs.
I know that “empathy” is an over-used word in the world of user experience and design, but with good reason. I think we should try to remind ourselves of why we make our architectural decisions by invoking who those decisions benefit. For example, “This tech stack is best option for our team”, or “This solution is the best for the widest range of users.” Then, given the choice, favour user needs in the decision-making process.
There will always be situations where, given time and budget constraints, we end up choosing solutions that are easier for us, but not the best for our users. And that’s okay, as long as we acknowledge that compromise and strive to do better next time.
But when the best solutions for us as developers become enshrined as the best possible solutions, then we are failing the people we serve.
That doesn’t mean we must become hairshirt-wearing martyrs; developer convenience is important …but not as important as user needs. Start with user needs.
Thursday, December 7th, 2017
If you’re looking for a Brighton-based junior developer, you should snap up Amber right now!
I like this distinction between coders and developers.
The Coder is characterized by his proficiency in a narrow range of chosen skills.
By contrast the Developer’s single greatest skill is in being an applied learner.
I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):
Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.
I prefer Charlie’s framing. It’s not about speed, it’s about priorities:
I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.
Wednesday, September 27th, 2017
I was in Singapore last week. It was most relaxing. Sure, it’s Disneyland With The Death Penalty but the food is wonderful.
But I wasn’t just there to sample the delights of the hawker centres. I had been invited by Mozilla to join them on the opening leg of their Developer Roadshow. We assembled in the PayPal offices one evening for a rapid-fire round of talks on emerging technologies.
We got an introduction to Quantum, the new rendering engine in Firefox. It’s looking good. And fast. Oh, and we finally get support for
But this wasn’t a product pitch. Most of the talks were by non-Mozillians working on the cutting edge of technologies. I kicked things off with a slimmed-down version of my talk on evaluating technology. Then we heard from experts in everything from CSS to VR.
The highlight for me was meeting Hui Jing and watching her presentation on CSS layout. It was fantastic! Entertaining and informative, it was presented with gusto. I think it got everyone in the room very excited about CSS Grid.
The Singapore stop was the only I was able to make, but Hui Jing has been chronicling the whole trip. Sounds like quite a whirlwind tour. I’m so glad I was able to join in even for a portion. Thanks to Sandra and Ali for inviting me along—much appreciated.
In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!
‘Twould be lovely to see you there.
Thursday, September 21st, 2017
I had the honour of being invited along to kick off the first leg of Mozilla’s Developer Roadshow in Singapore.
Thursday, September 14th, 2017
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
Monday, September 11th, 2017
I like Chris’s list of criteria for the nebulous role of senior developer:
- A senior front end developer has experience.
- A senior front-end developer has a track record of good judgment.
- A senior developer has positive impact beyond the code.
- A senior developer is helpful, not all-knowing.
- A senior front-end developer is a force multiplier.
Tuesday, October 11th, 2016
Thursday, October 6th, 2016
It’s not about what works for you. It’s about what works for your users.
If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.
If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.
But it’s worth remembering this caveat too.
Thursday, July 14th, 2016
This is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).
Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.
When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.
For someone like me with fairly mediocre technical capability, this is reassuring.
Now if I only I weren’t also mediocre in those other areas too…
Tuesday, June 7th, 2016
Jeffrey’s right. Instagram’s new deal with developers is openly hostile. It probably means the end of OwnYourGram in its current form …a service whose existence is frankly the only reason I’m able to use Instagram at all.
Sunday, January 24th, 2016
Some of the explanations get a little ranty, but Heydon’s collection of observed fallacies rings true:
- The gospel fallacy
- The Luddite fallacy
- The scale fallacy
- The chocolate fireguard fallacy
- The pull request fallacy
- The ‘made at Facebook’ fallacy
- The Bob the Builder fallacy
- The real world fallacy
- The Daphne and Celeste fallacy
I’ve definitely had the Luddite fallacy and the scale fallacy thrown in my face as QEDs.
The ‘made at Facebook’ fallacy is pretty much identical to what I’ve been calling the fallacy of assumed competency: copying something that large corporation X is doing just because large corporation X is doing it.
Friday, November 27th, 2015
Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.
A look at detecting, pinpointing, measuring, and fixing rendering performance issues.
Thursday, February 19th, 2015
When I look around, I see our community spending a lot of time coming up with new tools and techniques to make our jobs easier. To ship faster. And it’s not that I’m against efficiency, but I think we need to consider the implications of our decisions. And if one of those implications is making our users suffer—or potentially suffer—in order to make our lives easier, I think we need to consider their needs above our own.
Friday, January 9th, 2015
I’m not a new developer, but I can definitely relate to this. In fact, when I’ve spoken to any developer about this, it turns out that everyone feels overwhelmed by how much we’re expected to know. That’s not good. We should open up and talk about this more (like Charlotte is doing here).
Thursday, October 23rd, 2014
The one problem I’ve seen, however, is the fundamental disconnect many of these developers seem to have with the way deploying code on the Web works. In traditional software development, we have some say in the execution environment. On the Web, we don’t.
Lakoffian self-correction: if I’m about to talk about doing something “in the browser”, I try to catch myself and say “in browsers” instead.
While we might like think that browsers have all reached a certain level of equilibrium, as Aaron puts it “the Web is messy”:
And, as much as we might like to control a user’s experience down to the very pixel, those of us who have been working on the Web for a while understand that it’s a fool’s errand and have adjusted our expectations accordingly. Unfortunately, this new crop of Web developers doesn’t seem to have gotten that memo.
Aaron makes the case that, while we cannot control which browsers people will use, we can control the server environment.
Aaron sees requiring a specific browser/OS combination as an impractical impossibility and the wrong thing to do, whereas doing this on the server is positively virtuous. I believe that this is no virtue.
It’s true enough that the server isn’t some rock-solid never-changing environment. Anyone who’s ever had to do install patches or update programming languages knows this. But at least it’s one single environment …whereas the web has an overwhelming multitude of environments; one for every browser/OS/device combination.
Stuart finishes on a stirring note:
The Web has trained its developers to attempt to build something that is fundamentally egalitarian, fundamentally available to everyone. That’s why the Web’s good. The old software model, of something which only works in one place, isn’t the baseline against which the Web should be judged; it’s something that’s been surpassed.
However he wraps up by saying that…
In a post called Missed Connections, Aaron pushes back against that last point:
Stuart responds in a post called Reconnecting (and, by the way, how great is it to see this kind of thoughtful blog-to-blog discussion going on?).
But here’s the problem with progressively enhancing from server functionality to a rich client:
A web app which does not require its client-side scripting, which works on the server and then is progressively enhanced, does not work in an offline environment.
Now, at this juncture, I could point out that—by using progressive enhancement—you can still have the best of both worlds. Stuart has anticpated that:
It is in theory possible to write a web app which does processing on the server and is entirely robust against its client-side scripting being broken or missing, and which does processing on the client so that it works when the server’s unavailable or uncontactable or expensive or slow. But let’s be honest here. That’s not an app. That’s two apps.
Ah, there’s the rub!
When I’ve extolled the virtues of progressive enhancement in the past, the pushback I most often receive is on this point. Surely it’s wasteful to build something that works on the server and then reimplement much of it on the client?
I also think that building in this way will take longer …at first. But then on the next project, it takes less time. And on the project after that, it takes less time again. From that perspective, it’s similar to switching from tables for layout to using CSS, or switching from building fixed-with sites to responsive design: the initial learning curve is steep, but then it gets easier over time, until it simply becomes normal.
But fundamentally, Stuart is right. Developers don’t like to violate the DRY principle: Don’t Repeat Yourself. Writing code for the server environment, and then writing very similar code for the browser—I mean browsers—is a bad code smell.
Here’s the harsh truth: building websites with progressive enhancement is not convenient.
Developer convenience is a very powerful and important force. I wish that progressive enhancement could provide the same level of developer convenience offered by Angular and Ember, but right now, it doesn’t. Instead, its benefits are focused on the end user, often at the expense of the developer.
Personally, I’m willing to take that hit. I’ve always maintained that, given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time. But I absolutely understand the mindset of developers who choose otherwise.
But perhaps there’s a way to cut this Gordian knot. What if you didn’t need to write your code twice? What if you could write code for the server and then run the very same code on the client?
For me, this is the most exciting aspect of Node.js:
Some big players are looking into this idea. It’s the thinking behind AirBnB’s Rendr.
Here’s the ideal situation:
- A browser requests a URL.
- If the browser does cut the mustard, keep all the interaction in the client, just like a single page app.
So why aren’t we seeing more of these holy-grail apps that achieve progressive enhancement without code duplication?
Well, partly it’s back to that question of controlling the server environment.
In the meantime, building with progressive enhancement may have to involve a certain level of inconvenience and duplication of effort. It’s a price I’m willing to pay, but I wish I didn’t have to. And I totally understand that others aren’t willing to pay that price.
Three years ago, when I was trying to convince clients and fellow developers that responsive design was the way to go, it was a hard sell. It reminded me of trying to sell the benefits of using web standards instead of using tables for layout. Then, just as the Doug’s redesign of Wired and Mike’s redesign of ESPN helped sell the idea of CSS for layout, the Filament Group’s work on the Boston Globe made it a lot easier to sell the idea of responsive design. Then Paravel designed a responsive Microsoft homepage and the floodgates opened.
Now …who wants to do the same thing for progressive enhancement?
Thursday, September 11th, 2014
The Extensible Web Summit is taking place in Berlin today because Web Components are that important. I wish I could be there, but I’ll make do with the live notes, the IRC channel, and the octothorpe tag.
I have conflicting feelings about Web Components. I am simultaneously very excited and very nervous. That’s probably a good sign.
And here’s what I wrote after the Edge conference:
If Web Components work out, and we get a kind emergent semantics of UI widgets, it’ll be a huge leap forward for the web. But if we end up with a Tower of Babel, things could get very messy indeed. We’ll probably get both at once.
The exciting thing about Web Components is that they give developers as much power as browser makers.
The frightening thing about Web Components is that they give developers as much power as browser makers.
When browser makers—and other contributors to web standards—team up to hammer out new features in HTML, they have design principles to guide them …at least in theory. First and foremost—because this is the web, not some fly-by-night “platform”—is the issue of compatability:
You can see those principles at work with newly-minted elements like
video where fallback content can be placed between the opening and closing tags so that older user agents aren’t left high and dry (which, in turn, encourages developers to start using these features long before they’re universally supported).
You can see those principles at work in the design of
You can see those principles at work in the design of new form features which make use of the fact that browsers treat unknown
input types as
type="text" (again, encouraging developers to start using the new
input long before they’re supported in every browser).
When developers are creating new Web Components, they could apply that same amount of thought and care; Chris Scott has demonstrated just such a pattern. Switching to Web Components does not mean abandoning progressive enhancement. If anything they provide the opportunity to create whole new levels of experience.
Web developers could ensure that their Web Components are accessible, using appropriate ARIA properties.
But I fear that Sturgeon’s Law is going to dominate Web Components. The comparison that’s often cited for Web Components is the creation of jQuery plug-ins. And let’s face it, 90% of jQuery plug-ins are crap.
This wouldn’t matter so much if developers were only shooting themselves in the foot, but because of the wonderful spirit of sharing on the web, we might well end up shooting others in the foot too:
- I make something (to solve a problem).
- I’m excited about it.
- I share it.
- Others copy and paste what I’ve made.
Most of the time, that’s absolutely fantastic. But if the copying and pasting happens without critical appraisal, a lot of questionable decisions can get propagated very quickly.
To give you an example…
When Apple introduced the iPhone, it provided a mechanism to specify that a web page shouldn’t be displayed in a zoomed-out view. That mechanism, which Apple pulled out of their ass without going through any kind of standardisation process, was to use the
meta element with a
name of “viewport”:
<meta name="viewport" value="...">
value attribute of a
meta element takes a comma-separated list of values (think of
name="keywords": you provide a comma-separated list of keywords). But in an early tutorial about the
viewport value, code was provided which showed values separated with semicolons (like CSS declarations). People copied and pasted that code (which actually did work in Mobile Safari) and so every browser must support that usage:
Many other mobile browsers now support this tag, although it is not part of any web standard. Apple’s documentation does a good job explaining how web developers can use this tag, but we had to do some detective work to figure out exactly how to implement it in Fennec. For example, Safari’s documentation says the content is a “comma-delimited list,” but existing browsers and web pages use any mix of commas, semicolons, and spaces as separators.
Anyway, that’s just one illustration of how code gets shared, copied and pasted. It’s especially crucial during the introduction of a new technology to try to make sure that the code getting passed around is of a high quality.
I feel kind of bad saying this because the introductory phase of any new technology should be a time to say “Hey, go crazy! Try stuff out! See what works and what doesn’t!” but because Web Components are so powerful I think that mindset could end up doing a lot of damage.
Web developers have been given powerful features in the past. Vendor prefixes in CSS were a powerful feature that allowed browsers to push the boundaries of CSS without creating a Tower of Babel of propietary properties. But because developers just copied and pasted code, browser makers are now having to support prefixes that were originally scoped to different rendering engines. That’s not the fault of the browser makers. That’s the fault of web developers.
With Web Components, we are being given a lot of rope. We can either hang ourselves with it, or we can make awesome …rope …structures …out of rope this analogy really isn’t working.
I’m not suggesting we have some kind of central authority that gets to sit in judgement on which Web Components pass muster (although Addy’s FIRST principles are a great starting point). Instead I think a web of trust will emerge.
If I see a Web Component published by somebody at Paciello Group, I can be pretty sure that it will be accessible. Likewise, if Christian publishes a Web Component, it’s a good bet that it will use progressive enhancement. And if any of the superhumans at Filament Group share a Web Component, it’s bound to be accessible, performant, and well thought-out.
Because—as is so often the case on the web—it’s not really about technologies at all. It’s about people.
And it’s precisely because it’s about people that I’m so excited about Web Components …and simultaneously so nervous about Web Components.
Monday, July 14th, 2014
My interest in rich client-side apps has almost entirely reversed, and now I’m more interested in doing good ol’ server rendering with the occasional side of progressive enhancement, just like we did it in 2004.
This post resonates with me 100%.