These wireframes satisfy this bug: http://f.cl.ly/items/1a1v3A1N1w1V2E3V351e/calendar-quick_add_events.pdf Design feedback/round 2 forthcoming.
The quick-add feature depends on the agenda view being adjusted. Steph, can you review 802449 with Rob or Francis to make sure what I have proposed in that bug makes sense.
hi folks - Shane brought it to my attention that the os has some issues with touch functionality that allows mistaps to be frequent - the propose quick-add functionality includes single tap events, as opposed to long tap events which we have been trying to stay away from. Is single-tap , with the possibility of mistaps - thus frustrating the user - a better payoff than a long-tap event - where a user might need to learn the trigger but is much less likely to accidentally trigger the event?
another note - we all discussed that when a user navigates to a future month in calendar view, the first of the month would inherit an "active" state and would be the default start date if a user were to tap the + buton in the top right of the screen while still in this future month. We also decided to extend this functionality to week view, where the first day of the week would inherit an active state as well. My issue with week view having days with an 'active' state, is that there is no action associated with a day in week view that would require an active state, whereas month view's active day has the action of of showing that day's list of events. An active state on a week view doesn't make a lot of sense to me right now as there is no way for a user to change what the active day is (the current propose functionality is that tapping an empty day in week view would quickly create an event). I still think that the default start date of an event triggered by the + button in the top right of the screen should still default to the first day of the week in the visible list, however, I question the need for an 'active' state design on that day.
This spec is complete and in implementation.