Change:
Creating a new issue specifically to track discussion for the tag system - spinning off of . This also follows up on
Here's some notes I wrote down from our meeting: Make a "tags" dropdown or something expandable in the block descriptions. When expanded, it would list all the tags that are used in steps within that block. When you click on a tag, it filters the steps in the grid display to only show steps with that tag.
Just throwing out some more requirements/suggestions/questions on what we would need to do to enhance accessibility. The user would need to know what tag the grid is currently filtered on (or if not filtered at all), even if the tags dropdown is contracted. It might be helpful to include a "clear filter" button so that keyboard users don't have to navigate through the tags in order to undo a filter. This button could be displayed only when the list is filtered. The previous/next step keyboard shortcuts will come in handy here to allow users to quickly go through the filtered steps until they find what they are looking for. I've heard remarks in the past that these particular shortcuts are intended for power users and thus discoverability isn't a big concern. But with this functionality I think they are now intended for everyone and we should make sure that everyone knows they are available. If we are going to list all of the possible tags in the dropdown then the tags themselves would need to be implemented with an element that can communicate its state (i.e. whether it is the current filter). A would work using the attribute (this is probably my preferred suggestion at this point). A checkbox would work, although a group of checkboxes usually allows for multiple checkboxes to be selected, so we might be going against expected behavior in this case. Another option would be to use a for the tags. Then we wouldn't need a separate dropdown for this (or a clear button), but we would most likely need to add a button since we wouldn't want the filter to apply when the user is merely scrolling through list to view the filters.
For this design, the goal was to create tags with topics that will show up under the "Start Project" button. When clicked, they will highlight the blocks of steps that are connected to the tag’s subject. While designing, I had the following considerations in mind: People with visual impairments should be able to use this feature like everyone else, therefore we shouldn’t rely solely on color or contrast to differentiate the relevant numbersOne posible option could be to have a small text somewhere explaining what the tags do for those who are not familiar enough with technology and don’t understand that these are linksIf there could potentially be like 50 tags, we need to come up with a way to make them look easy on the eye so the users will want to interact with them and not be intimidated or confused, otherwise if they look cluttered users will ignore them due to how difficult they are to read. This is why I made the tags a bit bigger, especially because the tag section can be hidden as you'll see in the design The final draft I made today can be found on the lower right side of the figma file, the frame where the flow starts is called "Second iteration". If you choose this frame you can interact with the prototype, here's a screenshot for reference: <img width="1008" alt="Screen Shot 2022-12-19 at 5 00 18 PM" src="https://user-"?node-id=239%3A953&t=6BabYSgem7caPwLG-1)where you can explore the process, some of my notes and the final design And this is a quick video showing you where to find the prototype and the flow itself. For some reason the video saved at half speed so it is extra slow Bu the way, this is just an initial draft that needs refining once we can discuss it. The design of the "See all steps" button particularly needs more work and I've just put it there as a placeholer, we may in fact replace it with a "clear filters" button and also change it's location. https://user-
I like what you've done here and you incorporated my first two bullet points above! I just have a few suggestions at this time: It would be best if the name for the toggle button that opens/closes the list of tags stays the same for both states. Perhaps just keep it as "Filter steps by topic"? We will use the attribute on the button itself to let screen reader users know which state it is in. The issue with changing the name on toggle is that some screen readers might not immediately pick up the change. Also, using the attribute is an accessibility best practice and it wouldn't make logical sense to change the name when using that attribute. I would vote for "Clear filter" as it would be more consistent with using "filter" on the toggle button. If we change the name on the toggle button to something that doesn't use "filter" then whatever that is, I think the clear button should use that same name for consistency's sake.
Great! If you guys like the design I can start converting it to a final draft, which includes the accessibility comments above
?page-id=234%3A62&node-id=239%3A953&viewport=-694%2C-189%2C0.53&scaling=min-zoom&starting-point-node-id=235%3A242) <img width="691" alt="Screen Shot 2022-12-28 at 1 28 02 PM" src="https://user-"
Thanks for sharing those designs, The idea is really taking shape and the mockups look great. The only thing that leapt out to me was that there's quite a bit of empty space in the filtered view. What do you think to collapsing the gaps between the filtered steps? e.g. rather than having it would just be . That way, even for projects with lots of steps, there's no risk that people fail to notice that later steps are unfiltered, even if they would otherwise be off the page.
I think that's a good idea, here's a quick mockup showing what the design would look like with that modification <img width="369" alt="Screen Shot 2023-01-04 at 12 19 55 PM" src="https://user-"
Thanks I think that looks great.
Great job on the mocks Here is a minimal version if we decided to go down that route: <img width="528" alt="Screen Shot 2023-01-06 at 8 35 27 PM" src="https://user-"
I'm really happy to see this idea taking shape :) Regarding the two designs, I don't have a strong preference between the two, perhaps can weigh in on accessibility. I like the design of the tags of but I think is a little easier to implement and takes up less space
Just to clarify, are we allowing multiple tag filters at at time, or just one?
I'd start with one. If that feels too limiting we can consider allowing more, but I suspect it'll be fine in practice.
Assuming we only allow one tag at a time, in the minimal design, is that supposed to function as a traditional element? Or is it similar to the original design in which it acts as a disclosure button?
Could you clarify?
Hello Following up on your discussion, I would like to take this one!
I think we decided that we want to use something similar Ahmad's mock to start. The argument for keeping the full grid is that campers can see where they are and also where the challenge is that has that tag. As far as the dropdown, we can start with that but may want to show the tags. We are going to add a help wanted label on this and can fine tune some things on the PR. Feel free to work on it if you want or anyone else
If we allow multiple tags at a time, are those going to be OR'd together or AND'd together?
I think we'd want OR (i.e. the union). Reason being there should not be many lessons with multiple tags, so AND would typically be empty.
Ya, that was my thought too. here's another update for your PR :slightlysmilingface:
I would like to work on this issue
We typically do not assign issues. Instead, we accept the first pull request that comprehensively solves the issue. Issues labelled with or are open for contributions. Please make sure you read . We prioritize contributors following the instructions in our guide. Join us in or if you need help contributing - our community will be happy to assist you.
We have decided not to implement this feature.

