2010-10-28 HIG3 IRC Meeting Log

kirkbridger 28/10/10 16:10:29 Seems really quiet here - am I in the right place/time for the HIG discussion?

andreasn 28/10/10 16:11:11 hi KirkBridger!

calumb 28/10/10 16:11:20 KirkBridger: an hour early I think...

kirkbridger 28/10/10 16:11:20

ah, hmm - ok 28/10/10 16:11:33

andreasn 28/10/10 16:11:36 oh, it's today? I thought it was yesterday I'll grab mpt (we're at the same conference) and make sure he attends 28/10/10 16:11:50

aday 28/10/10 16:27:56 KirkBridger: hi! oops... 28/10/10 16:29:06 Kirk: hi 28/10/10 16:29:15

kirk 28/10/10 16:29:45 Hey

aday 28/10/10 16:31:29 Kirk: you made it! got irc working in the end, then?

kirk 28/10/10 16:32:32 you bet

aday 28/10/10 16:50:46 hmm, no wers

aday 28/10/10 17:01:15 so is it meeting time? mpt: you tuned in? 28/10/10 17:01:20

mpt 28/10/10 17:02:32 aday, yes, but (1) the Internet connection here is a bit dodgy and (2) I'm in an important meeting right now I'll pay as much attention as I can 28/10/10 17:02:38

calumb 28/10/10 17:03:12 Is anybody logging the chatroom?

aday 28/10/10 17:03:36 calumb: i can do that

calumb 28/10/10 17:03:43 Cool...

aday 28/10/10 17:05:32 the brief agenda i put together was 1) structure 2) format and 3) content marginally more detail is here - http://mail.gnome.org/archives/usability/2010-October/msg00015.html 28/10/10 17:05:41 does that sound ok with everyone? 28/10/10 17:05:49 JanCBorchardt: welcome, we just got started 28/10/10 17:06:02

jancborchardt 28/10/10 17:06:09 hey all. sorry, took the wrong train

calumb 28/10/10 17:06:26 I guess we can also discuss whether we're aiming at GNOME-only, or something open to KDE/other desktops...

aday 28/10/10 17:07:10 calumb: agreed - it might make sense to talk about that when we cover structure

calumb 28/10/10 17:07:46 ok...

aday 28/10/10 17:08:06 okay, first topic - structure - should the HIg be YAPL (Yet Another Pattern Library), a mix of a pattern approach and something else, or just something else entirely? Kirk: you had some thoughts here, didn't you? 28/10/10 17:08:16

kirk 28/10/10 17:08:27 Sure! they revolve around patterns 28/10/10 17:08:38 YAPL will be a lot of work, probably reproducing existing pattern libraries if we stick to strict pattern definitions 28/10/10 17:08:59 So I'm not sure out time is best spent there 28/10/10 17:09:09 However I think patterns are a great way to capture information 28/10/10 17:09:17 So I'd like to see the HIG use patterns to inform the ideas presented, but not just be YAPL 28/10/10 17:09:34

aday 28/10/10 17:09:55 Kirk: can you give an example?

kirk 28/10/10 17:10:01 Sure Look at a web pattern like breadcrumbs 28/10/10 17:10:10 There's a pattern to them - they solve a common problem 28/10/10 17:10:21 The pattern describes them, when to use them, etc. It doesn't describe implementation or design though 28/10/10 17:10:41 Is there value in us writing another version of a breadcrumb pattern, or could we just use existing pattern libraries to emphasize a point or design decisoin we're documenting in the HIG 28/10/10 17:11:29

calumb 28/10/10 17:11:38 One thing I would say in defence of "YAPL" is that there aren't really any desktop pattern libraries out there already. other than the bits MS have woven into the Windows 7 guidelines -- the vast majority are for web. So there could be some overlap, but some important differences too.

