Cell navigation feedback

[isabela-pf]

Problem and context

This issue comes from our user testing round 2: content, though some of these conversations were repeated across sessions. As mentioned in other issues, navigation became a big talking point in this round of tests because content was spread across a long notebook and we did not ask tasks to be completed in a strictly beginning to end order. This was intentional, and gave us some good feedback on more specific navigation interactions.

Starting by putting participants first, here summary of some of the comments we got directly from participants (paraphrased):

• "I want to leverage keyboard navigation available to screen readers without having to use a screen reader." This mostly meant wanting to have comfortable and robust keyboard navigation and access to HTML structure. Specifically mentioned wanting to use a key to jump from cell to cell.
• “I want to be able to tab between cells.” While some participants said this, others spoke directly against this as mentioned in Add user test 2 results! #56. Tabbing between cells does not seem to be the best solution, but the desire to move on a cell by cell level with the keyboard is worth noting.
• “Being able to jump between cells would be more useful than headers because it is way to walk through the content faster than scrolling.” Once again, not all participants agree with this. I want to put focus on the sentiment that some participants valued or hard more trust for understanding the notebook by cell content, while some trusted authors to have good (Markdown) content headings. Both need to be available.
• “Jumping between headers is helpful, but I don't remember what keys I need to use to navigate between headings.” There can be a discoverability issue with features, especially keyboard ones. This also echoes Add a table of contents to rendered notebooks #9's table of contents discussion.
• "I need to navigate to different code cells quickly." Not only is this a cell level request, this is a kind of filtered cell level request. I suspect this is related to the interest that code savvy participants had in pulling notebook code out of the notebook to work with it elsewhere. Either way, being able to not only navigate by cell but to know what cell type or content one is entering seems helpful to some.

In summary, here are some notes on what might make a better experience:

• Make it clear to the user if there are navigation options, especially ones in addition to heading navigation (which seem to be the most likely to be expected). Make it somewhere people can reference as needed.
• If possible, the choices that are made would benefit from being a standard between all notebooks. The distinction between and editable, rendered, or other type of notebook is not always clear to users. The patterns they expect to interact with do matter.
• If there are keyboard shortcuts, have them listed somewhere users can reference.
• Maintain heading navigation. Keeping these as links and proper HTML headings is good; don't change that part.
• Explore options for and provide cell by cell navigation.
• Label cell types. This could help provide the visual breaks between Markdown cells, code cells, and outputs in a non-visual way. This might also be able to serve as underpinning for cell by cell navigation.
• Provide a table of contents Add a table of contents to rendered notebooks #9

This issue may be related to #14 and #5.

Possible solutions

For the most part, I do not have solutions that I am more confident than any other. I made this issue to gather feedback so we could explore potential options. I expect a combination of solutions will create the most flexible experience that suits the feedback.

Acceptance criteria

This issue can be closed when we

• We decide a direction to take and record what it will be.

Tasks to complete

Because they will be highly dependent on the direction we choose, tasks are to be determined by further tests and team discussion.

[tonyfast]

* "I want to leverage keyboard navigation available to screen readers without having to use a screen reader."  This mostly meant wanting to have comfortable and robust keyboard navigation and access to HTML structure. Specifically mentioned wanting to use a key to jump from cell to cell.

this is a good suggestion. we could have keyboard navigation that uses I, J to go up and down with Shift variants for reversing. I/Shift + I would mimic item navigation on a screen reader.

* “I want to be able to tab between cells.” While some participants said this, others spoke directly against this as mentioned in [Add user test 2 results! #56](https://github.com/Iota-School/notebooks-for-all/pull/56). Tabbing between cells does not seem to be the best solution, but the desire to move on a cell by cell level with the keyboard is worth noting.

tabbing is always going to be a more tedious process, it would be more assistive to have a predictable way to move between cells.

* “Being able to jump between cells would be more useful than headers because it is way to walk through the content faster than scrolling.” Once again, not all participants agree with this. I want to put focus on the sentiment that some participants valued or hard more trust for understanding the notebook by cell content, while some trusted authors to have good (Markdown) content headings. Both need to be available.

there is a case for cells having headings, they would include more semantics from the code. when we do this, the table of contents will contain both markdown and code headings equitably.

* “Jumping between headers is helpful, but I don't remember what keys I need to use to navigate between headings.” There can be a discoverability issue with features, especially keyboard ones. This also echoes [Add a table of contents to rendered notebooks #9](https://github.com/Iota-School/notebooks-for-all/issues/9)'s table of contents discussion.

i'm not clear on this feedback. did keyboard users have a hard to getting to a specific place? or did they really want a table of contents for navigation?

* "I need to navigate to different code cells quickly." Not only is this a cell level request, this is a kind of filtered cell level request. I suspect this is related to the interest that code savvy participants had in pulling notebook code out of the notebook to work with it elsewhere. Either way, being able to not only navigate by cell but to know what cell type or content one is entering seems helpful to some.

we've added announcements for cell types, but i realized there isn't a visual label yet. i will add this because its probably an iffy violation. may be can use Shift or Ctrl to change a navigation mode. either way it sounds like keyboard shortcut discoverability need consideration. the classic notebook had the best implementation of this.