A cornucopia of interactive visualisations. You control the horizontal. You control the vertical. Networks, flocking, emergence, diffusion …it’s all here.
Wednesday, May 22nd, 2019
Thursday, March 7th, 2019
I have no doubt that showing just the top outrageous tweets leads to more engagement. If you’re constantly hitting people with outlandish news stories they’ll open the app more often and interact and post about what they think so the cycle continues.
Wednesday, March 6th, 2019
Unsolved Problems by Beth Dean
An Event Apart in Seattle continues. It’s the afternoon of day two and Beth Dean is here to give a talk called Unsolved Problems:
Technology products are being adapted faster than ever. We’ve spent a lot of time adopting new technology, but not as much time considering the social impact of doing so. This talk looks at large scale system design in the offline world, and takes lessons from them to our online work. You’ll learn how to expand your design approach from self-contained products, to considering the broader systems in which they exist.
Fun fact: An Event Apart was the first conference that Beth attended over ten years ago.
Who recognises this guy on screen? It’s Robert Stack, the creepy host of Unsolved Mysteries. It was kind of like the X-Files. The X-Files taught Beth to be a sceptic. Imagine Beth’s surprise when her job at Facebook led her to actual conspiracies. It’s been a hard year, what with Cambridge Analytica and all.
Beth’s team is focused on how people experience ads, while the whole rest of the company is focused on ads from the opposite end. She’s the Fox Mulder of the company.
Technology today has incredible reach. In recent years, we’ve seen 1:1 harm. That’s when a product negatively effects someone directly. In their book, Eric and Sara point out that Facebook is often the first company to solve these problems.
1:many harm is another use of technology. Designing in isolation isn’t new to tech. We’ve seen 1:many harm in urban planning. Brasilia is a beautiful city that nobody wants to live in. You need messy, mixed-use spaces, not a space designed for cars. Niemeier planned for efficiency, not reality.
Eichler buildings were supposed to be egalitarian. But everything that makes these single-story homes great places to live also makes them great targets for criminals. Isolation by intentional design leads to a less safe place to live.
One of Frank Gehry’s buildings turned into a deathtrap when it was covered with snow. And in summer, the reflective material makes it impossible to sit on side of it. His Facebook office building has some “interesting” restroom allocation, which was planned last.
Ohio had a deer overpopulation problem. So the solution they settled on was to introduce coyotes. Now there’s a coyote problem. When coyotes breed with stray dogs, they start to get aggressive and they hunt in packs. This is the cobra effect: when the solution to your problem makes the problem worse. The British government offered a bounty for cobras in India. So people bred snakes for the bounty. So they got rid of the bounty …and then all those snakes were released into the wild.
So-called “ride sharing” apps are about getting one person from point A to point B. They’re not about making getting around easier in general.
Google traffic directions don’t factor in the effect of Google giving everyone the same traffic directions.
AirBnB drives up rent …even though it started out as a way to help people who couldn’t make rent. Sounds like cobra farming.
Automating Inequality by Virgina Eubanks is an excellent book about being dropped by health insurance. An algorithm did it. By taking broken systems and automating them, we accelerate disenfranchisement.
Then there’s Facebook. Psychological warfare is not new. Radio and television have influenced elections long before the internet. Politicians changed their language to fit the medium of radio.
The internet has removed all friction that helps us behave cooperatively. Removing friction was once our goal, but it turns out that friction is sometimes useful. The internet has turned into an outrage machine.
Solving problems in the isolation of our own products ignores the broader context of society.
The Waze map reflects cities as they are, not the way someone wishes them to be.
—Noam Bardin, CEO of Waze
From bulletin boards to today’s web, the internet has always been toxic because human nature is toxic. Maybe that’s the bigger problem to solve.
We can look to other industries…
Ideo redesigned the hospital experience. People were introduced to their entire care staff on their first visit. Sloan Kettering took a similar approach. Artwork serves as wayfinding. Every room has its own bathroom. A Chicago hostpital included gardens because it improves recovery.
These hospital examples all:
- Designed for an intended outcome.
- Met people where they were.
- Strengthened existing support networks.
We’ve seen some bad examples from urban planning, but there are success stories too.
A person on a $30 bicycle is as important as someone in a $30,000 car, said Enrique Peñalosa.
Copenhagen once faced awful traffic congestion. Now people cycle everywhere. It’s the fastest way to get around. The city is designed for bicycles first. People rode more when it felt safer. It’s no coincidence that Copenhagen ranks as one of the most livable cities in the world.
Scandinavian prisons use a concept called restorative justice. The staff plays badminton with the inmates. They cook together. Treat people like dirt and they will act like dirt. Treat people like people and they will act like people. Recividism rates in Norway are now way low.
- Design for dignity and cooperation.
- Solve for everyone in a system.
- Policy should reflect intended outcomes.
The deHavilland Comet was made of metal. After a few blew apart at the seams, they switched from rivetted material. Airlines today develop a culture of crew resource management that encourages people to speak up.
- Plan for every point of failure.
- Empower everyone on a team to solve problems.
What can we do?
- Policies affect design. We need to work more closely with policy makers.
- Question access. Are all opinions equal? Where are computers making decisions that should involve people.
- Forget neutrality. Technology is not neutral. Neutrality allows us to abdicate responsibility.
- Stay a litte bit paranoid. Think about what the worst case scenario might be.
Make people better curators. How might we allow people to assess the veracity of information for themselves? What if we gave people better tools to affect their overall experience, not just small customisations?
We can use what we know about people to bring out their best behaviours. We can empower people to take action instead of just outrage.
What if we designed for the good of the community instead of the success of individuals. Like the Vauban in Freiburg! It was squatted, and the city gave control to the squatters to create an eco neighbourhood with affordable housing.
We need to think about what kind of worlds we want to create. What if we made the web less like a mall and more like a public park?
These are hard problems. But we solve hard technology problems every day. We could be the first generation of builders to solve technology’s hard problems.
Thursday, February 21st, 2019
Speculative fiction as a tool for change:
We need to think harder about the future and ask: What if our policies, institutions, and societies didn’t have to be organized as they are now? Good science fiction taps us into a rich seam of radical answers to this question.
Thursday, December 13th, 2018
This is the real challenge for service workers:
For 30 years, we taught billions of humans that you need to be connected to the internet to consume the web via a browser! This means web users need to unlearn that web sites can’t be used offline.
Friday, November 23rd, 2018
Chris Ferdinandi has a good rule of thumb:
Makes sense, given their differing error-handling models:
‘Sfunny; I remember when we got pseudo-classes, I wrote a somewhat tongue-in-cheek post called
:hover Considered Harmful:
Presentation and behaviour… the twain have met, the waters are muddied, the issues are confused.
Monday, July 23rd, 2018
Sara shows a few different approaches to building accessible toggle switches:
Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.
Tuesday, July 10th, 2018
Components and concerns
But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:
This echoes a point made previously in a slidedeck by Cristiano Rastelli.
Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?
In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:
Your starting point should always be well-structured markup.
This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.
That’s basically an application of starting with the rule of least power.
In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:
We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”
There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.
My point is this:
- Separating structure, presentation, and behaviour is a good idea.
- Separating an interface into components is a good idea.
Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.
Thursday, May 3rd, 2018
The nature of human nature is that it changes. It can not, therefore, serve as a stable basis for evaluating the impact of technology. Yet the assumption that it doesn’t change serves a useful purpose. Treating human nature as something static, pure and essential elevates the speaker into a position of power. Claiming to tell us who we are, they tell us how we should be.
The latest explainer/game from Nicky Case is an absolutely brilliant interactive piece on small world networks.
Wednesday, July 19th, 2017
The magical and the mundane
The iPhone—and by extension, the smartphone—is a decade old. Ian Bogost has written an interesting piece in The Atlantic charting our changing relationship with the technology.
First, it was like a toy dog:
A device that could be cared for, and conspicuously so.
Then, it was like a cigarette:
A nervous tic, facilitated by a handheld apparatus that releases relief when operated.
Later, it was like a rosary:
Its toy-dog quirks having been tamed, its compulsive nature having been accepted, the iPhone became the magic wand by which all worldly actions could be performed, all possible information acquired.
Finally, it simply becomes …a rectangle.
Abstract, as a shape. Flat, as a surface. But suggestive of so much. A table for community. A door for entry, or for exit. A window for looking out of, or a picture for looking into. A movie screen for distraction, or a cradle for comfort, or a bed for seduction.
Technology tweaks our desire for novelty; but as soon as we get it we’re usually bored. There are no technologies that I can think of that haven’t become mundane.
This is something I touched on in my talk last year at An Event Apart. There’s a thread throughout the talk about Arthur C. Clarke, and of course I quote his third law:
Any sufficiently advanced technology is indistinguishable from magic.
I propose an addendum to that:
Any sufficiently advanced technology is indistinguishable from magic at first.
The magical quickly becomes the mundane. That’s exactly the point that Louis CK is making in the piece that Ben references.
Seven years ago Frank wrote his wonderful essay There Is A Horse In The Apple Store:
I have a term called a “tiny pony.” It is a thing that is exceptional that no one, for whatever reason, notices. Or, conversely, it is an exceptional thing that everyone notices, but quickly grows acclimated to despite the brilliance of it all.
We are surrounded by magical tiny ponies. I mean, just think: right now you are reading some words at a URL on the World Wide Web. Even more magically, I just published some words at my own URL on the World Wide Web. That still blows my mind! I hope I never lose that feeling.
Thursday, November 3rd, 2016
I don’t really have much of an opinion on his central point that browser makers should work more closely with framework makers. I’m not so sure I agree with the central premise that frameworks are going to be around for the long haul. I think good frameworks—like jQuery—should aim to make themselves redundant.
But anyway, along the way, Tom makes this observation:
Google has an institutional tendency to go it alone.
I don’t really mind these inventions. We’re not forced to adopt them, and generally, we don’t. Tom again:
See, that’s a really, really good point. It’s so much easier to get people to adjust their behaviour than to change it completely.
Sass is a really good example of this. You can take any
.css file, save it as a
.scss file, and now you’re using Sass. Then you can start using features (or not) as needed. Very smart.
Incidentally, I’m very curious to know how many people use the scss syntax (which is the same as CSS) compared to how many people use the sass indented syntax (the one with significant whitespace). In his brilliant Sass for Web Designers book, I don’t think Dan even mentioned the indented syntax.
Or compare the adoption of Sass to the adoption of HAML. Now, admittedly, the disparity there might be because Sass adds new features, whereas HAML is a purely stylistic choice. But I think the more fundamental difference is that Sass—with its scss syntax—only requires you to slightly adjust your behaviour, whereas something like HAML requires you to go all in right from the start.
This is something that has been on my mind a lately while I’ve been preparing my new talk on evaluating technology (the talk went down very well at An Event Apart San Francisco, by the way—that’s a relief). In the talk, I made a reference to one of Grace Hopper’s famous quotes:
Humans are allergic to change.
Now, Grace Hopper subsequently says:
I try to fight that.
I contrast that with the approach that Tim Berners-Lee and Robert Cailliau took with their World Wide Web project. The individual pieces were built on what people were already familiar with. URLs use slashes so they’d be feel similar to UNIX file paths. And the first fledging version of HTML took its vocabulary almost wholesale from a version of SGML already in use at CERN. In fact, you could pretty much take an existing CERN SGML file and open it as an HTML file in a web browser.
Oh, and that browser would ignore any tags it didn’t understand—behaviour that, in my opinion, would prove crucial to the growth and success of HTML. Because of its familiarity, its simplicity, and its forgiving error handling, HTML turned to be more successful than Tim Berners-Lee expected, as he wrote in his book Weaving The Web:
I expected HTML to be the basic waft and weft of the Web but documents of all types: video, computer aided design, sound, animation and executable programs to be the colored threads that would contain much of the content. It would turn out that HTML would become amazingly popular for the content as well.
Humans are allergic to change. And that’s okay.
Monday, April 13th, 2015
Sunday, March 29th, 2015
This gets nothing but agreement from me:
For altering the default scroll speed I honestly couldn’t come up with a valid use-case.
My theory is that site owners are trying to apply app-like whizz-banginess to the act of just trying to read some damn text, and so they end up screwing with the one interaction still left to the reader—scrolling.
Saturday, September 13th, 2014
A great piece by Erin on the value of a code of conduct for conferences, filled with practical advice.
Once you decide to create a code and do it thoughtfully, you’ll find the internet overflows with resources to help you accomplish your goals, and good people who’ll offer guidance and advice. From my own experience, I can say that specificity and follow-through will make your code practical and give it teeth; humane language and a strong connection to your community will make it feel real and give it a heart.
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.
Tuesday, August 6th, 2013
Saturday, July 27th, 2013
Caterina Fake takes a heartfelt look at the history of online communities:
The internet is full of strangers, generous strangers who want to help you for no reason at all. Strangers post poetry and discographies and advice and essays and photos and art and diatribes. None of them are known to you, in the old-fashioned sense. But they give the internet its life and meaning.
Sunday, July 21st, 2013
Brad has done a great job in documenting navigation patterns for responsive designs. More recently I came across Erick Arbé’s similar collection of patterns for responsive navigation. And, of course, at the Responsive Day Out, David gave a presentation on the subject.
As I mentioned in the chat after David’s talk, choosing a pattern doesn’t need to be an either/or decision. You can start with a simple solution and progressively enhance to a more complex navigation pattern.
But you don’t have to stop there. Now that you’ve got a simple solution that works everywhere, you can enhance it for more capable browsers.
I haven’t applied any media queries in this instance, but it would be pretty straightforward to apply absolute positioning or the
display: table hack to display the navigation by default at wider screen sizes. I’ll leave that as an exercise for the reader (bonus points: apply the off-canvas from the right of the viewport rather than the left).
Feel free to peruse the somewhat simplistic code. I’m doing a bit of feature detection—or cutting the mustard—to test for
On a recent project, I found myself implementing a number of different navigation patterns: off-canvas, overlay, and progressive disclosure. But each one began as an instance of the simple footer-anchor pattern.
Wednesday, March 20th, 2013
Timoni tackles the tricky topic of teaching taps.
Discoverability can be hard, but that shouldn’t stop us trying out new interactions.