kirk 28/10/10 17:12:13 That's true - APple has a HIG of sorts too, and KDE's is still at a draft stage Here's Apples: http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html 28/10/10 17:12:35 MS's is a massive document over 500 pages, not for the light of heart 28/10/10 17:13:00 Here's MS's: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=e49820cb-954d-45ae-9cb3-1b9e8ea7fe8c 28/10/10 17:13:16 or one of them, anyways 28/10/10 17:13:23 And for completeness, here's KDe's: http://techbase.kde.org/Development/Guidelines 28/10/10 17:13:53

calumb 28/10/10 17:14:53 Here's the online version of the Windows guidelines: http://msdn.microsoft.com/en-us/library/aa511258.aspx

kirk 28/10/10 17:15:11 Nice - thanks!

calumb 28/10/10 17:15:23 And the iPad ones, which might be interesting http://developer.apple.com/library/ios/#documentation/General/Conceptual/iPadHIG/index.html

aday 28/10/10 17:16:31 so what is gnome specific about a pattern? let's say you write a pattern on toolbars - do we have anything gnomey to say there?

calumb 28/10/10 17:16:39 Here's an example of where Windows 7 guidelines include some patterns: http://msdn.microsoft.com/en-us/library/aa511484.aspx

godbyk 28/10/10 17:16:57 One positive aspect of having the pattern library in the HIG is that it consolidates all of that information in one place. We should strive to make it as easy as possible for developers et al. to find the information they're looking for.

aday 28/10/10 17:17:22 calumb: wow, that's thorough

kirk 28/10/10 17:17:41 could a link or reference to the pattern suffice there, or should we make local copies, in case ther esource changes?

calumb 28/10/10 17:17:58 I think the trick with patterns is to 'zoom out' enough that you find the GNOME-specific stuff... e.g. we might not have anything to say about 'toolbars' per se, but we might have something to say about toolbars in browser-style applications.

kirk 28/10/10 17:18:34 maybe it's the word pattern that is tripping me up then - are you describing guidelines?

aday 28/10/10 17:18:41 calumb: i like the idea of that. i'm keen to make this resource lightweiht *lightweight 28/10/10 17:18:46 Kirk: yes, i think we do need to be clearer what we mean by that. what would you describe this as? http://live.gnome.org/UsabilityProject/HIG3/EditableLists 28/10/10 17:19:49

calumb 28/10/10 17:20:49 My definition would be that a pattern defines a widget grouping and interaction model that incorporates several guidelines, but perhaps that's something we should define before we go any further s/incorporates/emobdies 28/10/10 17:21:25

kirk 28/10/10 17:21:44 aday: that feels a little lower level than what I would call a pure pattern, though it has elements of a pattern in it

calumb 28/10/10 17:22:02 We originally kind of started from this definition: http://www.uie.com/articles/elements_of_a_design_pattern/

jancborchardt 28/10/10 17:22:49 maybe we should have a problem library that links to solutions?

shaunm 28/10/10 17:23:38 as a developer of an app with an editable list, I actually find that page very useful

jancborchardt 28/10/10 17:23:45 when you have a basic design problem, you can look it up and then decide which pattern / solution is best for your particular thing.

aday 28/10/10 17:24:18 JanCBorchardt: the idea was to cross reference patterns. each pattern would say 'an alternative is pattern x'

kirk 28/10/10 17:24:41 That page does look good Here's another interesting article at UIE about pattern libraries vs component libraries: http://www.uie.com/articles/components_vs_patterns 28/10/10 17:24:57

jancborchardt 28/10/10 17:24:59 aday: yep ? the question is: who is our target audience? (I guess developers) so we should cater to them with this, shouldn?t we? 28/10/10 17:25:17

kirk 28/10/10 17:25:51 JanCBorchardt - I like that question - who is the key stakeholder in craeting the HIG? I really like this post on what is a pattern - I think it defines a pure pattern for me: http://blogs.infragistics.com/blogs/ux/archive/2009/02/03/what-is-a-design-pattern-and-why-use-them-for-quince.aspx 28/10/10 17:26:36

aday 28/10/10 17:26:38 agreed

