SXSW 2008: Creative Collaboration: Building Web Apps Together

by danhon

Creative Collaboration: Building Web Apps Together

Room A

Tuesday, March 11th

3:30 pm 4:30 pm

The all-knowledgable webmaster is long gone, replaced by groups of specialists. When they work well together awesome things happen. When they don’t the results are ugly, insecure, inaccessible and slow, assuming they launch at all. What’s the magic that great teams have in common, and what can we learn from them?

Paul Hammond Flickr

Simon Willison

George Oates Lead Designer, Flickr

Matt Biddulph CTO, Dopplr
Dave Shea mezzoblue.com

Collaborative Web Apps

Introductions – Hammond, Willison, Shea, Biddulph

Hammond: enjoy the things I don’t do for a day job at this conference, get all these different people together, talk and learn from each other. Been true of the teams I’ve worked with there. The redesign of the BBC homepage I worked on in 2002 – the one that changed colour a lot. It was a great tight-knit team, of developers designers, editorial staff, managers, usability people. We worked really well together, it’s 5-6 years since and I’m still really happy with the results and work we did there and that’s what I want to talk about today, those projects where you get a great team, great people and you get into a flow state. Not every project is like that. Some, you feel miserable, it’s not really worth it, you get overruled, you don’t feel like you’re working well together as a team. What we want to talk about is designers and developers working well together. This slide’s a bit misleading – it’s not really designers and developers, there’s lots of different types of designers, and there’s different types of developers. But these are the best terms we’ve got, so they’re what I’m sticking with. It’s the collaboration that’s interesting. I asked some people I respect in the industry, I’m still surprised they all said yes, to come up and talk with me. We’ll start with what they do, how they work and launch into Q&A, and then open it up to the floor so you can ask your questions.

Moving straight to Matt.

Biddulph: Hello – I’m Matt Biddulph, the CTO at Dopplr, the social network for frequent travlelers. That’s where you came from, today. Austin is suddenly the centre of the universe. But I’m not here to talk about the site but the process. We’re a small team, there’s 4 people in any capacity, not all of us full time, we’re only a year old since the first line of code and the first sketch on a whiteboard, it’s more productive and collaborative that I’ve ever worked in before, it’s the skills of the individuals and their vast experience and amazing good looks, and the way we work together. I’m going to focus on mr Matt. Jones. Who some of you may know. He’s got this long experience at the BBC and he’s spent time at Nokia, the kind of company where you can make big products that change the world but the lead time can be really long, at Dopplr we keep things moving and ship things several times a day. He refers to me as his technical wife – I’m proud to be his technical wife – he’s my design husband. [laughter] I think when a technical wife and a design husband love each other very much they have a special meeting and nine months later a website is born. [more laughter] What we want to do is keep all our new features live on teh site as early as possible to work with the clay of features. THis is our backend – we can tag any user, all the futures we’re workign on are available on this control panel – we’re about to launch a carbon calculator so you can see how awful it is to come here. You can live with the features while they’re being formed. So one of the things we’r eworkign on is intergrating with Flickr Places – being geobased it fits in with Dopplr, but we haven’t worked out how to fit it in the UI. So we’re providing that side of the clay for matt and Boris to work with we’ve dumped it in that’s ugly but that means we live with it and we can see how it might look like. So we’re testing new features live, this is something that Boris Anthony who works on designing and coding – sculpting not painting so designers and deves work together on new featuers and share a language and not work in a waterfall of preprepared design.

