CIID 09/10: Graphical User Interfaces

Refreshed from the winter break, we returned to the studio to embark on the next stage of the curriculum. Whereas the first part of the year had been focused on building and upgrading skills, the next couple of projects were longer investigations. First up was GUI, a 4 week course taught by a stellar cast.

The course was split broadly in two – two weeks with Timm and Frank from Raureif in Berlin, and then two weeks overseen by Matt Cottam, which in turn was taught in three stages: first Matt together with his colleague from Tellart, Brian, then a weekend whirlwind together with Timo and Jack, rounded off by three days with Fabio and Gianluca from frogdesign’s Milan office. Phew. Yes, it was as exhausting as it sounds!

PART ONE: METAPHORS AND PIXELS [Timm and Frank, Raureif]

For the first two weeks we were joined by Timm Kekeritz and Frank Rausch from Berlin-based design consultancy Raureif, who helped lay the foundations of designing and building graphical user interfaces. Standards, conventions, metaphors, colour, typography. That kind of thing. Mini projects and exercises, to get us thinking about the above. And then a slightly longer project, in groups of three, to work on one of several pretty tightly constrained briefs. The aim was not so much to come up with a cool idea or to invent lots of fascinating features, but to focus squarely on the implementation – developing a usable and, ideally, beautiful user interface. Briefs on offer included a podcast/radio application, an application for letterwriting, and the one my group chose, a safebox or wunderkammer application, a place for keeping digital files that are in some way special. We described it as “The digital version of the box under your bed”. You can read more about the project, called magpie, here.

It was nice to have not only the expertise, in the form of Timm and Frank, but also the time and appreciating context in which to really get down to the nitty-gritty pixel-level detail. Does it look better with this pixel here, or here? Does a 1px drop shadow make this type more legible or confuse things? We obsessed over type. Over shades of grey (although that might have been more me…). Over each and every pixel.

I was fortunate to be in a team with Mary and David, which meant we had both a wide range of technical skills – including the basics of photoshop and lots of coding experience – as well as a group more than happy to obsess perhaps more than was strictly speaking necessary (or healthy). In the end, we (well, Mary and David) designed a fully working application in processing, with every asset built (and rebuilt, and tweaked and argued over) down to the individual pixels. No pretending that screens were vector here!

Building the application to be working and alive meant that we could fine tune not only the pixels, but also the behavior. The decision to make the application fully functional might have stemmed out of stubbornness and the search for a challenge, rather than strictly necessity within the project, but by the end being able to play with and explore the behavioral aspects of the UI definitely affected the purely visual side as well. The scroll/pan buttons (below) didn’t just have two or three states, or even just fade, but showed more subtle changes depending on where the curser was in relation to each side of the screen (‘there’s something here if you come closer’; a non-linear fade in based on proximity, hover, and down/click) , something we would certainly not have considered without having the interface in a form we could use and test. A large part of the interface was based on zooming (infinitely, in or out, on an infinite canvas), something that’s very hard to imagine or specify without trying it – some things just ‘felt’ wrong which looked fine when static. The zooming aspect of the interface also meant that everything, logically enough, changed size as you zoomed in and out. Which sounds fine, until you realise that some interface elements only worked at certain sizes, or needed variations, not to mention transitions, designed for them.

All things that could quite easily have been glossed over – we could much more easily have made a set of lovely looking shiny screenshots in much less time. But an interface isn’t just a shiny screenshot, it’s an experience, and having been able to dive into the nitty gritty of making it work helped us no end in being able to create something that worked smoothly, even when encountered by an inevitably unpredictable user.

Creating both sides of the equation – visuals and behavior – side by side, three laptops buzzing away all through the night prior to the presentations, allowed all parts to be iterated together, argued about as one, and – pure GUI outcome aside – allowed us to learn so much more about designing interfaces, as opposed to screenshots.

PART TWO

2.1: DESIGNING FOR MOBILE DEVICES [Matt and Brian, Tellart]

Part two of the GUI course kicked off with Matt Cottam, together with his colleague from Tellart, Brian, introducing us to various tools for prototyping for mobile devices, with the iphone/ipod touch being the device of choice – availability and power being the key reasons.

The rather tough brief they set us to focus the mind was based in the context of disaster relief (this was just after the earthquake in Haiti had hit). But the interesting/difficult/mean bit was that we were to imagine (and design) an application for the iphone, but with the assumption that we couldn’t use the main phone networks, no internet connection, and not to imagine it being used in a primarily urban environment. So there went all the things that, depending on how you see it, generally make these kinds of projects interesting, or easy, or are used as crutches. In many ways it was a mixed blessing – it excluded a lot of exciting possibilities (I mean – most people buy an iphone to use as a phone, with networking, and in an urban environment) but it also meant we had to think abotu it not as an iphone, but as a mobile computing platform in its own right, and work from there, which was interesting. Primarily the result was that we had no crutches to lean on, no real existing examples to use as a basis for our thinking.

