I think Mimi has already nailed down how she thinks the end-user design
ought to work. The following is taken from a spec referenced in Bug
#2167: Who, Date, not always showing the right attribute.
- Who column
- Notes, Tasks, Events - Who - Blank (to the user)
- Messages - Who (from) or (to) - Display from
if it's incoming mail. Display to if it's outgoing
mail.
- Shared messages - Who (from) or (to) - Display from
if the sender is me. Otherwise, display to.
- About column
- [OI?]
There is a proposal to change the About column to be Subject for all
Kinds. Otherwise, it should be:
- Notes, Tasks, Calendar - About (Title) - Title
- Email - About (Subject) - Subject
- Date column
- The following proposal is contingent on the ability to display
an icon in the same cell as text in the summary table widget
- Which date to display in order of priority:
- Calendar date (if Alarm date is dependent on the Calendar
date: ie. 15 minutes before)
- Alarm date (even if there is a calendar date so long as the
alarm date is a custom date)
- Date sent or Date received
If you think this isn't the right way to go, you might follow up with
her.
John
Ted Leung wrote:
John
Anderson wrote:
I'm planning on getting rid of redirect
attributes to handle the Who, About and Date attributes in the Summary
Table. Instead I plan to add an explicit Who, About and Date attribute.
By noticing when attributes that affect the value of Who, About or Date
change (using onValueChanged), I'll update Who, About and Date as
necessary.
This is simple to implement and eliminates the current problem where
Who, About and Date sometimes doesn't display the correct value. It
also doesn't require a special "computed attribute" that isn't stored
in the repository, so you can always search for Who, About and Date
like any other attribute. Finally, it allows Andi to get rid of
redirect, which simplifies the repository design.
I think we need to take a step back here and really nail down how the
end-user design ought to work. Then we can figure out what the right
thing to do at the implementation level(s) ought to be.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
