Hi
I think I understand better what the issue is. Let me see if I can
repeat what's been said.
+ User-experience wise, it is better to be able to display some nice
balance of NOW, LATER and DONE items. This would make the 'Dashboard'
truly a Dashboard of your life.
+ There are technical difficulties around using pagination as a way
to curtail the number of items the UI has to load. Namely:
- There may be too much data to sort and paginate in the browser...
- And too much data to sort and paginate on the server
+ Paging doesn't really avoid this performance issue because in order
to figure out what items go on any given page, you have to sort first.
+ Proposal: Pick some # of items from each section to pulldown, sort
Questions about the Proposal
+ Will the #s we pick make it so that all items fit onto 1 page?
+ How will we deal with cases where there are 0 LATER items or 0 DONE
items? Will it be more work to change the #s dynamically depending on
how many items there are with any given triage status.
+ How will users see all items for a particular triage status? (I
think this will be important for users trying to look for a
particular item to edit, which we've said is a common CC use case.)
Other issues to consider:
+ How common will it be for CC's to use the Dashboard view as a way
to get an overview of a collection? Most of the use cases we outlined
have been targeted get in / get out operations: Adding my PTO,
Creating a new task to track, Updating status on a task. The
usability concerns addressed by this particular proposal feel closer
to use cases we've described for heavy Desktop users?
+ How common will sorting and paginating be for CC's in Preview?
(Note: Users will only be sorting on Triage status)
+ It is likely that users will start out with rather large DONE
sections. That's been the case on the Desktop. I wonder if it would
be strategic to focus mostly on concatenating DONE? (Heh, just saw
Jeffrey's post.)
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.
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?
Mimi
On May 15, 2007, at 4:05 PM, Brian Moseley wrote:
On 5/15/07, Priscilla Chung <[EMAIL PROTECTED]> wrote:
For 0.7, this may be ok. However, over the longer term there will be
a need for people to have access to everything they have 'DONE'. I
realize this may complicate the UI for 0.7 and agreed we should find
the happy medium on the limit of how far back to go.
and, well, we might need to think harder about how to provide that
access.
let me try to explain the concerns that matthew and i have. it's
likely that a typical chandler user will, over time, develop a very
large set of DONE items, a smaller set of LATER items, and a
relatively small number of NOW items.
matthew is concerned that the set of DONE + LATER + NOW items will be
so large that it will be slow and inefficient to sort and page them in
the browser. very important to avoid.
i'm concerned that the same set will be so large that it will be slow
and inefficient for the server to sort and page them, especially when
you consider that the server will be handling requests from many users
simultaneously. clients each represent an additional cpu that the
server doesn't have, and it makes sense to distribute as much work as
possible to each of these additional cpus to keep the server dedicated
to things that only it can do.
the best option for making us both happy is to constrain the data set
that the server has to return to the client.
yes, you could argue that's what paging is for. but paging across the
"superset" (DONE + LATER + NOW) doesn't seem to make sense for
usability, and anyway, paging requires sorting to be done first, so if
you give paging to the server, you have to give it both, and we're
trying to avoid that.
an alternative to "page the superset" is what we've suggested: define
constraints for each subset that naturally limits the number of data
items that come back from the server sorted in "natural" order.
natural order might be by triage status rank (that negative floating
number) or by chronology (reversed for DONE items). i don't know if it
matters.
let's say i have 2000 DONE items, 5 NOW items and 500 LATER items in
my collection. using the "page the superset" method, the server would
have to sort 2505 items and then slice out the requested page to
return to the browser.
with the "constrained subsets" method, the server would perform 3
queries and return, say, last week's DONE items (maybe 20?), the 5 NOW
items, and next week's LATER items (5?). the client could sort these
30 items in a fraction of the time the server could sort 2505, and it
wouldn't have to bother with slicing out a page at all, unless the
numbers are a lot bigger than i posit here, which would be pretty
surprising. and even then, it could page each subset individually,
which opens up some interesting possibilities.
of course, we could always build in ways to expand the subset
time-ranges or otherwise alter their constraints. taken to the logical
extreme, we could even remove the constraints. this would effectively
burden the client with doing all of the sorting and paging. but hey,
80% (probably more) of our users will never bother to do that, so only
the power ones will be (potentially) affected. that's way better, imo,
than automatically forcing all of this work onto the server,
decreasing its overall capacity and throughput.
One thing we could do is ask 'dogfooders' how far back their 'DONE'
items go and do they ever reference it. Secondly, how far back do
users view their e-mail to reference things?
yes please. i suspect many fewer people would be inconvenienced by my
proposal than by the original idea.
re email, i use gmail, so i just use search to find whatever i need. i
certainly don't try to browse sequentially through millions of
messages.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