[Shruti’s notes above, and I think it’s Ishac and Jacek debating those wireframes below]

Working in new teams, we developed a concept, sketched out how it would work, and settled down to build the thing. Most teams were working in Dashcode, but I was in a team with Sebastian and Dean – and that meant we were going to do it properly. Objective C it was. Thanks Dean.

The focus here was less on the pixel-level detail design as it had been in the two weeks with Timm and Frank, and more on creating a concept and implementing it in a feasable and believable interface, and in the process getting used to the constraints and affordances of a smaller screen, a touch-sensitive device, a platform that was mobile.

More than in most courses, there was a strong tension here between working on the concept, and our learnings as designers, in this case specifically around creating and implementing GUIs. Of course, it’s impossible to completely separate them, but I don’t think I was alone in being a little frustrated by being uncertain of the balance between creating a sound concept as a response to the brief, and the craft aspect of implementing a usable and visually beautiful or appropriate interface around said concept. Largely due to time constraints, I felt we (as a class, rather than as a team) somewhat rushed the GUI side of things, eventually creating perfectly functional, but perhaps not as finessed, outcomes as we could have done given a different focus. The feedback, too, emphasized the features and logic rather than the implementation, and I, certainly, felt hungry to have a bit deeper discussions about, if not individual pixels, then at least application flow, screen layouts, and so on. Perhaps an intermediate stage, where we worked more intensively with wireframes, might have done the trick? I don’t know.

Still – as ever, given an impossible timeframe and a challenging brief, we still managed to create a mostly working application. The project we came up with can be seen here.

2.2: TELLY-LIES [Timo, AHO; and Jack, BERG]

As a direct follow on from the week-long workshop with Matt and Brian, creating the mobile app, we were joined by Timo Arnall (AHO, Oslo) and Jack Schulze (BERG, London) for an intense 3 day workshop focused on really telling the story of the concept, and ultimately making a short, self contained video. I think we were all knackered and initially a bit grumpy at having to work over the weekend – that’s what you get when you’re taught by busy people! – but any grumpiness was quickly dissipated by the infectious energy (not to mention skill) of both Timo and Jack, as well as Matt.

[Jack does lots of gestures with his hands. They photograph well]

Partly we were learning the skills of video production, polishing what we had learnt in the video prototyping course back in October. But primarily, we were learning the craft of storytelling, using video as a medium. Communicating a concept, and the value of an idea, in a minute or two. Creating a visual trick, or a storytelling prop, keeping the viewer’s attention. Sure, some of that was about software (after effects, primarily), but as much time was spent on storyboarding, planning, making props, and carefully planning the actual shots. And the tedious editing, slowly shaving away precious seconds.

Of course, it’s not as polished as we would have liked it to be, but next time it will be…

The project is the same as the one above, but watch the video here.

2.3 ECOLOGIES AND SYSTEMS [Fabio and Gianluca, frogdesign]

To round off the project, we were joined by Fabio Sergio and Gianluca Brugnoli, Creative Director and Associate Creative Director of frogdesign‘s Milan studio, respectively. Whereas we’d previously been working with the constraints set out at the very beginning, forcing us to work with the iphone in isolation as a computing platform, we were now tasked to expand – the networks were available again, and our previously developed app was to be conceived as part of a larger ecosystem. Rather than working on a purely mobile device, we were encouraged to think how it might inter-operate with something else – other devices, a desktop computer, a command centre.

[Jacek describing part of his group’s system]

In our project, we worked on an ecology of iphones, basic mobiles, and a desktop-based command centre on a model involving local and central hubs, but others developed more complex ecosystems, and one team even worked in an elaborate microsoft-surface-like multitouch system – which may or may not have been useful, but was certainly fun to design for!

By the end of it, we were all very tired – we had been fine working over the weekend, but there are good reasons we humans try to have a break every5 days or so. Nonetheless, it was fascinating to get such a range of inputs on our projects (as concepts) as well as on the skill of crafting interfaces. I think maybe we were missing a bit of a detailed graphical focus, but the flipside of that was that we spent more time on the ideas and thinking about how they would work in the real world. Can’t have everything.

I don’t particularly want to make a living out of pushing pixels around, or even just designing interfaces (although you never know) – I can do it, but it’s not really where my main strengths lie. Not to mention it would probably drive me crazy after a while. Nonetheless, it was good to learn how to do it properly, and engage, hands-on, with the craft of pixel polishing.


← Back to the latest posts