[Design] [cosmo] Server Restraints and the Dashboard

[Matthew Eernisse]

Comments below ...

Brian Moseley wrote:
> alternate proposal: choose a time-range for each section and show only
> the items that are relevant to that time-range. allow the time-range
> to be widened/narrowed.

If users widened the range too far, resulting in too many items, we 
could provide a "please narrow your search" error. That's pretty common 
practice.

>> Some random ideas to throw out:
>> + What if we had separate buttons at the top of the Dashboard view that
>> allow you to view different configurations of triage statuses?
>> + We load by default with only NOW and LATER and users can opt to view 
>> DONE?
>> DONE could be mutually exclusive with NOW and LATER and/or we only 
>> pull down
>> 25 DONE items.
> 
> both of these ideas sound fine. i personally don't have a strong
> preference on how to set the constraints. what's important to me is
> that we don't have lots of clients asking the server for thousands of
> items all the time.

Seems like even with keeping Done separate, we could end up with a Done 
that is too big for the browser to handle. Even Done queries would need 
to be time-bound.

>> Lastly, when we say that sorting and pagination will be slow, what do we
>> mean by slow? I guess I'm not understanding why the Dashboard would be 
>> any
>> slower at paginating than other web apps that have to deal with long
>> lists...Is it because users can potentially change triage status, which
>> would kick off a re-sort/re-paginate? Could we delay re-sorting or
>> re-paginating when users change triage status?

Other Web apps deal with long lists by doing the sorting and pagination 
on the server.

We might want to do some benchmarking in all our supported browsers to 
determine how long is 'long,' and how slow is 'slow' -- but I suspect 
that lists of a couple of thousand items would be sluggish in both 
paging and sorting when done client-side.


Matthew