Web Directions South 2013 is done and dusted, as ever seeming to pass in a blur and be over in an instant.

Here are my notes, hammered out quickly for my own recall. The usual notes: they're done in a hurry, if you need exact quotes check the recordings later. Presume everything is a paraphrase rather than a quote. Jump menu is old school but hey it's a big post…

As has become our tradition, Rowen, Steve and I were often to be found huddled in the cold down in Siberia (the freezing area at the front, with the blankets):

Web Elders

Photo by Rowen Atkinson

Opening Credits

http://www.south.im/

Opening Keynote – Rachel Binx: People, Not Users

Rachel Binx

Photo by Rowen Atkinson

Slide of “Httpster” shirt – gotta love that. Rachel has just launched gifpop, a service that lets you create physical objects from animated gifs.

Rachel spends a lot of time on the internet – shows graphic of heirarchy of needs with a massive “internet” at the base - now spending times in spaces specifically designed for her (or feel like it)… so she will be talking about some spaces that work well and not so well.

Have to start with a mention of Facebook – it's simply massive… and Facebook's engineers/designers have made significant choices about how you can present yourself. Zuckerberg has said in an interview (“The Facebook Effect”) the days of having a different image for your work friends and your other friends are coming to an end… which is actually huge because it's not how we really work as humans. We tend to act differently in different contexts; and have different identities over the years as we change.

Compare our proscribed self vs our elastic self.

Think about the different ways you might present yourself to a room full of strangers… or even WDS itself, where you know what you are talking about so you might be more open, more confident. This might not translate to other areas of your life.

Facebook requires you to present a single, unified identity through time to all the people from different phases of your life. Your coworkers and childhood friends will see the same stream. This creates a pressure, consciously or not, to “fit” the new content you are posting in with the old, existing content. There's an expectation of consistency, regardless of whether you yourself are still the same.

Other services allow for multiple expressions of self – simply allowing you to have separate content for separate purposes. An Xiao compares facebook to “the small town you never left” and tumblr as a big city where you can go to a different bar every night and try out a different aspect of your personality.

Still other services allow for a more fluid, changing expression of self. Snapchat was originally just a 1-1, timebombed photo sharing service. When people asked for a “send all” option, the creators felt this was against the core idea of Snapchat. But they did put in “stories” which is a public 24-hour stream. This temporary profile broke the usual requirement to fit new content into the context of the old. Your identity, your profile, is fluid rather than fixed.

This quickly gets to the privacy debate. Zuckerberg has famously said “The age of privacy is over.” Which is interesting for a service that was very private for the first few years of its life; and has slowly turned into a sort of Whack A Mole game chasing privacy settings around.

Twitter… since IPO there has been a little more visibility about pushes (in the past) to open all twitter communications. One of the founders wanted to phase out direct/private messages and publicise everything. This idea has been reeled back in the run to IPO when it became clear there may be some value to having private messaging.

Http://sta.mn/9yd – a screenshot of someone's aunt asking for them to email the photos they'd shared on path… “I don't have a smartphone… can you email them to me?”

There are problems being open. Relationships can change: someone's “most contacted” data may include abusive ex-partners. It may be accurate according to data, but not a reflection of the relationships you now have. The past persists in data, in ways that don't help us.

Instrumentation was added to planes via mandate, because they avoided serious safety problems. But the instrumentation of the web does not necessarily have a positive effect for users. Staring at stats can dissociate people from other people – their users.

The digital duality…

Classic New Yorker cartoon – “on the internet nobody knows you are a dog”…

There's a lot of fear and uncertainty about whether we are making ourselves stupid, or anyway worse, by being online and using technology. It's easy to conclude that online is less valuable, or can't have a positive effect. But in truth our online and offline friendships influence each other, they build and change each other.

“Who remembers these?” - big screen of punctuation-only smileys, emoticons. Then we have emoji and even reaction gifs which can express extremes of emotion. Reaction gifs let people tell their friends exactly what kind of excited they are.

We eventually must arrive at….. the selfie. There's so much hate for selfies, but people certainly react to them! One of the creators of Vine had to be convinced that selfies weren't just vanity; that it was a personal way to share an experience. Also we shouldn't forget that humans are hardwired to respond to faces.

Then there's a fear that we are posting ever-smaller pieces of content; and that diminishes us and our attention spans. But the content we create for long or short form is usually for a different audience, with a different context.

There is different context on twitter vs. a long letter you might have written, or a long blog post that has to fill in all the context to make sense. Short form contexts like twitter are more like hanging out with a group of friends every day. You can refer to recent events without having to explicitly spell it all out again. The shorter messages are part of a broader set of information.

In general the form of communication may be changing, but what we're trying to say, what we're trying do remains the same. We want to share experiences with the people in our lives; and technology is just a way to share that faster and more easily. As bandwidth increases, so does the level of rich content that we can casually share.

Concept of third places – Ray Oldenburg.

  • First places are your home (private)

  • Second places are school/work (public)

  • Third places are the spaces in between like coffee shops, parks (where you can be with friends AND interact with strangers).

Often the use of third places has to evolve with the people using them – although you can put in a design, users will have their own ideas. This is how twitter ended up with at-replies and retweets.

Richard Serra created a piece “Tilted Arc” which bisected a public space and made it harder to use. It sparked a huge fight as it had effectively taken away a public space – although he argued art isn't meant to be pleasing, it had been taken out of a more private space (a gallery) and put into a public space that people wanted to continue using in a certain way. Parks, public spaces, have all been designed – someone made conscious decisions how they should be built.

We are the architects of online spaces. We need to make the world that we want to live in.

Andrew Betts: Making Web Apps As Smooth As Native

Wds13

Photo by Rowen Atkinson

In animation and effects, there is a concept of the Uncanny Valley, where something is so close to realistic it's bizarrely horrifying. This is a useful concept to apply to mobile applications which are trying to emulate native interactions.

Financial Times (FT) have been releasing content for a long time – newsprint was a highly effective mobile reading device!

Moving into the future we need to lose the constraints. Ipads are a technology solution that tries to emulate many other things within its own constraints.

FT use detection methods like identifying the presence of a mouse before adding hover-specific navigation aids.

FT have also discovered that people really like “native apps”, even when FT are just putting a thin wrapper on a web page. But in the end, because it was started with an icon and it was a polished experience, users thought it was native.

So, in a sense, “native” means “works really well”.

Three numbers to keep in mind:

  1. 16ms – this is the frame rate you must hit. After 16ms you get juddery animations.

  2. 100ms – this is the time the human brain requires to notice time passing. Anything which happens faster than 100ms will be perceived as “instant”

  3. Matching expectations – match what the user expects to happen.

