Blog Archives

Web Directions 2014 wrapup

This week I attended Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. I’ve blogged about most of the sessions I attended. This post is a summary of my impressions, with links to the more detailed posts.

This was a technical conference for technical folk. Yet the presentations that went down best were those that mixed the human side in with the tech. Those that gave techniques for handling situations and people as well as code. Those that included humour and people in the slides. Code is for people by people.

A theme stood out in the keynote presentations and many of the other sessions: putting humanity into technology. There’s a concern that technical design focuses on what’s cool and new, when it should rather focus on what people need and how users want to interact with their tech.

IMG_20141031_090244 (1)

The quality of the sessions overall was excellent. In particular, Sarah Mei’s presentation on day 1 gave me a lot to think about. Her idea is innovative and unusual: to analyse the way we make technical decisions, so that we can then apply the same process to the harder tech decisions. Jeremiah Lee’s talk on day 2, about what makes an excellent API, had some excellent nuggets of information that were particularly relevant to me as an API technical writer. I especially liked the bit about passive usability testing via analysis of existing data.

My own presentation was on day 1: Bit Rot in the Docs. It was a bit freaky – the sessions took place in a theatre, so I was literally on stage, with bright lights shining down on me and the audience in tiers of seats extending into the blackness.

Looking for more pics? Try Xavier Ho’s photos. There’s even one of me giving my presentation. (I’m in the fourth row of photos, third from the left.)

Here are my detailed notes:

A huge thanks to Maxine Sherrin and John Allsopp for the hard work and dedication they put into organising Web Directions. Thanks also to all the presenters and attendees. It was a great experience! Oh, and one final observation: The chocolate brownies were to die for.

Web Directions 2014 – day 2

This week I’m attending Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. I’m excited to be part of this event. I’ll blog about my take-aways from the sessions I attend, and anything else that comes to mind.

The keynote this morning was Being human in a digital world, by Genevieve Bell. The link is to my post about that funny, inspiring talk. Now for my notes on the rest of the day.

Elements of API excellence, by Jeremiah Lee

Jeremiah Lee is lead API engineer at Fitbit. His talk was about evaluating the maturity of APIs, and what it takes to make an excellent API.

Jeremiah ran through some scenarios that may result in a bad API. For example, you may create an API unintentionally (it was just something we auto-generated, and people started using it), selfishly (we looked only at our own requirements), or blindly (we imitated other APIs, without knowing why).

Instead, we need to actively understand the problem that needs to be solved, and to test it thoroughly before letting it loose in the wild. And we need to design it holistically. How? Tie up with our UX colleagues. We need to understand the people who use the code, as well as the code itself. The users of APIs are our peers – other engineers.

Empathy is an applied science. UX is a research-driven field. The aim is to acquire knowledge, with the purpose of doing something with that knowledge.

An excellent API is functional, reliable, secure, usable and pleasurable. Jeremiah broke down each of those points into smaller divisions. For example, usability breaks down into intuitability, testability, and corrective guidance. Pleasurable means that integrating the API is something you’d choose to do again.

Personas are a useful way of getting to know your users. Remember, in this case the users are other developers. Personas describe the people who use the product and the context they operate in. Personas also make visible our assumptions about users, and give our team a frame of reference. Jeremiah took us through the development of personas for API users, and the type of characteristics we’d need to analyse to create such personas. For example, what technologies are they using, what’s their skill level, and more.

Passive usability testing is the idea that we can use our existing data and systems to test the usability of our APIs. For example, the engineers can examine the support requests with specific questions in mind: at what times are people asking for help – immediately after a release or on long-running software; what are the frequently asked questions; what are the frequently misunderstood concepts; and so on. Another passive usability testing technique is to look at the data about API usage during an integration: how long between app registration and first request; what are the first requests and first errors; and so on.

