I guess I could weigh in now rather than later (but before done) (sorry, obscure Chandler humor) ...unchecking an all-day event and having it next turn into an anytime event is exactly what I expect, and makes sense to me. To be clear, it makes sense to me the way Chandler currently handles this scenario. After unchecking All-day, Chandler presents the start and end time fields should the user decide to fill them in and make the event a timed event. If the time fields are left unpopulated, the event remains an anytime event on the same date it was previously an All-day event. (And it will be great when sharing anytime events from Chandler to Cosmo does not result in the anytime events being converted into all-day events, which is not expected and not useful).
My two scents/sense/cents/etc., Andre On Mon, 16 Apr 2007 16:55:37 -0700, "Priscilla Chung" <[EMAIL PROTECTED]> said: > Last call on this…Mikeal/Adam, I realize we haven't heard from > you— > but I know you're probably super busy w/ testing. Just LMK if you'd > like time to respond on this. > > The proposal is to keep the behavior as it is for 0.7 and we'll > revisit it based on user's feedback post preview. > > Thanks, -Priscilla > > On Apr 10, 2007, at 12:29 PM, Priscilla Chung wrote: > > > This in regards to bug 8130 targeted to 0.7: https:// > > bugzilla.osafoundation.org/show_bug.cgi?id=8130 > > > > --- > > *Issue* > > + Create an all day event > > + user unchecks the event as all day > > + event becomes 'anytime event' > > + This behavior is consistent with Chandler > > + But this doesn't make any sense to Adam/Mikeal > > > > The expectation is that the event should go back to the main > > calendar canvas > > and force the user to complete date/time so it falls correctly on > > the main > > calendar canvas. The event should not just change into a different > > type of > > event, ie. into an 'anytime' event appearance. > > > > In Chandler Desktop, (running current veresion: > > Chandler_osx_0.7alpha5.dev-r13755-checkpoint20070402) when you > > create an event in the 'all day area', it starts off as an 'anytime > > event' (an event w/ no time info.), *not* an all day event. > > > > This behavior is at odds with iCal. When you add an event event in > > the 'all day area', it starts off as an 'all day' event' (all day > > checkbox is checked in the detail view). When you uncheck the item, > > the event drop down to the main calendar canvas and expands from > > 10AM to 6PM. (hmm…why 10AM, lazy bones?) > > > > Note: 'anytime event' is unique to Chandler. > > > > I completely understand it's a bit hard to grasp the 'anytime' > > event in the all day area. > > > > *Proposal* > > + Since this is workflow is consistent to Chandler desktop I would > > recommend to visit this later post preview. > > + Review this again to identify why it's odd when you unmark an > > 'all day' item, it become an 'anytime' event and stays in the 'all > > day' area. > > > > --- > > Here are some thoughts I have: > > + Do users really understand the difference by looking at the > > lozenge that it's an 'anytime' event? > > + Would ppl use the 'anytime' event lozenge more if it's made more > > apparent to the user that this exists? > > + An event can't be both an 'all day' and an 'anytime' event, has > > there been thought about changing the 'all day' check box to either > > a bullion: > > > > [ ] all day *OR* [ x ] anytime. (Or to save space, use a drop > > down list?) > > > > Terminology: > > + Change the name of the 'all day' area? > > +Rename 'anytime' to a more familiar term say 'stickie note', > > 'scribble pad' (ooh…I like that!) or 'note to self'—because > > essentially that is what it is. The lozenge would look different > > then other lozenges (and I don't mean a subtle difference in status— > > I mean more of a distinct looking lozenge) > > + Perhaps a header can be displayed to identify a different type of > > event item, since it is a 'note item'—crossing over to a 'calendar > > event item'. > > > > -Priscilla > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > > > 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
