You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue comes from our user testing round 2: content. When exploring different content types, participants spent more time in code cells and their outputs than in the previous rounds of tests. This resulted in more feedback about the details that made reading code cells more or less comfortable for different participants. One of the most specific pieces of feedback was that the default syntax highlighting being applied to all code in the notebook
Often had low contrast (at least on the light theme used during testing)
Has limited categories compared to their expectations from other applications (we did not get note of an example of what they do expect) which makes them harder to skim effectively
Might not work well in different situations (ie. presenting the notebook) or lighting
It is important to note that the current state of syntax highlighting did not prevent any participant from completing any task, they increased difficulty and eye strain. Syntax highlighting is also a purely visual support, so for participants not using vision these issues did not come up at all.
Possible solutions
I can imagine three solutions at this time.
Replace the syntax highlighting theme with a theme designed to provide better contrast. I have seen few of these, so I'll recommend these contrast-focused highlighting themes as an example. This is the most scoped solution, but also one that may be the most possible as we approach the end of our timeline.
Adjust whatever is behind the scenes setting categories to have more robust syntax highlighting. In rendered notebooks, I'm not sure where these categories get pulled from, though I would guess they are a result of the code editor or language server when the notebook is in an editable form. While I would love to address this feedback, I suspect that it may have to a change several projects upstream and that it may be a lot of work. If this option is done, option 1 can also benefit.
Allow users to select from multiple syntax highlighting themes so they can decide what works best for them. I believe customization like this would be one of the most accessible things we could do. However as we have no other customization available for rendered notebooks at the moment, I know this is likely to be a big design and code ask at this time.
Acceptance criteria
This issue can be closed when we
Merge a PR that addresses at least one of the possible solutions listed above.
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.
The text was updated successfully, but these errors were encountered:
Problem and context
This issue comes from our user testing round 2: content. When exploring different content types, participants spent more time in code cells and their outputs than in the previous rounds of tests. This resulted in more feedback about the details that made reading code cells more or less comfortable for different participants. One of the most specific pieces of feedback was that the default syntax highlighting being applied to all code in the notebook
It is important to note that the current state of syntax highlighting did not prevent any participant from completing any task, they increased difficulty and eye strain. Syntax highlighting is also a purely visual support, so for participants not using vision these issues did not come up at all.
Possible solutions
I can imagine three solutions at this time.
Acceptance criteria
This issue can be closed when we
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.
The text was updated successfully, but these errors were encountered: