Hi Robin,
Thanks for the engagement about all this!
> It seems that it is all the list views that gives priority to the alarm
> time. That means that there is no list view in the whole application that I
> can go to see my the actual start time of events. It certainly makes sense
> to have an alarm view and I am sure it would be useful to show both the
> alarm time and the actual time - but I still feel the need to have a list
> view that shows the actual time of the event.
I can definitely see how a time-only view might be helpful. Can you
describe some scenarios in which you might use this?
One feature that isn't enormously easy to discover may be useful to you
in the interim: If you're in the list view, you can click on particular
days in the mini-calendar and the preview area will show you a list of
that day's events (with start times, no fussing with alarms).
Both the mini-calendar and preview area show events that are in "mine"
collections. A bit of historical background: we wanted to have a
variety of different user-configurable contexts ("spheres"), not just
mine and not-mine, but for Preview we decided not to invest resources in
that. We know mine/not-mine probably isn't enough, it's just giving a
taste of how different spheres might be used.
> The Cosmo Hub gets it right. It shows AM and PM and also uses color to
> highlight work hours. The systems should be consistent.
The assertion that UI on the web and the desktop should be consistent is
actually somewhat controversial. Organizationally we've decided not to
make the two move in lockstep. The upside of this is that we have more
room to experiment with this sort of UI detail.
Personally, I find the repeated AM/PM to be visual clutter, but I'll
confess I also occasionally get confused about whether I'm looking at AM
or PM, so I agree that the desktop certainly doesn't have it right yet.
I wonder if there's some out-of-the box way to avoid confusion without
repeating AM/PM?
> Might not some users prefer a 24 hour clock rendition of the time?
Yup, the display of hours is currently locale sensitive, so European
users will see 24 hours (unless there's a bug with this, I haven't
checked recently!).
> I am on Windows XP SP2. I uninstalled the checkpoint version before
> installing the RC1. Also note that my screen resolution is set to 1280x1024
> 120DPI. The DPI setting can mess up dialogs so it might be interfering with
> your tooltip code if everyone else is seeing tooltips. Note that I get
> tooltips on the toolbar icons. I am expecting to see tooltips on at the
> icons I float over on the list view - like the task/tick icon and the
> clock/alarm icon and the column headings.
I'm on XP SP2, also, and I see tooltips for those list-view icons. But
I don't have my fonts set to 120DPI, perhaps that's the source of the
problem? In any case, that's a bug we should fix.
> When I try and test this feature now it only cycles between the original
> date and 'Today' -but it does cycle - there is no 'Tomorrow'. Also might it
> not make sense to change the Triage status to Later if I create an alarm on
> Done items?
The heuristic for the alarm created is 5PM today if it's before 5PM, or
9AM tomorrow. We chose those times arbitrarily, eventually it'd be nice
if users could customize how far in advance the default custom alarm
should be. You can always change the alarm manually, but of course
defaults are important.
Interesting point about moving DONE items to LATER if an alarm is added.
I can imagine situations where I don't want the triage status to
change, but the truth is in my personal use I've never added an alarm to
a DONE item, so I have a hard time gauging what the right behavior is
for our target user ("a hub").
> I also see that it is not possible to change the alarm status of a recurring
> item that is in the done section but I can add an alarm to a recurring item
> that does not have an alarm. The only problem is that the icon does not
> change from a clock to the alarm icon.
Hmm, this is complicated.
If a before/after event alarm on a recurring event has already fired, we
don't display an icon for that event's alarm in the table view. So if
the whole recurrence series has an alarm for 15 minutes in advance, you
won't see the alarm icon on an old event.
On top of this, we don't let you manipulate N minutes before/after
alarms from the list view, so because the old occurrence has an
already-fired alarm, it'll seem like you can't add a custom alarm in
this case.
If the whole series doesn't have an alarm, you should be able to create
a custom alarm on a single occurrence from the list view icon, or from
the detail view.
This is pretty confusing, so I'm not saying any of the above is the best
behavior, just explaining the functionality that currently exists.
> I can see that it makes sense not to have the item jump right away but I
> might expect to move if I resort. I tried changing a Done status item to a
> Now Item and the status changes and does not move (ok) but I then hit the
> triage column heading to resort and the Now item is still in the Done
> section. When will it move to now? Oh I see that it moves when I hit the
> Triage Toolbar button. So the Toolbar button and the Sort column headings
> have different semantics. Is that by Design? (there is no tooltip on the
> column heading)
Several people have expected the sort-by-triage column header to have
similar semantics to the triage button, it's definitely interesting to
get more feedback that this is what's expected.
The tricky thing is that when you use Chandler to share with other
people, there's information encoded in items that are sorted in the NOW
section but whose color is, say, LATER (it alerts you to the fact that
someone else has edited the shared item). Clicking the triage button
takes such items out of NOW and puts them back in their normal section.
If you'd sorted by date instead of triage, and if changing back to
sorting by triage reset this, you wouldn't have that visual cue that
someone else had edited the LATER item, which I think is pretty useful
for quickly and easily managing the focus of your attention.
I don't have a good idea of how to resolve the tension between these two
at-first-glance-identical affordances. Certainly more documentation and
tutorials (which we're working on) would help. Perhaps also we could
display more information in the tooltip over displayed-out-of-section items?
Thanks again for the good feedback, hope my detailed answers aren't too
overwhelming!
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
