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