MacNN coverage

[Andrew Abernathy]

On Nov 30, 2004, at 2:37 PM, Tim Pritlove wrote (regarding the look of 
the checkboxes in OO3):

> Hmm. I will postpone my final opinion until I have had my hands on 
> this new version but so far I disliked it when software didn't accept 
> OSX's look and feel as I don't like to learn recognizing GUI controls 
> on a per-application basis.

As James noted, we do acknowledge that this is an issue. This is a 
subject that got a lot of attention internally before we decided to 
make the change. To defend our choice:

Apple's checkboxes are _controls_. OmniOutliner's checkboxes are 
_content_. (Yes, checking a parent's checkbox can affect the checkboxes 
of ancestors and descendants, but so too can changing the value of a 
numeric cell change the value of its ancestors. Fundamentally, in our 
case the checkboxes are more content than control.)

We feel that this is an important distinction. There are differing user 
expectations for the two different situations. The biggest is probably 
that content should not imply that it is a control, but another big 
issue is simply aesthetic - a control often needs to be "heavier" (for 
lack of a better term offhand) than content, and it's visually 
unappealing to have these heavy elements stuck in the middle of other 
document content. Similarly, we want to keep the on-screen 
representation similar to or identical to the printed version where 
possible (and where appropriate - there are cases where it makes sense 
to treat on-screen and printed output differently, of course). It 
probably wouldn't be good for us to _print_ checkboxes that looked like 
Apple's standard checkboxes, but we did have the reasonable opportunity 
to make the on-screen checkboxes look like the printed ones.

Part of this is also context - widgets may simply be visually 
problematic in different contexts. There is an example that you 
yourself touched on, though you weren't aware of or didn't remember 
Apple's solution:

> Pop-up menus seem to have a different appearance as well... hmm.

Apple changes the appearance of their standard popup buttons when they 
are in tables. This makes sense - the standard popup button would 
typically force a taller-than-desired row height, and would be visually 
unattractive (and even difficult to read/visually process) placed in 
tight table rows. (I'm drawing a blank on a good example at the moment, 
but I expect you've seen it at some point.)

Apple also changes the popup appearance in Address Book (when you're 
editing an address) and iCal (editing an event), as a couple of 
examples. These cases aren't using tables, but I think most people 
would agree that it works very well in these contexts.

OmniOutliner has always taken Apple's approach to popups in tables (in 
our case, in an outline). In version 3, we extended that a bit, in the 
spirit of "this is content not control": popup handles are not visible 
unless you are hovering over the cell. We believe that this greatly 
improves readability by removing visual clutter, with minimal negative 
impact.


Having said all that, I'm sure that some people will prefer the 
standard checkboxes. We have discussed some ways to accommodate that, 
and we do hope to address it in the future (there are other reasons for 
wanting more flexibility that I'm not going to go into at this point), 
but it's unlikely be in the near term (depending partially on user 
feedback, of course).

-andrew