21:02 < seele> yep
21:02 < seele> so.. usability time
21:02 < seele> who here is for the usability talk?
21:02 < Riddell> take it away seele
21:03 < seele> ok.. so just a little about myself first
21:03 < seele> seele == Celeste Lyn Paul (celeste@kde.org)
21:03 < seele> i'm on the kubuntu council and have been working with kubuntu for about 2 years
21:03 * stdin waits for the Usability session with seele
21:04 < seele> i manage the KDE usability project and have been working with kde for about 4 year
21:04 < seele> i am a usability/design mentor for the OpenUsability Season of Usability project
21:04 < seele> and also work as a designer in my Day Job doing pretty much the same thing i do here
21:05 < seele> what is it that i do? well, i try to make floss software (particularly the KDE flavor) easier to use
21:05 < seele> i do research, design, and testing, but also work very closly with developers as they are coding
21:05 < seele> so i imagine many of you have heard of this usability thing already.. or else you wouldnt be here
21:05 < seele> (or you think Jonathan's catchy subtitle to my talk was funny)
21:06 < Earthwings> seele: which company are you working for?
21:06 < seele> Earthwings: User-Centered Design, Inc. is a small human factors engineering and design firm in the Washington, DC area
21:06 < judith_h> seele: no but even though it's funny ;)
21:06 < seele> I am Senior Interaction Architect, i manage projects and designers to get stuff done
21:07 < seele> yes, i will get to the part about removing options or whatnot soon :)
21:07 < seele> anyway.. in 20 words or less, what do you guys think usability is? (and no cheating on wikipedia)
21:07 < dwidmann> seele: what about cheating with other dictionaries/etc?
21:08 < seele> dwidmann: no cheating period!
21:09 < seele> ok.. so it seems like many of you have a partial picture of usability
21:10 < seele> if we take this from an ISO standard, usability means that a product must be 1) learnable, 2) efficient, 3) memorable, 4) prevent errors, 5) and be satisfactory to users
21:10 < seele> 1) learnable
21:11 < seele> this is the one no one usually picks when i ask the "what is usability" question
21:11 < seele> a product (in our case software) doesn't have to be so easy that you don't have to learn it
21:11 < seele> it is all relative
21:11 < seele> (no you want to prevent errors)
21:12 < seele> for a simple task, then you expect it to be simple
21:12 < seele> but for a complext task, it is OK to expect learning
21:12 < seele> you guys have all heard of a learning curve, correct?
21:12 < seele> the apex of the curve is relative to how complex a system is
21:12 < seele> so for example, printing a document is a pretty simple task
21:13 < seele> so you would expect no learning, or very little learning to be able to do that task
21:13 < seele> but something more complex like photo or imagine manipulation is degrees more complicated
21:13 < seele> and so it is OK if the user can't make a masterpiece at their first time sitting down with krita, gimp, or photoshop
21:14 < seele> you wouldnt want someone dumbing down an air traffic control board just because the goals was "anyone" should be able to use it
21:14 < seele> air traffic control is a very complex system, and in order to take advantage of the technology, some learning is reasonable
21:14 < seele> 2) efficiency
21:15 < seele> this probably shouldnt be #2 even though it is listed in the ISO spec this way, because it is related to learnability and memorability
21:15 < seele> but it is exactly what the word means.. an appropriate use of time and resources in relation to the complexity of the system
21:16 < seele> even if you made a simple printing function an easy to use 10 step wizard.. it isn't very efficient if you need to do that every time you print
21:16 < seele> clicking one button will get the same amount of work done than stepping the user through all the options and clicking 10
21:16 < seele> 3) memorability
21:17 < seele> this i think should be #2 because it is closely related to learnability
21:17 < seele> have you guys ever heard of the term information scent? it is an information science theory
21:17 * seele watches everyone look up "information scent" on wikipedia
21:18 < seele> information scent is a search behavior theory
21:19 < seele> information scientists believe we search using the "gathering" skills of our "hunter-gatherer" basic instincts
21:19 < seele> what it turns in to from a UI perspective is how easy it is to find information (functionality or options) from it's surface presentation
21:19 < seele> so.. what options you expect to be under menu X before you open menu X
21:20 < seele> by having good information scent (good labels, structure, etc.), you can use the UI more efficiently because you can stack layers of information
21:20 < seele> Forky: sortof, yes
21:20 < seele> basically you are leaving hints to the user to find the information on their own
21:21 < seele> they don't need to Remember where options are, but only follow a logical path
21:21 < seele> this saves the user's cognitive resources to go on and solve more complex problems
21:21 < seele> instead of using them on the UI
21:21 < seele> remember that a UI is a tool to solve a problem, the UI shouldn't be the problem
21:22 < seele> #4 error prevention
21:23 < seele> have any of you guys heard of jef raskin?
21:23 < seele> he was a famous designer who worked at apple (i think he was employee #12 or something close)
21:23 < seele> he was a true user advocate in the sense that he believed no matter what the circumstance, the computer should do no harm
21:24 < seele> also, many of you are probably familiar with the practice of confirming actions, particularly destructive ones, yes?
21:24 < seele> error prevention is more than just confirming a destructive action
21:24 < seele> it is preventing the user from having to make that decision to start with
21:24 < seele> we dont see this too much in the desktop environment because we model a lot of our workflows off of existing software
21:25 < seele> but i see this a lot in other expert systems
21:25 < seele> "Are you really sure you want to do that? It will cripple the system and you will lose all of your data"
21:25 < seele> (Well then, the user should have never been able to choose that option from the top level of a UI)
21:26 < seele> even so, there are a lot of confirmations we do in the desktop environment which could be prevented if we shaped the workflow differently
21:26 < seele> the user should never have to select Cancel
21:26 < seele> the last part of the Usability ISO standard is satisfaction
21:26 < seele> #5 satisfaction
21:26 < seele> (keeping it consistent ;)
21:27 < seele> satistfaction is the quality many people tend to identify with usability
21:27 < seele> but it is also the last dimension in the spec (and i believe the least important of all we've talk about)
21:27 < seele> satisfaction is important. if a user finds a system pretty or cool, they will want to use it more than the other system that is not
21:28 < seele> users will sacrifice ALL of the other parts of usability (learnability, efficiency, memorability, error prevention) for satisfaction
21:28 < seele> our goal is to help them not make sacrifices
21:28 < seele> ive seen users in usability tests take 3, 4, 10 times longer to complete a task in a terrible UI that looked pretty
21:28 < seele> and complete the same task in a different not-as-pretty UI much much faster
21:29 < seele> and they still like the pretty UI
21:29 < seele> this is an advantage and disadvantage: it gives us room to experiment because users will be forgiving if we give them options they want or other cool toys
21:29 < seele> but at the same time, we should use eye candy as a crutch to solve problems. we should solve problems and make our solutions beautiful
21:30 < seele> so.. any questions so far?
21:30 < seele> er.. *should NOT
21:30 < seele> thanks for the correction
21:30 * seele can't wait to hear the comments when people read the logs..
21:30 < seele> wow.. halfway through already
21:30 < seele> haha
21:31 < seele> yes
21:31 < seele> oh, on the topic of learning
21:31 < seele> have you guys ever heard of a one-time learning event?
21:31 < seele> ok
21:32 < seele> often when you are reviewing a new ui or workflow, one of the questions you may ask yourself is "will the user figure this out"
21:32 < seele> and the first time around, sometime the user doesnt. they can't find the options, they don't know the label, they can't figure it out.
21:33 < seele> BUT.. if they have someone show them how to do it, they find the solution on a webpage, or painfully figure it out, it makes sense to them and they remember it for next time
21:33 < seele> we call this type of experience a one time learning event
21:33 < seele> they won't figure it out the first time, but if they can do it once, they will remember how to do it
21:33 < seele> this is something that is often forgotten in UI design
21:34 < seele> yes, that is another question
21:34 < seele> you can break users out in to different dimensions.. one of them being problem solving skills and related motivation
21:34 < seele> some users are not afraid to try something and fail
21:34 < seele> other users will not try new things in fear of failing
21:35 < seele> the users who do not explore are at risk of never exploring options hidden behind a single-learning event
21:35 < seele> that is why doing user research on your product and understanding who your users are, their motivations, environment, and their skill (it's not JUST about their skills) is important
21:36 < seele> this leads me in to a discussion about universal usability
21:36 < seele> has anyone heard this term before?
21:36 * seele watches the wikiers
21:36 < seele> haha
21:36 < seele> almost
21:37 < seele> universal usability is the belief that any user, no matter their skill, background, motivation, experience, etc. should be able to pick up and use a product
21:37 < seele> in cases where products must serve the general public (such as evoting machines), this could be a valid argument
21:38 < seele> but there are very few products that focus on EVERYONE
21:38 < seele> even so, the concept of universal usability would be extremely difficult to achieve
21:38 < seele> especially in expert systems or systems which knowledge workers use
21:39 < seele> the ipod. why does everyone use that as an example of universal usability..
21:39 < dwidmann> seele: for lack of better example?
21:39 < seele> the ipod is an excellent example of very sexy tech that people forgive its shortcomings for
21:39 < seele> it doesn't do everything everyone wants, and not everyone can use it or figure it out
21:40 < seele> but because it is so damn beautiful, most people dont care
21:40 < seele> i like my ipod, but i wasn't born how to use it (and even now make mistakes trying to find options)
21:40 < seele> anyway..
21:40 < seele> universal usability
21:41 < seele> universal usability forces designers to lower the bar of the average user to accomodate more people
21:41 < seele> this is why it hurts expert systems
21:41 [ clinx ] [ freeflying ] [ jussio1 ] [ NickNak ] [ seele ] [ Xand3r ]
21:41 < seele> if there is a pocket of experience or information that a certain group of users may not have or be able to attain, it must be removed
21:42 < seele> yes, but apple traditionally does not follow a user-centered design approach. they believe that designers know better
21:42 < seele> it's only been recently that they've done usability testing.. everything before was market research (which is very different)
21:43 < techno_freak> seele, with 15 mins more, can we get with contributing to usability in kubuntu/kde? :)
21:43 < seele> dwidmann: that is a possibility. this will help expert users retain their expert options, but not get in the way of other types of users.
21:43 < seele> techno_freak: yes, sorry.. this is taking much longer than i thought
21:43 < seele> anyway.. there are three domains of usability i work in: User Research, Design, and User Testing
21:43 < seele> together, these are part of the user-centered design process (UCD)
21:44 < seele> it is a design philosophy which keeps users in mind while creating a system for them
21:44 < seele> User Research is often linked to the Requirements stage of software development
21:45 < seele> so when you developers are thinking of new features to integrate in to a software, or a new software to develop from scratch, here are some things you should be thinking of in addition to your functionality spec and other things
21:45 < seele> Who are your users?
21:45 < seele> try to come up with some example users who you are building the software for
21:46 < seele> even if you are a user, try to keep yourself out of the list, it makes it too easy to do what you want instead of what they need
21:46 < seele> What will you users be doing?
21:46 < seele> too many times, not all of the functionality is documented or fully planned
21:46 < seele> a single function might be discussed and mapped, but the other functions of a system aren't thought of until afterwards
21:47 < seele> what happens is you dont have a complete picture of how your users are using the system, and if the functions are integrated properly
21:47 < seele> mapping out screen flows before you begin coding will help document your functionality (so you aren't trying to squeeze or force options in later) and give you a reference for when you code
21:47 < seele> What problem are you trying to solve?
21:48 < seele> This is the big one, your Vision Statement
21:48 < seele> having an idea of your goals before you start will help development. it is related to the "What are my users doing?" question
21:49 < seele> if you don't know what problem you are trying to solve with your software, you can't know what to provide users or what they will expect
21:49 < seele> plus, in larger projects, it is a good idea that all the developers are on the same page
21:49 < seele> it prevents a lot of roadmap issues later on
21:49 < seele> any questions so far?
21:50 < judith_h> seele, what is the worst example of usability you have ever seen?
21:50 < seele> being able to answer those three questions will give you a head start. on kde techbase there are user research templates to help guide you
21:50 < seele> judith_h: hmm.. well there is a classic screenshot of a dialog with about 100 widgets and matching labels squeezed on to a configuration dialog
21:50 < seele> but i will give a more realistic example
21:51 < techno_freak> seele, i have seen those templates, what if i want to do a contextual interview kinda keeping that am not the developer but want to help the dev by doing UI reviews/tests for him?
21:51 < seele> hmm.. too many questions not enough time
21:51 < seele> techno_freak: yes, that is a very good way to help them
21:52 < seele> ok.. i guess we will get in to open source usability 101 now..
21:52 < seele> first step: contact the project you want to work with and express interest in working with them
21:52 < seele> you dont want to surprise developers by dropping a usability report in their inbox
21:52 < seele> it will just make them angry, even if the work was good
21:53 < seele> second step: start small. open source is a community based on commitment and trust (after the getting work done thing)
21:53 < seele> start with a small activity such as interviewing users, conducting a survey, or doing a small UI review. this will help developers get used to your methods, get used to you, and know what to expect from your work
21:53 < seele> third step: maintain your relationship with the project
21:54 < seele> design is an iterative process, just as open source is iterative development
21:54 < seele> developers are wary of seagull designers: designers who fly in, poop on their software, then fly away
21:55 < seele> developers are in for the long hull, they are committed to their project and want to see it succeed
21:55 < seele> they dont want to work with a designer who will ask them to change a bunch of things, then disappear and not be able to comment on the results
21:56 < judith_h> makes sense seele
21:56 < seele> obviously i dont want to see any unhealthy marriages, but keep in mind that you will make a bigger difference in one project than doing a bunch of little activities for a bunch of projects
21:56 < seele> so i'm sorry we didnt get through everything i made notes on to cover, i guess i need to become a faster typer
21:56 < seele> techno_freak: yes.
21:57 < seele> design is a VERY iterative process.. it is important for both you the designer and the developer you work with to understand this
21:57 < seele> i've been working on a KDE GRUB UI for the past few months with Aretemis_Fowl
21:57 < seele> i cant tell you how many times i've asked him to go back and forth on little design issues
21:57 < seele> yes, GRUB configuration tool
21:57 < techno_freak> seele, one last question if your are closing up, do we have anything like KDE-HIG for Ubuntu/Kubuntu to which we can contribute to?
21:57 < seele> similar, but I'm hopeing much more useful and usable
21:58 < seele> we're having problems with automagic though
21:58 < seele> techno_freak: good question
21:58 < seele> for Ubuntu designers, you will want to look at the GNOME HIG. It might be a little out of date, but one way to get started with contributing would be updating it!
21:58 < seele> for Kubuntu designers, you will want to look at the KDE4 HIG and the KDE3 User Interface Guidelines
21:59 < seele> these are under active development, and so if you have any questions it would be best to ask me or Ellen Reitmayr who sometimes lurks in #openusability
21:59 < seele> other resources: look at other interfaces that do similar things
21:59 < seele> not just in your own environment, but in windows, kde/gnome, macosx
21:59 < seele> you'll find similar and very different solutions
21:59 < seele> you will want to look closely at the context of the solutions and make sure it is a good fit before you use it as a model
22:00 < seele> copying a solution will not solve a problem, the goal of reviewing other software is to get inspiration when you have no other better ideas
22:00 < dwidmann> seele: what is that grub configuration tool called, and where can I get it?
22:00 < seele> in the example of the GRUB config UI, after we looked at the Mandriva and Suse UIs, we realised we could do A LOT better
22:00 < seele> but what we did do was look at which options they thought were important for users to help us build our funcitonal spec
22:01 < katastrophe> seele: is it kgrubeditor?
22:01 < seele> katastrophe: yes
22:01 < seele> dwidmann: there is a work page on the wiki with links to oru progress
22:01 < seele> i think it is in Artemis' PPA, but i'm not sure
22:02 < seele> so it looks like i'm out of time
22:02 < seele> i'm in #kubuntu-devel and #openusability all the time, so feel free to ping me with questions
22:02 < Riddell> thanks seele
22:02 < GreySim> Thanks seele.
22:02 < katastrophe> seele: thanks!
22:02 * seele waves
22:02 < Schnullerbacke> thanks a lot seele
22:02 < techno_freak> thanks a lot seele, that was very informative :) hope to contribute to usability, which means bugging you ;)