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

Syntax highlighting feedback #54

Open
isabela-pf opened this issue May 10, 2023 · 1 comment
Open

Syntax highlighting feedback #54

isabela-pf opened this issue May 10, 2023 · 1 comment
Labels
test 2: content Related to the second round of user testing with varied content types emphasized

Comments

@isabela-pf
Copy link
Contributor

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

  • 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.

  1. 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.
  2. 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.
  3. 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.

@isabela-pf isabela-pf added the test 2: content Related to the second round of user testing with varied content types emphasized label May 10, 2023
@tonyfast
Copy link
Contributor

we are using https:/Quansight-Labs/accessible-pygments for dark and light accessible pygments themes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test 2: content Related to the second round of user testing with varied content types emphasized
Projects
None yet
Development

No branches or pull requests

2 participants