Yep. The focus/selection indication. It also shows up on stuff like form
elements like checkboxes and buttons too, when they have focus (either
clicking or moving focus with the tab key).
Unfortunately, at least the way the graphic shows in Thunderbird, the
two lozenges in the side-by-side comparison look really similar. If I
saw either one in isolation in a browser, I'd probably assume the UI
element is something that has focus.
Sometimes violating existing convention makes sense of course -- I was
just saying that usually that kind of thing is a last resort. Ideally I
would think we'd want to exhaust the other possible design avenues first
-- and look to see if there's not some other way to indicate 'tentative'
status that's equally effective, and doesn't conflict with a really
pervasive, pre-existing visual motif.
Perhaps 'tentative' could be represented by making the block look
fainter by changing its opacity? I don't know if that's even possible in
Chandler. I know it is something we could do with CSS in the browser.
Matthew
Mimi Yin wrote:
Matthew, you're talking about the dotted black outline that appears
when browsing links with the keyboard and/or on mouse-down when
clicking on links? (IE And Firefox do this, Safari doesnt.)
Here's a tweak that might almost address your concern: Making a 2 pixel
wide dashed outline that lies flat against the lozenge border, rather
than a single-pixel dashed outline. This makes the dashed outline stand
out a bit more without making it ragged and too distracting.
The lozenge on the left has the single pixel black dashed outline to
indicate selection. The lozenge on the right only has the tentative
status 2 pixel-wide dashed outline.
Mimi
------------------------------------------------------------------------
On May 1, 2006, at 5:53 PM, Matthew Eernisse wrote:
Just a thought re. dotted lines and focus indication ...
Mimi Yin wrote:
I think so long as we don't also use a dotted line to represent
selection in Chandler or Scooby, we should be okay.
Users don't need to be able to decipher the visual syntax just by
looking at the calendar. They will learn the visual syntax through
interaction (cause and effect). Assuming performance improvements,
users should be be okay on this front.
The only problem I might foresee is that people's interaction with
Scooby as a Web app will be informed by their interaction with other
Web apps.
They will likely assume (for better or for worse) a certain set of
conventions shared between all the browser-based apps they use --
like the dotted line around focused elements that you see in Internet
Explorer. That's pretty universally understood in the browser by
people using IE as meaning "this thing has focus."
I'm not even sure if this is something you can override, so the idea
of simply not using it to represent selection in Scooby may not be an
option.
That's not to say we should never depart from conventions, but we
should do it thoughtfully, when there are compelling reasons to do
it, and with the awareness that it will cause users some
consternation because we are not only not leveraging existing
conventions, we are contravening them.
Matthew
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
