Hi Folks, Today Brian, Bobby and I had a meeting hashing out more details of triage status in the web UI's table view. Most of our focus was on recurrence.
I wanted to call out a few differences between how recurring events interact with triage on the desktop and the current plan for how they'll interact in the web UI. On the desktop, when a recurring event is first imported, all the occurrences in the past are triaged DONE, but as time goes by, occurrences are triaged into NOW. So if I have a daily 10AM event, if I quit Chandler and come back to it two days later at 2PM, two occurrences will have moved from LATER to NOW. This works on the desktop because there's a clear concept of when the recurring item was created or imported, and we know which occurrences need to be triaged to NOW because of the passage of time. On the web, both of these details are missing. There isn't really a concept of whether a particular recurring event is new, or when events' triage status attributes were last updated to NOW. So it's hard to know which, if any, occurrences that are currently in the past ought to be triaged to NOW because of the passage of time. What Bobby, Brian and I proposed today was to have the web UI only show a NOW occurrence in a few cases: - When a web UI or desktop user triaged the occurrence to NOW already - If the table happens to be shown when an occurrence is in progress - If a future occurrence has non-triage changes (like, say, the title was changed), creating a modification. In this case the when the modification is created it will have a LATER triage status associated with it, so if the client sees the modification after time has passed, it will know to triage it as NOW This means most of the time, recurring events will show a LATER occurrence, but not a NOW occurrence, similar to the way recurring events are displayed when they're imported in the desktop, even if a day or two has passed and what used to be a LATER occurrence is now in the past. One minor aspect of this is that if an occurrence in the past is triaged as LATER, it won't stay that way, the next time the web UI views that collection it will see an occurrence in the past with a LATER triage status, and it will move it to NOW. ------------ Now that I've written all that up, I wonder how hard it would be to have the web ui's table view store the most recent timestamp for when it renders a collection, and use this to remedy these issues? It seems like if that information was saved, the web UI could behave more like the desktop without too much extra effort. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
