22:01:59 <danielsmw> #startmeeting Design Eye for Frightful UIs - Mairin Duffy
22:01:59 <zodbot> Meeting started Sat Dec  5 22:01:59 2009 UTC.  The chair is danielsmw. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
22:02:56 <danielsmw> Someone is videoing this talk, as an aside. I have no idea where that will end up.
22:03:14 <danielsmw> Hopefully on the wiki...
22:04:04 <danielsmw> #topic Intro
22:04:32 <danielsmw> Mairin: my name is Mairin Duffy, I've been working with the Fedora community for a few years now.
22:05:19 <danielsmw> Why aren't people using free software?
22:05:28 <danielsmw> <Paul interrupts...?>
22:06:10 <danielsmw> Perhaps we're not as ubiquitous as other OSes is because the user isn't considered first; most of us are very technical, and think more about implementing cool stuff than about user interaction.
22:06:17 <danielsmw> People won't use something they aren't comfortable with.
22:06:27 <danielsmw> We need design.
22:06:38 <danielsmw> My personal background: I double majored in design and computer science.
22:06:46 <danielsmw> When I started out, i thought I could do half and half.
22:07:09 <danielsmw> But I quickly learned that you can't think with both sides of your brain at the same time; you can't live in both worlds at once.
22:07:15 <danielsmw> You can think both ways, but not at the same time.
22:07:32 <danielsmw> As a developer, you have concerns at odds with designeer concerns.
22:07:42 <danielsmw> s/designeer/designer/
22:07:51 <danielsmw> These two worlds can conflct sometimes.
22:08:02 <danielsmw> Ex: there's no library for pink flying ponies.
22:08:06 <danielsmw> Topics:
22:08:13 <danielsmw> 1) Figure out your story.
22:08:17 <danielsmw> 2) Prepare to share
22:08:23 <danielsmw> 3) Attract designers' attention
22:08:28 <danielsmw> 4) Negotiate
22:08:35 <danielsmw> #Topic Figure out your story.
22:08:42 <danielsmw> You know what you're working on and why
22:08:56 <danielsmw> But when you're atlking to a designer, they might have no idea what you're talking about
22:09:06 <danielsmw> Your Your technical jargon can make their eyes glaze over.
22:09:27 <danielsmw> The most important question to relate to the designer: what problem are you trying to solve? What's the villain?
22:09:47 <danielsmw> Ex: Dan Williams: Network manager.
22:10:10 <danielsmw> Dan Williams: It's too hard to get a network connection!
22:10:11 <danielsmw> Mairin: The next thing you want to think about is: what kind of help do you need?
22:10:24 <danielsmw> I need design help, but the designer says: what kind of design help?
22:10:34 <danielsmw> These are examples you can use as jargon with designers:
22:11:10 <danielsmw> Examples: existing software -- you might want a usability test and a redesign with mockups.
22:11:20 <danielsmw> Note that these will tell you about the problems, but not about how to solve them.
22:11:45 <danielsmw> Also note that if you don't know what you problem is or where your software is going, you might need to rethink the project.
22:11:59 <danielsmw> Existing software: "Can you make it pretty?"
22:12:09 <danielsmw> Ask for icon design, logo design, etc; not just "Design help"
22:12:29 <danielsmw> New software - I have a great idea and I want to do it right from the beginning"
22:12:34 <danielsmw> Ask for user research, brainstorming, task analysis
22:13:06 <danielsmw> Net software - I want my softawre to do X, but now sure how my users will like it: ask for user research.
22:13:11 <danielsmw> What's your scope?
22:13:21 <danielsmw> Sometimes you'll ask for help, but won't explain how big it is.
22:13:33 <danielsmw> If you want help with the entire project, don't just send a single screenshot:
22:13:45 <danielsmw> explain the scope of your project to the designer so they can figure out their plan of attack.
22:13:49 <danielsmw> Who is it for?
22:13:54 <danielsmw> Your audience is very important
22:14:33 <danielsmw> Even though programmers like customization, an insurance agent might not. For him, you want a simple layout and you need to know this to setup mockups.
22:14:51 <danielsmw> But if your user is a power-developer, you'll want a different design paradigm for that audience.
22:15:07 <danielsmw> It can be hard for developers to tell designers this at first.
22:15:21 <danielsmw> There aren't a lot of designers, so these are strategic tips for getting them to work faster.
22:15:25 <danielsmw> Why use it? (The software)
22:15:45 <danielsmw> This is an important idea for the designer so they can understand what's important in designing workfolwo
22:15:58 <danielsmw> Ex: pressing play should be easier than editing mp3 data tags
22:16:07 <danielsmw> Where's the action? How do I get involved?
22:16:30 <danielsmw> Make sure you relate the mailing list and IRC for your designer to get up to speed with your project
22:16:40 <danielsmw> Even if you have to hold your designers hand to use IRC.
22:16:42 <danielsmw> #Topic Prepare to share
22:16:56 <danielsmw> Document your story:
22:17:13 <danielsmw> Write out these questions that we just talked about and a top five task list (or top ten, etc) for your designer.
22:17:21 <danielsmw> These should be things that are critical to your app's function
22:17:28 <danielsmw> This helps your designer prioritize.
22:17:51 <danielsmw> It also helps QA understand what' mission-critical.
22:18:08 <danielsmw> Don't right a task like: you should be able to click a button and download a file.
22:18:12 <danielsmw> Rather, it cou
22:18:16 <danielsmw> ld be to burn a cd for a party.
22:18:31 <danielsmw> I want to hand out Fedora shirts and bling at a conference.
22:18:39 <danielsmw> Prepare a demo:
22:19:16 <danielsmw> Don't have a  designer setup a development environment just to see a demo; take a screenshot instead.
22:19:41 <danielsmw> You could also use rough sketches or screenshots of similar features in other apps.
22:20:24 <danielsmw> For existing software, you could do a screenshot slideshow, record a personal demo, create a pre-installed VM, do a VNC live dmo, or install it in a live test enivornment.
22:20:38 <danielsmw> I prefer this last option, because it doesn't screw up my computer.
22:20:56 <danielsmw> If there's a live test environment installed somewhere, the designer can refer to it when they need.
22:21:09 <danielsmw> Where's the action?
22:21:20 <danielsmw> If you don't tell the designer how to get in touch with you, they can't!
22:21:22 <danielsmw> Get the word out:
22:23:50 <danielsmw> #topic Negotiate
22:24:02 <danielsmw> (Sorry for the lag, I lost internet for a bit --danielsmw)
22:24:12 <danielsmw> Designers  are thinking about what the users need to a blue-sky scenario
22:24:18 <danielsmw> But as a developer, you're thinking about reality
22:24:30 <danielsmw> What libraries to have access to, what are the standards, what are my time constraints
22:24:37 <danielsmw> You're thinking realistically, they're thinking for the users;
22:24:42 <danielsmw> the answers are probably in the middle.
22:25:15 <danielsmw> If they come up with a crazy unimplementable mockup, let them know what is and isn't implementabl.
22:25:32 <danielsmw> Developers and designers are in different mindsets; try to shift mindsets to understand each other and find the compromise that serves the users but doesn't keep everyone up till late at night.
22:25:44 <danielsmw> You'll need to backtrack a lot with the designer.
22:25:51 <danielsmw> You'll often have more work to do once you bring a designer on.
22:26:03 <danielsmw> It's easy to develop unusable software when you're just thinking about the developer side.
22:26:20 <danielsmw> Designer: Why does your software work like this? Why?
22:26:35 <danielsmw> You might be offended, but don't take it personally; she's just trying to understand how to help the user.
22:26:43 <danielsmw> Don't be afraid to pull features that don't help the user.
22:27:01 <danielsmw> Make it clear what you want and when, and what your expectations and time frames are.
22:27:06 <danielsmw> If you need user interviews, tell them.
22:27:16 <danielsmw> You'd think this is common sense, but it often isn't discussed.
22:27:18 <danielsmw> Questions?
22:27:34 <danielsmw> Surely! You must have question!
22:27:35 <danielsmw> s
22:27:58 <danielsmw> Question: I work on things with lots of legacy. Working on a new feature, how do you scope working on old problem?
22:28:16 <danielsmw> Mairin: I call that the jenga tower, where pulling one piece can make the whole thing fall apart because of older problems.
22:29:46 <danielsmw> Oftentime a solution is hard to get. When a project spirals out of control but you still need to move forward, I suggest that you take an inventory of what users use and cut out the rest.
22:29:51 <danielsmw> Fix twhat's left and minimize the nightmare.
22:30:18 <danielsmw> Question: What are you  favorite tools for mockups?
22:30:47 <danielsmw> Mairin: I'll show you an example. What I typically do is a developer comes and explains the problem they're trying to solve.
22:31:04 <danielsmw> If it's not possible to meet in person, we'll do it over IRC or VNC, etc.
22:31:37 <danielsmw> So first I get the lay of the land and take notes about probles I see. I'll try to do a usuability test or just a heuristics test.
22:34:13 <danielsmw_local> For anaconda, for example, someone wasn't sure if GTK would support a widget, then got back to me and told me how I had to do it.
22:34:17 <danielsmw_local> That's how the conversation might go.
22:34:34 <danielsmw_local> In the last part of the conversation is when he looks at what I have and implements it.
22:34:48 <danielsmw_local> So he'll call a meeting with me after he tries to implement it and we'll work out compromises.
22:35:01 <danielsmw_local> Once it's released, we'll do usability tests.
22:35:11 <danielsmw_local> question: Do you prefer IRC to the phone?
22:35:19 <danielsmw_local> Mairin: I actually prefer IRC because we get the transcription.
22:35:43 <danielsmw_local> It's a personal thing. Lots of them that aren't weird like me might prefer personal contact.
22:35:56 <danielsmw_local> Anything here that surprised you, or that you thought wasn't true?
22:36:15 <danielsmw_local> Question: Is Inkscape better than GIMP?
22:36:40 <danielsmw_local> Mairin: Inkscape is vector based, so better for mockups because you can move things around. Some people prefer GIMP, but it's harder to move things around in the mockup as a bitmap program.
22:36:55 <danielsmw_local> One of the main things I do when I'm drawing UIs is drawing shapes, which is hard to adjust in GIMP.
22:37:37 <danielsmw_local> Question: Are there a couple of obvious references for best practices stuff? For UI design? If we're starting off on our own or improving by small margins, is there a reference?
22:37:59 <danielsmw_local> Mairin: There's an O'Reilly book that came out recently, something like "Interface Design for Web Applications." I think it's purple.
22:38:32 <danielsmw_local> That's a really good book for design stuff. There's another O'Reilly book with a duck called "Interaction Design" by Tidwell. That's a great reference and includes different design patterns.
22:38:42 <danielsmw_local> She explains what's good for different widgets and applciations.
22:39:13 <danielsmw_local> Aboutface 3.0 is also a design bible, a big green book, that talks about everything from user research to mockups. If you want to buy _one_ book with it all that's probably the best choice.
22:39:28 <danielsmw_local> Anyone can come get by card after the presentation and I'll send out a standard bibliography.
22:39:31 <danielsmw_local> Any other questions?
22:39:36 <danielsmw_local> Thanks for coming!
22:39:40 <danielsmw_local> I hope it was helpful... etc.
22:39:47 <danielsmw_local> #endmeeting
22:41:46 <danielsmw> #endmeeting