Simon Willison: I’m Simon Willison – web tech enthusiast, started out as server side, CSS, javascript a few years ago, now switched back to opposite direction, always looking at technical side, but current speciality is freelance – consultant on Javascript, OpenID, Django. Previous experience: worked at Yahoo for a year, Hammond, Willison and Coates doing rapid prototyping and then worked with local newspaper in the middle of Kansas. And that’s the most relevant to this panel. Lawrence Journal-World – 10k circulation when joined in late 03 and despite having no one buying the paper they had a fantastic award winning nationally acclaimed website, all these were being built by two devs, including myself, one designer a dab hand with html and css, problem we had there was a small team being expected to produce sites on a journalism schedule than a regular dev schedule. We’d have a story come up, e.g. exploring voting results, and you’d have two days to go from concept to live with real data and people looking at it. What came out of that is DJango – building content oriented websites. The workflow it supports – the sites you build in newspapers are very dependent upon dates, data, quite a clear set of informatino to be displayed. When working with Django the way we worked is we start with the data model, we’re building the obtituary section, from very early on it’s possible to design this data model I believe that it’s still a design activity, I’d never consider myself visual, but it relates to solving problems in a set of constraints. Create full-fledged admin interface to add data while still building the rest of the site – parallel workflow, data straight away letting devs working on interesting part – the stuff people see, the interesting pages. Knock out stub templates to be flipped over the wall to designers. A few hours later, they get templates they can start fleshing out. This is efficient for a certain category of sites, there’s a lot of parralellism, only works for sites defined by data in them.

With apps, underlying data is only a small part of what’s going on. App projects that have been successful where we have continuous collaboration with designers right form the start and after launch. Has left me with real problem – get to work with designers in professional jobs, but personal projects for which I don’t have a design husband, find myself looking for my own Matt Jones. So that’s me.

Dave Shea: web directions north, css zen garden, mezzoblue, Designer who happens to code. Tools are visual in nature, Photoshop, Illustrator, InDesign, but also use a coder, ftp, command line in my arsenal, so valuable combination for myself. Now also independent – believe Simon is these days as well, but have no experience working in large companies, never worked for anything more than a dozen or so people, but do end up going and working with clients who involve m ein process from start to finish. People think the design process is: here’s what I want to build, designer builds it, hand it back. Magic design box where everything happens. Client will have idea, well your idea sucks, here’s how to make it better, back and forth, mockups, clients say what they like, what they don’t, suggest changes, that they ignore, templates implemented by their developers. I code – I have the capability, but I try not to. I’m collaborating with someone on design and smoeone else on code. I’m fidning that in both cases there’s a lot of back and forth and give and take and I get stuck in the middle, it’s an interesting position to be in and clients rely on me for a lot of stuff – translating geek speak to human friendly language.

George: Worked at Flickr since it was born an Feb 10 04. Up until recently, was lead designer. Favourite way to work is paper and whiteboard. Even gets down to the level – if they can see the direction your hand is moving in, then that makes it clearer. It’s lo-fi. It’s easy to throw away. So, hats: interaction designer, visual designer, copywriter, program manager, project manager, copywriter, community wrangler, customer care provider. Have watched Flickr dev team grow and change. So I’ve been curious to watch and see what’s happened to the development style. Oates, Cal and Eric, people who had fingers in the code, could check things in and deploy. Over four years grown to 16, and balloned up to different areas. Supporting cast of well over 100. Over 2.3b photos on Flickr, and still freaks me out. Over 20m members, curious on affect of way we work. Early days, we released early and often, but now as it’s grown. Hope to shed light on things that put pressure on release early, often.

Who’d win? Designer or developer?

(Developers, it feels.)

[sorry, missed some Qs]

Willison: most frustrating thing – handed spec and told to build it. Ignoring any skills and knowledge I might have around using the web for the last 10 years. Works better if there’s collaboration early on, whiteboarding sessions, collaboration between the two roles, don’t care the typeface, but the screens yet. If you don’t leave me out, I’m perfectly happy.

Shea: Here’s the site, just change the css and skin it for us!

Hammond: On Friday – difficult to respect something I don’t understand. How do we help people understand? George?

George: Everything to do with how design is put together and if you have members from all of the disciplines collaborating at that early stage and agreeing on what it will be, the job’s done. It’s when you have top down stuff that Simon’s talking about that you get that breakdown in criticism and questions, if everyone’s in the same room with the same conversation, then you get it out of the way.

