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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
