See inline comments.
>> 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.
>
I guess I am using list views to get a quick view of future events. This
afternoon I put in my son's Soccer schedule and I wanted to review my
entries against the xls that the coach emailed me. Because I used alarms it
was not easy to cross check the list.
This raised another issue. The soccer schedule consists of practices - which
I was able to enter as recurring events and the actual games which have
differing times and locations. The resulting list view filters out all the
recurring events after the next one.
>> 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?
>
How about some shading or gradient in the time panel?
>> 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!).
>
There you go then I am an Englishman living the US;) Tying this to locale
does not make sense to me. There must be all sorts of users who have a
preference that does not match the locale.
>> 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.
>
I will install Chandler on another XP system and look for differences.
>> 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").
>
The fact that I was setting an Alarm on a Done item was rather perverse but
I can imagine wanting to undo a Done item that was marked Done in error
perhaps.
>> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