Then there’s active usability testing. Go out and talk to people who are using the API. Hang out with them at their place of work, and take notes about how they use the API. See how they talk about the API with the rest of their team; how do they get started and what problems do they encounter/solve; how does the API fit in with the rest of their app? Or create a prototype of the API, and have people use it. Jeremiah recommends Silverback to record the user’s reaction, and then look at their emotional responses at various points during the integration. Were they happy or sad, and can we fix the sad moments.

Jeremiah finished by saying he hasn’t given us answers to building an excellent API, because there are no one-fits-all answers. Instead, he has given us the tools to find those answers.

Build better content, by Jonathon Colman

Jonathon Colman is a content strategist at Facebook. I’ve met Jonathon a couple of times, most recently at the STC Summit in Phoenix AZ earlier this year. It turns out we share the habit of waking up before the crack of dawn, and falling asleep soon after the birds stop tweeting for the day. We also share a love of technical writing. 🙂

Jonathan’s talk focused on how content strategy has to be part of UX strategy. He started off by promising us 127 slides! He’s a “madman with a clicker”. Heh. The slides are at Heh again.

First we looked at some definitions of content strategy. Then we saw some new Facebook content that aim to improve user experience, such as a privacy tool. It’s all about using language as an interface. Language is how we understand things. Content strategy is interaction design, because it focuses on experience, and the users of a product. Content strategy blurs the lines between engineering, design, testing, and so on. It crosses all those silos, focusing on the user. Jonathan calls this “intertwingling”.

The aim is to design content as a system, a product and an experience. Not as a campaign. Jonathan aligns his strategy with Lean principles: build, measure, learn. He also stresses the importance of incorporating your organisation’s core values into the design. And then go back and question your norms and values, especially if something breaks. Always remember that people are on the other end of the system.

“Slow down and fix your shit” – this is the essence of content strategy. Jonathan walked us through the quality framework his team uses at Facebook, and the content principles that guide them through the complex path of designing a product from strategy to the surface where the users see it. Aim for: simple, straightforward and human.

Thanks Jonathon for an information-packed session. Some quotes that made me think:

  • Keep it simple, get to the point, and talk like a person
  • Great content is invisible
  • If you want a better Web, you have to build it

A voice for everyone, by Doug Bowman

Doug Bowman talked about his experiences as Creative Director at Twitter, and how products like Twitter are giving people a voice. If eyes are the window to the soul, then the voice is the gateway to the heart. Whether the voice is spoken or written. A voice can change your day, or alter your life for ever. But a voice can only be powerful if it’s heard.

Doug started working at Twitter five years ago, when there were no designers in the company. So he got to grow the designer team from scratch. He loves Twitter. It’s connected him to so many people that he hadn’t met before.

The message that Doug wants to share is the human connection. Twitter is unique and wonderful because of the people who use it, not because of the service. We can connect with anyone who shares an interest with us, whether we know them or not. We get to overhear the conversations between people we don’t know.

Doug read out some tweets from conference attendees, showing lots of humour and character. He also showed us some cute, funny tweets between people or businesses, famous and not. Where else do you see businesses taking the time to reply to random mentions of their name, and often in the same humorous vein? Then we looked at some more serious tweets among people mourning a loss or going through other difficult experiences.

Tweets are a series of human moments. But you can also analyse the tweets en masse, to see patterns. For example, the tweets mentioning #hungry spike at certain times of the day. How about the tag #tired – it’s the pulse of humanity. You can see when people tend to be happy, late for work, hung over…

Big events show a huge outpouring of emotion, such as when the Giants won the World Series, or shocking world events happen. Doug told us the story of Vivienne, who made a commitment to earn $100,000 to free 500 child slaves, by selling lemonade at a stand on her street for a year. That was 5 years ago, when she was 5 years old. Her father helped her tweet about it. She reached her goal in half the time planned. What’s more, she’s given a TED Talk and runs a company that aims to end child slavery.

