Breeze meeting hosted by Cambridge.
Minutes of a sort:
- Google docs button drop-down, but that raises accessibility concerns with its javascript already
- Jim: a lot of tools already use js, and i'm not sure how much of Sakai would work without it
- Kathy: not sure js is a problem in principle, but i'm not sure where js introduces accessibility issues
- as soon as something hidden and not HTML
- we should run these things past Mike Elledge
- Jim: I think there are serious accessibility issues with resource right now.
- Jim: about the drop-down button - is there a reason that a simple drop-down element wouldn't work? Because that would involve no js.
- Harriet: takes up less room, looks better, that's really it.
- Kathy: I think the button is so much nicer that we should look into it, we should just be clear about that before we head too far down that road.
- there does seem to be some "anti-button" sentiment out there in the design community, and not sure if those objections might be raised here as well.
- the original design in fact turned a button into a link - do we have the rationale for that?
- Jim: I don't think that was a resource-specific issue, it was more of a style guide thing to be applied across tools, and the resources change was a by-product of that.
- I think it has to do with establishing some consistent semantics about what should be a link and what should be a button
- Harriet: that makes sense, but perhaps it's now time to re-examine
- Jim: it would be good if you brought this up to the UI DG to re-surface some of this thinking that came out of the style guide process - we should get that input
- Harriet: yes, but I'd like to have some usability data to actually show first, to better support the discussion
- Jim: I was suggesting something a little different. If we want to draw out what the issues are, rather than just prevailing in the debate, it might be better to begin with the discussion again
- Harriet: it could also be important for the discussion to not appear to be about ideas simply springing from our own heads.
- Harriet: We don't want to change things too much for 2.4 and then change them again for 2.5, so that's why the current 2.4 mockup is minimal
- Harriet: I'll try to develop an HTML mockup and get some user responses, and then go out to the UI DG and get some more feedback
- Harriet: I poked around in Google docs JS. Complex. Not sure how much of it is necessary, but it may turn into a lot of work.
- Jim: you've taken out the "checked" language
- Harriet: doesn't mean anything in the UK, or it's confusing. Google uses "select" rather than "check," which is a little more global.
- Kathy: the problem is still how scattered across the page so many actions are
- Jim: we're talking about maybe for 2.5 doing some refactoring, which may involve consolidating actions in a certain location at the top, which will be sensitive to what's been selected - but let's not tinker with that for 2.4, since that may change
- Harriet: Let's minimize the changes for 2.4, yes.
- Harriet: There's consistency across versions of the tool, and then there's consistency within the tool, and there's some tension between that in the current design.
- Jim: We've collapsed actions into "Add," but someone had earlier raised the idea that uploading files and adding folders are conceptually different operations for a user, and perhaps they shouldn't both fall under the same umbrella, which has to be navigated through. Thoughts?
- Harriet: I'd say let's think about that for 2.5, because i'm not sure we have the time to treat that well, and then possibly create a change will have to be undone for 2.5