calumb 28/10/10 17:26:41 UI designers (both those familiar and not familiar with GNOME), and developers who don't have access to UI designers, would be my first attempt at an answer to that Kirk: yes, that's a nice definition... kind of boils down the uie.com definition to the essentials. 28/10/10 17:27:58

kirk 28/10/10 17:28:46 Here's a key phrase: Patterns, as such, are discovered, not invented; they can come from an invention, but they must be seen to apply in multiple solutions

aday 28/10/10 17:28:54 yes, i like that too

mpt 28/10/10 17:28:56 Probability of reading the guidelines at all <- HIG length -> Probability of getting something wrong that the guidelines don't specify

kirk 28/10/10 17:30:02 So using that defn, the page you linked to feels like more than a pattern, but in a good way @mpt - I think usability of the HIG should be a key evalaution metric of its success. Length in a digitial world might be something we can work around (i.e. don't dump it into a PDF like Microsoft did) 28/10/10 17:30:56

aday 28/10/10 17:32:01 i think it would be helpful to talk about the pattern template at some point - that would help clear things up

calumb 28/10/10 17:32:01 Right, so I think one advantage of a pattern library, as opposed to the old HIG, is that it's not some monolithic document that people feel they have to read... it should be something they can benefit from by searching or browsing when they want to or need to. (Although we may need some kind of supporting document as well, I dunno...) I would say it should almost be fun to look through the pattern library, but maybe that's just me 28/10/10 17:33:03

thos 28/10/10 17:33:15 calumb: there were several "design problems" in the new control center that might be patterns. For example, search boxes, help buttons and privilege escalation (i.e., entering a password to make changes).

aday 28/10/10 17:33:26 calumb: agreed. i like the idea of supplementing our patterns with high level advice of the kind that mpt wrote - http://live.gnome.org/UsabilityProject/HIG3/HandlingErrors * i also like 28/10/10 17:33:38

jancborchardt 28/10/10 17:33:44 I guess we all agree on having a distributed document where you can pick out the things that you need (+ get linked to related ones).

calumb 28/10/10 17:33:59 thos: yep, they all sound like likely suspects.

aday 28/10/10 17:34:13 that combination of high level advice with a pattern library could be quite effective

thos 28/10/10 17:35:00 calumb: in fact, I think we still don't have an answer for how to implement help buttons, or entering a password to set certain preferences calumb: it would be good if any document would cover these 28/10/10 17:35:15 calumb: jimmac made some suggestions for the search entry, which might be useful to mention too 28/10/10 17:35:48 calumb: such as having a "search" icon on the right, that changes to "clear" when text is entered 28/10/10 17:36:24 calumb: not sure if this is too detailed though? 28/10/10 17:36:33

kirk 28/10/10 17:36:44 aday: that page mpt wrote seems to be more along the lines of design principles, practices, etc. I think that kind of info is key to include That kind of stuff won't be casually read though, and if we mix it in with the nitty gritty details I'm not sure it will be most effective 28/10/10 17:37:11

aday 28/10/10 17:37:11 thos: sounds like that should be a gtk widget

calumb 28/10/10 17:37:27 thos: that does sound like the sort of thing that would be better integrated right into the toolkit, but if it means writing a pattern first that turns into a spec for the gtk guys, so much the better...

thos 28/10/10 17:38:08 aday, calumb: yes, could be

aday 28/10/10 17:38:26 Kirk: indeed. i think it makes sense to separate out the serious reading from the problem solving sections

kirk 28/10/10 17:38:42 I'd be curious to hear a dev's take on the mpt page linked here - is that kind of guideline text helpful, or not concrete enough? There are some examples there but we can't describe all cases where these things should be applied

aday 28/10/10 17:39:01 any devs in the room?!

kirk 28/10/10 17:39:08 it might be more for the designers, which may not be the primary audience of this doc?

aday 28/10/10 17:39:38 i like that page, though it is maybe a bit verbose

shaunm 28/10/10 17:40:15 thos: I'm working on a library to manage help buttons and menus

thos 28/10/10 17:40:25 shaunm: yes, I remember you saying

shaunm 28/10/10 17:40:37 not 3.0 material

kirk 28/10/10 17:41:38 Let me throw this out there for structure discission. it is the structure we're using for a HIG-like document to be shared with design and implementation teams: not sure how to insert CRs into IRC client, so bear with me 28/10/10 17:41:50

shaunm 28/10/10 17:42:28 Kirk, aday: regarding usefulness of that page to devs, I think it's good, and I like the example-based language. visual examples might be a nice addition

thos 28/10/10 17:43:30 shaunm: did your plans cover help in dialogs? (control center is mostly dialog-like)

calumb 28/10/10 17:43:40 Right... for me, that 'preventing errors' page could be turned into a number of patterns more like the other ones we've been looking at... validating forms, saving files etc. But would that be the right thing to do? 28/10/10 17:44:03

kirk 28/10/10 17:44:40 1. Introduction 2. What's New 28/10/10 17:44:44 3. UX Methodology and Practices 28/10/10 17:44:49 4. Elements of Good Design 28/10/10 17:44:53 5. Project's Design Principles 28/10/10 17:44:58

godbyk 28/10/10 17:45:00 calumb: I was thinking the same: that the Errors page encompassed a few patterns. It'd be good to organize those patterns together, though. (Cross-reference them, put them in the same hierarchy branch.)

kirk 28/10/10 17:45:02 6. Project Design Components 6a) Page Flow and Navigation Principles and Patterns 28/10/10 17:45:08 6a)-1 Page Flow Principles 28/10/10 17:45:12 6a)-2 Page Flow Patterns 28/10/10 17:45:16

