HIG Meeting Log: 2010-11-12

aday: kirk: hi

kirk: good day

kirk: I haven't missed the HIG discussion, have I?

aday: not much of a turn out today, unfortunately...

aday: i saw you've been doing some work on the wiki. anything you're keen to talk about now, or shall we try for another time?

kirk: Well, I have some thoughts on the pattern template that exists, and was going to ask for feedback on the pattern I started to put together - but it can cerrtainly wait. Given more time I could flesh it out a little more too

aday: looks

aday: cool - this is really useful

kirk: I was hoping calumb could weigh in, as I was following his ideas of what a pattern constitutes

aday: gives a good idea of how patterns could be approached

kirk: I wanted to make sure it was true to his vision

aday: heh heh

aday: the real advantage of this kind of approach is that it makes the alternatives really clear

aday: it makes it difficult for a dev to think that there is one solution to each kind of problem

aday: i think that is what calum was aiming for

aday: the question, i think, is how to make a library based on these kinds of patterns dynamic/updateable

aday: because that was another goal that we had

aday: kirk: one solution would be to have a couple of layers - you'd have a set of 'problems', each with a set of solutions patterns

kirk: So looking at the Progress Indication page I started, you're suggesting that the display of progress is the problem, and that the 3 types I've started to outline are solution patterns?

kirk: just clarifying, I think it sounds good

aday: kirk: yeah...

aday: we should probably play around with draft structure, to see how it would work

aday: you might end up with some solutions which span problems, for instance

aday: (which could be ok)

aday: kirk: have you got an idea of other 'problems' that might be covered?

kirk: you mean for progress display, or the "pattern list" calum had set up?

aday: brothers and sisters for progress display

aday: (rather than children)

kirk: nod

kirk: if I had to make a list I would start with good design principles - things like undo, mental model, colour usage, consistency. I'd take the principles and think about how they can manifest in desktop apps

kirk: that would lead to the list that I think calum was starting to put together

kirk: we're not trying to come up with new design ideas here, just document the existing good ones

kirk: so relying on good design principles would be a good start

aday: agreed

aday: i wonder how many of those principles could be incorporated into patterns per se? how would colour usage or consistency fit, for example?

kirk: is thinking

kirk: perhaps not all

kirk: I was using them as a sedd for creating the list

kirk: might not be 1:1 as you suggest

aday: mmm. i think that's fine - we can have an introductionary section for general stuff if necessary

kirk: agreed

aday: JanCBorchardt: hey, you here to talk hig?

aday: i guess not :-P

kirk: that's a maybe at best

aday: kirk: i find it quite hard to think of obvious 'problems'

kirk: I think it will be even harder to say that we've thought of ALL the problems

aday: mmm

kirk: Such is the problem with a conceptual document like this

kirk: we can't document the world

kirk: we just need to focus on guidelines

kirk: so what guidelines do we want to give to the Gnome community: designers, developers, marketers, etc

aday: kirk: good question. shall i list a few things, and you tell me what you make of them?

kirk: great idea

aday: i guess i see it as spectrum from low to high level...

aday: i can see about 4 levels

aday: 1. low level implementation specs (eg: 'use this kind of capitalisation for headings')

aday: 2. mid level implementation specs (eg: throbbers vs progress dialogues)

aday: 3. problem specific design advice (eg: don't provide too many configuration options)

aday: 4. fairly generic design advice (eg: keep it simple, consider the needs of your users)

aday: so i think the question is which part of that spectrum we want to concentrate on

aday: the existing hig mainly covers the extremes - 1 and 4 in my list

kirk: I can guess that it is the lowest level that will be of most value to developers

kirk: in the short term

kirk: level 2 might be valuable to designers and devs

kirk: level 3, hmm - who would be the primary audience there?

kirk: level 4 would be "required reading" or something like that - difficult to actually apply to any particular problem though

aday: people who want to learn about design... perhaps devs

aday: yes, so 4 is a possible introduction

aday: 1 is actually quite generic

kirk: 1 wil be the most voluminous though

aday: possibly, though it should be quick to navigate all the same

kirk: I agree with those levels

kirk: they're bang on in my mind

kirk: so where do "problems" fit, and where do "patterns" fit?

aday: i think that's the main question

kirk: problems feel somewhere around 2 or 3

aday: 3 could be our problems, and 2 solutions

kirk: 2 could be possible solutions - or do we want to close that door and just list the accepted solutions for Gnome?

aday: kirk: one of the ideas for the hig was to try and make it a dynamic resource - having a space to add new solutions would be quite good from that pov

- 17:35 -

kirk: happy to hear that

aday: kirk: i'm terribly sorry, but i seem to have started another etherpad

kirk: lol

aday: just playing with some possible patterns -> http://openetherpad.org/ODXteARqt5

aday: call it a thought exercise

kirk: what level are these at?

aday: each heading is a 'problem', roughly equivalent to the beginning of your progress display pattern

kirk: yeah, so header is about a level 3, and pooints are level 2-ish

kirk: still just an exercise right? Some of my tings I'm putting in there are rough

aday: kirk: sure

kirk: Interesting that progressive disclosure shows up in two things

kirk: I see it also as a way of preventing errors

kirk: as well as managing complexity

aday: kirk:maybe that means that some solutions should be under more than one problem?

aday: this structure lets us ask two questions, i think:

aday: 1) is there anything that needs to be covered that cannot be accomodated?

