product-backlog
product-backlog copied to clipboard
hypothesis
Highlight in multiple colours
Problem you are trying to address
As a user who makes private notes with Hypothesis I want to be able to make highlights in multiple colours, denoting my personal categorisation of annotations So that I can convey meaning quickly and efficiently directly on the document
User requests
- https://hypothesis.zendesk.com/agent/tickets/776
- https://hypothesis.zendesk.com/agent/tickets/992
- https://hypothesis.zendesk.com/agent/tickets/1912
- https://hypothesis.zendesk.com/agent/tickets/1969
- https://hypothesis.zendesk.com/agent/tickets/1968
- https://hypothesis.zendesk.com/agent/tickets/2116
- https://hypothesis.zendesk.com/agent/tickets/2328
- https://hypothesis.zendesk.com/agent/tickets/2463
- https://hypothesis.zendesk.com/agent/tickets/2168
- https://groups.google.com/a/list.hypothes.is/d/msg/dev/B-B5PCAunNk/avLUbqEKBAAJ
- https://hypothesis.zendesk.com/agent/tickets/2778
- https://hypothesis.zendesk.com/agent/tickets/3053
- https://hypothesis.zendesk.com/agent/tickets/3228
- https://hypothesis.zendesk.com/agent/tickets/3665
Another user request came in today (#1969, added to Nick's original comment). Would also like to point out that this is an accessibility issue for those with low vision and/or who are colorblind.
A new review on the Chrome web store mentions this as well. Unfortunately, I don't see a way to link to reviews, so I am adding a screenshot:
Summary
As a user, I want to be able to highlight in colors other than yellow so that:
- I can categorize annotations by type, topic, or importance (see Zendesk tickets #992, #1968)
- I can differentiate between text that is highlighted vs text that is highlighted and annotated (Zendesk ticket #2116)
- I can easily see highlights, even if I am low/no-vision and/or colorblind
User requests
- https://hypothesis.zendesk.com/agent/tickets/776
- https://hypothesis.zendesk.com/agent/tickets/992
- https://hypothesis.zendesk.com/agent/tickets/1912
- https://hypothesis.zendesk.com/agent/tickets/1969
- https://hypothesis.zendesk.com/agent/tickets/1968
- https://hypothesis.zendesk.com/agent/tickets/2116
- https://hypothesis.zendesk.com/agent/tickets/2328
- https://hypothesis.zendesk.com/agent/tickets/2463
- https://hypothesis.zendesk.com/agent/tickets/2168
- https://groups.google.com/a/list.hypothes.is/d/msg/dev/B-B5PCAunNk/avLUbqEKBAAJ
W3C compliance considerations
- There should be notification of the number of highlights of different types, a way to navigate to each highlight and to choose which type of (color) highlight to navigate between (meaning color of highlight should be reflected in the syntax).
- Make sure that the contrast between background and foreground has a ratio of 4.5:1 or higher
- Most common type of color blindness renders greens and blues indistinguishable, so if we are providing color options, that’s something to keep in mind.
- Furthermore, we might consider differentiating brightness/saturation among options so color is not the only difference between highlight options
Examples
Google Docs & Adobe products offer a palette of default highlight colors to choose from with the option to enter custom RGB or hexadecimal values. There is no limit to how many highlight colors can be used in one document:
Google Docs:
Adobe Acrobat:
Apple's Preview app offers a limited set of options: Yellow, Green, Blue, Pink, Purple (As well as underline and Strikethrough)
Yawas (a Chrome extension for highlighting) allows for yellow, red, blue, and green:
Questions and Considerations
- Should highlight options be available only for private highlights? Or perhaps private + within groups (do we want people annotating over the public layer in various colors)?
- How many colors should we offer? Which colors should we offer?
- How will we communicate the different highlight colors to screen readers?
Should highlight options be available only for private highlights? Or perhaps private + within groups (do we want people annotating over the public layer in various colors)
Great question. My instinct suggests the same direction, namely private + within groups. I don't think we want folks annotating in the public channel this way. Or if they do, that their personal color choices aren't necessarily visible to all. Private groups are different matter.
Old vision issue for reference: https://github.com/hypothesis/vision/issues/123
User request: https://groups.google.com/a/list.hypothes.is/d/msg/dev/B-B5PCAunNk/avLUbqEKBAAJ
F1000 provides this.
FWIW I use them with a personal set of meanings for a few of the colors:
red - i disagree orange - key idea yellow - default green - i concur blue pink
possibly simplifying thought...
make color simply an extension of tagging!
So, if an annotation has a tag matching the regexpr /color:(.*)/, then color the region $1.
Conversly, build UI tools to set/reset the value of the annotation'scolor tag.
Notably provide small standard pallette of 5 or 6 named colors when chosen simply set/reset the value of the color tag.
"color:green" anyone?
Came up in a Chrome store review. There isn't a great way to link to reviews, so here's a screenshot:
I don't know if it has been mentioned before, but per-user colors would really do the trick for some of my group use-cases. Perhaps doing it similarly to how it already functions very well in Etherpad would be just fine - users can pick their own (more or less) unique color, that is then seen by all.
Notes from a user in Zendesk on what they'd expect from this implementation:
- User can select color of the current highlighting fast from GUI and not from Preferences [i.e., can be selected in context where the user is annotating, rather than making them go to a separate preferences page]
- The color for each highlighting/annotation is persistent and kept in DB - at implementation level some predefined tags like: color-red or color-R-G-B-A could be fine;
- Last but not least, API to set current color by a side app or 3-rd party app via the local communication like https://developer.chrome.com/extensions/nativeMessaging
Additional requests: https://hypothesis.zendesk.com/agent/tickets/6044 https://hypothesis.zendesk.com/agent/tickets/6240 https://hypothesis.zendesk.com/agent/tickets/6888 https://hypothesis.zendesk.com/agent/tickets/7272 https://hypothesis.zendesk.com/agent/tickets/8106 https://hypothesis.zendesk.com/agent/tickets/8654 https://hypothesis.zendesk.com/agent/tickets/8737 https://hypothesis.zendesk.com/agent/tickets/9265 https://hypothesis.zendesk.com/agent/tickets/9266 https://hypothesis.zendesk.com/agent/tickets/10378 https://hypothesis.zendesk.com/agent/tickets/10934 https://hypothesis.zendesk.com/agent/tickets/10991 https://hypothesis.zendesk.com/agent/tickets/13370 https://hypothesis.zendesk.com/agent/tickets/13730 https://hypothesis.zendesk.com/agent/tickets/14380 https://hypothesis.zendesk.com/agent/tickets/14939
I just put in a request for this feature myself (Ticket #7272), and was alerted to this existing ticket. I second malcooks suggestion to associate the different highlighting colors with the tags and not the annotations, so you only see the color in each annotations little id marker near the scrollbar when there is a tag assigned to it. This is a basic feature of qualitative data analysis softwares like ATLAS.ti. The annotations have id's like 2:17 (the 17th annotation in document 2) in the "scrollbar marker," and then the name of the tag(s) are listed and those are back-colored. I think this also brings it down to a project-level feature so there is no private vs. public issue with highlighted text since it's the tags being colored at the project-level.
As a user who have constant eye fatigue when not using LED screens with low-blue light filter (flux, night shift, etc, whatever you called it). Yellow highlights just own't show up with a white background, it's makes the whole app unusable for me. I think it's better to implment color changing feature on the display. That is, to record various colors, as COLOR1, COLOR2 written in the data information, and let users decide in what hue they want COLOR1, COLOR2 be defined as.
@IAmNotAJerk I changed the color code for the highlight with some Javascript in the bookmarklet so the highlights would be visible despite f.lux.
The bookmarklet is at https://gist.github.com/jasonkena/862510cef19d78eb0390799e4c4af19c
The important section is rgba(255, 150, 255, 0.5), customize it as you like.
@IAmNotAJerk as part of recent accessibility work we've also increased the opacity of highlights, so that contrast (rather than just color) will show that a section is highlighted - hopefully that will provide some improvement in the shorter term
So it seems there are two separate use cases for multiple highlight colors here which are in some cases in conflict:
- Using different colors for different highlights for semantic purposes.
- Enabling users to change the color for accessibility reasons. This might include changing the color and/or boosting the contrast
In a private context, there is no conflict. In a group context, the members need to share semantics somehow. Some ideas on how to overcome this:
- Separate color hue from contrast/opacity. The color hues may be defined on a per-group basis but contrast is defined by the user according to their needs.
- Associate entries in a color palette (per @IAmNotAJerk's suggestion) with semantic labels (eg. tags as suggested above) on a per-group basis. This enables individuals to change the color palette according to their needs while still keeping the semantics within the group. There could still be some confusion if screenshots/videos of annotated documents get shared and different people are seeing different colors, but I guess that's an inevitable trade-off.
Hi all - just starting to use hypothes.is. Wondering if it is possible to use different highlight colours or whether this functionality doesn't yet exist. Apologies for the questions
Hi @andrewg1978 - This functionality does not exist yet. We're using this issue to discuss possibilities and constraints.
@robertknight - thanks - appreciate your rapid response... look forward to seeing how things develop. Ideally I want to be able to highlight a paper according to different contexts - eg methods vs key findings vs smaller findings etc - Each of these would have a colour to enable them to be distinguished. Hopefully it becomes possible to use some sort of alternate colouring over the next short while
@robertknight ,
In a group context, the members need to share semantics somehow.
I don't think you're going to find a solution that works for everyone, especially balancing accessibility considerations with semantic color-coding considerations. But, you can design UX to provide guidance toward best accessibility practices.
How's this approach toward balancing concerns?...
- introduce tag-color-map as a 1st class thing
- provide a few tag-color-maps out of the box that are well-thought-out, and take both accessibility and common use-cases into consideration in their design
- allow users to define custom tag-color-maps, with in-built guidance toward designing them for accessibility (but do not require), guidance to include choosing from well-designed color palettes.
- provide group admin function to assign a tag-color-map to be used by default by all contributing members, guiding them toward selecting
- allow group admin to assign such a tag-color map as the default tag-color map
- allow user to override default tag-color-map for personal use.
https://hypothesis.zendesk.com/agent/tickets/10395
it would be great to have the option to change the highlighting colour. Why? Many websites use yellow to highlight information within their articles. If the colour of hightlights made in hypothes.is using the Chrome extension could be changed (on a per-user basis, meaning public highlights would still look the same to everyone but users have the option to change the color of all highlights made with hypothes.is they see, both their own and those made by others), that would make it easier to differentiate between the websites' highlights and the ones made with hypothes.is.
https://hypothesis.zendesk.com/agent/tickets/14160
I can imagine many ways this could be useful. Asking students to look for 3 different themes in a reading, and each one should be coded with a different color. Or having students work in teams to code a single document during a class, and each team uses a different color. Or one color for instructor comments, and another color for student comments.
@malcook ,
How about an option for a set of default accessibility alternatives, which people which specific issues can select, such as the cividis colormap, or "highlights" of differents quiggly lines.