shaunm 28/10/10 17:45:17 thos: yes, definitely. but the traditional bottom-left location for help buttons conflicts with where privilege-escalation buttons are going these days

kirk 28/10/10 17:45:20 6b) On Every Page 6c) Page Layouts 28/10/10 17:45:24 6c)-1 Layout Templates and Patterns 28/10/10 17:45:28 6c)-2 Creating a New Layout 28/10/10 17:45:32 6d) Page Components 28/10/10 17:45:36

aday 28/10/10 17:45:39 Kirk: can you paste that somewhere else?

kirk 28/10/10 17:45:43 WHere?

aday 28/10/10 17:46:20 Kirk: pastebin would be fine, i think (unless anyone has a better idea)

godbyk 28/10/10 17:46:37 http://openetherpad.org/HIG-layout Then we can play with it if we need to. 28/10/10 17:46:46

thos 28/10/10 17:46:48 shaunm: yeah, which needs to be specified too

aday 28/10/10 17:46:55 godbyk: thanks Kirk: want to use that etherpad? 28/10/10 17:47:12

kirk 28/10/10 17:47:13 Good idea - in the etherpad THis is for a web app, so the "page" term might not apply 28/10/10 17:47:23 but we may want to intoduce Window flow instead, for example 28/10/10 17:47:41 or omit that section 28/10/10 17:47:45

godbyk 28/10/10 17:48:12 I was going to ask what all the page-flow stuff was.

kirk 28/10/10 17:48:14 this wil include patterns in section 6, as ways of further explaining design that needs to be adhered to, as well as providing external proof points mostly in 6d 28/10/10 17:48:27

shaunm 28/10/10 17:48:59 thos: yes, certainly. I guess what I'm saying is, if you guys figure out what you want them to look like, I'll try to make that happen

kirk 28/10/10 17:49:04 the main point I wanted to make is that we can put the desig guidelines and best practices somewhere else, and then also focus on deep dives which I thik is what I've heard here too 28/10/10 17:49:20

calumb 28/10/10 17:49:27 yep, I think so.

kirk 28/10/10 17:49:58 the Visual Index is a way to address mpt's concern that it be usable - not everyone calls a throbber a throbber, or a spinner, etc but everyone knows one when they see it 28/10/10 17:50:04

