...
Daphne's suggested additional bullet: will serve as a taxonomy for the Fluid components
- is taxonomy too restrictive? is it meaningful? does it sound like it's understandable to our audience?
- changed to: will provide a taxonomy and design advice for the Fluid components
- mission statement was originally worded as UI design patterns – A.B. changed to UX design patterns – a little more open if we want to include other things.
- rachel – UI is just a button
- Paul – much more embracing of all we're talking about
- Jonathan – what about the audience – will them makedevelopers understand UX patterns? They may not understand that they are meant for them. UI is clearer.
- Jess – may have associations with UX and UI – know the audience first
- Jonathan – keep UI bit – developers get that right away – our ulterior motive is the UX stuff rubbing off on them as they experience the library.
- Paul – need to have focused UI content approachable to developers plus a general appreciation of UX. Tricky.
- Rachel – they should be asking for bigger things – if they come here for UI they've come to the wrong place?
- Daphne – yes and no, some of our components are UI mostly
- allison – make sure target audience understands what we mean (e.g. UX vs. UI). I think the mission is for us mostly. Changing the wording from UI to UX will change our scope a little bit. Peter Rwwley suggested adding some cooperative work patterns...might not include that if it's just UI.
- daphne – UX if we leave it at that can we have a parenthetical phrase that says the depth of what we're thinking.
Who is the audience of the mission statement? Where is it going to be? Do we want to add this to the front page of the OSDPL? - Daphne: ux to us means:
interface design, interaction design, visual design
- rachel – mission statements are good for 'about' pages
- Allison: goal statement is finalized - will send it out to the list.
...
- daphne – #3 is easier – so let's talk about that.
- rachel – why have another pattern library? what is it and what's in it for me?
- allison – how can this add value to the community – trying to explain how we are helping the Fluid community – one easy answer – patterns help with implementing usable, accessible, Fluid components.
- paul – the OSDPL is needed for the fluid community – it's a great mechanism for people to contribute to the community.
- jonathan – can forsee how the OSDPL can become a testing ground for future testing components and modules for Fluid or beyond. Patterns can be refined by having this feedback loop – btw. between designers and developers – how the patterns worked for the developers.
- paul – conduit for a connection with other communities.
- let's move this to the list – got some great info
...
- allison --love to get the yahoo-pattern-authors folks involved in this list to generate interest among them to getting patterns into this library., but wondering if it's too early to pull in other groups?
- rachel – opportunity for new interfaces – mobile, etc. having patterns available for different platforms. brings up the important platform question.
- allison – is a question for fluid too
- daphne – though this is an important question to talk about but it might be too early. too early to pull them in...
- allison / jess – hold off on pulling them in until we have the high-level questions ourselves.
- jess – let's come back and revisit this question, discuss in the future instead of right away. It will help us to understand our own goals before tackling this question.
...
- Allison – no lack of suggestions for the diff. patterns.
- daphne – way finding or cherry picking – navigate – example of HCI pattern
- allison – in the front of Jenifer Tidwell's book (Designing Interfaces) there is a set of patterns which are not Interaction design patterns, more user bahaviour patterns.
- rachel – that sounds like a step before getting to designs
- allison – might be different steps represented in our patterns
- daphne – usable systems, to teach – we do want these things. Tidwell calls them "what users do" patterns.
- rachel – how to use this library
- allison – another page in the library which tells people to at what stage could give an orientation to the different patterns in the library and where they may be used in the design process people should use each pattern.
- jess – this lends itself to a diagram
- daphne – different interfaces for different audiences – they come in at different places in a process.
- rachel – lends to function structure – a whole bunch of links on a page. an Inform. architecture pattern.
cherry picking sounds like infor architecture – not a functional structure – but it is a design. - jess – this might be beyond scope and while it is a pattern, it might be more info architecture.
- allison – browse the other pattern libraries to see examples - there are definitely information architecture patterns out there
- daphne – I don't think cherry picking is an information architecture pattern. take a look at beginning of tidwell's book for some more examples – I think they are more user behaviour patterns.
- jess – sounds like this is an open question we should continue to discuss
...