Right now the calendar screen shows the events in a standard list. The viewer navigates through the days of the calendar with the left and right arrows. The idea of scrolling through the days and not seeing events organized on a hour-by-hour basis throws me. I think that our next revision should either (1)leverage the DayPlanner metaphor a little more heavily, and space the events out on a scale, starting at 7am and ending at midnight or (2)go with the standard list but revise the navigation to a less formal 'earlier, later' scheme.
3 comments:
We were trying something different with this page due to restrictions on screen size. Calendars that use the "day planner" metaphor are really heavy on meta-data (times, lines, delineations, overlap) and we don't really have space to do that. Instead, we decided to queue up your upcoming appointments so that you can see your day at a glance. If you want all the details of a calendar, a different view from a different app will probably do the job better. We just wanted to keep it simple.
That said, this hasn't come up as an issue in a single one of our usability tests. In my opinion, I think this falls under the "if it ain't broke, don't fix it" category. We have bigger fish to fry for this iteration and the next.
Feel free to draw out other designs and post them. I'm certainly not opposed to putting in a better solution - I just don't want to spend the time on it. A good solution will limit the text and detail on the screen but won't hide necessary info behind more clicks.
So, I kind of like the earlier/later scheme more than the current day switching thing. It might save people from having to jump around just to see what events are happening 2 days from now. I would suggest that we insert a little header in the list view in between each day.
Ideally we would offer the user some clever way to jump between days while still offering the same earlier/later UI. Perhaps we can do something with the softkey buttons.
As per Fred today, there is a big chance that the Calendar stuff won't make it into this prototype simply because there is a lot of code to write and not a whole lot of time. We can spend some time on this design for the next one, since we're hopefully just talking small changes.
Post a Comment