aday: 2) are each of the problem/solution items equivalent?

kirk: your earlier point also makes another point for me - this does not have to be a structured document, it can be more like a wiki where pages can live on the same level but are related through links. So in that way we could have a level 2 thing point to multiple level 3 things without worrying about which is its true parent etc.

aday: so longing that it doesn't get too spaghetti like

kirk: agreed

kirk: I think the answer to your second question is no - some of these things like coverflow are a different level than thinks like Encouraging exploration

kirk: Coverflow is closer to a solution, whereas Encouraging is more of a guideline/concept

aday: agreed

kirk: Do you hve an example of an editable list?

kirk: not sure what you're refering to there

aday: kirk: http://live.gnome.org/UsabilityProject/HIG3/EditableLists

kirk: thanks

kirk: Browsing data and Viewing data feel very similar to me

aday: agreed

aday: kirk: what would wayfinding include if that were a problem area?

kirk: ways to help the user get to where they want to be, like breadcrumbs, Home buttons, history, etc. Not sure about trees though

kirk: I'm just marking what I think might be some higher level umbrella categories for each header

aday: so if i merge those two sections into 'wayfinding'?

kirk: that might feel right, if we compare to the throbber example

kirk: throbber sits at level 2 as a solution, as would bookmarks, history, breadcrumbs etc

aday: looking at things from the user's point of view seems like it's quite high level - right up there at 4

kirk: true

aday: kirk: i'm feeling quite satisified that this kind of structure could accomodate the material that we want to cover

aday: my questions at this stage are - does this map onto the problems encountered by our target audience?

aday: and is this accessible/efficient for readers

aday: i mean, what will a dev think if they encounter this kind of resource?

kirk: as a designer I'd love it

kirk:

aday: ha ha

aday: some of these headings might not be very useful for devs. i can't see many of them saying 'i have a problem with the intelligability of my ui'

kirk: no

kirk: have we ever surveyed devs to find out what they use the current HIG for, and what kind of info they think it should contain?

aday: i have anecdotal evidence that there is a range of usage patterns

aday: problem solving is definitely one

aday: though quite what problems i'm not sure

aday: *some* have sat down and read large portions of the hig though

mclasen: aday: are you interested in feedback on the editable list example ?

aday: mclasen: general feedback would be useful. we're not so concerned with details at this stage

mclasen: some things that developers tend to get wrong (and that are infuriating for me as a user) are e.g. selection handling vs removal

mclasen: if you remove the selected item(s) where does the selection go ?

kirk: you mean the focus? or the item removed?

mclasen: I mean if the remove button removes the selected item, there will be no selection afterwards

mclasen: unless you arrange things so that the next item is selected

mclasen: if removing multiple items is common, it is very annoying to have to select them one-by-one

mclasen: instead of just holding the delete key down

aday: mclasen: is that a problem that is specific to editable lists, or do you encounter it elsewhere?

mclasen: comes up whereever you can delete items from a list

mclasen: so yes, editable list, I'd say

mclasen: another thing that developers might get wrong is when to allow manual reordering

mclasen: (only when it is relevant)

aday: mclasen: we're thinking about going for a problem/solution format (with multiple solutions)

mclasen: and how to handle addition if there is some implicit ordering (e.g. alphabetic)

aday: mclasen: these definitely sound like notes we should add to that pattern

kirk: so it sounds like we realy need to provide information on how to handle spcific widgets in detail, not just as a general description of the solution

aday: kirk: agreed. i think we can accommodate that though

mclasen: aday: last note: the empty list screenshot should have the remove button disabled

mclasen: and the edit button too)

aday: mclasen: cool, thanks

aday: kirk: so it seems like we've got a possible approach here. needs some more work, but this is something we can run with at least as a prototyping

aday: *prototype

kirk: agree, feels natural to continue down this path

aday: cool. i'll maybe send an email with our progress and elaborate some of the draft material

aday: the configuration and progress patterns could easily be shifted into the new format, for example

godbyk: I'm back now.

godbyk: Looks like I've got some catching up to do!

aday: godbyk: shall i fill you in quickly? i'd be interested to hear your thoughts

