<scribe> scribe:slewth
<Daniel> https://github.com/w3c/wai-curricula/wiki/designer-modules-outline
Daniel: reporting on thinking on current approach to modules. Updating on areas to be covered. New module on informational design.
... Working to put together the different types of information and how to be handled from accessibility perspective.
... Other modules more on interactional design.
... Instructions on feedback, types of messages, types of info for more complex applications, widgets etc.
... Wanting to take view on these changes. Is outline improved?
... Can we work with these foundations and flesh out?
... General comments welcome.
Carlos: this seems to be much more design oriented, I agree totally with changes
Daniel: is anything unclear?
Carlos: just looking at the add-ins is 'operability' something that resonates with designers?
... Will they understand this?
Daniel: I was trying to make this apparent tying this to accessibility guidelines. We can look at that.
... I was trying to make this apparent tying this to accessibility guidelines. We can look at that.
Estella: I see there are 7 modules, does this align with other modules?
... Do All curriculums have the same length and duration?
Daniel: foundations have 5, others have 7, we don't have to be constrained. It's about organising content.
... If we decide to join or split we can.
... We can agree on structure. We shouldn't be looking at this as 7 for developers, 7 for designers, etc. This is coincidence, not a plan
Estella: weight should be proportionate to all curricula
Daniel: agreed
Gerhard: where do we see the responses, which module?
Daniel: we're now in module 2, the layout. I was hesitant, should we have this throughout? and then repeat? or should have responsive - which is important. should responsive design have it's own module
... I'm unclear, but this is currently in module 3
Gerhard: I think it's very important topic since there's success criteria in WCAG that deals with responsiveness
... For a lot of designers the responsiveness stuff is a little bit too complicated. They want to design for responsiveness, e.g. for mobile, desktop, but all the stages between they don't think about it.
Daniel: good point. Some designers won't be thinking about this.
... I also think because of that, designers will need to be working closely with developers to ensure responsive design, so may be we need to separate out to new module
shadi: can I clarify?
... You're suggesting when the module is developed you would put a specific topic on responsive design?
... Did you (Gerhard) say this would be deterring some designers?
Gerhard: if you ask some designers to design between mobile and desktop, where does the content go? Something like that - often designers clueless how to do this, if you show, no problem but has to be clarified.
Shadi: but you are happy for responsive design to be in this module on layout and spacing? And where is it in the curriculum overall?
Gerhard: yes, it's a layout topic
Daniel: following up, we need to point designers to what they need to do, is that clear ?
... Is it not clear from the learning outcomes on resizing, or is more work needed on this?
... Should I take more into account?
Shadi: interjects - maybe this needs to be broader, so not just sequence but also reflow, so content is not lost. Varying size should be taken into account?
Gerhard: this is what I mean. This is mentioned in WCAG, it's also important.
Daniel: I will expand this at a topic level, and also this in the Outcomes.
... further comments on structure?
... moving to next agenda item.
Daniel: this is about user research module
... We were leaning to putting this at the end of the course, but this is one of the first things that needs to be done from a design process perspective
... gathering user requirements and defining the different user needs, would be best upfront in the modules, rather than last
... Another concern was some might be put off by this, as not addressed on a daily basis, 'I'm a designer not a UX research'
... We can add that this module can be skipped - but just making sure that this is a good sequence and this going first is good overall.
Howard: I'm not sure it needs to be first. Perhaps from a designers point of view it might not be central.
... You're focussing on the user, but maybe not first. Maybe slip in a little bit later - but this is thinking out loud
Estella: why are people taking this module if they are not interested in accessibility? There's no need to move it down.
... People need to take into account needs of all users - so we're coding the need.
... Maybe title could be catchier - but the position is the right one.
Daniel: from accessibility perspective we want to shape how it could be taught or what can be included, this shows that this is a priority
... Some people do not do user research as it's not in their tasks - so both points are valid
... Other thoughts
Carlos: I agree with estella, this is an opportunity to raise awareness.
... People looking at this curriculum are interested in knowing more
... When teaching accessibility it's important to teach the Why? and not just the How?
... This is a good module for the 'Why'
... Other modules don't necessarily have this
Daniel: the overview will cover this
Shadi: I agree with estella until the last bid - is this about the How or should it be about the How?
... How to include people with disabilities in research, but it shouldn't necessarily be 'Why'
Carlos: I do think we have the Why in the developer curricula
Shadi: when we're explaining specific techniques, but the first bullet, talks about how involving with disabilities can lead to overall improvements, these kind of benefits of accessibility are not really the point,
... so it's about how that particular point is beneficial
Daniel: the why does have to be throughout the modules, in some modules this is stronger and vice versa - but having both is needed. Happy to reword
Shadi: it's a different 'Why'
... this is not specific to user research
... Moreover don't need to mention people with disabilities in user research, we don't mention this in for example colours and styles
Daniel: maybe we need to discuss more, specifically how to include people with disabilities in user research - i do see the point that this needs to be reworded
... do we want to provide overall user research - how to do this, or focus on inclusion of disabled people?
... If you say - have you done your UX, they say Yes, but people with disabilities not included.
... This is the major concern
Howard: I think I like including people with disabilities, add 'including people with disabilities in User Research'
... be more specific - it's a bit general right now without a verb
Daniel: this is a good point - do we get to this level of detail? Or is this about the techniques of user research?
Shadi: let me clarify
... This is about accessibility considerations in usability research
... Because, same with colours and styles, this is not about theory and general design, this is about accessibility considerations in colours and styles
... If we add this in, then we have to add across the board
... This is maybe for later - it feels odd to suddenly specify people with disabilities, when this is the subject overall
Estella: In module one I'm missing user requirements that I think designers do in their first stage
... the requirements might be a title - so you don't need to user 'people with disabilities' in user research.
... Requirements gathering -could be the words, or integrated better - are we on the same page?
Shadi: it's the design for the design actually. I think I see you're point Stella
Howard: I can see that.
<shadi> [[User Research and Requirements]]
Howard: What's a title that will draw people in and link to the rest of the topics, maybe something like 'preparing design for user research' I don't know if I have a specific
... preparing for design with user research - something link that.
... Something that explains why we're coming to this first.
<shadi> [[Preparing for Design using User Research]] (from Howard)
Howard: Some type of title that puts it in context would be helpful
Daniel: a title that explains why it's there.
Howard: It struck me as curious when I first looked at it. I don't have a problem with it going first but I'd like more context
Daniel: so it's not just techniques - we're adding user requirements and providing, explaining what the reasoning for this going first is, when including accessibility in design
... I'll work on that
... Other comments?
... sequential structure is planned, but can be taught in isolation - so more context will help
<Howard> Sarah: Will there people who jump in and out of this curricula? If so, then context would help.
Estella: regarding last two bullets - may be dependent on national laws, which will vary, when conducting research with people with disabilities, do we need to add point that teachers should check local policy
Daniel: this point may be important for instructors, so they know informed consent etc is used
... And look to local law/policy
... We can't detail those laws but we can direct them to consider
Howard: in the US we call this IRB, going deeper can be in the module when it's developed.
Daniel: next agenda item
... I looked at subroles and sub categories of designers, describing requirements for visual designers for interaction designers etc, but that is somewhat messy
... It's difficult to decide which requirements belong to which category as there are overlaps. E.g. Contrast ratios
... My question is do we want to make sure these categories are well spread through the modules without or with names to make clear this is what we're trying to accomplish?
Howard: I would lean towards leaving this out
... It's nice to know, but not everyone separates tasks like that.
Daniel: Leaving as is?
Howard: yes
Estella: I agree Howard. I see you're point Daniel.
... It will also depend how deep you are going into the curriculum. Will this be at a beginners, intermediate, advance level - separating the three roles is difficult
Daniel: To be clear, we will have this separation. What we currently have is an outline. We could stream according to visual, or interaction.
... Naming explicitly is what we're trying to avoid
<shadi> Sarah: do we make the decisions visible to teachers?
<shadi> ...seems relevant decision
Daniel: I'm not aware that we've done that in the past. Maybe we need to explain this in the overview page for the designer.
... We could do something like this - explaining that this subdivision is in mind, but not named in outcomes
Shadi: what's the point?
<shadi> Sarah: trying to address different groups
<shadi> ...but not naming explicitly
<shadi> ...maybe needs to be explained
shadi: if we look at the developer curriculum
<shadi> https://wai-curricula.netlify.app/curricula/developer-modules/
shadi: at the top is says for 'front end developers', which excludes some other groups. So we could use a similar framing approach - e.g. information designers etc, and list the groups and that would set the stage.
... this needs to be communicated,
Daniel: I don't think this needs to be on the overview page
... As with the developers page, we'll have a similar one for designers.
... summing up, the overview page should explicitly mention the subcategories of designers that we are thinking about when developing this curricula
Estella: I think also possible in competencies?
... For students and instructors
Daniel: I think we have prerequisites.
... Stating the knowledge students should have.
I... see something similar could be done here
Estella: this could be integrated in the overview page, but also how to include at the module level. which will be the requisites and competencies for instructors and for students
Daniel: so we need to determine what will be required, so when we go to the last modules, 5, 6, 7, we do need to require the previous ones, or certain one, as done elsewhere.
... Hard to imagine as planned, but not yet in place.
... I'll be putting this in the navigations to the relationships between modules are visible.
... Any other business?
... Thank you everyone. More needs to be done on context, and resizing on layout and spacing module, also I hear about this point about explicitly defining the groups identified when developing this module.
Daniel: As next steps, I will be working on this, and start fleshing out the module.
... I'll also put these in the WAI website as we have done with the developer modules.
... Thank you. I'll keep you posted when these goes to the editors draft. See you all next meeting