On Freitag, 24. März 2017 08:37:57 CET you wrote: > > On 22 Mar 2017, at 18:53, Jonas Wielicki <[email protected]> wrote: > > > > During the Chemnitzer Linux Tage, Georg, Daniel and I had some discussion > > on the topic of how to generate "randomised" colours for use in XMPP > > clients. Uses include but are not limited to: Nicknames (this is already > > done by many clients, but inconsistently), Individual roster entries, > > User accounts, MUCs and MIXes and so on. That idea alone isn’t new. > > > > The idea is to standardise how those colours are generated accross > > clients. > > The advantage is that a user can quickly recognise all of their contacts, > > no matter which device they’re on. The recognition of colours is way > > faster than names. Combined with geometrical features like length of > > name, it often, from my experience, is a sufficient identifier to be > > unique even in crowded MUCs. > > > > So we threw together our thoughts on that matter in a wiki article > > <https://wiki.xmpp.org/web/Contact_Colors > > <https://wiki.xmpp.org/web/Contact_Colors>>. Georg came up with using the > > YCbCr colour space for sampling the colours, and we’re pretty happy with > > the results so far. It’s trivial to adapt the lightness of the colours to > > the environment. > > > > We’d like to have input from other client developers. We think that this > > is a good idea which can subtly improve user experience; implementations > > which already have a "randomised" colouring can easily upgrade. > > > > > > We would like to have input from other client developers, especially on > > those things explicitly marked as "open for debate", but other > > suggestions for an easy-to-implement colouring scheme are also welcome. > > > > > > We might turn this into a ProtoXEP at some later point---although I’m > > personally not sure this is XEP material. > > Quite a complex problem you choose to solve there. Ideally you want a colour > palette where the colours are as much different to the user as possible. > Each user has a different impression on what colours are different and what > look the same,
Which is why we will uniformly sample a space of hues covering most hues. That’s as good as it can get, I think. (Of course, it’s possible that Georgs and mine colour perception is way off and everyone thinks that YCbCr BT.2020 way better represents nearly equally light colours than YCbCr BT.601 does. In that case, everything may be lost, really. But I sure hope that’s not the case!) > considering things like colour blindness or dyschromatopsia > <http://www.dict.cc/englisch-deutsch/dyschromatopsia.html>. Indeed, colour blindness is an issue. I have thought about that and came to the conclusion that it is not trivial to solve, due to the different types which exist. What is theoretically possible is to exclude some part of the colour space to cater for red-green-blindness. I’m not sure if it makes sense to have this feature at all for the more severe (and rare, to my knowledge) types of disabilities(? Note: English is not my native language. Let me know if my choice of words is insulting or in any way inappropriate here!). We had thought about specifying a "red-green-blind" profile of the algorithm, but we would like some input from people who know more about that type of disabilities before proposing anything. > The more > colours you have in your colour palette, the more likely you’ll have very > similar colours, which some users can’t distinguish. Ideally you want as > many different colours as you have members in the room, so they are most > distinguishable. However, what happens if people join/leave. If you > generate a whole new palette all occupant colours change, but you would > want occupant colours to be stable. Right, we are after a 90% solution here. The idea is that with a mixing function like SHA-1, the colours hues will be uniformly distributed (unless someone attempts to collision-attack using nicknames). This makes it as good as it can get. Don’t forget that the colour isn’t the only geometrical feature of the nickname which is immediately and easily recognised. The rough shape of the name will also be recognisable, and will in most cases add the few bits of visual entropy needed to distinguish participants with, due to colour unavoidable collisions, similar or equal colours. > Furthermore a sensible colour palette > for nicknames depends on the colours of the chat theme. If the chat theme > has a light green background it probably rules out some colours that would > work fine in a white background chat theme. Coloured backgrounds will be tricky. We suggest in the article that it might make sense to mix the generated colour with the inverse of the background to improve contrast in such cases. In many cases it will be sufficient to mix in some black or white to improve contrast between background and colour. > An interesting site regarding colour palette generation, with scientific > background, I’ve found a couple years ago is > http://tools.medialab.sciences-po.fr/iwanthue/ > <http://tools.medialab.sciences-po.fr/iwanthue/> . Don’t know if you guys > know about that. Haven’t seen it yet, thanks! We will take a look at it. Thanks for your input! kind regards, jonas p.s.: If it’s possible for you without additional work, please do not address replies which you also sent to the list directly to me. It helps with sorting my email and with replying correctly.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