godbyk: Sure.

aday: godbyk: so we were trying to figure out how to incorporate a focus on 'problems', but also how to encompass a range of levels of abstraction/specificity

godbyk: Okay.

aday: and we were wondering about structuring things around a problem/solution format

aday: where problems are a bit more abstract than solutions

aday: so a problem might be configuration, and a solution might be 'preferences windows'

aday: and me and kirk brainstormed a possible solution - http://openetherpad.org/ODXteARqt5

aday: this is all very exploratory, i'd hasten to add

aday: so it would be great to hear if you've got different ideas

godbyk: I was just skimming through the pad.

godbyk: It looks like the 'problems' (the bold headings) are fairly categorical or related to a principle/guideline.

aday: yes, so the 'problems' could also talk about generic advice

godbyk: I see.

godbyk: In most cases, it looks like your bulleted items correspond to my sense of patterns.

godbyk: And the headings correspond (roughly) to design principles.

godbyk: The levels mentioned at the top of the pad may be somewhat analogous to the different levels of detail of design principles mentioned in About Face 3.

godbyk: I can add their four levels and definitions to the bottom of the pad if you'd like (for reference).

aday: godbyk: that could be useful. the main question is 'what do we want to include?' the levels were meant to indicate the document's scope

godbyk: aday: As far as what to include, I would say that you'll want to cut across the different levels to some degree.

godbyk: aday: Using the categories from About Face, I'd say much of the HIG would focus on interface-level principles and behavioral principles with just a smattering of conceptional principles and design values.

godbyk: I wouldn't expect a developer to be able to pick up our HIG and become an expert in all design matters.

aday: godbyk: no. one clear question is how we anticipate the resource to be used

godbyk: I think that the HIG should focus primarily on GNOME-specific stuff but provide references and links to resources to explore the bigger-picture issues of usability.

godbyk: Have we discussed how we expect the HIG to be used?

godbyk: (I don't want to retread that if it's been settled already.)

kirk: What are the opinions on putting out a quick survey to Gnome developers about their use of the existing HIG, and what more they'd want?

godbyk: kirk: I'm all for that.

godbyk: I have other things I want to pick developers' brains about, too. Depending on the scope, we may be able to fold some of those questions together into one survey.

aday: kirk: yes, that would be useful

aday: need to be careful about survey design - self-reporting of behaviour is notoriously inaccurate

aday: plus asking 'what do you want' doesn't necessarily answer the question of 'what do developers need?'

kirk: agreed

godbyk: aday: True. But given that the developers are scattered about, it's hard to do an ethnography study.

kirk: godbyk: I wonder if combining with another topic would cloud the waters and make it overly long

kirk: we also don't need to restrict this to Gnome devs, do we?

aday: godbyk: true. but we have other data sources. mclasen was telling us about some of the common UI mistakes he observes devs making, for instance

godbyk: kirk: The study than Jan-Christoph and I were putting together was to try to figure out what developers think of designers and their work and how developers and designers could work together, etc.

godbyk: aday: We might also be able to pull stats from the web server to see how often the HIG is accessed online.

godbyk: Should we spend a few minutes on drafting some survey questions? Or would you like to continue discussing the current pad? (Or call it quits for today?)

kirk: I need to focus on work today - but I think we should start thinking about a survey, as we always run into this question of not knowing what our users actually want or need

aday: i need to quit! start with research questions though, not survey questions

godbyk: No problem.

godbyk: Here's a pad for the survey stuff: http://openetherpad.org/hig-survey

godbyk: I'm going to grab some lunch, but I'll play with the HIG stuff some more in the pads.

kirk: just a final thought - it might be nice to have some questions in the survey that ask for feedback on some example work we've got done

godbyk: kirk: Great idea!

aday: kirk: agreed

kirk: For example "Which parts of this are the most useful, least useful" What more would you want to see, etc

kirk: OK good, my last thought is a good one, I'm bowing out now

aday: the main problem here is extrapolating into the future. how people treat the current hig doesn't necessarily predict how they will use the next gen hig, for example

kirk: true

aday: kirk: good talking to you

kirk: but their needs aren't changing regardless of what the HIGis doing

aday: kirk: but the next gen hig may change their perceptions of what their needs are

kirk: heh

kirk: then HIG4 needs a survey too

kirk: we should always continue tor efine the HIG, but right now we have 3 inputs, the old, the draft, and the users. We should not worry yet how users will usde the future revision as we can't predict nor measure that

kirk: once it is out we then can start with it as an input to further refinements

kirk: anyhow, great chat today! I'm heading out. Do we want to schedule something again for next week?

aday: kirk: i'll be in touch

godbyk: 'kay.

godbyk: Thanks for hanging around and filling me in!