These numbers are like a budget you spend.

Network. Whenever you hit the network there's lag that's 100ms+, which means the user perceives lag. So do all the known things - async everything, load scripts after onload, reduce http requests (sprites and concatenation).

[Sidenote - “I'm assuming everyone is doing that already” he said… in my experience people still aren't. They often use tools (blog tools, CMS, etc) which don't do it for them; but don't give them access to do it themselves.]

Beyond this, there are other sources of latency – radio has different power states, so sending requests at longer intervals hits low-power states, where the device has to warm back up. This is not only making things slow, it's using battery.

Solutions?

  • request batching – collect requests asynchronously; use callbacks per action and per group; process queues in the background

  • in theory https 2.0/SPDY will make this unnecessary; but it's not usable yet and doesn't handle CORS

  • there's also the W3C Beacon API

  • there will also always be a use case for delayed requests

Images

  • typically 70-95% of web page data

  • use accessible responsive images technique

  • when creating high and low resolution, try using high resolution images with high compression – this may give better filesize (JPG at least) for the smaller resolution as well (compared with compressing the smaller image separately)

Third party scripts (statistics, advertising)

  • you can really lose a lot of good work here – you can't stop them bringing more stuff down, polling with timers, etc

  • Two things to do: test your site before and after adding the third party scripts; and ask questions before you add a third party script

Andrew is creating a tool that evaluates third party scripts “3rd Party SLA”. Gives an easily-readable report on the impact of a script.

Prefetching

  • Each request has four phases; and we can do prefetching in each phase for the next

  • There are meta tags to help this – dns-prefetch, subresource, prefetch, prerender (Chrome only). This can create the appearance of instantaneous performance

Rendering

Chrome has the best tools for measuring rendering:

  • Timeline

    • This showed FT that old flexbox was really slow to render (100ms+ to lay out flexbox)

    • New flexbox however is really performant

    • Hover effects during scrolling are really expensive and create janky scrolling – so you can turn them off. Use JS to apply a body class and namespace your hover effects.

  • Framerates (activate in chrome://flags)

    • This identified an expensive combination of border-radius and box-shadow on a single element. This was within the layout boundary which is the area the browser has to re-layout when you change something.

    • You can create a new layout boundary and avoid the expensive relayout

    • See article by Wilson Page for more information about layout boundaries

Layout “thrashing” - when we make more DOM changes than we need.

  • Browser will batch writes for you; but if you read something (eg. A height) you force it to write as well.

  • So don't interleave reading and writing actions – do all the reads first, then all the writes after. This should greatly reduce the amount of hits on the DOM

  • What about asychronous DOM? Wilson's FastDOM library gives huge gains (15ms down to 2ms in the demo)

Images in the browser

  • Image decoding is probably the most expensive thing you ask the browser to do.

  • Don't load images on demand for mobiles – it kills the battery; and also if you lose signal you don't have the whole document. When you scroll down, you find the images are all just placeholders.

  • There's no browser API to load all images and not decode them? …there should be!

  • FT polyfill by downloading data URIs, they're encoded on the server, loaded via XHR, then inserted into <img> as a string to trigger decoding. This can fool the browser in funny ways though, you can lose browser-side optimisations. Use with care.

Hardware accelerated transforms

  • you need the GPU if you're going to animate a move, scale, filter, rotate

  • GPU-driven transforms don't need repainting to move things around

  • You can force webkit to put things into GPU with translateZ(0) hack

  • (measure with Timeline → Frames in chrome devtools)

Storing data

  • Native apps are good at storing data, because they have access to the file system. On the web we have a large range of not-very-good options. They're a dysfunctional family of options.

  • [Brilliant analogy, see the recording for this one :)]

  • So which do you use? Use the best storage backend for the kind of data you want to store. But it tends to be slow.

  • There is a new standard coming – currently named ServiceWorker, but it's had a lot of names. But it's a highly promising standard. It's like a server in the browser; takes a while to understand it but gives a great deal of flexibility.

Storage optimisation

  • There are slim pickings for HTML5, native apps have a lot of advantages here.

  • FT did some interesting tricks with encoding – packed ASCII into UTF-16. Very small JS to encode and decode which is very quick. This means you can store a lot of data in offline storage in a very size-efficient manner.

Click delay

  • More click, less delay.

  • New paradigms like double-tap to zoom required a delay to see if they were occurring. If you're just clicking, 300ms delay is annoying. So you can use something like Fastclick – noting very little of the library is removing the delay, the rest is adding back all the edge cases.

  • The 300ms delay, remember, is three times our “instant budget”.

Perception

  • Once you are done with things that make the app actually faster, you can start making it seem faster. You can trick the user's mind into the perception of speed where none really exists.

  • FT use different styles of progress bar depending on how well the request/download is actually happening. Different animations give the user a greater sensation of what's going on; when things aren't fast it looks more thrashy, when it has failed there's a retry button.

@triblondon, @ftlabs

Q&A

Q: has there been much actual research about real vs perceived performance?

A: they have done some research using classic A/B testing, the only way to test perception is with real users.

Q: to get that performance do they hand-code js, or use frameworks?

A: rather than big frameworks, they use smaller, more targeted tools. Website loads jQuery but only because the advertisers require it.

Q: how do you handle the OS specific paradigms in the UI?

A: it's really important, the expectations of users on different platforms do vary. They mostly deal with it by being intentionally different. This is a great way to avoid the uncanny valley. Rather than emulate the OS badly, do a different design very well. Sometimes, eg with scroll physics, they are very different so you choose a middle ground.

Q: does the fastclick library handle onclick events and so on for analytics?

A: Think so but don't know for sure. Unless it's detecing binding in an unusual way, it should work.

Q: how big is your team, and how do you get them to keep all this in mind?

A: They catch it in QA. Would love it if everything was performant from the start but it's not always possible; and performance is not always logical or obvious (eg. The flexbox problem). You write code that makes sense; then you test it; then you write fast code…

John Allsopp: Satisfying Movements – animation on the web

John Allsopp

Photo by Rowen Atkinson

Humans love things that move – we have a long history of commercial animation. There are suggestions that the earliest cave paintings were a kind of animation, as they appear to “move” when you move the light source around in the cave.

We've had animation on the web for a long time; from the crude early things like blink and marquee. We have some state in CSS; we have plenty of JS animation as well. There have been non-native animation sources as well, most obviously Flash.

Now we have CSS Transitions. This lets us avoid the instantaneous change between states, we can do a smooth transtion instead of a sudden, jarring change. We can specify which property to animate, with what duration and easing.

CSS Transitions respond to both DOM scripting and user changes like resizing the browser window.

