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: 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: 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: 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
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
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
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: 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
kirk: Do you hve an example of an editable list?
kirk: not sure what you're refering to there
kirk: Browsing data and Viewing data feel very similar to me
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
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
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: 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
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
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
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?'
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
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: 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: Thanks for hanging around and filling me in!