I really like the way that Paul’s talk builds on top of ideas laid down by Ethan and Frank. Good stuff.
The slides from Paul’s talk-in-progress on design principles for building responsive sites. He gave us a sneak peak at Clearleft earlier this week. ‘Sgood.
These are principles of visual design—hierarchy, rhythm, etc.—nicely explored and explained.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
- Know Your History
- Know Your Medium
- Respect Those Who Came Before You
- Respect Your Audience
- Get Involved
I have to admit, my initial reaction to the idea of providing free access to some websites for people in developing countries was “well, it’s better than no access at all, right?” …but the more I think about it, the more I realise how short-sighted that is. The power of the internet stems from being a stupid network and anything that compromises that—even with the best of intentions—is an attack on its fundamental principles.
On the surface, it sounds great for carriers to exempt popular apps from data charges. But it’s anti-competitive, patronizing, and counter-productive.
Ten facets of web development that you can choose to focus on. One of them is from me …but other nine are worth paying attention to.
Now this is what I call a conference write-up. Paul synthesises the talks from Responsive Day Out 2 into five principles for responsive design:
I don’t work in the tech industry. I work on the Web.
Thoughts from Luke Bacon on two topics that fascinate me: archives and design principles.
Like Drew, I’ve noticed some real hostility to the idea of progressive enhancement recently. Like Drew, I don’t really understand where this attitude comes from. It’s not like progressive enhancement prevents you from doing anything you would do otherwise: it’s just another way of approaching the way you build for the web.
I hope I’m wrong, but I suspect that some developers are letting their tools dictate their principles—the tail wagging the dog (where the tail is Angular, Ember, etc.).
I heartily concur with Lyza’s mini-manifesto:
I think we need to try to do as little as possible when we build the future web …putting commonality first, approaching differentiation carefully.
It’s always surprised me how quickly developers will reach for complex, potentially over-engineered solutions, when—in my experience—that approach invariably creates more problems than it solves.
Simplicity is powerful.
A cogent definition and spirited defence of progressive enhancement:
Progressive Enhancement is an extension of our shared values on the web and goes to the root of the web. I believe—and hope you agree—that the web is for everybody and should be accessible regardless of the device a user brings to the party.
Well, this is rather nice. John Maeda uses my list of design principles as a jumping-off point for investigating the differences between design for people and designing for machines.
Design principles for APIs.
An API is a user interface for developers. Put the effort in to ensure it’s not just functional but pleasant to use.
I like these design principles for server-side and client-side frameworks. I would say that they’re common sense but looking at many popular frameworks, this sense isn’t as common as it should be.
Y’know, I’m on board with pretty much every item in this manifesto.
An oldie but a goodie: Clay Shirky looks at the design principles underlying HTML in order to figure out what made it so successful. Even though this is fourteen years old, there are plenty of still-relevant insights here.
My short talk from Aral’s Update conference in Brighton last September. I’m pretty happy with how it turned out. If I only I had a handheld mic—then I could’ve done a microphone drop at the end.
Everyone has their bullshit. You can simply decide whose you’re willing to tolerate.
The slides from my presentation at this year’s An Event Apart. Such a fantastic event …it was an honour to be on the roster.
Given some recent hand-wringing about the web as a “platform,” it seems appropriate to revisit this superb article from Ben. The specifics of the companies and technologies may have changed in the past year but the fundamental point remains the same:
Everything about web architecture; HTTP, HTML, CSS, is designed to serve and render content, but most importantly the web is formed where all of that content is linked together. That is what makes it amazing, and that is what defines it. This purpose and killer application of the web is not even comparable to the application frameworks of any particular operating system.
Andy responds to Joe Hewitt’s recent despondent posts about the web. I tend to agree with Andy: I think comparing the web to other “platforms” is missing the point of what the web is.
See also: http://benward.me/blog/understand-the-web
John reinforces the importance of universal access above the desire to build only for the newest shiniest devices:
Universality is a founding principle of the web. It is the manifesto the web has been built on, and I believe one of the key drivers of the almost unimaginable success of the web over these last two decades. We ignore that at the web’s peril.
I’m getting behind Oli’s proposal to allow non-quoted footers within blockquotes in HTML. Here’s where I quote the design principles to support his case.
Luke’s notes from my talk at An Event Apart in Atlanta.
A quick chat with me in the hallway after my talk in Seattle.
Luke’s notes from my talk at An Event Apart Seattle do a good job of capturing the gist of what I was saying.
Kate Rutter on the importance of keeping design principles out in the open.
Bert Bos's 2000 Treatise (published in 2003) is a must-read for anyone involved in developing any kind of format. "This essay tries to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, longevity, and other long words ending in -y."
Gareth is putting some wisdom of crowds behind the design of APIs. Vote on the principles that you think are important in a good API.