These stories of human connection were rooted in Twitter. But Doug’s message is for everything we do. As communicators and designers, we are the creators of the modern age. It’s our responsibility to make sure everyone on this Earth has a voice.

Architecting the rise of connected devices, by Hadi Michael

Hadi Michael is a digital adviser and software engineer at Deloitte Digital. He gave the first of three 15-minute sessions. His talk is about the importance of API layers in the growth of the Internet of Things. An example of a connected device might be a chair. It could have sensors, activators, computational power, and connectivity. The powerful idea is that the devices have contextual awareness. Some devices may decide to activate when you leave the home, such as those that clean the house. Others may switch off when you leave. Cisco estimates that we’ll have 50 billion connected devices by 2020. And that’s a conservative estimate.

How are we going to handle this – how will our solution architectures service this growing number of connected devices? Hadi showed us how various organisations have started preparing. Those that are successful have API layers at the core of their architectures, either unifying their API layer retrospectively, or doing it right from the start. The trick is to move your business systems behind the API layer, at least when there’s any chance that you’ll want to expose those systems to anything other than just the website.

Hadi walked through some tips for designers when taking connected devices into account. Thanks for a tantalising glimpse into the world of connected design!

Welcome to the fold, by Katie Miller

Katie Miller is an OpenShift Developer Advocate at Red Hat. Her presentation, the second 15-minute session, was about higher order functions in JavaScript. Katie started with a story about a secret garden, a chain of paper dolls, and a bowl of pebbles. That was a surprise! The rest of Katie’s talk was about fold, also known as reduce, and how to use it to write elegant JavaScript code. A higher-order function (HOF) is any function that takes another function as a parameter. Famous examples of HOFs are the map and filter functions, which can also be written as a fold.

Be aware also that there is a family of fold functions, such as fold left and fold right. Katie’s slides, with references, are at

Responsive in the wild, by Guy Podjarny

Guy Podjarny is Chief Technology Officer at Akamai. Guy’s talk was about the adoption of responsive web design. Which websites are going response, and how are we architecting them?

When we try to see if a website is responsive, we usually just resize the page and see if the content is cut off. We also look for a scrollbar, which indicates a non-responsive site. This isn’t ideal, but it’s pretty good and we can automate it. Guy showed us the details of the test he ran, and the results. Here are some highlights.

The adoption in the top 10,000 sites has grown by approx 8% over the last year. The average number of requests in responsive websites is substantially lower than non-responsive. The average resource size in the responsive websites is bigger. Interestingly, the image size is also bigger in responsive sites – perhaps because of retina?

Guy also compared responsive designs on the big screen with the small screen. We’d expect a substantially lower volume of data on the small screen. That’s not the pattern that shows up, presumably because the resources are downloaded anyway and then just hidden or shrunk on the client. Only approx 13% of responsive websites are 50%+ smaller on mobile. We’re doing better here than last year, but still need to make an effort.

Mobile-only sites are significantly smaller than responsive sites. Processing time follows the same pattern. Responsive sites take longer to process than mobile sites.

In summary: Adoption of responsive design has nearly doubled in less than a year. But we need to work on the performance.

Haunted machines, by Tobias Revell

Tobias Revell is a critical designer and futurist. He gave the closing keynote of the conference. Note: Today is 31 October. Halloween!

Tobias’s talk revolved around the notion that any sufficiently advanced technology is indistinguishable from magic. (From Arthur C Clarke.) Tobias gave some examples of recent hoaxes: that if you add this app to your phone, it will become waterproof, or that you can put your phone in a microwave oven to recharge it. The amazing thing is that people fell for these hoaxes. But the fact is that people are dealing with such advanced technology that they can’t understand it. As technology gets more and more advanced, it gets more and more opaque.

On the other hand, people have built computers on Minecraft. Some people are even trying to build a computer on Minecraft that you can play Minecraft on. Go figure.

