Archive of: web development
Last night I attended the always excellent JS Oxford, and as well as having my mind expanded by both Jo and Ruth’s talks (Lemmings make an excellent analogy for multi-threading, who knew!), I gave a brief talk on the Indieweb movement.
If you’ve not heard of Indieweb movement before, it’s a push to encourage people to claim their own bit of the web, for their identity and content, free from corporate platforms. It’s not about abandoning those platforms, but ensuring that you have control of your content if something goes wrong.
From the Indieweb site:
Your content is yours
When you post something on the web, it should belong to you, not a corporation. Too many companies have gone out of business and lost all of their users’ data. By joining the IndieWeb, your content stays yours and in your control.
You are better connected
Your articles and status messages can go to all services, not just one, allowing you to engage with everyone. Even replies and likes on other services can come back to your site so they’re all in one place.
I’ve been interested in the Indieweb for a while, after attending IndieWebCamp Brighton in 2016, and I’ve been slowly implementing Indieweb features on here ever since.
So far I’ve added
rel="me"attributes to allow distributed verification, and to enable Indieauth support,
h-cardto establish identity, and
h-entryfor information discovery. Behind the scenes I’m looking at webmentions (Thanks to Perch’s first class support), and there’s the ever-eternal photo management thing I keep picking up and then running away from.
The great thing about the Indieweb is that you can implement as much or as little as you want, and it always gives you something to work on. It doesn’t matter where you start. The act of getting your own domain is the first step on a longer journey.
Frank Chimero really nails something I’ve been feeling for a while now but have been unable to put into words (emphasis mine).
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.
Learning to code through reading source was how I get started. The first site I ever built is still out there thanks to archive.org, and I delight in showing the ramshackle beginnings of my career to new students at Codebar and Code First:Girls.
Frank continues (again, emphasis mine).
As someone who has decades of experience on the web, I hate to compare myself to the tortoise, but hey, if it fits, it fits. Let’s be more like that tortoise: diligent, direct, and purposeful. The web needs pockets of slowness and thoughtfulness as its reach and power continues to increase. What we depend upon must be properly built and intelligently formed. We need to create space for complexity’s important sibling: nuance.
As Jeremy has said in Resilient Web Design:
Here’s a three‐step approach I take to web design:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
I continually go back to these three rules. I want to build things that others can learn from.
Say hello to dev.wdcs.org.
Over the next fortnight, our team will be busy posting news and blog posts from the IWC, offering us a great opportunity to ensure that the structure, work-flow, and multilingual nature of the new site all work as we hope. And in what I think is a brave move by everyone here, we’re doing it in the public eye. If GDS can do it, well so can we (seriously, the GDS team has been, and continues to be, a massive inspiration).
It’s a bit shabby round the edges: the theme is bland and temporary but hopefully very readable, there are some bugs in the internationalisation framework that I’m still fixing (“Ray, when someone asks you if you want to build a multilingual site, you say ‘NO’!”), and you might find yourself in a bit of a navigation dead-end if you follow the wrong link.
As I said, it’s a bit shabby, but it’s our shabby.
If you’re interested in the background of what led us to this point and where we’re going in the future I gave a talk to the Oxford UX group a couple of months ago that fills in some of that.
Thanks to everyone at WDCS who’s been helping on this project. As a web geek you couldn’t ask for a more passionate and committed bunch to build for.
And now, some sleep.
Last Wednesday (25th April) I gave a talk at the UX Oxford Speaker Series about the work I’ve been doing at the WDCS over the past year, and why to my friends it seemed like I had vanished off the face of the earth.
It’s a wide-ranging talk, looking at the problems with the current site, our initial research and findings, and the the content-out/responsive approach we’ve taken towards the redevelopment.
The talk itself lasts around a half-hour, with another half-hour Q&A session afterwards.
The books that I reference during the talk are:
- The Elements of Content Strategy by Erin Kissane
- Content Strategy for the Web by Kristina Halvorson & Melissa Rach
- Responsive Web Design by Ethan Marcotte
- Adaptive Web Design by Aaron Gustafson
And the list of useful links and further reading can be found on my Pinboard account under the tag uxoxford2012.
Thanks to UX Oxford for inviting me to speak, it was great to finally show everyone what I’ve been working on and I really enjoyed the questions after.
Fingers crossed we’re due to go into public beta sometime in June.
Progressive enhancement follows the Golden Rule because it is concerned with the “other”. That’s why accessibility is such a key part of building websites following the progressive enhancement philosophy. It’s about putting yourself in someone else’s shoes—someone whose abilities and situation probably differ from yours. We are a diverse lot after all.
One hell of a read from Aaron Gustafson on the Golden rule, egalitarianism and the philosophy of progressive enhancement in web design.
Done is better than perfect, or “the best” is the enemy of “the good”. Perfectionism is a form of procrastination. It assumes that time is an infinite resource, that other tasks can wait while you add “just one more touch” and that “perfect” is attainable.
One of the guiding principles behind Shopify’s apps team. Great advice for any dev team.
Jeremy Keith on the proliferation of hash-bang URLs and the recent Gawker redesign:
I’m always surprised when I come across as site that deliberately chooses to make its content harder to access.
He links to this great post by Mike Davies on just how badly this new anti-pattern – which was only ever supposed to be a band-aid for sites that ignored best practise and couldn’t get indexed by Googlebot – is breaking the structure of the web, and led directly to the site outage affecting all Gawker properties on Monday.
Speaking of simplicity.
Isaac Hall, co-founder of Dropbox competitor Syncplicity, answered the Quora question “Why is Dropbox more popular than other tools with similar functionality?“
It’s a wonderfully in-depth answer, encompassing PR companies, the press, and how to structure a beta, but despite all of those influences it came down to this:
In the end, it really came down to one incredibly genius idea: Dropbox limited its feature set on purpose. It had one folder and that folder always synced without any issues — it was magic. Syncplicity could sync every folder on your computer until you hit our quota. (Unfortunately, that feature was used to synchronize C:\Windows\ for dozens of users — doh!) Our company had too many features and this created confusion amongst our customer base. This in turn led to enough customer support issues that we couldn’t innovate on the product, we were too busy fixing things.
If you’re starting a new company, the best thing you can do is keep your feature set small and focused. Do one thing as best as you possibly can. Your users will beg and beg for more functionality. They will tell you their problems and ask you to fix it. My philosophy is that they’re right if their feature request is right only if it works for 80% of your customers. Until you have a lot of resources, stay focused on your core competency.
Rands In Repose interviews the creator of Instapaper, Marco Arment.
When asked about the early decisions he made in order to manage as a one-man shop:
The biggest design decision I’ve made is more of a continuous philosophy: do as few extremely time-consuming features as possible. As a result, Instapaper is a collection of a bunch of very easy things and only a handful of semi-hard things.
Keep it simple, iterate.