moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 01:32:22 -05:00
Code Issues Releases Wiki Activity

XEP-0392: Remove all UX/UI recommendations

Browse Source 
Those are out of scope for the XSF. This also constitutes the
release of version 0.7.0.
This commit is contained in:
Jonas Schäfer 2019-10-16 17:44:35 +02:00
parent 3cf95c2f27
commit e885fcbbef
1 changed files with 31 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
xep-0392.xml
View File

@ -23,6 +23,16 @@
<supersededby/>
<shortname>colors</shortname>
&jonaswielicki;
<revision>
<version>0.7.0</version>
<date>2019-10-16</date>
<initials>jsc</initials>
<remark>
<p>Remove anything except the Hue generation from the specification. The
other parts were user interface suggestions which are out of scope for
the XSF standards process.</p>
</remark>
</revision>
<revision>
<version>0.6.0</version>
<date>2018-10-02</date>
@ -98,7 +108,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Colors provide a valuable visual cue to recognize shapes. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities, without having to actually read the text.</p>
<p>Clients have been using randomly or deterministically chosen colors for users in multi-user situations for a long time already. However, since there has been no standard for how this is implemented, the experience differs across platforms. The goal of this XEP is to provide a uniform, platform-independent, stateless and easy-to-implement way to map arbitrary bytestrings to colors, as well as give recommendations how this is applied to color names of participants in conversations, roster entries and other pieces of text.</p>
<p>Clients have been using randomly or deterministically chosen colors for users in multi-user situations for a long time already. However, since there has been no standard for how this is implemented, the experience differs across platforms. The goal of this XEP is to provide a uniform, platform-independent, stateless and easy-to-implement way to map arbitrary bytestrings to colors.</p>
<p>To allow cross-client use, it is important that the color scheme can be adapted to different environments. This specification provides means to adapt colors to different background colors as well as &cvds;.</p>
<p>In no way is the system presented in this specification a replacement for names. It only serves as an additional visual aid.</p>
</section1>
@ -115,28 +125,14 @@
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Generating a color' anchor='usecase-textcolor'>
<p>To generate a color from a string of text, the follownig algorithms are applied in order:</p>
<p>To generate a color from a string of text, the following algorithms are applied in order:</p>
<ol>
<li><link url='#algorithm-angle'>Generate a Hue value from the text</link>.</li>
<li>If enabled, <link url='#algorithm-cvd'>apply configured corrections for &cvds;</link>.</li>
<li>If the output device only supports a small palette of colors, <link url='#algorithm-mappalette'>map the angle to the closest palette color</link>.</li>
<li>If constraints mandate the use of only a small palette of colors, <link url='#algorithm-mappalette'>map the angle to the closest palette color</link>. (Such situations could for example be a UI environment with guidelines to only use a specific set of colors or an output device which only supports a limited amount of colors.)</li>
<li>If the output device supports RGB output, <link url='#algorithm-rgb'>Convert the angle to a RGB</link>.</li>
</ol>
</section2>
<section2 topic='Adding colors to participants of a conversation' anchor='usecase-nickcolor'>
<p>Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish.</p>
<p>In such cases, the color SHOULD be generated as described in the <link url='#usecase-textcolor'>Generating a color</link> section. The input used SHOULD be, in descending order of preference, (a) the bare JID of the user (not the room), (b) the nickname as chosen by the user in the room.</p>
</section2>
<section2 topic='Auto-Generating Avatars' anchor='usecase-avatar'>
<p>Implementations may want to show a picture in connection with a contact even if the contact does not have an avatar defined (e.g. via &xep0084;).</p>
<p>In such cases, auto-generating an avatar SHOULD happen as follows:</p>
<ol>
<li>Obtain a name for the contact, in descending order of preference, (a) the nickname from the conversation, (b) the bare JID of the contact (<em>not</em> the bare JID of the conference in case of a &xep0045; room).</li>
<li>Generate a color as described in the <link url='#usecase-textcolor'>Generating a color</link> section.</li>
<li>Fill an implementation-defined background shape with that color.</li>
<li>Render the first character of the name in white or black centered on the shape.</li>
</ol>
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<ul>
@ -171,24 +167,8 @@
<p>Note: the same effect can be achieved by setting the most-significant bit to zero before conversion to floating point in <link url="#algorithm-angle">Angle generation</link>. This avoids having to perform a floating-point modulo operation.</p>
</section3>
</section2>
<section2 topic='Adapting the Color for specific Background Colors' anchor='algorithm-bg'>
<p>Input: RGB values for the color to adapt (Ri, Gi, Bi) and for the background color to adapt to (Rb, Gb, Bb), in the range from 0 to 1 each.</p>
<p>Output: Values for Red (Rc), Green (Gc) and Blue (Bc) in the RGB color space in the range from 0 to 1.</p>
<ol>
<li>Invert the background color by subtracting the individual channels from 1 each:
<code><![CDATA[
rb_inv = 1-rb;
gb_inv = 1-gb;
bb_inv = 1-bb;]]></code></li>
<li>Mix the inverted background with the color to adapt, using a mixing factor of 0.2:
<code><![CDATA[
rc = 0.2*rb_inv + 0.8*ri;
gc = 0.2*gb_inv + 0.8*gi;
bc = 0.2*bb_inv + 0.8*bi;]]></code></li>
</ol>
</section2>
<section2 topic='RGB generation' anchor='algorithm-rgb'>
<p>Use the HSLuv operation <tt>hsluvToRgb</tt> to convert the Hue angle to a color. For this, saturation SHOULD be set to 100 and lightness SHOULD be set to 50.</p>
<p>Use the HSLuv operation <tt>hsluvToRgb</tt> to convert the Hue angle to a color. The saturation and lightness are to be defined by the implementation (see also the <link url="#accessibility-cr">Contrast Ratio considerations</link>).</p>
</section2>
<section2 topic='Conversion of an RGB color palette to a Hue palette' anchor='algorithm-genpalette'>
<p>Input: A set of RGB colors (each component from 0 to 1).</p>
@ -225,24 +205,24 @@ bc = 0.2*bb_inv + 0.8*bi;]]></code></li>
<section2 topic='Gamma Correction' anchor='impl-gamma'>
<p>Implementations should be aware of Gamma correction and apply it as needed.</p>
</section2>
<section2 topic='Background Color Correction' anchor='impl-bgcolor'>
<p>An implementation which shows the generated colors on a colored background SHOULD apply <link url='#algorithm-bg'>Adapting the Color for specific Background Colors</link>. If the background is not uniformly colored, it is up to the implementation to determine an appropriate surrogate background color to correct against.</p>
<p>If an implementation shows the generated colors on a grayscale (including white and black) background, it MAY apply the background color correction algorithm. It is RECOMMENDED to always apply the algorithm if the background color is changed dynamically, to avoid discontinuities between grayscale and colored backgrounds.</p>
<p>Implementations SHOULD use the same background color for all generated colors. If this is not feasible, implementations SHOULD use the same background color for all generated colors within the same GUI control (for example, within a conversation and within the roster).</p>
</section2>
<section2 topic='Normalization' anchor='impl-norm'>
<p>When processing JIDs as text input, implementations MUST prepare the JID as it would for comparing it to another JID with a case-sensitive comparison function.</p>
</section2>
</section1>
<section1 topic='Accessibility Considerations' anchor='access'>
<p>As outlined above, implementations SHOULD offer the &rgblind; and &bblind; corrections as defined in the <link url='#algorithm-cvd'>Corrections for &cvds;</link> section. Users SHOULD be allowed to choose between:</p>
<ul>
<li>disabling all corrections (skip the Corrections for &cvds; step entirely),</li>
<li>applying one of the &cvd; correction profiles and</li>
<li>disabling colorization altogether.</li>
</ul>
<p>The last option is useful for users with monochromatic view or who find colors distracting.</p>
<p>Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts.</p>
<section2 topic='Color Vision Deficiencies' anchor='access-cvds'>
<p>As outlined above, implementations SHOULD offer the &rgblind; and &bblind; corrections as defined in the <link url='#algorithm-cvd'>Corrections for &cvds;</link> section. Users SHOULD be allowed to choose between:</p>
<ul>
<li>disabling all corrections (skip the Corrections for &cvds; step entirely),</li>
<li>applying one of the &cvd; correction profiles and</li>
<li>disabling colorization altogether.</li>
</ul>
<p>The last option is useful for users with monochromatic view or who find colors distracting.</p>
<p>Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts.</p>
</section2>
<section2 topic='Contrast Ratio' anchor='access-cr'>
<p>Implementations should adapt the lightness value according to the background on which the color is rendered.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see &xep0165; for examples) in JIDs, it may add additional protection against attacks based on those.</p>
@ -272,28 +252,14 @@ bc = 0.2*bb_inv + 0.8*bi;]]></code></li>
<p>SHA-1 is widely available. From a security point of view, the exact choice of hash function does not matter here, since it is truncated to 16 bits. At this length, any cryptographic hash function is weak.</p>
</section2>
<section2 topic='Palette-mapping function' anchor='design-palette-mapping'>
<p>The palette-mapping algorithm operates on angles only and disregards the Y value except if the angles match. This has the downside that the brightness is not equal over the range of the palette mapped colors.</p>
<p>The alternative would be to require Y to be close to the target Y. This has several issues:</p>
<p>The palette-mapping algorithm operates on angles only and disregards the lightness value except if the angles match. This has the downside that the brightness is not equal over the range of the palette mapped colors.</p>
<p>The alternative would be to require the lightness to be close to the target lightness. This has several issues:</p>
<ul>
<li>We cannot know if a palette can satisfy the given Y at all.</li>
<li>Many colors from e.g. the "Web Safe" palette (used in 256 color terminals and the test vectors) will not satisfy any given Y, reducing the size of the effective palette drastically.</li>
<li>We cannot know if a palette can satisfy the given lightness at all.</li>
<li>Many colors from e.g. the "Web Safe" palette (used in 256 color terminals and the test vectors) will not satisfy any given lightness, reducing the size of the effective palette drastically.</li>
</ul>
<p>For the sake of having more colors available, the given algorithm was chosen which prefers many colors with hue conformance over fewer colors with hue and lightness conformance.</p>
</section2>
<section2 topic='Input for color generation in a Multi-User Chat (XEP-0045) context' anchor='design-muc-input'>
<p>In &xep0045; conversations (MUCs), there are two viable choices for the hash function input when generating a color for a participant: the nickname as chosen by the participant (or their full JID) and the participants real bare JID. Both options have advantages and disadvantages. The advantages of using the nickname are:</p>
<ul>
<li>Yields the same output even in anonymous MUCs if the same nickname is used.</li>
<li>Is guaranteed to work for transports implementing &xep0045;.</li>
</ul>
<p>The advantages of using the bare JID are:</p>
<ul>
<li>Allows to use the same color in 1:1 communications with that entity as in group chats, helping with recognizability.</li>
<li>Stays constant even across changes of ephemeral information like nicknames.</li>
</ul>
<p>There is no obvious correct choice to make here; both choices break in different use-cases. Specifically, the "nickname" choice breaks when the same entity has different nicknames in different rooms, as well as when two different entities have the same nickname in different rooms. The "bare JID" choice breaks when (semi-)anonymous MUCs are involved.</p>
<p>The choice "bare JID" has the conceptual advantage that it ties as closely as possible to the identity of the entity. It is also forward-compatible with future protocols where nicknames might not be available or work differently.</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;. </p>