[Design] [Proposal] Selection behavior when choosing different
mimi at osafoundation.org
Thu Jun 15 09:37:22 PDT 2006
I'm not sure how this addresses the issue of:
+ Persisting overlays separately per each App area; while
+ Persisting collection selection across App areas
Does that sound reasonable to do?
On Jun 14, 2006, at 4:16 PM, John Anderson wrote:
> Thanks for the all caps "heads up" -- although I did glance at the
> previous email.
> How you map selections between the different collections is tricky.
> When I thought it over in the past I concluded that there wasn't a
> solution that would make everybody happy all the time. Furthermore,
> when collections get large, e.g. the All collection, some of the
> proposals, for example the one implemented by Jeffrey, won't scale
> well, i.e. switching to All with take too long to be practical.
>>> From: Jeffrey Harris <jeffrey at osafoundation.org>
>>> Date: June 14, 2006 3:11:50 PM PDT
>>> To: Mimi Yin <mimi at osafoundation.org>
>>> Cc: John Anderson <John at osafoundation.org>, Philippe Bossut
>>> <pbossut at osafoundation.org>, Sheila Mooney
>>> <sheila at osafoundation.org>
>>> Subject: Re: Fwd: [Design] [Proposal] Selection behavior when
>>> choosing different collections
>>> Hi Folks,
>>>> When yous have a moment, could you take a look at this
>>>> thread? http://lists.osafoundation.org/pipermail/design/2006-
>>>> Below is the proposal I've put forth. This affects how selection
>>>> across App areas in the sidebar (both selection in the summary
>>>> pane and
>>>> selection/activation in the sidebar).
>>>> In a nutshell, I'm proposing we move to more of a "Destination"
>>>> where the App areas function more as separate areas and less as
>>>> or ways to switch views (e.g. table to calendar).
>>> Well, the reasonable point that could be described as "when I have a
>>> moment" has most certainly passed, but now I'm looking at this more
>>> Basically, most of what you're asking for here already works.
>>> The main
>>> change is to tweak the selection differently when different
>>> are overlaid, and to store different selection and overlay sets
>>> different destinations. The former is easy to do (I do it one
>>> way in
>>> the calendar, it could be changed easily enough).
>>> The latter means persisting sidebar selection and overlay state
>>> differently, I don't think that should be hard at all, but I'll
>>> defer to
>>> John there, because I don't exactly understand how we do that now.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Design