Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Designer Module 6: Interaction and Feedback] Needs to be two different sections #392

Closed
daniel-montalvo opened this issue Aug 2, 2021 · 3 comments

Comments

@daniel-montalvo
Copy link
Collaborator

@MicheleAWilliams-A11y says in
https://www.w3.org/2002/09/wbs/35532/curricula-designers-starfish/results#xq17

This feels like it needs to be 2 different sections - one for multiple interactions (keyboard and gestures) and then one about forms (which would include layout/grouping, labels, error handling, and timeouts from the various current modules). Forms are pretty complex and usually built all at once (similar to multimedia and animations), so I suspect it makes sense to have all the info about forms in one reference-able module as people are building them (or they can be skipped if something doesn't have a form).

@daniel-montalvo
Copy link
Collaborator Author

Hey @MicheleAWilliams-A11y

We have been discussing this in our 3 August TF meeting

We see the point on having forms more prominent as something most designers are heavily involved with.

There is a danger, though, that if we start pulling out specific components and adding specific modules for each of them, the list could easily get lengthy and arbitrary.

We acknowledge that more work needs to be put in this module to better structure it and to better communicate its relationship to forms, and we are studying ways to put, for instance, forms as the first module topic.

Do you think that would go in the right direction?

@MicheleAWilliams-A11y
Copy link

MicheleAWilliams-A11y commented Aug 11, 2021

Thanks for this follow-up. Not sure without seeing all the updates but from what I recall when reviewing it just seemed like a lot of form considerations were sprinkled throughout the modules (appropriately) which might in practice get a little hard to follow when you sit down to create a form. There's so much to consider with the unique interactivity of a form and Web application versus a static Webpage that sometimes it seems worth synthesizing (and vice versa in that a lot of what you need to consider about a form, such as the design of error messages, doesn't apply for other pages).

Actually, I think I'm aligned with this comment from the meeting notes:
Donal: it is good when navigating a list of topics to find the topic you're looking for, so if "forms" isn't explicitly covered in a module title or topics, that's an issue. Seems like it should be explicitly covered, maybe as a standalone topic in Module 6, and also mentioned in the module title. Forms are a major application of Interaction and Feedback, so seem to be naturally are covered in this module

But again, was just a suggestion to consider with the other feedback so I'm sure the team will come up with the right ideas!

@daniel-montalvo
Copy link
Collaborator Author

Closing. This has finally been split

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants