KG01 - See comments inline. On Jul 19, 2012, at 11:33 PM, Andre Fischer <[email protected]> wrote:
> On 19.07.2012 16:43, Ariel Constenla-Haile wrote: >> Hi there, >> >> entering a color in the new color, with its hex code, has a rather >> strange result. Try >> >> - menu "Tools" -"Options..." >> - on the "Options" dialog, select the on the tree "OpenOffice.org" >> - "Colors" >> - select a color and press the "Edit..." button (side comment: the color >> picker should be available from the floating window that opens from >> the toolbar!) >> - enter some color in the "Hex #" edit field, for example AA >> >> If I enter AA, I would expect it to be #0000AA, that is, zeros added at >> the left. >> >> AA -> 0000AA -> RBG 0,0,170 >> >> but the color picker shows RGB 170,170,170 > > AA -> AAAAAA > > seems to me more natural then than AA -> 0000AA or AA -> AA0000 (or AA -> > 00AA00) > KG01 - These examples, along with the behavior expectations may make sense to a developer, however in 15 yrs of digital design, I've never assumed a tool would resolve my hex input. I suspect we all agree that the colour picker UX needs work, I'm not sure this fix would address the core issues. Regardless, from a UX perspective, the tool should prevent users from having to refine or correct autocomplete. Furthermore, if a specific syntax is required, then the input field and supporting instructional text and examples should make the expected syntax obvious. >> >> Enter only A >> >> A -> 00000A -> RGB 0,0,10 >> >> but the color picker shows RGB 160,160,160 > > this is unexpected. Following the previous case I would have expected > A -> 0A0A0A > >> >> Enter ABC >> >> ABC -> 000ABC -> RGB o,10,188 >> >> the color picker shows 171,171,171 > > urgh, I would expect an error message here > KG01 - error prevention is better than error recovery > -Andre > >> >> Which should be the expected behaviour? >> >> >> Regards >> >
