Discussion: Dashboard and server contraints

The Cosmo and PPD teams got together to discuss the thread that's been iterating on the design list. The following is a summary of the items that were discussed.

Notes

Exploration of Concerns and Proposals

• BCM summarized the issues...
  • Issue at hand - how do we deal with pulling in all items into the dashboard in the Now, Later and Done section?
  • The current Dashboard design has some performance and scalability issues that we need to consider.
  • Has concerns that we were still displaying every item in the collection. There are browser and server concerns over displaying that much data.
  • The Eng team talked about how to move some of the work off the server and onto the client - minimize the transfer and still show useful amount of data.
• Some options that came up....
  • Limit what is shown in Now, Later and Done constrained by time frame - not paged - time range queries.
  • Limit the number of items coming back in the queries
  • Limit what is shown in the UI
  • We will have to allow the time range to maybe be changed
  • Explored utility of not showing Done items at all unless the user needs to see it
• Jeffrey
  • Time range limiting works with events but does it works for tasks?
  • Can see that limiting the scope of the recurring events that appear in Later will help but this may not be the use case that people are looking at.
• Bobby
  • What about not showing Done? This can be huge.
• BCM - What is the purpose of the list view in the web ui
• From a design perspective there are some questions we need to answer...
  • What are the goals and what are the requirements?
  • What are the use cases that we want to satisfy
  • We have goals and tenets for the Preview release.
• Casual collaborator use cases - trying to accomplish
  • Use Case #1: Plausible promise - enough to give people the sense that we are satisfying more than just calendar events
  • Use Case #2: Overview of what is in the shared collections - see a full list (some of the use cases satisfied by the month view) - compressing a low density calendar
  • Use Case #3: Update status in tasks, targeted use cases, not sitting and looking
• Some strategy for time based display might work but falls short for use case #2
• BCM doesn't want to meet short-term goals wants to think about longterm
• There are a couple of options emerging....
  • Drop the issue of trying to increase the efficiency and suck it up on the server - ignore the performance implications
  • Put in some mechanism where we don't show all the data either paging or defining a timeframe as a short-term solution only - this would have to be changed
• BCM: leaning toward option #1 and cope with performance implications
• Mimi proposed segmenting not by time frame but querying for Now, Later and then Done separately. The server will not always know whether it's Now, Later or Done.
• BCM: what if triage status is not shared. Hard to say if this technique will make a difference really.
• Who owns the the logic of getting all these things triaged (server or client)?
• Are these scenarios we care about?
• If you don't share triage status and we don't have auto-triage on the server side then the dashboard is essentially useless
• Force people to share triage status - not an option - could think about this.
• It's probably ok if people get confused or it gets weird in the case where you don't share triage status.
• Bobby
  • Simple proposal that handles some auto and manual triage section
  • Now - specifically marked now and unmarked - few recurring events
  • Later - everything that is one out for recurrence - upcoming only
  • Done - handled separately - end time of event is prior to now or explicitly set to done (maybe a month back)
  • We could not show the recurring events in Done
• Do we have numbers on our test data set?
• Hard with time since it's a moving window.
• Different rules that determine what the server returns for Now, Later and Done - 3 different queries
• Mimi - summary of things we agree on
  • We agree that it's an edge case that the casual collaborator will end up with a big list of things that have no triage status
  • Edge case that the Now and Later sections will be large
  • Do we have a sense of what is too large? 100 or over
  • Recurrence - we are most worried about recurrence in a particular section? We are not sure at this stage.

Possible Algorithm

• Now:
  • If something is not triaged and non-recurring and not an event
  • If something is not triaged and not passed
  • Specifically triaged as Now
  • If it's occurring right Now
  • If it's recurring and there is an instance that is happening Now
• Later
  • If specifically triaged as Later
  • If recurring event, next occurrence after right now
  • Future modification, return as later
• Done
  • If you have explicitly triaged an item to Done
  • If not triaged and has passed
  • No recurrence
  • Date range giving some # of recently became Done items

• Auto-triage because time is passed - BCM - the client should do this.
• There might be some untriaged items
• If it's it Now, Later and client will figure out if it's really in the wrong.
• Server will handle untriaged stuff and client will handle making sure this is right.
• If we are publishing from the desktop we could handle Done as triage status changed.
• Time based query for Done - when they became done - most recent #
• Creating events - next month automatically becomes Later
• Change to last month - make it Done by default
• Do you do auto-triage on date change
• Explicitly triage blocks this - this would happen on the client if it's feasible
• Ted
  • If we are pushing some of the auto-triage stuff in the client then query the server at different times will come up with a different list.
  • The client does it's first query for each section - processes these and sends info to the server
• Recurrence:
  • All modifications are rendered regardless of Now, Later and Done

Next Actions

• BCM, Bobby and Jeffrey has a separate meeting to work out the details of the algorithm. PPD will review the algorithm to make sure the use cases are satisfied.

-- SheilaMooney - 31 May 2007