aday 28/10/10 17:51:02 i love the idea of a visual index

kirk 28/10/10 17:52:13 so should we start hacking at this structure, or is it too removed from Gnome to be helpful?

godbyk 28/10/10 17:53:07 A book I was just reading the other day had the following chapter headings: selection and manipulation, wayfinding, system control, and symbolic input.

aday 28/10/10 17:53:21 the main question for me right now is whether we go with a set of higher level guidelines in addition to patterns

godbyk 28/10/10 17:53:30 (We might want to come up with friendlier names, but I think those are better headings than the page-flow stuff.)

aday 28/10/10 17:54:27 can we push everything down into the patterns without reproducing similar advice over and over? Kirk: i'm still not quite sure what we're aiming for 28/10/10 17:59:21 anybody still around? maybe we should try and sum up what we've covered so far? 28/10/10 18:02:43

kirk 28/10/10 18:04:45 Let's try to figure out next steps for 15 minutes then

godbyk 28/10/10 18:05:21 Here's another example of a pattern library (of sorts): http://designinginterfaces.com/

aday 28/10/10 18:05:38 i think we have done some good work clarifying what a pattern is, and we can add that to our existing planning notes

kirk 28/10/10 18:05:40 Looking back at Allan's agenda, it looks like we might have answered part 1 about structure. It sounds like it should be a mix of patterns and implementation details?

aday 28/10/10 18:06:06 Kirk: yes let's put these notes here -> http://live.gnome.org/UsabilityProject/HIG3 28/10/10 18:06:39 the question of whether it's patterns + guidelines still seems to be open. i'd like to resolve that 28/10/10 18:07:42

shaunm 28/10/10 18:08:14 I think guidelines are useful.

godbyk 28/10/10 18:08:41 I'd like to see both, as well.

calumb 28/10/10 18:08:49 I think there are certainly going to be other concepts or documents that multiple patterns will have to reference.

shaunm 28/10/10 18:08:49 I also think redundant information in a document is a good thing, so I wouldn't worry about repeating stuff all over the place

kirk 28/10/10 18:09:44 redundant info makes it harder to maintain (though that might depend on how it is implemented)

jancborchardt 28/10/10 18:09:53 aren?t guidelines point 3 ? 6 in the table of contents: 3. UX Methodology and Practices 4. Elements of Good Design 5. Project's Design Principles 6. Project Design Components

kirk 28/10/10 18:10:45 yes, guidelines as well as edicts/prescriptive

aday 28/10/10 18:10:52 this is what i think of as high level guidelines > http://openetherpad.org/IAWZip4Ruf

shaunm 28/10/10 18:11:01 can I make a suggestion?

kirk 28/10/10 18:11:08 the aim was to ensure that the designers of the project, who have made design decisions, have those decisions understood and adhered to by other teams

aday 28/10/10 18:11:55 shaunm: no

shaunm 28/10/10 18:12:39 do things a bit more bottom-up, so that you have concrete stuff to work with. everybody go have a cup of coffee and then brainstorm a list of topics/pages/sections/concepts/whatevers that you think might be useful. don't worry about organization, and don't worry about whether you're sure it should go in. aday: too late 28/10/10 18:12:41 put it all in a big list. maybe write some content on some of them. then talk about it 28/10/10 18:13:02

calumb 28/10/10 18:13:15 Like http://pad.ubuntu-uk.org/ui-patterns ...?

shaunm 28/10/10 18:13:21 then you can ruthlessly kill anything that doesn't belong calumb: why yes 28/10/10 18:13:49

godbyk 28/10/10 18:14:55 Where was this half an hour ago?

calumb 28/10/10 18:15:49 Nah, we did want to take a step back and think about it again, so I didn't really want to mention it earlier

aday 28/10/10 18:16:27 ha ha... so there are some thing in that list that i'd like to remove, there are some things that look like patterns, and other things that look like guidelines

