On 5/15/07, Mimi Yin <[EMAIL PROTECTED]> wrote:
+ Proposal: Pick some # of items from each section to pulldown, sort
<admiral ackbar> it's a trap! doing this is effectively the same as paging. it requires sorting the entire section in order to find the "first n" or "last n" items of the section. we're trying to avoid this specifically in order to handle very large collections which must have at least one very large collection. 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.
Questions about the Proposal + Will the #s we pick make it so that all items fit onto 1 page?
what do you mean by page? do you mean within a browser window without having to scroll? if so, i don't know how accurately we can predict this. is it important for some reason?
+ How will we deal with cases where there are 0 LATER items or 0 DONE items?
show a section header and maybe a message to the effect that are no later items?
Will it be more work to change the #s dynamically depending on how many items there are with any given triage status.
see above for why this isn't a good idea.
+ 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.)
as i suggested above, provide widgets to control the time-frame for each section. this still gets us into the situation where the server has to send a huge data set across the internet to the browser, regardless of who sorts the data set.
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?
if i understand you correctly, you are suggesting that the people who will need to look at the really old stuff or the stuff happening way out in the future are likely to be heavy desktop users rather than primarily web users. i agree with that and think that's how we should push them. in other words, we might not need to offer a "view all" option for any section or for the collection as a whole.
+ How common will sorting and paginating be for CC's in Preview? (Note: Users will only be sorting on Triage status)
do you mean, how common will it be for people to have large collections? pretty common, i think, with folks importing historical personal calendars. again, calendars only grow over time. they almost never shrink.
+ 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.)
that's the area of main concern, yes. but there's also the birthday problem for LATER.
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.
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?
consider mitch's calendar, which has what, 2000 events? 1) if the browser asks for all of the items, including recurrence expansion, and does the sorting and paging itself, the server has to transmit a HUGE amount of data back to the browser. that's why subscribing to such a collection from the desktop app takes minutes. then the browser has to sort that large list and find the slice to actually render. that's probably not a terribly big deal, but i understand matthew's sensitivity to every millisecond the browser spends preparing itself to render updates. 2) if the browser asks for "page five" of the items, the server has to do the sorting and paging itself. that's not a big deal when one browser is asking, but what if a hundred or a thousand or ten thousand browsers are asking in the same short period of time? this would quickly become a scalability bottleneck. here's why i think it's so compelling to define LATER, NOW and DONE as time ranges. when an update is made to an item by the user, the ui doesn't have to re-fetch any data from the server. the ui already has all of the information it needs to update the display. it knows which section to move the item into, whether or not the item start/end times overlap the section's time range, and how to re-sort the new section. the only need to talk to the server is to save the item update. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