Hammond: how does it work coming in from outside?

Shea: As a designer, I can point to things, I don’t need to have the interpretation layer, I show past examples, what I did before, if I have to go into detail, these are the steps we went through to get to that point, that cuts through steps, they have something to grasp on to to see that.

George: Prtototyping is useful, HTML, live data, speaks to both parties. Setting this up to be opposite but don’t mean to do that. If anyone can see a prototype working then that speaks volumes much more than a static photoshop document.

George: database guy has overview, he can do really weird shit, he can do search result page thinking in crazy directions, hugely inspiration, gives view of data wouldn’t ahve confused of myself.

Shea: Curious – when you build these prototypes, are designers involved, or is it a developer thing? Most people on the flickr team cross pollinate betweenroles, but there’s two people over a shoulder looking at things, designer and dev, or two devs, even a customer care person.

Willison: Flickr API is rich, any feature on the site can be replicated against it.

Oates: That’s how we rolled out places – Dan and I worked on getting a roughshod design together, then used public facing API to put a prototype together, had to translate his woolly code into production ready code. He was making heaps of calls. Really useful process to see the crunching he could do with live data in a prototype form.

Hammond: You mentioned job roles, I realised everyone on this panel is a generalist. Do you think people need to be multitalented?

Wililson: In my experience, the projects most successful have been small teams of generalists. A sculptor who knows how carving stone works. But that’s just in my experience.

Biddulph: very important to have specialists or specialist knowledge, the shared thing that’s important in our work is the shared understanding of product, the thing you’re trying to make, the voice of your product is important for everyone to understand, copy – Dopplr’s a word heavy UI, copy helpsyou explore what the product does.

George: Developers can help you with designer – they can see gotchas and error cases, they all need to ahve copy written for them, you need to help someone come back out when they hit a wall, I might catch 5-6 and thre might be more that I miss. What the system needs to account for is beneficial.

Shea: I’m finding constantly that I’m coming up with ideas and stopping that it doesn’t work with data that’s out of a databsae constantly, have to figure out another way. This has been a problem with print design transitioning to the web, no fixed canvas, content will be dynamic and changing, understanding that is a critical first step and taking it further these days and being the interpretation layer between code and other members of the team and client, that works really for me. Generalise if you’re independent, if you’re a client, look for one.

Hammond: trend in industry – separate clientside developer from interaction/graphic designer. Is this good?

Willison: I’ve already said that best designers have been client side developers as well. Possiblity the hardest role in all today, 5 rendering engines without mobile, 3 version of IE you need to care about, great that they’d also be elite html and css hackers, you can’t expect that of people when there’s so much you need to learn. They’re also starting to encompass javascript as well, it’s a real programming language so I like it if people do all those things, then I think that divide is osmething that needs to happen realistiically.

Biddulph: always been server side developer, went away from web work for a while, even paid to do stuff in SL and infrastructure – browser tools have come back to be good enough, can tinker in front end, insight that that gives me, not just working in data but also in interface helps me understand flows going into the design.

Oates: More relaxing to know who you’re working witha nd what the’yre specifically involved in to do, being able to rely on people having specific areas of functionality, really important. If we’re all fluffy, then you get woolly on decisions and responsibility.

Willison: That doesn’t scale down to 3 people.

Oates: With 3 people, the roles are pretty clear.

Hammond: Someone said process is an antidote to stupid people. Do you think that’s a fair assessment?

Shea: I agree with the sentiment. The proposals are almost contracts, they specifically set out the steps for the design process, how we get from point A to point B, it’s laid out clearly, listen, we’re not going to follow that, it’s more organic, it’s not 3x rounds of feedback, unless I feel that it’s taking more time and you’re being too hard to work with (that’s what I don’t say) then we fall back and I have that accounted for. I trust that you’ll be a better person to work with if you’re not, process will save me.