Tobias gave us a link to his site: The Ongoing Collapse, “a growing collection of data sources and links positioned as a reflection of the state of the world in the terms that it likes to use. It’s a gentle ticking of the crumbling weird at the base of civilisation”. (More about the site.)

Tobias ended with this somewhat convoluted, dark thought: As makers of virtual reality, we control people’s perception of objective reality. Happy Halloween!

Thanks Tobias for a rollercoaster ride past ghosts and technologies past, present and future.

Web Directions 2014 – Being human in a digital world

This week I’m attending Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. I’m excited to be part of this event. I’ll blog about my take-aways from the sessions I attend, and anything else that comes to mind.

Genevieve Bell is director of User Experience Research at Intel Corporation, and vice president of Intel Labs. She gave the keynote on day 2 of the conference: “Being human in a digital world”. Her focus was what makes us human and the intersection of tech and culture. Below are my take-aways from this funny, engaging, thought-provoking talk.

Genevieve told us about her childhood in the Northern Territories, where she lived amongst indigenous people who would take her out into the bush at the drop of a hat. She often spent time in the bush learning from the people instead of attending school. This has shaped the way she views the world. Next, Genevieve led us through a rollicking tale of how she got her job at Intel. It’s well worth hearing. When you have the chance, sit her down, give her coffee, and ask her about it.

Genevieve’s role could be summarised like this: How do you make sense of what people care about, and how do you use that to shape next-generation technology? It involves telling stories about the future. We saw some stories from the 50s about what the future may be. (This has been a theme of the  conference keynote presentations.) Some of them were eerily close to the truth. Genevieve said that the stories show us what people’s aspirations are.

People need friends and family. The technology that makes use of this fact, such as telephony, as the ones that have succeeded. The ones that help people connect with other people. Facebook, Instagram, and so on. We also want to belong to community of people who share our skills, interests, or values. Technologies play into this too. Pinterest, Tumblr, eBay. We need to belong to something bigger than ourselves. Viz the Arab Spring. We use things to tell the world about ourselves: clothes, cars, and technology – what do you own, what services do you use, and what worlds do you belong to. And lastly, we need to keep secrets and tell lies. Evidently the average human being tells between 6 to 200 lies a day! Sharing secrets with just one or a few people is a way of bonding.

We worry what people think about us. So, we filter what we tell other people and what we put on the Internet. Are smart objects such as bathroom scales and fridges going to gossip about us? There are of course also genuine concerns about the amount of data that is available about us now. But the notion of new technology revealing information about us isn’t new. Genevieve told how, when electricity was about to be introduced to homes, gainsayers said it would make people vulnerable because strangers would be able to see what they were doing in their houses at night.

It turns out that people need to be bored. It puts our brains into a different state, where creativity can happen. But we’re living in a world where algorithms generate content that we should like. We’ll go with that for a while, because we like the familiar. Then we’ll get bored, and want to be surprised.

Genevieve says there’s something unnerving about living in a world that knows how to entertain us. The notion that once in a while, your device might do something different and surprise you, is one worth contemplating. Genevieve gave the example of a device that wakes you up with your favourite coffee every morning, then one morning suggests you look at a particular piece of art before having the coffee.

Is the Internet making us more uniform, more global, or more different? People want to be different. We want to retain our cultural identity. We spend a lot of effort maintaining our boundaries, and we imagine technology will help us do that. Even the “Internet” is now split into different internets in different parts of the world.

People want to feel the passage of time, and to have periods that are distinguished from other periods. Genevieve thinks this is a space worth investigating, particularly in connection to our smart devices and digital technology. How can we manage them, in their always-on state? We also want to be able to reinvent ourselves, which means we may want to be forgotten.

So, where does that leave us? There are things that make us human, that don’t change or only change very slowly. There are parts of us that have been in flux for ever. Genevieve showed two columns, “stable” and “in flux”, with five aspects of humanity in each column: friends and family, shared interest, reputation, and so on. The technology that plays to one of the stable aspects of humanity will endure. And the side of us that is in flux is where there is space for flashes of brilliance. This is where we can do extraordinary work.

