Sophie Dennis
-
Working in Harmony: Links and further reading from my talk
My talk at Port80 2013 riffed on the theme of the parallels between music and the web, and why music offers often better analogies, especially when considering workflow and collaboration, than traditional print design. Here are the slides, playlist and suggestions for further reading.
Slides
http://www.slideshare.net/sophiedennis/working-in-harmony-port80-2013
Further Reading
Antiphonal Geometry
Designing with musical harmony
Owen Gregory, Antiphonal Geometry, Responsive Day Out, Brighton, March 2013
Slides | Transcript | Audio | VideoOwen Gregory, Composing the New Canon, 24Ways, 9 Dec 2011
A more detailed look at designing to harmonic proportionsWorkflow
Viljami Salminen, Responsive Workflow, 28 May 2012
Karen McGrane, WYSIWTF, A List Apart, 2 May 2013
Zen Garden
Dave Shea, 10 Years, mezzoblue, 7 May 2013 Dave relaunches the Zen Garden for the HTML5 era
Context
Stuff I don’t necessarily entirely agree with, but that forms the context for some of the points I’m making.
Mark Boulton, A New Canon, 9 Dec 2012
Owen Gregory takes issue with Mark’s argument that on the web “there is no page” in his Antiphonal Geometry talkRachel Lovinger, The Nimble Report, Razorfish, 2010
“it’s more structure that makes content nimble and sets it free” - remains one of the key references when arguing for greater structure beyond simple HTML in content authoringCennydd Bowles, What Bugs Me About “Content Out”, 20 Nov 2011
Although Cennydd is also making the content+design=meaning argument, I’d take issue with the idea that “content out” disregards the influence of design on meaningHistory
Cern, Twenty years of a free, open web
Jeffrey Veen, The Art & Science of Web Design, 2000
I quote from Veen’s earlier Hotwired Stylebook in the presentation, but this is a better overview of the history of the web and where we were c. 2000John Allsopp, A Dao of Web Design,A List Apart, 7 April 2000
A lot of people are quoting this when discussing responsive design. It’s worth reading the whole thing to see how far we’ve comeJeremy Keith, A Brief History of Markup, HTML5 for Web Designers, (2010)
Playlist
- Steven Isserlis, Prelude Suite no 1 and Gigue Suite no 4, Bach: The Cello Suites (2007)
- Yo-Yo Ma, Gigue Suite no 4, Inspired by Bach (1998)
- Kathryn Tickell, Old Morpeth Rant / Morpeth Rant / Hesleyside Reel, Northumberland Collection (2009)
- Bellowhead, Dockside Rant, Broadside (2012)
- Kate Rusby, The Unquiet Grave, 20 (2012)
- Lau, The Unquiet Grave, Lau Live (2008), released 2012 on Lightweights & Gentlemen + Lau Live Remastered (2012)
- Seth Lakeman, Sound of a Drum, Poor Man’s Heaven (2008)
The Isserlis Bach Cello Suites is not on Spotify but you can listen to samples at hyperion-records.co.uk
The Rant Step
Morpeth Rant on The Session
Basic notation and midi filesEnglish rant step danced by Derek Shaw, YouTube
How to Dance the Rant Step, Colin Hume
Colin explains the vital “po-ta-to crisps” trick120 web designers attempt to dance a Rant Step, a Vine by @cole007
1 Comments -
Predict the Sky: New UX & UI concepts, Oct 2012 from Sophie Dennis on Vimeo.
Another weekend Hackathon at The Met Office meant a chance to reconvene Team Predict The Sky. The story of building our prototype iOS and Android apps, which tell you when there is something cool happening in the night sky where you are, during the NASA Space Apps Challenge in April 2012, is told on the PredictTheSky GitHub Page.
You can see videos of my original paper prototype, and the prototype iOS and Android apps which we built over the original weekend.
I think this weekend was a bit of a hard lesson for some of the team in the large gap between a prototype and a finished product. Circumstances meant I was only able to join in remotely, so the team in Exeter did some corridor testing with the prototype Android app. This revealed a number of UI issues, especially with the rushed design implementation. We also hadn’t been touch-centric enough, with a lot of pressing buttons when people’s first instinct was to swipe. Plus I had an idea for a “date driven” UI approach which I wanted to try.
After a long conference call with the team, I spent the evening working on ideas for simplifying the existing concept, making things more swipe-y, and experimenting with the UX implications of switching to a date-driven model. Once I was happy with my basic sketches I made the video walkthrough* above to explain my ideas to the team, and help us explore the two very different user experiences they represented.
I find committing things to paper, even as very rough sketches, really helps clarify my thoughts. I’m liking these rectangular post-it notes for sketching mobile apps too. I know a lot of designers love their molekins, but I actually like using something that’s cheap. It encourages you to throw it away, which I think is important when you don’t want to get too wedded to a particular sketch or idea, and means you iterate rapidly.
As informal “UX Lead” my next task is to turn this into a slightly more robust prototype and talk to some real users about it. Meanwhile the technical team are going to pin down exactly what cool space events the app can tell you about.
(* Actually, using a pre-recorded video during a hackathon turned out to be a bad idea. While it was really quick to make, it took forever to upload and share, meaning the team didn’t get a chance to review it before the event was almost over. A video call would have been much better. A lesson for next time.)
1 Comments -
“Your user experience is not your deliverables” —Martin Belam, ‘Why I have (some) sympathy with the people behind the Olympic ticketing website’
Martin Belam reflects on the disaster area that the Olympic booking system has become, after spending many hours fruitlessly attempting to buy tickets through their convoluted, multi-step system:
> “I wonder the extent to which they tested the actual user experience of sitting in front of it for twenty or more minutes, only to have no tickets at the end. The user experience is not your beautiful design, or carefully thought through deliverables. There is a case to be made that you’d have a better user experience if the page just said “Sorry, we can’t process that request at the moment” any time the queue was over ten minutes, rather than putting you into a queue where fulfilment is unlikely.”
Which neatly ties into yesterday’s post about conceiving interfaces as sets of jobs. The user experience is the whole story not just the individual screens.
1 Comments -
'Thinking of interfaces as sets of jobs' by Ryan Singer Interactive systems like websites and apps are best designed as a flow. But it is very easy to lapse back into designing them as a series of ‘moments’ made up of static screen. Wireframes and design concepts are still predominantly created as flat files. As a designer you work on one state at a time, which can lead to a kind of tunnel vision in which each screen is honed in isolation from the rest of the task flow, leading to a disjointed user experience.
Ryan Singer’s deceptively simple suggestion to combat this is to think of the interface as a set of jobs, each with a beginning, middle and end. It’s a simple concept that’s easy to grasp and to keep in mind while designing each step in that journey.
Although it’s not mentioned in Ryan’s post, I’m sure it’s no coincidence that, just like a job well-done, having a clear beginning, middle and end is also the essence of a good story. Storytelling and designing for emotion are gaining traction in interaction design. As a user, though, I find some of their manifestations crude and heavy-handed. There is a tendency to try too hard, manufacturing emotion and telling me how I should feel like some annoyingly perky user-experience cheerleader. A good storyteller doesn’t tell you how to feel and neither should a good interface. Perhaps if we craft a strong beginning, middle and end to our user interactions, by designing jobs not screens, the emotion will take care of itself.
1 Comments -
“ Design the top level of your navigation in isolation. Base it on your top 20 tasks. Then test it with about 20 top task questions. Ask a minimum of 20 people what their first click would be based on the navigation you present them. You can do this manually using the simplest of wireframes.
Aim for a 90 percent first click success rate. Keep tweaking your navigation until you get that success rate…
Most of what you will be doing to improve success rate will involve changing words.
”—[My emphasis]
Gerry McGovern on The vital importance of the first click and how to get it right.
0 Comments -
Simple is not a design treatment
Simple is hard. Simple requires deep investigation, a thorough understanding of every aspect of a project, in line with the needs and expectations of the audience.
Simon Collinson, ‘Taming Complexity’, 24ways 20112 Comments -
Is Google's clean-and-simple aesthetic dull, or classic? Mashable can't decide. I’m confused. The new Google Reader is “super stark, open and clean, but is it too dull?” yet the “Clean and Simple Homepage” - which could hardly be more dull - is “still a classic”. Make up your mind Mashable.
Much of this can be ascribed to users’ well documented hatred of change. As Jakob Nielsen wrote in 2009 “Users hate change [but] in the long run, incrementalism eventually destroys cohesiveness”.
1 Comments -
Rethinking the Mobile Web by Yiibu (View more presentations from Bryan Rieger on Slideshare)As a follow-up to yesterday’s post on the Morrisons mobile site, here’s Bryan Rieger’s excellent presentation Rethinking the Mobile Web from 2010.
0 Comments -
Mobile sites: beware flaky device detection
Morrisons, the UK supermarket chain, have a mobile site. So far, so good. Unfortunately their device detection is somewhat, ahem, flaky.
Here’s what it looks like on my HTC Desire S, a recent Android phone:
Let’s leave aside for a minute that that mock phone surround is pretty cheesy. The offending image, “iphone-surround.gif”, is being applied to the <body> by the stylesheet “notmobildevice.css”. Which suggests it’s intended to be loaded only if you’re not viewing on a mobile phone. Presumably to show, should you stumble across it on a desktop, that this is a mobile-specific site.
Unfortunately my small Twitterverse sample suggests whatever device detection Morrisons are using is only treating iPhones (and iPods) as mobile. On iOS the cheesy phone is mercifully absent. But iOS is only around 18% of the mobile market. So - assuming my guess is right - 82% of mobile users are getting a desktop experience in error. This is, in essence, the flaw in relying exclusively on device detection.
What Morrisons could - should - have done is use CSS media queries to load notmobiledevice.css only at larger screen sizes. Either in conjunction with their device detection or instead of it. Media queries future-proof sites against the introduction of new devices their device detection script is unaware of. Provided the new device supports CSS media queries, which new devices almost certainly will, the site owner does not need to fret about supporting every mobile device individually.
Media queries offer a flexible, reliable, future-proof method to give different styles for different screen sizes. Used well they let your site elegantly fit to any screen size in a way that is device agnostic. As mobile devices proliferate and overtake desktop internet use, as assumptions about screen size become ever more dangerous, every site will need to use them to ensure a good browsing experience for its users. I’m not against either device detection or mobile-specific sites. Both have their place. But you want to use them alongside media queries to enhance the mobile-browsing experience, not instead of them.
(As a weird ps, I’ve realised the mobile detection is even more messed up. It was capable of redirecting me to the mobile site in the first place, but then decided I wasn’t mobile after all.)0 Comments -
Beware web designers bearing solutions
The Law of the Instrument can be seen in every web discussion forum, on sites such as Forrst and on Twitter. Ask for a CMS, blog or framework recommendation and you’ll see people immediately leap in to declare their hammer the best, without any knowledge of the requirements at hand – sometimes even when the requirements really rule out that tool from the outset
You cannot recommend a solution until you’ve identified the problem. Yet the web is awash with people pushing their favourite one-size-fits-all answers to whatever question is posed, whether a particular CMS, a certain programming language, or the latest social media cure-all. They are focused on a solution: one which works for them, one in which they are competent. Their own personal comfort zone, recommended as much for their own benefit as anyone else’s. But Twitter is not a marketing strategy, nor WordPress the only answer to web publishing.
I’m much more interested in problems, burrowing down into what’s really holding a business or organisation back and seeking out those golden nuggets, the smart ideas which are the real solutions to people’s complex, real-world problems. When someone asks for a recommendation, your first answer should be a question: what are you trying to do, what is the problem you are having, tell me more…
1 Comments -
Mike Reed, on judging D&AD 2011 ‘I wish I’d written this one.’ That’s what you listen for, of course: the ultimate creative’s compliment. That potent mixture of delight and envy – and the undercurrent of anxiety that, presented with the same brief, one wouldn’t have come up with anything like as powerful a solution. (Or perhaps that’s just me.)
0 Comments -
Designers fail 95% of the time
All designers fail 95% of the time. This is true for all creative work. And it is unusual in the professional world. The process by which we create is failure centric.
We were talking just last night about design critique and feedback, and how easily it becomes a fraught experience for both parties. If can be just as difficult for the client to talk about what they don’t like, as it is for the designer to hear it.
If both parties accept that, 95% of the time, any design isn’t going to be “right” yet, and treat that as a perfectly normal and natural state of things, those conversations become a lot easier. Because just cos it isn’t right yet, doesn’t mean it won’t be right when we’re finished. The design process is all about spotting what isn’t right and working out how to fix it; refining, improving, polishing and adjusting until it’s all just so.
2 Comments