Biddulph: I ran away from process in big companies, when I left the BBC I knew I never wanted to work for a big company, big = 12, resources are allocated. If people can be resources. You’re already in a strange situation. I wanted process to work, I started reading literature on project management, and realised how many I’d had who didn’t have the same background in their discipline. But in the end I gave up and ran away, I pick the people I work with who’re good with what they do, I have respect for people who work with process.

George: I don’t know. Humans don’t respond well to anarchy. There’s a revulsion against process, we’ve all worked on waterfall style checkpoints and gates and approvals. But I think it’s still useful, I enjoy touchpoints, it’s good to hit.

Biddulph: good to measure youreslf along the way, we may ship several things and fix a day, but we still have a monthly release.

Oates: We like kicking goals, feeling like we’re being productive. Having release goals is useful to keep everyone on track, the trouble comes when you start to load a process with a variety of inputs that don’t get the project built any faster. The pressure exerted on Flickr now – we release in 8 diff languages, anything we do has to be translated into all those languages, makes it more difficult for us to make mistakes – they have to be robust enough to not go through too many translation cycles.

Hammond: How can I as a developer make myself easier to work with to designers.

Oates: main difference is organic information system that stretches and moves and snaps and I think it’s very important for web designers to transition to building apps to have an understanding of that. What does it look like when there’s zero interaction, devs have insight into data structures, tables in database, fields, sorts of fields they are that I wouldn’t necessarily know, educating designers about data constraints is really important.

Biddulph: Show your working, basically. Something that works well, we have philosophical pretensions about our deep disciplines, somethign that matt and Boris do very well is explain models in their thinking. These pixels are there for a reason, these things are hyperlinked and not, that’s the model we’re trying to impress. Knowing why things are there, helps me when I’m improvising a bit of a page. Following the rules and the model, what should the page do and how should it look?

Shea: Learning svn.

Willison: They build html prototypes to communicate to dev teams about what they need to build. Neat thing they were doing was embedding hidden notes in the page – should look like x when not signed up yet. Annotations – link at top that you can click to show/hide notes. Interesting idea.

Hammond: How can server side/client side devs communicate better?

Willison: this is one of the few things where I think technology can save us, Django is designed to be easy for designers to understand. Knock out templates with horrible HTML that the designers want to fix. Seen projects where clientside devs hand off to implement, gets completely butchered, results in angry clientside devs. Templating mechanism where clientside devs can do their thing and make changes.

Shea: Biggest thing – abstractions are too tough to talk about at the beginning, something simple – wireframes, mockups. Somewhere you need to be looking at something together, that’s what I’m talking about right now.

Qs from the floor:

Q: Offshore devs in South Africa. Working for company that’s 15 years old still in startup, complex technology. Change management in change request system. Problem is RAD, scrum-type situations, overhead you don’t have time for. What Willison said about tech saving us – agile change management/request systems which allow all of us as devs and designers, or both, to quickly make suggestions and get credit, appeal decisions, any tools you use like that?

Willison: One of the first things I introduce is a simple ticketing system – preference is trac. Often called bugtrackers. Not tracking bugs, bugs, design decisions, things that need to be changed. Lightweight tools easy to get into. That speaks to teams that haven’t been doing that already.

Shea: Problem for me as an independent is that overhead of setting that up has prveented me form doing that. Change requests go into my inbox and sit there for a long time.

Willison: There are hosted apps that can do that.

Q: We have a small team, recent startup, awesome web designer. Awesome dev. Running into problems where dev is programmer, designer is html/css. Not communicating.

Oates: If your dev thinks he’s so fantastic nothing he can ever do will be wrong, you have other problems. Cultural problem, not communicative. Perpetual design. The idea that something is not concrete ever, is a liberating way to work.

Bidduph: Only two server devs have keys to do magic deploy, which is not what we want.