On Sep 18, 2007, at 4:15 PM, Philippe Bossut wrote:
Hi Mimi,
Mimi Yin wrote:
I'm not sure we need to solve this problem for Preview.
Which is too late anyway since Preview has been shipped already,
hasn't it? :)
Whoops, force of habit. 1.0 :)
I propose that we display the byline info (edited-by/updated-by)
ONLY WHEN AN ITEM HAS BEEN MARKED UNREAD (either because a sharee
edited the item or because someone else updated the item).
However, as soon as the user has clicked on the item and the item
is now READ, the WHO column should return to displaying either
FROM or TO depending on whether the message is Inbound or Outbound.
Here's an example to illustrate.
I dragged an email in from my email client that was sent to me by
a friend. She wants me to help her figure out something about a
banking acct / routing number.
It's useful for me to see my friend's name in the WHO column
because it reminds me of what the task is. And when the email
first appeared in my Chandler, that's exactly what I saw in the
WHO column. However, as soon as somebody else edits that item, I
no longer see that the email is 'fr my-friend'. Instead, I see 'ed
random-subscriber'. That's extremely useful when I first see that
someone edited the item (I want to know who!). But once I've been
there and done that, I'd prefer to see 'fr my-friend' again,
because that's the person I associate with this task.
Changing stuff based on read/unread seems too flimsy to me.
Remember that the user can sometimes "glance" at an item but not
really "read" it so, in that case, the 'ed random-subscriber' could
still be useful in the Who column even if it's "read". It's not
lost (it's still in the byline), but it certainly hasn't registered
with the user (assuming she cares about the Who column display).
Also, that column is a tri state button "read/needs reply/unread"
and the user can manually set it to "unread" if she wants to (which
would modify the "Who" column).
Yes. Read/Unread is flimsy and I'm not sure it's the right trigger
for changing the WHO column. But that aside, the deeper point is that
'ed/up' are ephemeral attributes, that especially for message items,
they aren't very useful 'memory anchors' and they're not how we
identify items. For example, I'm more likely to say, look at that
email from xxx, rather than, go look at that email that xxx just
edited. (I might for non-addressed items, but for addressed items,
the people in the addressing fields are the VIPs.)
This is what leads me to the idea that we don't always need at-a-
glance table-view access to who last edited message items.
The scenario plays out something like this:
When I check in on shared collections, I see a hand-full of 'unread'
items at the top of NOW and I see in the WHO column who made the
change. I may not even click on them to look at what the change was.
In other words, the 'ed/up by xxx' information is useful to me at a
'collection-level': Morgen and Andi were the last 2 people to edit
the Office Calendar and together they changed 5 items.
'Who last edited' a shared item isn't important to me again until I'm
examining the contents of a particular item, at which point, I can
see that information in the byline of the detail view.
To recap, 'ed/up by xxx' is ephemeral. It's not part of the user's
persistent memory of the attributes associated with any given item.
And so I think the 'time it spends in the WHO column' should be
ephemeral as well. It should be present long enough to give the user
a high-level report on who changed what in the shared collection.
Once that purpose has been served, the WHO column should return to
displaying the who-attribute that users 'most associate' with their
items.
I'm not stuck on Read/Unread status being the trigger for changing
the WHO column. But I can't think of a different trigger that would
make more sense.
Generally speaking, I think the byline is a way to mitigate the
absence of an affordance to visualize the history/versioning of an
item: in the absence of the byline, I wouldn't even know that the
item has been edited. That's good but the byline only gives me info
for the current state, nothing in the past, nothing in particular
to indicate who created the item (always an interesting tidbit).
This is related to the Who column since that column currently
echoes the byline (most of the time). Using that single one cell to
view both the last editor and the creator and rely on smart
heuristics to display the one which we think is the most
appropriate depending on where in the viewing/reading/editing
process the user is, is tricky. This is bound to have issues. e.g.:
I sort my items by "people" clicking on the "Who" column, I select
an unread item and, boom, the item gets resorted out of view
because Who changed from 'ed random-subscriber' to 'fr my-friend'.
I'd much prefer the following:
- Byline: evolve the byline widget to turn it into a full fledge
history/versioning browsing widget: continue to display the same
thing but make it a drop down, display in the drop down the list of
versions and, for each, the author/date, allow the user to select
one of those past versions to display it and, if editing, overwrite
the current one.
- Who column: allow the user to choose (contextual menu, drop down
from the column header or preference) between the "creator" or
"last editor" (i.e. author of rev 1 or author of last rev). As a
user, I need to feel there's some predictability as to what is
displayed there, especially when I sort my items according to the
content of that column (note that we already had users mentioning a
similar issue with the "Date" column where we do a similar guess
work as to what we should be displaying).
I agree with both of these points.
I do think however that there still needs to be a 'default' setting
that's smarter than just a single attribute. That smart-setting is:
Display the byline unless the item is a message. If it's a message
display TO: if it's fromMe and display FR: if it's toMe.
The lack of this single piece of intelligence is what prevents most
email clients from offering useful 'mixed' views that show both
Incoming and Outgoing messages. (For example, both Entourage and
Outlook's mixed views omit the WHO column altogether.)
I fully concede that we won't make all of the people happy, all of
the time with our 'smart defaults'. But I *am* willing to bet that we
can make people happy more of the time than if we could only display
a single attribute at a time.
That being said, I agree that we need support for being able to
'specify' which attribute you want to appear in which column,
primarily for 'search' scenarios and specialized views (e.g. For a
shared collections of PPD Team Tasks, I always want to see the TO:
field in the WHO column because that tells me who the task is
'assigned to'.)
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
