Timeline for Keyboard navigation over repeating informational elements
Current License: CC BY-SA 4.0
11 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 14, 2021 at 19:11 | comment | added | panta82 | Yes that could work. But it'd mean converting the list into a table view, with all the problems that entails (responsive sizing, can't have vertical arrangement within items, etc.) | |
Jul 14, 2021 at 15:02 | comment | added | Izquierdo | Rather than adding the tooltop to the element itself, could you add a label that says "Status" as a header, and an i-ball or ? icon next to that? Then the user only has to encounter it once. | |
Jul 14, 2021 at 14:58 | comment | added | panta82 | That's kind of what this already is. User can click on the label or tab into it. From the linked article: "3. Support both mouse and keyboard hover". So they are advising to do exactly what I am doing. Not a problem in a document, but IMO problem when you have repeating elements, like in a list. | |
Jul 13, 2021 at 13:17 | comment | added | Izquierdo | It's sounding like this might be a good candidate for a popup help tip (clickable ? icon) next to a general "status" label, if your design allows for that. NNG has some info on use cases: nngroup.com/articles/tooltip-guidelines | |
Jul 13, 2021 at 12:47 | comment | added | panta82 | Hmm, it's not that simple. This happens automatically based on other interactions in the app (eg. a different user does something, which switches the state to active). Even if I could figure out a way to move this help info elsewhere in the app, the question still remains, is there a good way to handle this situation in a general sense? Because this isn't the only place this UI paradigm happens in the app, just a representative example. | |
Jul 12, 2021 at 14:30 | comment | added | Izquierdo | Thanks for the additional info. It seems like moving developers from Assigned to Active is important, and you might want help text on the UI element that does that. Is that available in this screen? | |
Jul 12, 2021 at 11:09 | comment | added | panta82 | So I guess an experienced user probably won't need to see these messages all the time. But I still want them to have an option to click and see, without going to documentation site or contacting support. There could be users who are not using this UI all the time, but just occasionally. So quick access to help is important IMO. | |
Jul 12, 2021 at 11:00 | comment | added | panta82 | The actual help message will be something like "Assigned developers are those who are given a task, but their task hasn't yet activated. You can assign developers from... blah blah". It can also be shorter, I haven't decided yet. I am trying to do a contextual help system across the app, but I am open to doing something different if there is a better pattern. | |
Jul 11, 2021 at 18:57 | comment | added | Izquierdo | Do "Active" and "Assigned" need explanations that are more than a few words? And once the user understands what they mean, would they need that help again? | |
Jul 10, 2021 at 15:08 | comment | added | panta82 | Thats a neat improvement. But doesn't resolve the issue with repeated info messages. I'd still want to add info what "assigned" and "active" mean. But if I activated that info on keyboard focus, user would still need to tab through the same help text target over and over again, as they are going down the list. | |
Jul 9, 2021 at 22:15 | history | answered | Izquierdo | CC BY-SA 4.0 |