Some great thoughts here from Francis on how crafting solid HTML is information architecture.
Monday, December 19th, 2016
Sunday, December 4th, 2016
Well, look at these fresh-faced lads presenting their little hypertext system in 1992. A fascinating time capsule.
Monday, November 21st, 2016
Russell wrote an article for Wired magazine all about PowerPoint, but this extended director’s cut on his own site is the real deal.
Who knew that the creator of PowerPoint was such an enthusiast for the concertina?
Saturday, October 29th, 2016
It’s still many years away from being a viable storage option, but here’s the latest on using DNA to back up our collective data.
Magnetic tape may survive a few decades, and DVDs even longer, but they are by no means immortal. Data stored in DNA, provided it’s kept cold and dry, could last for thousands of years.
Sunday, October 9th, 2016
A fascinating look at an attempt to redefine the taxonomy of online porn.
Porn is part of the ecosystem that tells us what sex and sexuality are. Porn terms are, to use Foucault’s language, part of a network of technologies creating truths about our sexuality.
Reminds of the heady days of 2005, when it was all about tagging and folksonomies.
The project, at its most ambitious, seeks to create a new feedback loop of porn watched and made, unmoored from the vagaries of old, bad, lazy categories.
Wednesday, July 13th, 2016
Did you know that Abby Covert’s book is available online in its gloriously hyperlinked entirety?
Saturday, April 30th, 2016
A lovely profile of Claude Shannon (concluding with an unexpected Brighton connection).
Thursday, February 11th, 2016
Friday, July 24th, 2015
It is a sad and beautiful world.
Thanks to their work, there was a moment in history when neuroscience, psychiatry, computer science, mathematical logic, and artificial intelligence were all one thing, following an idea first glimpsed by Leibniz—that man, machine, number, and mind all use information as a universal currency. What appeared on the surface to be very different ingredients of the world—hunks of metal, lumps of gray matter, scratches of ink on a page—were profoundly interchangeable.
Monday, July 14th, 2014
A profile of Norbert Wiener, and how his star was eclipsed by Claude Shannon.
Sunday, June 29th, 2014
Guardian beta · The container model and blended content – a new approach to how we present content on the Guardian
This is what Oliver was talking about Responsive Day Out 2 — a new approach to information architecture.
Cast off your sidebars! You have nothing to lose but your grids!
A short film about Claude Shannon and Information Theory — not exactly as in-depth as James Gleick’s The Information, but it does a nice job of encapsulating the fundamental idea.
Sunday, December 15th, 2013
Defining the damn thang
Chris recently documented the results from his survey which asked:
Is it useful to distinguish between “web apps” and “web sites”?
There is just nothing but questions, exemptions, and gray area.
This is something I wrote about a while back:
Like obscenity and brunch, web apps can be described but not defined.
The results of Chris’s poll are telling. The majority of people believe there is a difference between sites and apps …but nobody can agree on what it is. The comments make for interesting reading too. The more people chime in an attempt to define exactly what a “web app” is, the more it proves the point that the the term “web app” isn’t a useful word (in the sense that useful words should have an agreed-upon meaning).
Tyler Sticka makes a good point:
By this definition, web apps are just a subset of websites.
I like that. It avoids the false dichotomy that a product is either a site or an app.
But although it seems that the term “web app” can’t be defined, there are a lot of really smart people who still think it has some value.
Having spent years working on both apps & sites, I think there’s a significant difference. Hard to explain doesn’t mean non-existent.— Cennydd Bowles (@Cennydd) December 6, 2013
I think Cennydd is right. I think the differences exist …but I also think we’re looking for those differences at the wrong scale. Rather than describing an entire product as either a website or an web app, I think it makes much more sense to distinguish between patterns.
Ok, I’ll try. An app’s primary material is behaviour. A website’s primary material is information.— Cennydd Bowles (@Cennydd) December 6, 2013
Let’s take those two modifiers—behavioural and informational. But let’s apply them at the pattern level.
The “get stuff” sites that Jake describes will have a lot of informational patterns: how best to present a flow of text for reading, for example. Typography, contrast, whitespace; all of those attributes are important for an informational pattern.
The “do stuff” sites will probably have a lot of behavioural patterns: entering information or performing an action. Feedback, animation, speed; these are some of the possible attributes of a behavioural pattern.
But just about every product out there on the web contains a combination of both types of pattern. Like I said:
Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?
Now you could make an arbitrary decision that any product with more than 50% informational patterns is a website, and any product with more than 50% behavioural patterns is a web app, but I don’t think that’s very useful.
Take a look at Brad’s collection of responsive patterns. Some of them are clearly informational (tables, images, etc.), while some of them are much more behavioural (carousels, notifications, etc.). But Brad doesn’t divide his collection into two, saying “Here are the patterns for websites” and “Here are the patterns for web apps.” That would be a dumb way to divide up his patterns, and I think it’s an equally dumb way to divide up the whole web.
What I’m getting at here is that, rather than trying to answer the question “what is a web app, anyway?”, I think it’s far more important to answer the other question I posed:
Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?
I think by making the distinction at the pattern level, that question starts to become a bit easier to answer. One possible answer is to do with the different skills involved.
For example, I know plenty of designers who are really, really good at informational patterns—they can lay out content in a beautiful, clear way. But they are less skilled when it comes to thinking through all the permutations involved in behavioural patterns—the “arrow of time” that’s part of so much interaction design. And vice-versa: a skilled interaction designer isn’t necessarily the best at old-skill knowledge of type, margins, and hierarchy. But both skillsets will be required on an almost every project on the web.
So I do believe there is value in distinguishing between behaviour and information …but I don’t believe there is value in trying to shoehorn entire products into just one of those categories. Making the distinction at the pattern level, though? That I can get behind.
Incidentally, some of the respondents to Chris’s poll shared my feeling that the term “web app” was often used from a marketing perspective to make something sound more important and superior:
Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.
Approaching things from the patterns perspective, I wonder if those same feelings of inferiority and superiority are driving the recent crop of behavioural patterns for informational content: parallaxy, snowfally, animation patterns are being applied on top of traditional informational patterns like hierarchy, measure, and art direction. I’m not sure that the juxtaposition is working that well. Taking the single interaction involved in long-form informational patterns (that interaction would be scrolling) and then using it as a trigger for all kinds of behavioural patterns feels …uncanny.
Friday, July 26th, 2013
A really terrific piece by George Dyson taking a suitably long-zoom look at information warfare and the Entscheidungsproblem, tracing the lineage of PRISM from the Corona project of the Cold War.
What we have now is the crude equivalent of snatching snippets of film from the sky, in 1960, compared to the panopticon that was to come. The United States has established a coordinated system that links suspect individuals (only foreigners, of course, but that definition becomes fuzzy at times) to dangerous ideas, and, if the links and suspicions are strong enough, our drone fleet, deployed ever more widely, is authorized to execute a strike. This is only a primitive first step toward something else. Why kill possibly dangerous individuals (and the inevitable innocent bystanders) when it will soon become technically irresistible to exterminate the dangerous ideas themselves?
The proposed solution? That we abandon secrecy and conduct our information warfare in the open.
Monday, June 17th, 2013
Battle for the planet of the APIs
Back in 2006, I gave a talk at dConstruct called The Joy Of API. It basically involved me geeking out for 45 minutes about how much fun you could have with APIs. This was the era of the mashup—taking data from different sources and scrunching them together to make something new and interesting. It was a good time to be a geek.
Anil Dash did an excellent job of describing that time period in his post The Web We Lost. It’s well worth a read—and his talk at The Berkman Istitute is well worth a listen. He described what the situation was like with APIs:
Five years ago, if you wanted to show content from one site or app on your own site or app, you could use a simple, documented format to do so, without requiring a business-development deal or contractual agreement between the sites. Thus, user experiences weren’t subject to the vagaries of the political battles between different companies, but instead were consistently based on the extensible architecture of the web itself.
Times have changed. These days, instead of seeing themselves as part of a wider web, online services see themselves as standalone entities.
So what happened?
I don’t mean that Facebook is the root of all evil. If anything, Facebook—a service that started out being based on exclusivity—has become more open over time. That’s the cause of many of its scandals; the mismatch in mental models that Facebook users have built up about how their data will be used versus Facebook’s plans to make that data more available.
No, I’m talking about Facebook as a role model; the template upon which new startups shape themselves.
In the web’s early days, AOL offered an alternative. “You don’t need that wild, chaotic lawless web”, it proclaimed. “We’ve got everything you need right here within our walled garden.”
Of course it didn’t work out for AOL. That proposition just didn’t scale, just like Yahoo’s initial model of maintaining a directory of websites just didn’t scale. The web grew so fast (and was so damn interesting) that no single company could possibly hope to compete with it. So companies stopped trying to compete with it. Instead they, quite rightly, saw themselves as being part of the web. That meant that they didn’t try to do everything. Instead, you built a service that did one thing really well—sharing photos, managing links, blogging—and if you needed to provide your users with some extra functionality, you used the best service available for that, usually through someone else’s API …just as you provided your API to them.
Then Facebook began to grow and grow. I remember the first time someone was showing me Facebook—it was Tantek of all people—I remember asking “But what is it for?” After all, Flickr was for photos, Delicious was for links, Dopplr was for travel. Facebook was for …everything …and nothing.
I just didn’t get it. It seemed crazy that a social network could grow so big just by offering …well, a big social network.
But it did grow. And grow. And grow. And suddenly the AOL business model didn’t seem so crazy anymore. It seemed ahead of its time.
Once Facebook had proven that it was possible to be the one-stop-shop for your user’s every need, that became the model to emulate. Startups stopped seeing themselves as just one part of a bigger web. Now they wanted to be the only service that their users would ever need …just like Facebook.
Seen from that perspective, the open flow of information via APIs—allowing data to flow porously between services—no longer seemed like such a good idea.
Not only have APIs been shut down—see, for example, Google’s shutdown of their Social Graph API—but even the simplest forms of representing structured data have been slashed and burned.
Twitter and Flickr used to markup their user profile pages with microformats. Your profile page would be marked up with hCard and if you had a link back to your own site, it include a
rel=”me” attribute. Not any more.
Then there’s RSS.
During the Q&A of that 2006 dConstruct talk, somebody asked me about where they should start with providing an API; what’s the baseline? I pointed out that if they were already providing RSS feeds, they already had a kind of simple, read-only API.
Because there’s a standardised format—a list of items, each with a timestamp, a title, a description (maybe), and a link—once you can parse one RSS feed, you can parse them all. It’s kind of remarkable how many mashups can be created simply by using RSS. I remember at the first London Hackday, one of my favourite mashups simply took an RSS feed of the weather forecast for London and combined it with the RSS feed of upcoming ISS flypasts. The result: a Twitter bot that only tweeted when the International Space Station was overhead and the sky was clear. Brilliant!
Back then, anywhere you found a web page that listed a series of items, you’d expect to find a corresponding RSS feed: blog posts, uploaded photos, status updates, anything really.
That has changed.
Jo’s feelings about Twitter’s anti-RSS policy mirror my own:
I feel a pang of disappointment at the fact that it was really quite easy to use if you knew little about coding, and now it might be a bit harder to do what you easily did before.
That’s the thing. It’s not like RSS is a great format—it isn’t. But it’s just good enough and just versatile enough to enable non-programmers to make something cool. In that respect, it’s kind of like HTML.
The official line from Twitter is that RSS is “infrequently used today.” That’s the same justification that Google has given for shutting down Google Reader. It reminds of the joke about the shopkeeper responding to a request for something with “Oh, we don’t stock that—there’s no call for it. It’s funny though, you’re the fifth person to ask today.”
RSS is used a lot …but much of the usage is invisible:
RSS is plumbing. It’s used all over the place but you don’t notice it.
That’s from Brent Simmons, who penned a love letter to RSS:
If you subscribe to any podcasts, you use RSS. Flipboard and Twitter are RSS readers, even if it’s not obvious and they do other things besides.
He points out the many strengths of RSS, including its decentralisation:
It’s anti-monopolist. By design it creates a level playing field.
How foolish of us, therefore, that we ended up using Google Reader exclusively to power all our RSS consumption. We took something that was inherently decentralised and we locked it up into one provider. And now that provider is going to screw us over.
I hope we won’t make that mistake again. Because, believe me, RSS is far from dead just because Google and Twitter are threatened by it.
In a post called The True Web, Robin Sloan reiterates the strength of RSS:
It will dip and diminish, but will RSS ever go away? Nah. One of RSS’s weaknesses in its early days—its chaotic decentralized weirdness—has become, in its dotage, a surprising strength. RSS doesn’t route through a single leviathan’s servers. It lacks a kill switch.
I can understand why that power could be seen as a threat if what you are trying to do is force your users to consume their own data only the way that you see fit (and all in the name of “user experience”, I’m sure).
Returning to Anil’s description of the web we lost:
We get a generation of entrepreneurs encouraged to make more narrow-minded, web-hostile products like these because it continues to make a small number of wealthy people even more wealthy, instead of letting lots of people build innovative new opportunities for themselves on top of the web itself.
I think that the presence or absence of an RSS feed (whether I actually use it or not) is a good litmus test for how a service treats my data.
- Instagram doesn’t provide an RSS feed of my uploaded photos.
- Twitter doesn’t provide an RSS feed of my tweets.
- Facebook doesn’t provide an RSS feed of my band’s updates
It might be that RSS is the canary in the coal mine for my data on the web.
If those services don’t trust me enough to give me an RSS feed, why should I trust them with my data?
Friday, March 15th, 2013
A really lovely piece on the repositories of information that aren’t catalogued—a fourth quadrant in the Rumsfeldian taxonomy, these dark archives are the unknown knowns.
Monday, July 2nd, 2012
Vannevar Bush’s original 1945 motherlode of hypertext.
Monday, April 23rd, 2007
Great post by Leisa on the real reasons for using personas (they might not be the reasons you think).
Saturday, March 31st, 2007
Leisa's slides from the IA Summit in Vegas. Looks like it was an excellent presentation, channelling the spirit of Kelly Goto and Jeff Veen.
Wednesday, September 13th, 2006
Happy Cog redesigns Dictionary.com and its siblings.