Meeting minutes
Work on Covering Different Menu Types and Behaviors https://wai-curricula.netlify.app/curricula/designer-modules/navigation/#topic-menu-behaviors-and-patterns
DM: Navigation module, topic on Menu Behaivors and Patterns
… comment was not clear enough
… added guidance on styling and resize
… several other improvements
… anything missing in your view?
DS: module is on navigational menus
… but also covers application menus
… might be more for interaction module
DM: yes, going back and forth on this
DS: maybe not an issue, just struck me
SAZ: so how will application menus be handled?
DM: focus here is on navigational menus
… then discuss application menus later on in interaction module
CD: could make explicit the different dimensions here
… static vs fly-out navigation
… maybe needs explicit distinguishing
… menus based on their purpose
… and based on their behavior
CD: so application menus in interaction
DM: so hearing that application menus should not be here
… but make it more clear the different types of menus
… and purpose of these
DR: I support that
<Daniel_> https://
DM: not very sure how it fits in interaction and menus
… already a lot there
SAZ: wonder if menus explained well in the Navigation module
… especially styling, behavior, and such
… then application menus can be inline in the topics in Interaction module
… might not need a specific topic on application modules
CD: recall we discussed a module on widgets
… if so, then it fits in there
… otherwise support idea from Shadi
DM: think we concluded against a module on widget
SAZ: think module on widgets would get repetitive
… maybe add examples in Ideas for Teaching in Interaction module
… and also reflect at the top of the module, to make it easier to see what is covered
Extended Error Coverage https://wai-curricula.netlify.app/curricula/designer-modules/interaction-and-feedback/#topic-errors-and-notifications
DM: added more on error messages and suggestions
… now a little more spread-out
… the different types of notifications and messages
… still missing inline messages and notifications
… like messages appearing while you type an email telling you it's wrong
… apart from this, do you miss anything else?
CD: messages that disappear after some time
… covered here but maybe not as directly and clearly
SAZ: maybe small tweak to sharpen the wording
… but not get into specifc techniques
DS: agree with comments so far
… maybe add examples of bad practice in Ideas for Teaching
… because examples are so powerful
+1 to Dave
… can also be applied to other modules
… but especially here in error management
… because so many different ways of doing it
CD: agree with Dave, examples can be very illustrative here
… wonder about messages that rely on a single mode
… might also need to talk about conveying messages programtically
DM: could add some of the cross-references here
… like to not relying on color alone and such
… will do that here as well, as a reminder
… will also look at the programatic approach and cross-reference to developer role here
Design-Related Competencies
<Daniel_> Module 1 Competencies
<Daniel_> Module 2 Competencies
<Daniel_> Module 3 Competencies
<Daniel_> Module 4 Competencies
<Daniel_> Module 5 Competencies
<Daniel_> Module 61 Competencies
DM: competencies sections describe requirements for students and instructors
… want to focus on "In-depth knowledge of" part for the Instructors
… thoughts about this approach?
… or on other parts of these sections
SAZ: missing user aspect
… maybe too indirect under "prerequisets for students"?
CD: thinking of two more competencies for instructors
… prototyping and coding
… think needed for this content
… to be able to convey issues to developers
DM: maybe not for all modules?
CD: agree
SAZ: isn't that part of designer skills in any case?
DC: should be
DM: will look at that
… what do others think?
DS: competencies section is very helpful
… why not include business benefits?
DM: had same approach in developer modules
… thought that business case is not always core to teaching developing techniques
… for consistency same approach here
DS: think may need to be different for designers
SAZ: is it because designers are often less supportive of accessibility
… or because they need to explain it more often than developers?
DS: good question, I think both
SAZ: interesting observation
… I often feel developers are more resitant to adding code
… but maybe designers in WAI circles are different
DS: designers often earlier in the process
DM: maybe sometimes design perceived as art
… so more resistance to changing
CD: see Dave's point
… but not really sure required for this module
… but it may be a competency designers should have
… so on the fence here
Next Steps
DM: will be opening survey in the next week or two
… extensive review
… so really deep review
… please take the time for that
… a little behind schedule
… but hopefully now more polished
… thank you all!