Thanks Genevieve for a funny and idea-generating talk.

Bit rot in the documentation

This week I’m attending Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. It’s a privilege to be here, and to speak at this cool get-together.

My session is called Bit Rot in the Docs. (The link goes to the slides on SlideShare.) The presentation looks at how documentation can degenerate over time, and some techniques for finding and fixing errors.

The very mention of bit rot will strike terror into an engineer’s heart. “Unused programs or features will often stop working after sufficient time has passed, even if ‘nothing has changed’.” (From the hacker’s Jargon File.)

Bit rot affects documentation too. Whether the cause be a changing environment, human error, or the infamous cosmic rays, we need to root out that rot. But should the technical writer read and test the documentation on a regular basis? That’s the least efficient and most error-prone way of detecting doc decay.

Instead, in this session we looked at the following techniques:

  • Automated testing of code samples.
  • Documentation reviews as a standard part of engineering team procedure.
  • Collaborative spot-testing.
  • Customer feedback.

For more details of the session, see the slides on SlideShare.

Bit Rot in the Docs

Web Directions 2014 – day 1

This week I’m attending Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. I’m excited to be part of this event. I’ll blog about my take-aways from the sessions I attend, and anything else that comes to mind.

Day one started with an excellent keynote by Matt Webb. Now for some notes from other sessions I attended.

Lean Engineering, by Bill Scott

Bill Scott is the VP Engineering, Merchant | Retail | Online Payments at PayPal. His talk was about his journey from Netflix to PayPal, and how to make engineering a full lean UX partner. The concept is for the design team and the engineering team to work closely together, in tandem. Build, measure, and learn. Here are some snippets that I jotted down from this talk.

Any technology you use should be “Googlable”. When you hit a problem or want to learn something, you should be able to search for and find the solution.

When you want to make a change or pursue something innovative, decision turn around must be fast, so that you can “build, measure, and learn”.

Prototype in real time, with engineer and designer working alongside. Do sketches on a whiteboard and take them to regular design meetings, such as once a week. Make sure prototyping is enabled in the engineering stack. Your technology choices must reflect this methodology. Not everything that’s built has to be delivered to the customer. Bill talked us through the bits of tech that he and the team implemented at PayPal.

Create an engineering organisation that is partner to learning, and that encourages failure. Etsy does this well. Shift from celebration of delivery to celebration of failure and learning. Provide the framework that makes this happen.

Make delivery a non-event. A good way to do this is with continuous integration. Deliver all the time.

Engineer for volatility and throwaway-ability. Things will change. Design for that. Think of the UI as the experimentation layer. Choose a technology that allows you to control the experience and learn from it. Bill talked about choosing HTML 5 at Netflix for this reason.

Democratise innovation. Bill gave GitHub as a shining example here. Keep your teams small. Two pizzas should feed a team. Use a repo that democratises the code – no-one owns it. Get involved in and learn from external open source communities, such as in the JavaScript world. Use an open source model internally.

Bill sees the Lean methodology as a way of putting the customer into the Agile equation. Giving Agile a brain, where the brain is the user.

Unpacking technical decisions, by Sarah Mei

Sarah Mei is Chief Consultant at DevMynd. Her session was about finding out how we make technical decisions, with a mind to getting better at programming. How do people make decisions about code?

One of the biggest questions in webapp development today is, which JavaScript framework should I be using? There are so many choices. In the backend world, the question is: which datastore should I use? There’s a lot of information out there, but no easy way to make a decision. Making the wrong decision can have bad to disastrous consequences. What’s more, if you’re using an outdated technology you can be dragged to a standstill, yet changing to a new stack is expensive especially in training your team.

