[Design] [cosmo] Server Restraints and the Dashboard

[Mimi Yin]

<Jared, please scroll down to see a question for you.>

Ah, things are clearing up...see in-line below...

On May 16, 2007, at 11:10 AM, Brian Moseley wrote:

> On 5/15/07, Mimi Yin <mimi at osafoundation.org> 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.

oops. I misunderstood your proposal. I get it now. I don't think we  
can use event-start/end time as you mention at the bttom. We could  
however specify a time range based on the date an item was triaged to  
a particular triage status? the DOATC - dateOnAutoTriageChanged?

We just might end up with views where you can only see 3 items  
because those are the only 3 that show up in the specified time span.  
(Which is what led to the 'dynamically re-adjusting' questions I have  
below.

> 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?

>> 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.

Oh...No, I was trying to say that the people who want to see a little  
bit of everything (items from all 3 triage statuses) in a single view  
are heavy desktop users. It's the people who are 'sitting' in the  
Dashboard, using it as a way to manage their focus.

The theory is, CC in the web UI will have more 'targeted' use cases  
where they go in to enter a new item or edit a specific item, not  
trying to get an overview of the data set.

>
>> + 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.

No, common will people be paging through and changing the sort order  
of the Triage status column.
+ You wouldn't do either if you were just coming in to add your PTO
+ You might have to paginate if you were looking for a specific item  
to update and it wasn't on the 1st page. Users are more likely to  
want to edit NOW and/or LATER items than they are DONE items.

>
>> + 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.

Yup, perhaps as a first pass we could pull down NOW and LATER  
items...and then only as users paginate past LATER items do we pull  
down DONE items? This would save us the additional widget work?

>
>> 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.

Do we have performance targets for Preview? I think it may help  
structure these conversations around 'slowness' in the UI. Otherwise,  
it's hard to ever know if we're fast enough for certain kinds of  
scenarios.

But I understand your concern and we don't want users to have to wait  
several minutes to see anything in the UI.

It seems like however we could stage the data we pull down to the web  
client by TS, as proposed above. First pull down NOW and LATER. Worry  
about DONE on an as-needed basis.

As for recurring events, they are never fully expanded in the  
Dashboard? Do we ever need to expand the entire series in one go?

>
> 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.

Again, I think we need some numbers for Preview. How many  
simultaneous requests do we expect in the Preview timeframe? Jared?

>
> 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.