I think this colour-coded scheme is really misguided, as it is not based in any way on either:
1. the way people use multiple colours of highlighter on paper 2. any of our intuitions about what various colours 'mean'.
On paper and in Acrobat Professional, for many years i have used a system something like:
Yellow - generic highlight--something 'important' Green - I Agree! Red - I Disagree! Orange - I find this dubious... (orange is 'close' to red qualitatively) Ice Blue - I don't understand this, or I'll read it later (you're putting the passage 'on ice' for now)
this is the core of the system, and is what i advocate to others. I sometimes also use: Pale Green - i'm *inclined* to agree Pale Red - i'm *inclined* to disagree Purple - this is really unusual/cool/exceptional Black (with the inner text turned grey), or Grey - to visually mark 'structural' phrases such as "Firstly," or "My second point is as follows:"
I *don't* think that diigo shoudl force users to use one colour system, but shoudl allow them to control colours separately from the 'tag' applied to the annotation (i.e. agreement or disagreement)--i.e. certain highlight would enter diigo's system with the tag 'agreement' or 'disagreement' highlights, and the local user could control what colour highlights with the tag 'disgareement' highlights are displayed as, and if they change this setting, all of their previous disagreement highlights would change colour. This woudl be EXTREMELY useful as it would allow users to evolve their highlight system over time, as they discover what colour patterns aid the perceptual process of working with a document. (Note that tags shoudl be free-form as well, imo, a la many features of google, or how last.fm, the social music site, works.)
However, although no system of colorus should be imposed, one such as the one outlined above shoudl be configured by default for new users, as it is really the best way to use colour in the user experience.
PLEASE don't start using up colours for other purposes (such as pink for group annotation) while i am waiting patiently for you to implement multicolour highlight at the user's discretion for the sort of purposes i've just outlined here--half the point of highlight is to manipulate the salience of the page, so that later you can glance at the page and the pattern of colours in the highlight conveys aspects of the document to you the way a painting does, rather than having to read through every highlight and figure out why you highlighted it, etc.
Not to mention that, using colour both to indicate whether there is an annotation, and whether it's public or group or private is overloading colour too much, imo. Colour should be used for one purpose, and that is to demonstrate at a glance why the user highlighted it--this is how students have highlighted textbooks for years, because obviously there is no analogue to "group" or "public" highlighting on a paper text. Therefore, it's ill-advised to now attempt to use colour for and aspect of highlighting which didn't exist in the paper experience--indicate new aspects, such as public/group highlighting, with something *new*. I would suggest a small icon in the corner of the highlight, or pehraps just a pop-up when you mouse over the highlight, although come to think of it, if you really want to use colours for this purpose, you could make it fully customizble, so that a user could have public disagreement highlights as 'green' or whatever they want, and private agreement highlights as 'olive' or whatever.
maggie_diigo wrote: > Adam, > > Thanks for taking the time to provide us with lots of good feedback. > > As a user, I can appreciate your points about customized colors. However, default color schemes not only make it easy for us to implement (I'd imagine there might be some performance issues if we allow users to dynamically customize the display - performance is something critical that we are unwilling to compromise), it also applies some consistency throughout the site when one is viewing the public annotations. Without a default color scheme, it will also make explaining to the new users how our system works even a lot more complex. For the sake of personalization for some users, wonder if this may cause a lot more confusion to majority of users... Lots of considerations needed here.
hi maggie, i think you misunderstand my suggestion. I suggested that:
1. highlights be of different types, including a 'normal' hihglight, and things like agreement or disagreement
2. there be a default colour for each highlight type
3. users be able to change the local mapping between colours and highlight types
So, when a user viewed public highlights, the default would be, for instance, that all public generic highlights are yellow, all public agreement highlights are green, etc. So even if user A highlighted a passage as 'agreement' and they had their agreement colour set to 'brown', if user B came a long and viewed user A's public highlight, the colour they woudl be see woudl be whatever they have set locally to be the colour for 'agreement' highlights, which would have a reasonable default which most users wouldn't touch. The display of public highlight would be very consitent this way, and in explaing it to new users, the distinction between the tag and the corresponding colour need not even be mentioned--just give them the defaults and perhaps mention briefly that they can change the default colour. I should say this clearly: it's not defaults that are the problem--defaults are *very good*--it's having *unalterable* defaults here. And i say this not just in worship of customizability for customizability's sake--this is a very real part of how people interact with paper documents, and the whole point of electronic annotation ought to be to offer *more* functionality than you have on paper, in every way possible, so that it's less of an uncomfortable trade-off.
You could simplify all this for the user int he following way:
1. by default, only one highlighting type is enabled, and by default it displays as yellow 2. factors such as whether the highlight is public or private, and whether there is a pop-up are NOT indicated by colour, but by other graphical elements, as in Acrobat Professional, for instance 3. users could turn on the 'meaningful colours' option or some such, which would add a few other highlighters to the toolbar, clearly indicated as 'agreement', 'disagreement', etc. and displayed int heir default colours 4. buried much deeper, in 'advanced options' could be the ability to change what colours the highlights display as. this option is less important if a good colour scheme is chosen in advance, but a bad colour scheme could easily displease exactly the sort of annotation-happy user to which this product ought to appeal
The basic idea is that tagging should be more fundamental than the colour of the highlight--at base, users are selecting a passage and identifying it as generically 'important', or 'dubious', or what have you. Then a local setting in the diigo toolbar controls which colours each tag is displayed in, and this would be set to a reasonable default, and most users would never need to touch it. moreover, new users would only be presented with a single highlighter which just tags things as generically 'important' (although of course other tags could be added using the existing interface). This would appeal to the casual users of diigo, as well as the intense annotators who would be the product's greatest proselytes.
as for performance, enlighter and gibeo both offer multicolour highlighting without being slow even on my archaic machine. enlighter's big downfall, other than it appears to be somewhat abandoned now, was that it didnt' allow the reassignment of the colours you have for each tagging category, and so the user documentation urged the user to think carefully about how the set up their colour scheme before they began highlight doccuments--not a good system, as no one wants to have to commit themselves to a system upfront like that--it's time consuming, and guaranteed to disappoint down the road whent he user gradually gets used to the annotation experience adn realizes they'd like to do it a slightly better way. having customizability here allows diigo to evolve to meet various user's needs without additional development.
the 'reassigning' of colours also wouldn't be any more performance intensive than having fixed multiple colours, if the colour reassignment required a reboot of the browser anyway.
> > But still, thanks for bringing this up. We will discuss more in our team to see if there might be a better way of doing this. > > Meanwhile, the new toolbar is up, and the highlight are shown in brighter sets of colors.
I think this colour-coded scheme is really misguided, as it is not based in any way on either:
1. the way people use multiple colours of highlighter on paper
2. any of our intuitions about what various colours 'mean'.
On paper and in Acrobat Professional, for many years i have used a system something like:
Yellow - generic highlight--something 'important'
Green - I Agree!
Red - I Disagree!
Orange - I find this dubious... (orange is 'close' to red qualitatively)
Ice Blue - I don't understand this, or I'll read it later (you're putting the passage 'on ice' for now)
this is the core of the system, and is what i advocate to others. I sometimes also use:
Pale Green - i'm *inclined* to agree
Pale Red - i'm *inclined* to disagree
Purple - this is really unusual/cool/exceptional
Black (with the inner text turned grey), or Grey - to visually mark 'structural' phrases such as "Firstly," or "My second point is as follows:"
I *don't* think that diigo shoudl force users to use one colour system, but shoudl allow them to control colours separately from the 'tag' applied to the annotation (i.e. agreement or disagreement)--i.e. certain highlight would enter diigo's system with the tag 'agreement' or 'disagreement' highlights, and the local user could control what colour highlights with the tag 'disgareement' highlights are displayed as, and if they change this setting, all of their previous disagreement highlights would change colour. This woudl be EXTREMELY useful as it would allow users to evolve their highlight system over time, as they discover what colour patterns aid the perceptual process of working with a document. (Note that tags shoudl be free-form as well, imo, a la many features of google, or how last.fm, the social music site, works.)
However, although no system of colorus should be imposed, one such as the one outlined above shoudl be configured by default for new users, as it is really the best way to use colour in the user experience.
PLEASE don't start using up colours for other purposes (such as pink for group annotation) while i am waiting patiently for you to implement multicolour highlight at the user's discretion for the sort of purposes i've just outlined here--half the point of highlight is to manipulate the salience of the page, so that later you can glance at the page and the pattern of colours in the highlight conveys aspects of the document to you the way a painting does, rather than having to read through every highlight and figure out why you highlighted it, etc.
Not to mention that, using colour both to indicate whether there is an annotation, and whether it's public or group or private is overloading colour too much, imo. Colour should be used for one purpose, and that is to demonstrate at a glance why the user highlighted it--this is how students have highlighted textbooks for years, because obviously there is no analogue to "group" or "public" highlighting on a paper text. Therefore, it's ill-advised to now attempt to use colour for and aspect of highlighting which didn't exist in the paper experience--indicate new aspects, such as public/group highlighting, with something *new*. I would suggest a small icon in the corner of the highlight, or pehraps just a pop-up when you mouse over the highlight, although come to think of it, if you really want to use colours for this purpose, you could make it fully customizble, so that a user could have public disagreement highlights as 'green' or whatever they want, and private agreement highlights as 'olive' or whatever.
> Adam,
>
> Thanks for taking the time to provide us with lots of good feedback.
>
> As a user, I can appreciate your points about customized colors. However, default color schemes not only make it easy for us to implement (I'd imagine there might be some performance issues if we allow users to dynamically customize the display - performance is something critical that we are unwilling to compromise), it also applies some consistency throughout the site when one is viewing the public annotations. Without a default color scheme, it will also make explaining to the new users how our system works even a lot more complex. For the sake of personalization for some users, wonder if this may cause a lot more confusion to majority of users... Lots of considerations needed here.
hi maggie, i think you misunderstand my suggestion. I suggested that:
1. highlights be of different types, including a 'normal' hihglight, and things like agreement or disagreement
2. there be a default colour for each highlight type
3. users be able to change the local mapping between colours and highlight types
So, when a user viewed public highlights, the default would be, for instance, that all public generic highlights are yellow, all public agreement highlights are green, etc. So even if user A highlighted a passage as 'agreement' and they had their agreement colour set to 'brown', if user B came a long and viewed user A's public highlight, the colour they woudl be see woudl be whatever they have set locally to be the colour for 'agreement' highlights, which would have a reasonable default which most users wouldn't touch. The display of public highlight would be very consitent this way, and in explaing it to new users, the distinction between the tag and the corresponding colour need not even be mentioned--just give them the defaults and perhaps mention briefly that they can change the default colour. I should say this clearly: it's not defaults that are the problem--defaults are *very good*--it's having *unalterable* defaults here. And i say this not just in worship of customizability for customizability's sake--this is a very real part of how people interact with paper documents, and the whole point of electronic annotation ought to be to offer *more* functionality than you have on paper, in every way possible, so that it's less of an uncomfortable trade-off.
You could simplify all this for the user int he following way:
1. by default, only one highlighting type is enabled, and by default it displays as yellow
2. factors such as whether the highlight is public or private, and whether there is a pop-up are NOT indicated by colour, but by other graphical elements, as in Acrobat Professional, for instance
3. users could turn on the 'meaningful colours' option or some such, which would add a few other highlighters to the toolbar, clearly indicated as 'agreement', 'disagreement', etc. and displayed int heir default colours
4. buried much deeper, in 'advanced options' could be the ability to change what colours the highlights display as. this option is less important if a good colour scheme is chosen in advance, but a bad colour scheme could easily displease exactly the sort of annotation-happy user to which this product ought to appeal
The basic idea is that tagging should be more fundamental than the colour of the highlight--at base, users are selecting a passage and identifying it as generically 'important', or 'dubious', or what have you. Then a local setting in the diigo toolbar controls which colours each tag is displayed in, and this would be set to a reasonable default, and most users would never need to touch it. moreover, new users would only be presented with a single highlighter which just tags things as generically 'important' (although of course other tags could be added using the existing interface). This would appeal to the casual users of diigo, as well as the intense annotators who would be the product's greatest proselytes.
as for performance, enlighter and gibeo both offer multicolour highlighting without being slow even on my archaic machine. enlighter's big downfall, other than it appears to be somewhat abandoned now, was that it didnt' allow the reassignment of the colours you have for each tagging category, and so the user documentation urged the user to think carefully about how the set up their colour scheme before they began highlight doccuments--not a good system, as no one wants to have to commit themselves to a system upfront like that--it's time consuming, and guaranteed to disappoint down the road whent he user gradually gets used to the annotation experience adn realizes they'd like to do it a slightly better way. having customizability here allows diigo to evolve to meet various user's needs without additional development.
the 'reassigning' of colours also wouldn't be any more performance intensive than having fixed multiple colours, if the colour reassignment required a reboot of the browser anyway.
>
> But still, thanks for bringing this up. We will discuss more in our team to see if there might be a better way of doing this.
>
> Meanwhile, the new toolbar is up, and the highlight are shown in brighter sets of colors.