godbyk 28/10/10 18:16:29 calumb: So was the rethink aligned with this previous work? Or did it head off in a different direction?

calumb 28/10/10 18:17:24 godbyk: I think we've come to mostly the same conclusions, really.

aday 28/10/10 18:17:28 for example - 'feedback' = guideline, 'throbber' = pattern 'configuration' = guideline, 'preference window' = pattern 28/10/10 18:17:55

jancborchardt 28/10/10 18:18:02 aday: yep, the guidelines are more abstract, the patterns are the implementation

kirk 28/10/10 18:18:21 sweet, sweet validation for calumb!

calumb 28/10/10 18:18:31 heh That big list is by no means my own creation -- quite a few of us worked on it before. 28/10/10 18:18:49

aday 28/10/10 18:19:28 calumb: what are your thoughts on those examples?

calumb 28/10/10 18:19:50 aday: sounds broadly correct to me. aday: I'm sure some things won't fit quite so nicely into one category or the other, though... 28/10/10 18:20:20

aday 28/10/10 18:20:29 whoa. we might be getting somewhere calumb: sure, that's inevitable 28/10/10 18:20:36

kirk 28/10/10 18:21:20 Sorry, but what is a BOF?

calumb 28/10/10 18:21:35 birds of a feather session... aka 'people talking about the same stuff at the same time' 28/10/10 18:21:42

jancborchardt 28/10/10 18:21:52 Kirk: at GUADEC

kirk 28/10/10 18:21:55 gotcha, thanks good comments from the BOF! 28/10/10 18:22:20 what does the comment of screenshot vs wireframe mean? Is a wireframe in this context a mockup, e.g. Balsamiq or something? 28/10/10 18:23:28

calumb 28/10/10 18:23:46 Kirk: right... a low fidelity vs a high fidelity mockup, really. actually, that's not a terribly accurate description either 28/10/10 18:24:58

kirk 28/10/10 18:25:09 OK, tis is a good place to start (perhaps start again?) Next steps? Do we want to just braindump like shaunm suggested?

mpt 28/10/10 18:25:22 has to either go to lunch, or go hungry

calumb 28/10/10 18:25:48 has to go too

mpt 28/10/10 18:25:58 Thanks for organiazing this aday and organizing it too 28/10/10 18:26:05

aday 28/10/10 18:26:18 mpt: no problem. i'll circulate notes and a log

mpt 28/10/10 18:26:23 k

calumb 28/10/10 18:27:34 So do we all do our own braindump, or do we try and do it together in etherpad?

aday 28/10/10 18:28:15 i can write up our pattern definition conversation and put it on the wiki shall we meet again to finalise a structure? 28/10/10 18:28:55

kirk 28/10/10 18:29:20 I'd love to do it in etherpad - would be good to hash out dtails as they occur

calumb 28/10/10 18:29:52 sure... perhaps some of us should have a go at putting together a straw man structure before the next meeting?

godbyk 28/10/10 18:30:04 calumb: Good question. It might be neat for everyone to devise their own table of contents for the HIG and return with that. The TOC would go down to the level of listing some guideline and pattern names.

aday 28/10/10 18:31:42 calumb: good idea. want to nominate a pad to use?

calumb 28/10/10 18:32:04 Could just work on http://openetherpad.org/HIG-layout, I guess...

aday 28/10/10 18:32:35 perfect. any objections to meeting at the same time next week?

calumb 28/10/10 18:32:45 Works for me...

godbyk 28/10/10 18:32:50 aday: Worked well for me.

aday 28/10/10 18:33:38 okay - i'll organise that brilliant. thanks everyone for coming - it's been a really good meeting! 28/10/10 18:34:18

kirk 28/10/10 18:35:17 thanks all - look forward to next week

calumb 28/10/10 18:35:17 thanks aday, talk to you again soon no doubt

aday 28/10/10 18:36:36 Kirk: great to have you involved

kirk 28/10/10 18:39:05 aday: Thanks - hope I can be helpful