[Design] [cosmo] Server Restraints and the Dashboard

Bobby Rullo br at osafoundation.org
Fri May 18 16:44:59 PDT 2007


On May 18, 2007, at 12:35 PM, Jeffrey Harris wrote:

> Hi Bobby,
>
>> That made sense until I saw the word "auto" in your
>> "dateOnAutoTriageChanged" variable. Why only "auto"?
>
> I think Mimi was confusing the boolean variable  
> doAutoTriageOnDateChange
> (occasionally abbreviated doATODC) with triageStatusChanged, which is
> akin to a timestamp.
>

Makes sense.

>> But otherwise, it does make sense to me that you cannot use only
>> "eventStart" as not everything is an event. But I think you do  
>> need to
>> have eventStart be part of the query because the event might not be
>> auto-triaged yet to "NOW" - there might not be a Chandler triaging  
>> this
>> event in which case it would never show up in "NOW"
>
> Hmm.  Chandler puts all new items in NOW by default, unless they've  
> got
> some date information in which case Chandler triages it appropriately
> based on its time.
>
> I can see why it might be challenging to have the server put events in
> DONE or LATER based on time, but I think probably you want to treat
> anything that hasn't been triaged yet as NOW.
>

Yes, but what about occurrences? They aren't explicitly triaged as  
anything because they are not persisted (until someone makes a  
modification) so that's why I said you need to use eventStart so you  
can figure out what occurrences haven't been triaged yet, to stick in  
"NOW"

>> What's so bad about just three events? If you really don't have that
>> much going on in the next week/fortnight, is it important to show  
>> stuff
>> beyond that range just for the sake of filling out the section?
>
> I think of the LATER section as having two big uses: things to  
> consider
> working on when I'm stuck on my NOW items, and an at a glance  
> picture of
> upcoming future stuff.  If you limit the time range in LATER, you
> satisfy the latter use, but it gets in the way of the former.

Ok, I never considered that use case.
>
>
> The collections I'm imagining a casual collaborator finding a  
> dashboard
> view useful for aren't likely to contain many (if any) birthdays or
> annual events, they'll mostly contain tasks and notes and a few  
> events,
> some of which may be a few months out but are important to see to  
> get a
> complete view of the project.  If you postulate that my posited  
> data set
> (although I understand we may disagree about how likely this is), does
> my attachment to seeing all of LATER make sense?

It does make sense. However we cannot dictate how people will use  
Cosmo UI ("Don't use dashboard for collections with birthdays!") so  
we have protect the server from getting hammered.

Maybe Mimi's idea of expanding the date range if there aren't  
"enough" events could work?

bobby





More information about the Design mailing list