Discussion:
{ <del> "node": true </del> <ins> /* * ENVIRONMENTS * ================= */ // Define globals exposed by Node.js. "node": true, /* * ENFORCING OPTIONS * ================= */ // Force all variable names to use either camelCase style or UPPER_CASE // with underscores. "camelcase": true, // Prohibit use of == and != in favor of === and !==. "eqeqeq": true, // Suppress warnings about == null comparisons. "eqnull": true, // Enforce tab width of 2 spaces. "indent": 2, // Prohibit use of a variable before it is defined. "latedef": true, // Require capitalized names for constructor functions. "newcap": true, // Enforce use of single quotation marks for strings. "quotmark": "single", // Prohibit trailing whitespace. "trailing": true, // Prohibit use of explicitly undeclared variables. "undef": true, // Warn when variables are defined but never used. "unused": true, // Enforce line length to 80 characters "maxlen": 80 </ins> }

<ins> { /* * ENVIRONMENTS * ================= */ // Define globals exposed by modern browsers. "browser": true, // Define globals exposed by jQuery. "jquery": true, /* * ENFORCING OPTIONS * ================= */ // Force all variable names to use either camelCase style or UPPER_CASE // with underscores. "camelcase": true, // Prohibit use of == and != in favor of === and !==. "eqeqeq": true, // Suppress warnings about == null comparisons. "eqnull": true, // Enforce tab width of 2 spaces. "indent": 2, // Prohibit use of a variable before it is defined. "latedef": true, // Require capitalized names for constructor functions. "newcap": true, // Enforce use of single quotation marks for strings. "quotmark": "single", // Prohibit trailing whitespace. "trailing": true, // Prohibit use of explicitly undeclared variables. "undef": true, // Warn when variables are defined but never used. "unused": true, // Enforce line length to 80 characters "maxlen": 80, // Enforce placing 'use strict' at the top function scope "strict": true' } </ins>