However CSS animation can be confusing – not all properties can be animated. Non-length heights can't be animated (animating from 0 to auto doesn't work). This is particularly problematic because animating dimensions is a really common thing to do. So you can use max-height instead of height. Instead of height:auto you can set a max-height that is always going to be bigger than the element; then animation will work.

You can also delay animation – really common in slide decks… delay the slide-in effect of nth-child list items.

Transition cushioning/easing can make a massive difference to how credible or believable your animations are. There are aspects of skeuomorphism which are valuable – we've got rid of faux stitching, but animation is still about skeuomorphism. We are trying to make people feel something about the animation, so beware the uncanny valley…

Browser support? Most browsers don't even require the webkit prefix any more. Plus if the browser doesn't support animation, it's probably the worst device to be doing expensive polyfills.

Many shortcomings of web animation are alleviated with keyframes - @keyframes allow us to specify multi-step animations, animations that run for multiple iterations; and keyframes can be reused across elements.

Step one: specify animation using @keyframes rule. You give the animation a name; you specify the steps – at minimum the start 0% and end 100%; each step is a lot like a standard CSS statement (percentage instead of selector; uses brackets for familiar syntax).

@keyframes pulse {
  0% {
    box-shadow: 0 0 0 yellow;
  }
  100% {
    box-shadow: 0 0 12px yellow;
  }
}

Step two: apply the animation to elements using animation properties. By default, animations will only iterate once – then it will revert to the state it had beforehand. So you specify how many iterations. Because animations can be jarring, sometimes you want to alternate the direction so things don't pulse alarmingly – but keep in mind that it will get an extra “step” by reverting to original state. This is resolved with setting the fill mode – with the value of forwards the final properties persist after an animation (it stops and holds the animation, rather than reverting).

input:focus {
  animation-name: pulse;
  animation-duration: .7s;
  animation-iteration-count: infinite;
  animation-direction: alternate;
  animation-fill-mode: forwards;
}  

John's heuristics for non sucky web development

  • If it can be done in HTML, with no need for CSS or JavaScript, use HTML.

  • If it can be done with HTML+CSS, with no need for JavaScript, don't use JavaScript.

  • Never use jQuery.

(example with a carousel - “one of the most derided patterns…”)

When calculating animations, you need to work out durations so you can convert to % for keyframes. Remember animations start when the conditions of the selector are met.

Animations are constantly changing the DOM. Each time the left of the element changes, there's a reflow and repaint.

This is where transforms come in, as they allow us to rotate, scale and translate the element in 2 and 3 dimensions – but without such huge performance hits.

We apply these with the transform property, which takes one or more transform functions as its value. eg. 2D: translateX, translateY.. which work in terms of the top left corner of the element.

You measure this with Timeline → Events. Using transforms reduced John's example many orders of magnitude.

Scale: numbers from 0-1 reduce the size; numbers 1+ increase. You can change the way things ease in and out by working with transform-origin.

For 3D effects you need to be aware of the perspective – this sets the scene, and essentially works out how far or close the observer seems to be. This is how you do foreshortening effects. Commonly apply this to the <body>.

So is all this animation just a gimmick?

When we move to flat design, 3D allows us to add meaningful depth. That depth can be animated. This helps the user start to imagine a space where your application lives.

(example with iOS effect applied to a stack of iframes – by rotating each one slightly more, you get a fanned look; by transforming the Z axis you can make each look a bit smaller behind the next)

The last thing is the perspective-origin, which sets the viewer's point of view – where they are viewing the scene from.

[“I'm clearly excited about this stuff…” ← not sure what web stuff John is not excited about? :)]

For a great animation 101: do a bouncing ball. It's the hello world of animation.

What's next? Explore, create! Remember animation is the new typography… don't use Comic Sans!

Don't use animation as a gimmick. Think about how can create meaningful transitions.

Pasquale D'Silva: Stiff and Static Sucks

Great summary of animation from @pasql at #wds13

Photo by Mike Sharp

There's a specific type of language animators use when they talk about animation. They talk about cushioning, anticipation, anvils… engineers talk differently. Pasquale wrote an article about this to bridge the communication divide (now shared on medium.com: https://medium.com/design-ux/926eb80d64e3).

There's an argument that animation takes up valuable time to implement… well yes, but it has a huge impact. It also takes time out of the users' day to observe it… but it also takes time for a person's brain to deal with abrupt changes in UI, which can be smoothed out with good animation.

Good animation is invisible.

Too much change in the UI can leave the user disoriented. Animation is a clue to why information is flowing and how it is connected. It's designing with the fourth dimention – time. Our old mentality is having screen after screen – but going between these is jarring. It's weird that this jarring experience is the baseline. We're emotional beings, we're not robots…

Reference: “From Cartoons to the User Interface” (missed author). Much thought goes into details, but not enough about the transition between them.

Animation is not new – it is in fact centuries old. We do not need to reinvent or rediscover animation, we can learn from what has gone before.

Demonstration of the bird+cage 2-frame animtation – our brains combine the information to make sense of it.

There are very few things in real life that happen instantly – not even balloons popping or lights turning on are actually instant. Some time passes during the event. If you make a UI transition instantly, it feels weird.

[Plays Back in Black as a transition! Feel like I'm watching Rockwiz… :D]

Animations don't need to be long or over the top, just enough motion to give you the idea what's happening and why. Ease in quickly, only emphasise the idea that it's about to go back out. Demo shows a modal that eases in, but the title bobs up then down before easing out. When a stream updates, injecting the new content pushes the old down before zooming quickly in.

Optimisations – you don't have to slide things all the way to the middle from the bottom, you can slide from 2/3 down, or just bounce it in, or flip it over like a card.

You can go crazy and abuse animation – keep the crazy stuff for unsual moments like a congratulation screen. Keep the rest of the animation subtle, unintrusive.

IOS7 got a lot flatter, but also brought in animation. Although many of the animations are too long, most could have their duraction sliced in half without losing their impact.

Real examples… (bad)

Twitter revealing an image has no transition and you actually see the image pop in. Even adding a spinner helps. Revealing new tweets has no transition at all, even a simple fade would help.

Facebook stream – opening a video is really glitchy, nasty. Adding a few frames of transition softens the blow of the modal. Some things including the Like button demonstrate an awareness of animation, but it's not consistent.

Evernote app – uses a right-pointing arrow, but then zips the content up from the bottom. The animation doesn't match the expectation set by the affordance.

Real examples… (good)

Will Call app for booking tickets – the animation has a good character, good consistency.

Letterpress, Path, Tumblr, etc – all do well with animation.

Designing with animation

Often helps to break out a specific element to work on it, to cut it down to a single interaction to see if it makes sense. Also Pasquale uses animated comps to inspire engineers to want to work on stuff – better than 2d mockups which aren't as enticing.

Traditionally we have designed interfaces with linear states and no care taken about moving between the states. Inbetweens help – we ask how does the app transition from State A to State B?

In animation, states A and B are the “extremes”. They are the poses with most contrast in the animation.

Demonstration: automated tweening of an arm waving seems totally unnatural with linear easing, which means all the tween states are evenly spaced between A and B. By moving the middle tween state closer to A or B you get different effects – in CSS terms, ease out and ease in.

By breaking up the arm into three separate shapes and having them move separately, you get a toy-story-esque floppy armed wave.

Pasquale spent hours on end as a kid looking at cartoons frame by frame - “drove my parents crazy!” He learned a heap about how animation worked.

Reference: Disney's 12 points of animation. Including anticipation, which prepares you for a bigger action… etc. Worth looking up the full list!

Youtube: back story of how the animations for Tarzan was done, studying animal movements to apply to Tarzan. They got into deep detail about anatomy – particularly musculature.

Take aways:

  • Static interfaces suck - “you can argue if you want, but you'll lose…”

  • Animation is a clue – it's meaningful, it can describe context

  • Great animation feels invisible

  • Learn from the classics – the principles apply to all animation, we don't need to reinvent the wheel

Q&A

Q: do you have any suggestions on how to convey information between devs and designers?

A: the tools to pass that along really suck right now… best way is to do animated prototypes, someone can do something in After Effects really fast, that would take a long time to build out for the web. Most times using videos for composition will be better than flat images. Nothing will replace sitting together and working on it. The animator has responsibility, they shouldn't just throw things over the fence and hope for the best.

Q: where would you start if you want to learn animation?

A: Learn After Effects, learn linear animation packages. Quartz Composer is really too hard to learn, don't start there… You need to be working in a visual tool. You could also try things with lower learning curves like Adobe Edge. Learn to make a ball bounce. It's really hard. It is the first thing a senior animator would give a junior.

Q: if you do put your first motion composition, where would you seek feedback?

A: that's another tough thing, not a lot of animators have crossed over into design; and a bouncing ball isn't so fun to critique. So there's not a whole lot of community around animation. Tried to create this but it's still baby steps, it's going to take time for that to come together.

Reference: Animator's Survival Kit.

Ryan Seddon: Flexbox

Kicks off with the classic “CSS is awesome” stab… where it breaks out of the box.

(cool demo, hopefully shared later…)

Flex-basis – essentially min width

“Before you get too excited…” there are three implementations!

  1. legacy, circa 2009

  2. Tweener – only shipped in IE10

  3. New version

You will almost certainly want to use a preprocessor for this. IE9 and down just don't work. But all others do have an implementation.

Pro tip: use modernizr to know which version of flexbox you have available.

There are preprocessor plugins that call out to caniuse.com for their prefixing data.

ZOMG!

.zomg {
  display: flex;
  align-items: center;
  justify-content: center;
}  

It only took 20 years for a nice solution to vertical and horizontal centring…

You can control the ordering of layout using the “order” property, that is to change which order the content will be read out in AT, etc.

“You're not alone… flexbox is hard to remember.” You need to play around with it, slowly learn the pieces.

Pro tip 2: flexbox lends itself to small modules, eg. OOCSS Media Object. Still use floats etc where they make sense. Don't use flexbox for the sake of it.

Slides: http://ryanseddon.github.io/flexbox-wds13

Live code demo: http://codepen.io/ryanseddon/pen/kjonw

Fiona Chan: Maintainable CSS

A cooking lesson on tasty CSS from @mobywhale at #wds13

Photo by Mike Sharp

Going to talk about how not to end up with spaghetti code.

“A small part of me dies every time I have to write !important just to get something to work.”

Process:

  1. Build the simple components first, because the more complex ones are made up of the simple ones. Fiona's base component is .box, a box of content.

  2. Naming your component. Naming is hard! Don't tie the class to the content, do presume you'll reuse the component. So name things in the abstract - “feature” rather than “breaking news”. But not box1, box2 as that's too hard to remember. Find the middle ground.

  3. Components should just work. Example is .clearfix so that boxes with floated elements clear as expected. Can be injected into your base classes using preprocessors, rather than using an actual class in the DOM. Uses placeholders and extend. But, there's the caveat not to over-use the powerful features of preprocessors.

  4. Namespacing – prefix classnames to give them a scope. This avoids clashes. Just because you CAN nest in SASS, doesn't mean you automatically should.

  5. Communication – set a code standard. It must be written down, communicated across the team, ensure new starters know about it. Make this a living style guide – use real code to document your design requirements and implementation.

  6. Collaboration – designers and devs need to work together to get the greatest value, work out where there is unnecessary repetition and remove it.

Jared Wyles: Drawing shapes with CSS

Here we go! @rioter talking about CSS… #wds13

Photo by Mike Sharp

“I don't do CSS, I hate it…”

Text on the web – it's always been there, it's always been pretty bad. It's embarrassing that printing presses were outperforming the web for so very long.

While typefaces are now in a good state thanks to font face, it's hard to make good looking content because layouts are quite blunt. Print from 1950 still outperforms us.

Adobe have brought in a new idea: CSS Regions. This lets text flow into or out of an element. What's exciting is the JS API that lets you detect the existence of overflowing elements.

document.getNamedFlows()['beer']

You set up regions, so when the content no longer fits in the first region, it overflows into the next specified region, etc. You can control when and how this happens. You can get content from elements entirely outside your layout elements.

Browser support is still pretty short…

Not only but also, you can draw non-rectangle polygons with -webkit-shape-inside: polygon() - you pass in coordinates for the points. You end up doing oldschool polygon tricks like using lots of triangles to make circles.

(Very cool demo of text flowing through a detailed Alice In Wonderland background image.)

Closing keynote – Maciej Ceglowski: Barely Succeed

Web Directions South 2013

Photo by Dushan Hanuska

“I want to warn you that this is going to be an incredibly inspirational talk…”

(there is no way to do justice to this intro, check out the recording…)

Discussing the value of culture – it's reasonable to think not just about what you are building, but the community you want to see using it, the culture you want to form around it. Visualising that is important and interesting. Science fiction gave us visions of the future – not that they mostly came true…

Things could be better than they are in tech culture. People could be making greater things and having more fun doing it.

“I face a handicap being a motivational speaker. I am a Slav… we believe the world is a place of heartache and pain…” and for this reason, he talks about Barely Succeeding. Find success within your mildest dreams. (not a typo!)

Startup culture is not in a good place… there's a focus on a domination dream, wanting to take over hugely. Empire building. Compare this with a more modest view…

In tech culture it's incredibly easy to have a rich and exciting career that doesn't really leave any meaningful work behind. It's a depressing thought that perhaps your work didn't help the world.

So now the rant about startups. Standard Model of Startups…

Classical version – two young men (of course) meet and make something awesome, they make money from venture capital to grow. They get more people. They get more VC. Then finally they go IPO and the Glorious Exit Event occurs.

Then there's an angel investment model that gets you through the no-revenue phase; or the incubator model… At the end the glorious event is being acquired by another company, where you live for a few years post acqui-hire before you are released back into the market.

Web Directions South 2013

Photo by Dushan Hanuska

The system does not worry about revenue, it worries about users – but only as eyeballs, market share. Actually getting revenue is considered a little gauche.

Sexism in the industry is less hate-based and more like a culture of wilful cluelessness. Simply not knowing how to deal with women. Why is it even a question why would Marissa Meyer do a fashion photoshoot? This doesn't even come up for men at all. If a male was asked to do a fashion shoot, would they be asked to explain 'what it means for men in tech'? (very hard to summarise this section, please refer to full video if you want a proper quote)

Startups also tend to exult in their ability to kill off dinosaur business models like music and publishing, while using the same business model themselves. The creativity doesn't seem to extend to ways to run a business.

There's a strange concept of a “lifestyle business” - as though anything that won't result in a large empire is too small to be worth it. Why isn't it ok to run a small, successful business?

Not everything needs to be free. If you ask for money, you maybe have a chance to keep doing it indefinitely. If you ask for money and get a lot of users, you make a lot of money. If you don't ask for money and you get a huge increase in users, you're losing a lot of money.

Low hanging fruit? While the overall industry is in trouble, publishing has changed so much it's opened up to people who didn't have the money to get involved before. Odd little publications like “We Were Crewdogs” can be sold for $2 because the overheads are gone.

The internet is somewhere we're going to be for a long time yet. We should treat it that way. We should make it a nice place to be and to work.

(end of day one)

Second Day Keynote – Scott Jenson: Beyond Mobile, Beyond Web

Scott Jensen

Photo by Rowen Atkinson

Although we have a complex situation with devices (mobiles), the cloud, apps, companies that run them all… We still think about human<->device and don't go beyond that.

There's a relationship triangle between user – device – cloud.

We need to remember “smart devices” can be barely smart. People laugh about the idea of a smart toaster… but what if every device broadcast a URL? Suddenly you have a link to all the information about that make and model of toaster, you have access to support for that toaster… We need to realised how valuable simple things are.

If you go up from the $1 chip to broadcast a URL to $5 for control chips, you can start doing fun things like set your phone to play a fun sound when the toast is ready (“it can play spongbob squarepants for my niece!”).

This gives several types of smart device:

  Direct Background
Swarm Direct swarm: Sensor based things like carpark space indictators, smart lights, iBeacon Background swarm: all the devices working together – smart light bulbs that do different things at different times of the day.
Device Direct device: everything we know… phones, consoles… Background device: Lavatron, Nest – devices that sit on your door handle and let you in without a key. Lavatron does this with bluetooth proximity. Nest only becomes a background device over time.

The main idea here is to have a vocabulary to discuss the modality of devices and how they move between them. There will be user flows that cross over these modes over time or even during a single interaction if it's a complex enough process.

Interesting questions arise with devices that have no screen – not to mention the complexity that may occur once a single app or page can be used on multiple screens at once… Also ponder the limit of how many apps we can install, how many single-purpose devices we can manage, how many things we can even do everything manually (or with user input to install an app).

Why mobile apps must die? I just wanted another alternative. People can't be bothered any more – you put a sign in your store “we're in the app store!” - people just can't be bothered.

Fundamental rule of UX design: Value > Pain

There has to be more value than pain. You can increase value or decrease pain.

“As a designer, my life is pain. I am a pain reducer.”

Curiously if pain goes down fast enough, value can come down too and yet you still have a successful product. When Google was only on the desktop you used it for important research, now it's in your pocket you use it for pub trivia arguments.

We've seen this before. Yahoo's directory model didn't scale, Google killed it. The mobile app model doesn't scale, something will kill it. “How many people have removed old apps from their phone? Trick question! We all do. We are gardening our phones!”

The web is amazing… but we have attached a command-line interface to the top of it. We type stuff into it. We don't take advantage of all the sensors in the phone the way apps are doing. The browser should be handling this stuff!

Just In Time (JIT) ecosystem: lots of barely-smart devices broadcasting simple information (a URL) and other smarter devices doing stuff with that.

“The cloud is a complete myth. There are cloudS and they are cranky and don't like each other.”

Every company sets up their own cloud for every device. But users want their data to be in one place, especially data like personal health data.

There's not going to be a single killer device, the killer app is going to be a meta app: reasoning over combined data.

Some companies are thinking about this – they're trying to open up services to collate data. (Spark, PersonalCloud, OwnCloud, Cosm)

People say this can never happen. But if we don't know what we want we can never move towards it.

Some examples… we forget it took ten years between Netscape and Gmail. Things take time. We forget how crap the web used to be! We need to think a little longer term.

We forget that in the very early days, the walled gardens like AOL were providing a better experience – until the open web blew them away. If we are seeing proprietary devices now, it's probably just the early days…

Two types of idea:

  • Truck Idea (single businesses)

  • Road Idea (infrastructure)

Malcolm McLean invented the shipping container, which vastly reduced costs and changed shipping forever – then gave it away to ISO, he did end up making a lot of money but not by holding on to a great idea… it was a rising tide that lifted all boats.

If we don't know what we want, that's what we'll get. We need to have a vision for the future and work towards it.

Relly Annett-Baker: Creating Content For An Imperfect Web

RAOM0548

Photo by Rowen Atkinson

Future Perfect Tense: the state of something from the past as viewed from the future.

  • Future tense: in the future, you move to London.

  • Future perfect tense: you will have forgotten me.

Reference: the Winchester Mystery House – house built with no real plan, by the widow of the gun magnate William Winchester. She wanted a house that would trap ghosts (because she didn't want to be “got” by the ghosts of people who were killed with Winchester guns). She would simply shut off rooms that she felt had ghosts in them – to trap them – and just make new rooms.

“This, ladies and gentlemen, is the average website.” Then we looked at our sites on phones…….and they were shit. Then we started looking at a 1 inch phone and a 50 inch tv as well…

Tumblr: Fuck Yeah Internet Fridge!

If we did everything according to predictions, we'd have been making apps for our internet fridge.

Why is the internet fridge so funny? As Tom Coates put it – who buys an internet fridge and doesn't already own a tablet? Nobody says “I've got an ipad but i'd rather listen to music on my fridge!”.

Content creators know our tools, our processes are not ready for the future where we have very cheap computers in our pockets. People are paralysed with fear of how to create the perfect website on a phone. At some point they will have to stop referring to “the mobile web” as it is simply the web we access.

Content creators are feeling future perfect tense:

  • What is coming?

  • How can we reduce duplication of effort?

  • How can we create content for it?

  • Should we be making native apps?

  • Should we have a mobile team? Well no! Having a separate mobile team is forking. It's painful. You don't have separate desktop and tablet teams. Don't make this temporary focus a permanently entrenched thing.

  • Won't new content cost us money? Well yes, people don't work for free.

  • Isn't mobile where all the money is right now?

  • Can't we just tell everyone to use the desktop site?!! - “I wish I could say I didn't get asked this…” No. You don't get to make that decision. People access the web with whatever is easiest and what they have to hand.

Lego is a smart structural system made to be infinitely flexible. Every piece of lego must fit every piece of lego ever made and every piece that will ever be made. Each piece is a discrete entity that combines. This is what our content needs to do if it is going to travel everywhere. We need to understand this and structure our CMS like this.

How will do this? We need to change…

  • The concept of content

  • The tools we use

  • The way we work

Content is not a black hole that you keep throwing money into to keep the content relevant. You can have a content plan. You know what happens to you and when; and if you have a good process for dealing with that you are also more prepared to deal with the unexpected.

Reference: orbital content article on a list apart

Let's talk about the smartphone myth: the idea that everyone using a mobile is on the go. Actually Relly is more likely to be using her phone on the couch to hit IMDb to look up where she's seen an actor before. This brings in the idea of the second screen… but even then, people presume the phone is the second screen, not the primary device.

People don't want lower fidelity information just because they're using a phone. A cancer patient looking up information about cancer has every right to be using a mobile to do it. It may also be an intensely private, emotional journey they don't want to share – so they're using their most personal device.

As people go through the journey of cancer treatments, they become hyper learners – they still don't care which device they're using. The cancer council of a america(?) felt it was a life-saving imperative to have all their content accessible, not stuck in PDFs that wouldn't load on some devices. It's a big deal.

Moving on…

Shouldn't we have a separate site? Forking your site should be a dirty word, certainly for content. Ideally, no! Don't do that. Pragmatically, if you have to – use it as an excuse to sort out all your content. Don't sweep the terrible content under the carpet, don't just show the nice bits you've cherry picked.

Link: Tom Coates “network enabled objects” on Pinterest; also the House of Coates, his house that tweets.

Book: Content Strategy for Mobile (A Book Apart)

There is an idea to put video playback onto a stovetop. Which sounds a bit odd, but it's actually where you probably need the information. You're not looking at the fridge while you cook. It is at least a bit less funny than the internet fridge…

Book: Content Everywhere, Sara Wachter-Boettcher

Concept of content:

  • Create structure – think about the possibilities now. You have a headline – you probably need a short, medium and long one. Do it now/up front.

  • Chunk not blob – make reusable chunks of content, not big amorphous blobs of content

  • Build in flexibility – back in the 50s the american TV guide created a database of short, medium and long reviews of movies; even though they were only publishing a magazine at the time. That data was later sold for much more than the magazine and the data is still used today.

  • Do the hard work now

  • Be platform agnostic – sometimes native is the answer… have content structured in a flexible way that will cope with the different requirements

CMSs… oh I hate them. Best is Perch because it doesn't do WYSIWYG.

WYSIWTF! WYSIWYG sucks. It encourages blobs, it encourages separation of responsibility, it decouples content from the development and design process.

Beware the preview! Most CMS editing systems will preview in the desktop site. Perhaps multiple previews would be the answer, showing different screen sizes – but almost none of the current CMS options out there are set up for this though. CMSs are the corporate system that UX forgot.

Inline editing is also not the answer. It further entrenches the idea that what you are creating today is all you will ever create. About the only time to use this is during “correct a typo” level of editing.

Tools:

  • true separation of form and content

  • writing tools need to be designed for writing, not styling (rich text editors tend to suggest you are editing a printing page)

  • re-education about what our tools need to do

  • Pixel by pixel control is not the answer

“If Google Docs is the best collaboration tool you have…. we need better tools.”

Markdown would be better than WYSIWYG. CMS makers need to drop WYSIWYG. CMS makers need to give better previews. CMS makers need to make proper writing tools with good UX.

“Stop making shitty MS Word ripoffs. MS Word was pretty shitty to start with.”

Relly: I know this is hard. But we should aim towards it.

“As a content strategist, what I most am is a counsellor.” Relly goes in when the tools aren't working, the content is in a bad state, they're not having a good time.

There is an assumption that training will trickle down through a whole company; and everyone can magically create fantastic content. People don't do a day's training in the new CMS and suddenly change what they've been doing for years.

This means multi-disciplinary teams are the way to go. Content creators together with designers with developers. That's what a web team means now.

There is no “make it easy” button. But you are smart people, you are all here… you can be the people who do this stuff.

Use cases can guide people through this – include content creators as users.

Being the advocate:

  • This stuff is hard – people need supporters

  • Understand the reasons for change

  • Understand the practicalities of change

  • Understand that you won't do this overnight. But it is the direction of travel.

  • Be the person who says “i can help you with this”

We don't know what the next device will be. But we can create fluid content that can adapt to the next thing.

Aarron Walter: Connected UX

The tools get us there, but it's connecting people that's important.

During the rebuild of Mailchimp they were doing a lot of “shooting from the hip” - guessing, really. So they started doing more UX stuff – interviews, testing (low fi, no fancy lab), collecting customer feedback (not always actionable, but it helped understand where the customers were coming from), using analytics to see what people were doing.

Suddenly they went from no data to data overload. They'd learn something then lose it - “we'd get smarter, then get dumber”. They'd learn something about a specific interaction or feature, then forget they'd done it because there was so much information to keep track of.

Aarron started seeing repetition of effort as they simply lost track of the information.

He noticed a pattern, shown as a pyramid: from all the raw data → some information → distilled to knowledge → but only rarely resulting in wisdom. Seeing the connections, understanding why something is happening and what will happen in future as a result. This is where strategy comes from, rather than living purely in tactics.

We need connections. We have research down to a science – we're good at studying people, fixing specific problems. But we don't connect the information very well.

Crisis point: Aarron's inbox was buried in user feedback emails. It just didn't stop. He talked to Merlin Mann about how to manage the information. He said “burn it! If you can't process it, it's not useful, not valuable.”

But rather than truly stop, he decided to get the information stored somewhere – at least get it out of the inbox. So he funnelled the starred emails into Evernote – starred being the ones worthy of later action. He got it down to a few hundred pieces of information, all with an attached email address.

Later on, he needed feedback about RSS. This returned a set small enough to make sense of it. He found some patterns. He was able to get further feedback from a small group; and they shipped a solution the following week to great reception.

The data can also determine what you are not going to do. They had a thought there might be a trend about a certain feature; but when they dug into the info, in several months they'd had just 11 mentions of it. It wasn't a big problem and not really worth the investment, compared with other potential work.

With all the information coming in, they created streams. There'd be a stream of social content, a stream of user feedback, account closing surveys, competitor news, delivery statistics, release notes (documentation of changes – they knew what they changed and when) and so on. Then they could start doing automated reports with the data.

They kept adding more streams – Tweets (positive and negative), surveys, screenshots of reports (making use of Everynote's OCR).

It all streamed into a huge bucket of searchable stuff. Searching would reveal connections across silos of information. Gigs of data. This also created a sense of shared ownership – it stopped being just the UX team's job to look at the data, everyone was involved.

You've got to have data for everyone and everyone's data.

This is a big win. It also has big political and collaborative implications. People can see what other people are doing and how it's relevant for them – and they started sharing ideas and asking if the other team had thought about this other thing?

They started having data nerd lunches – cross-discipline groups exchanging ideas and information. Once this became a habit, everyone wanted to join in. They started connecting the data and eventually managed to connect people.

There are many tools that can do this. For Mailchimp, email was the API. Low barrier to entry, very easy to start sharing information. No additional workflow. This meant even non-developers could very easily contribute – designers, accountants… everyone.

Principle: the information has to be Easy In, Easy Out. If it's not easy people won't take part.

Since the data is largely unstructured, it helps to add tagging. Their email API includes a way to add hashtags in the subject line, to help reveal the less obvious connections. That allows people to browse quite specific topics.

Process is simple:

  1. search for something… take all the information you find (example showing the mix of content, looking for Android information – feedback emails, long customer emails, related tweets and articles, statistics from surveys, browser analytics. Lots of disconnected information come together to give a picture of how people are using Android.)

  2. stage: put the information together in a more structured format to work on it

  3. collaborate on the work

  4. produce a strategy

This is great for known searches – where you know what you need to ask. How about unknown searches? Where you aren't quite sure what it is you need to be asking?

Having the data available across lots of devices helped get a good feel for the information coming in. It's passive learning, eg. Seeing a coworker contribute a set of notes on a specific topic and you go read it too.

They ended up creating personas; and putting posters up in common spaces so people knew the personas. That led to people around the company getting used to applying the personas; and then eventually people started tagging information in the database according to which persona it applied to.

Data does not transform itself into wisdom. Wisdom comes from turning the information into stories, which can be shared with the team. To get information out of dry reports, they created short videos that could be IMed to other people at Mailchimp. Showing the experience helped avoid doing a large number of mockups, as people understood the overall direction.

The real power of connecting to all these people? One of Mailchimp's designers was able to get information about the question he was trying to answer (“how do customers measure success”). He didn't have to do new research, the information was already there. He was able to get a ranked list of success factors, which informed the work he was doing.

This takes designers from decorators to problem solvers, which is better for everyone. By using data, you can make good decisions about what to work on and how to solve that problem. This leads to wisdom.

We have heaps of information being left on the table. How could you make this data accessible? How can you connect the data with other information you have? How do you connect people so they can collaborate and make things in a better way.

Connected UX leads to a culture of inquiry. When people know they can ask crazy questions and get answers, they ask more questions and they use more real information in their work. This is valuable for all teams across your company.

Q&A

Q: did you hit any barriers while setting up this system? “who will work on this, who will be the gatekeeper?”

A: they did while they were trying different apps, just so someone would be responsible for each of the options. That fell apart quite quickly because other people stopped contributing to “their project”. Evernote was the MacGuyver way to do things – it was quick and easy to add things, it was easy to start participating.

Q: at what point are you drawing the line about what information you will and won't store?

A: we have an understanding of junk in, junk out – when they found things that weren't valuable, they would push it out and try to keep it out of the database. The teams know what's valuable to contribute.

Alexandra Deschamps-Sonsino: designing the internet of things

Web Directions South 2013

Photo by Dushan Hanuska

“Recalculating – how to design the internet of things from the user and up and from data down.”

We are still in the wild west phase of the internet of things – there is a lot of experimentation going on, but there are still mistakes being made. Both in a practical sense of accidentally revealing data and in the broader sense of anticipating the things people want from and do with connected devices.

Slide: James Bridle's “the cloud is a lie”

With the advent of things like Arduino, it's become fast and cheap to create a device that can bridge the physical and digital. In 20 minutes you can make a button in the world that talks to a web server; and vice versa.

The idea of an internet of things includes not only the exciting, bigger things but the boring everyday things. Sensors in your pot plants…

(Run through of lots of connected items, from the Nabaztag to Nest; connected umbrellas and bathroom scales…)

When you start collecting information from personal items in the home, you have to become aware and concerned with privacy. There can be strange results – a connected set of bathroom scales can reveal the fact you're losing weight. It could market diet products to you; or could be used for nastier purposes – people might realise you are too light and slim to resist a home invasion. It's simply a good idea to protect this data and know where it is.

If the data is less personal, coming from a public space, you will want some say in how the data is handled. It becomes a community issue rather than a specifically personal issue. For example in china there are connected devices monitoring air quality; and parents want to know the air quality in schools.

In Japan there is a group of people publishing radiation information from around Fukushima – they bought their own geiger counters and published the information. They forced the government to admit the official data was being inaccurately taken and improperly published. The access to technology has a major impact on politics and society.

When you have devices publishing information, you should have the right to remain anonymous; and to control the way it's published (at all). There should be some granularity.

Open: accessible, transparent, findable. The internet of things has a lot of open aspects – communities, hardware, etc.

You can use chips, dev boards (eg. Arduino), cloud (eg. Ifttt), apps, existing products.

Why get involved? It's accessible, particularly with crowd funding. You can go from proof concept to shipping a product in six months – which is short compared with years, as it was in the past.

Downsides? It is more expensive to build physical things than it is to build websites; it takes new skills; it takes longer and geography matters (it's hard to deal with people in other countries).

However it is exciting. Making things is exciting; people get it; design is key and web thinking is essential – we need people who know how to handle data.

http://designswarm.com/blog/2013/10/web-directions-2013/

Q&A

Q: what are the particular challenges in making a new product via kickstarter?

A: It's a little hard in a way because there are the massive success stories. 90% of the projects funded on kickstarter are for lower costs – around $10k. However if you do well on kickstarter, bigger investors get more interested. They love it if you can demonstrate interest, willingness for people to actually pay for things. So kickstarter can be a marketing tool rather than the full funding source. Alex raised around 49k pounds in January (a difficult time to raise money) out of a 300k target. It has come up in every funding meeting since, but it did get some buzz.

Q: can you imagine us needing to have DRM (or some form of control) over our personal data?

A: there are some questions about potentially even selling or trading that data in a market. It hasn't been solved yet but it will become increasingly relevant.

Q: have you come across ninja blocks? Any thoughts?

A: yes… (jokes that someone must be in the room). I don't think anyone's really competing, everyone's going for something a little different. Some are very much educational and so on.

(mention of Melbourne-based Freetronics, working on building open-source hardware)

Q: a lot of Raspberry Pi projects seem to be thinking a little small… do you have any bigger examples, cooler examples?

A: Someone sent a Pi into space as a project with their daughter… There was a belt for pregnant women that tweets whenever the baby kicks (great as a way for their partner to share the experience in a new way). The Raspberry Pi is great even just for the attention is has gained… they are manufactured in Wales piggybacking on Sony's manufacturing facilities. There is a slight barrier for kids to use them as they do require you to use linux; but that's probably not going to be a barrier for long. Many people are using Pis as a media centre in the home, since that's obvious if you know linux.

Q: throw to Microsoft to mention a competition for kids…

A: (Lachlan) last year's winners were some RMIT students who built a stethoscope which plugged into the smartphone, so it would go on the phone rather than just being relayed. It ends up costing about $20 to make them, but a digital stethoscope costs about $800. They also did some awesome software stuff as well, so the app could then detect pneumonia – the UI walked the user through the procedure and tried to directly detect things.

Golden Krishna: No UI

There's so much to celebrate about technology, but there's a terrible trend in tech today… we're riding a wave that's taking us away from solving peoples' problems.

When we created computers, we made people use the CLI. But then we got the GUI. Then we got touch UI.

So now… how do you design a better (car|vending machine|toilet)? You whack an interface on it. Use a whole touchscreen device where you used to have a button.

We are surrounded by screens. We used to be surrounded by paper and dreaming of a paperless world. We should dream of a screenless world.

Principles:

  1. Embrace typical processes instead of screens

    • is it really better to use a smartphone to open your car? Key vs. BMW app. A long process of opening up a phone, closing other apps, finding the right app, using a weird UI… (see slides for the full walkthrough). The real goal was the physically present human opening the door – which you can do in two steps with a physical key.

    • Meanwhile Mercedes did it differently: if your key was nearby, the car door would simply open. This also meant you couldn't lock the keys in the car.

    • Ford realised people carrying things to the boot of a car have their hands full, so they put in a foot/kick activation to open the boot.

  2. Leverage computers instead of catering to them

    • We memorise passwords and do things the computer requires. But we do that because it's how we treat computers, how we expect them to behave.

    • (great example of a headlamp by Petzl, which senses the difference between looking ahead and looking down at a map, when you need the map to be dimmed. No extra interface added.)

  3. Create a system that adapts to individuals

    • Nest initially looks like a device with a UI slapped on it, but it learns – so after a while you don't need to interact with it at all.

    • Normal hospital machines are reactive – they report what has already happened. EarlySense detects normal data like heartbeat etc; but it learns your patterns and identifies changes in patterns well before things become a major problem.

There has been a lot of interesting discourse about No UI since it was published.

We are used to lots of automated things – doors, airbags, the auto transmission. It's impressive that people accept auto transmissions, a very dangerous time and place for automation.

Some advanced No UI devices will have a standard UI as a backup.

What about the web? Services like Tripit and Pandora are trying to learn enough that you don't need to interact with it for it to work.

How do you really do this?

Ran an exercise with a group of people who hadn't met each other before:

  1. Embrance typical processes instead of screens → observe the job the person is doing

  2. Leverage computers instead of catering to them → work out what sensors and data sources are available

  3. Create a system that adapts to individuals

Some results:

  • One kind of crazy idea was to use a scent in the room to remind people to take their medication. Unusual, but probably still better than a UI on a computer.

  • Running shoes wear out when the shoe compresses. There are various trackers that attempt to work out if your shoes are worn out. Someone thought of having dye in the sole that turns them red when they are too worn.

You can download the worksheet from nointerface.com

There's so much to celebrate about technology, but there's a terrible trend in tech today… hopefully this has given some ideas on how to do something better.

Q&A

Q: Once you move into automation – how do you handle responsibility, accountability for failures and problems? There are cases of cruise control malfunctioning and making cars accelerate, etc.

A: You have to be transparent when you are creating new technology… a lot of this relies on data tracking and understanding the users. You have to be transparent about what you are tracking, how you are doing it and give them a way to shut it off. New technology can always be scary if used the wrong way.

Q: can you mention any of the work you do at Samsung?

A: …uh, no. :)

http://www.cooper.com/journal/2012/08/the-best-interface-is-no-interface

Slides at nointerface.com

Closing keynote - Heather Gold: Nerd, Know Thyself

@heathr brightens up the final slot at #wds13

Photo by Mike Sharp

Talking about emotions… problems we have in their working lives…

A common problem on the web: projects which believe they will magically build a community around a product – we want passion, engagement, people to care… but this is very hard if you don't care yourself.

We are full, emotional people in our personal lives but we go to work and try to switch it off and be emotionless work machines. Then we try to appeal to people on a human level.

We get UX people talking about “empathy for users”… but how much empathy do you have for yourself? How can you really feel empathy for other people if you don't feel this for yourself?

Heather's job as a comedian includes spending a lot of time trying to be funny while including the audience; and reading faces for feedback, to see how people are feeling.

Developers tend to work with inanimate things – code doesn't get angry with you. It doesn't have feelings to read. People are harder to deal with than code.

(Session was largely interactive, quite hard to transcribe)

http://www.heathergold.com

(end of day two)

Future directions…

The lights go down on the last #webdirections at the Exhibition Centre.  #wds13

Photo by Mike Sharp

So the lights came down on the last WDS to be held at the Sydney Convention Centre (which is slated for demolition). Next year, WDS will be at the Seymour Centre; a move that will no doubt bring a new perspective and a new vibe.

Thanks Adobe!

A quick shout out with a thank you to Adobe - I was one of the six people lucky enough to win a pair of limited edition Converse shoes! I look forward to that parcel in the mail ;)

Edit 2013.06.11 - they arrived! ...and I'm pretty sure they are the most colourful item of clothing I've ever had ;)

Adobe CC converse all stars