This type of decision is one we don’t make very often. So it’s hard to learn from previous decisions. One thing we can do is analyse the way we make other technical decisions, and then apply that process to the bigger ones. For example, you might ask an engineer, “Why did you name a variable as you did?” The answer might be, “experience”, or “it feels more natural”. That’s not useful data. So Sarah wanted to analyse the data that goes into these decisions.

Sarah considered an example of a decision between two pieces of code to be included in a project. One thing you may do is search the Web for information about the libraries involved, and read the READMEs. But those don’t give enough information. Sarah asked people what else they do. They look at recency and completeness of the docs, GitHub, StackOverflow, what people think of the maintainer of the library, what are people saying on forums… and so on. The way we collect and use this data is complicated. And most of the information is social rather than technical. One outlier was code analysis – how familiar does the code feel, how comfortable am I with it – you can summarise this by asking, how accessible is it.

Sarah took us through a four-quadrant analysis of the above findings. The quadrant had these poles: internal, external, project, people. She then had a go at applying the quadrant to a more complex problem: Deciding which JavaScript library to use.

We looked in particular at the code familiarity (accessibility) aspect to decide between AngularJS, Ember and Backbone. Accessibility falls into the internal/people section of Sarah’s quadrant. The feeling of accessibility depends on either what you’ve used before (such as Java) or what type of projects you’ve worked on. Everyone who develops a framework bases the design on their own bias. This is why a particular framework may or may not feel right for you.

Then you need to decide which of the quadrants is most important for you and your project. Is your team ready to move on to something new, or will they be better working on something similar to what they’ve used before? This will help you decide, for example, whether accessibility is an important factor for you.

An Internet for humans, too, by Dan Hon

Dan Hon is Content Director at Code for America. His role is making digital government easy to understand and easy to copy.

Looking back at the previous sessions of the day, Dan promised to break the pattern by adding some dissent to the mix.

Some of the best brand design is working out the emotional contact you want to make, and then making it. He showed us an add which he affectionately called “weaponised emotion”.

Dan is excited about the future, but also angry about the present. Over the last 40 years, computing and communication technology has become cheaper and faster. Now we’re talking about the Internet of Things. But at the same time, there’s a shift in the way Silicon Valley is developing technology and governments are legislating it. We’ve lost the human factor.

We should be building an Internet for humans. Dan is worried there’s a gap between how we build services and how they’re used. We need to understand this gap. It comes down to the need for an organisation to understand its audience. We need to empathise with what people are going through, and then use technology to make things better. In a possible dystopian future, inflexible software breaks the world. An example would be a car that refuses to start if you’re not up to date with your payments. What if you really need the car at this moment, to take a sick child to the doctor?

Dan discussed some recent technology products. This was a humorous and fairly ruthless look at current innovations. Some of them don’t “feel” quite right. Others don’t handle data well, in that they show data but don’t necessarily tell us what it means or what we should do with it.

Dan says it isn’t hard to design for people. It’s just a matter of empathising. It’s not new, and doesn’t rely on new technology. Dan gave some examples of good practice, such as Dropbox and Zappos for great customer service. Dan also thinks the UK’s Digital Government Services is providing great customer service as well as saving money. It turns out that when you do things properly, it saves money.

The future we wanted to grow up in, is where things work. To make that happen, we have to care about it and take the time to do things right. We need to do the user research. The more time designers and product owners spend with end users, the better the products get.

About the rest of day 1

I attended a few more sessions today, but haven’t blogged about them – chiefly because they were just before my own session so I was totally stressed out. 🙂

The opportunities to meet people and chat with old friends at Web Directions are great. We had morning tea, lunch, afternoon tea, and an opening party in the evening. The food was yummy and the people were awesome. I met a bunch of ex-colleagues from Atlassian. And tonight I’m attending the speakers’ dinner.

Best tweet of the day is from Mike Riethmuller:

So far the quality of speakers shoes has been awesome! Can’t wait till tomorrow. #wd14

Tomorrow I’ll be back for Web Directions South day 2, probably wearing the same shoes.

%d bloggers like this: