At the last meeting I sketched out the beginnings of the algorithms
for Dashboard Queries on the server-side. Here is a rough outline of
that algorithm:
http://chandlerproject.org/Journal/TheAlgorithm
This page also contains a stab at the algorithm on the client side
for auto-triaging newly created items, and for auto-triaging items
obtained from the server due to time passing (tickling). Mimi's Open
Questions are also on that page.
As today's meeting will be about addressing recurrence issues and the
dashboard, and refining these algorithms, the page can serve as sort
of a worksheet and agenda for the meeting.
Bobby
On Jun 4, 2007, at 12:42 PM, Mimi Yin wrote:
Bobby and I chatted briefly today to catch up on Dashboard and
Recurrence issues and came up with the following list of Open
Questions and Scenarios. Bobby, BCM, Jeffrey and Ted will be
meeting tomorrow at 11AM PST to hopefully iron out some of these
issues:
The current Recurrence Proposal as I understand it:
1. The web client does not have the smarts to expand recurring
event series.
2. The web client will ask the server to expand the series and send
down:
+ 1 NOW occurrence (if there is one)
+ The next LATER occurrence (If there is one)
+ The last DONE occurrence (if there is one). Open question:
Jeffrey felt the logic for DONE instances was quite a bit more
complicated than NOW and LATER and perhaps should be ignored for
Preview.
+ Any modified instances. Open question: Would it help to ignore
modifications for Preview?
Open Question: Does the master event of a recurring event series
have a triage status? If so, what is it?
Open Question: When the server expands the recurring event series
and sends down 1 NOW and 1 LATER instant, does that turn those
instances into modifications?
===
The current Auto-triage Proposal as I understand it:
Bobby proposes that we do both kinds of auto-triage in the web client:
1. Auto-triaging events based on their start/end date/time metadata.
2. Auto-triaging events to NOW as time passes (aka Tickling)
3. Events will not be auto-triaged to DONE as time passes. Once
events have been auto-triaged to NOW via tickling, they stay there
until the user explicitly triages them to DONE.
4. The web client will understand how to set and respect the flag
to 'stop auto-triaging on changes to event date/time metadata.'
+ Once an item has been auto-triaged (tickled) to NOW as time
passes, the web client should stop auto-triaging items on changes
to event date/time metadata.
+ Once an user (any user, Desktop or Hub, sharing the item) has
explicitly clicked the Triage buttons to manually assign Triage
Status to an item, the web client should stop auto-triaging items
on changes to event date/time metadata.
5. The web UI will only auto-triage items based on event date/time
metadata and ignore alarms. However, Desktop clients that Auto-
triage (Tickle) items to NOW when alarms fire will send that
information to the server and the web UI will respect that the
Triage Status has been 'explicitly' set to NOW which in turns
overrides any Triage Status the web UI might wish to automatically
assign the event.
Are there other scenarios we should spec out in detail?
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
