High level Scooby UI Proposal

Status Threw together some mock-ups to try and visualize and capture some high level approaches to the Scooby UI. Not meant to be a complete, fully spec'd out proposal.

1. Porting desktop app UIs directly over to the web often feels clunky and unnatural (ie. Outlook's web access UI). This is primarily due to desktop app's free use of independently scrolling panes. However frames in web UIs oftentimes feel wrong. Desktop apps also have specialized navigation (sidebar) and tool (toolbar) areas whereas web UIs are more likely to have in-place navigation and tools.
2. Should we use Scooby as an opportunity to explore different UI ideas that feels more native to the web? Who knows, it might be a good way to validate more daring design ideas before applying them to the desktop app.

What's driving the wireframe proposals below is the attempt to make a UI that feels more native to the web:

1. In-place tools and navigation: Click on the calendar itself to move around rather than manipulating the calendar from an external set of buttons (ie. Day, Week, View buttons in iCal)
2. No independently scrolling panes
3. You never feel like you're switching between view types (ie. month view, week view, day view). Instead, it feels more like you're zooming in and out: 4 weeks at a time, 3 weeks at a time, 2 weeks at a time, 1 week at a time, a single day at a time and it's easy to jump between these different states. I think this will help people "not lose context" when they zoom into look at a particular week or day in their calendar.

The wireframes are by no means complete designs, a lot of things are missing (ie. a list of collections, ways to navigate outside of calendar, etc).

I'm also including a wireframe for the "week view" (at the bottom) basically what you see when you've collapsed all of the week-rows and you only have a single week left. (This will make more sense once you've read the stuff below.)

Matt, I also have some questions for you at the bottom.

A few words on process... I generally throw out a more or less "down the road" design, which I understand is not something we can whip out in Round 1. However, i find the "goal-oriented" design to be a helpful way to kick off an iterative process where we work backwards to figure out what the 1st realistic round of implementation might be.

The mock-up in more detail

The screen below shows some of the features we discussed namely:

1. Selectively "turning on or off" certain rows of weeks in the month view to "zoom into 3,2 or a single week".
2. Selecting a single day to zoom into just that day
3. Opening up potential multiple detail bubbles for an event, in-place a la Google maps.

• scooby_month.png:
  

• scooby_week.png:
  

Comments

MimiYin 2005 Aug 18

Matt,

re: Editing the date/time attributes, what makes "in-place" editing of the date/time attributes hard is that because there are 4 + 2 permutations of different types of events in Chandler:

1. Duration events
2. @ time events
3. all-day and all-day multi-day
4. anytime that day and anytime-multiday...

The number of attributes increases or decreases depending on what kind of event it is. So one simplifying assumption might be that when you're editing in-place in the pop-up lozenge...you CAN'T change the event type, you're stuck with the date/time attributes that were there in the first place. You can only change the event type by bringing up the full detail view below the calendar.

re: Animation between having 2,3 or 4 weeks open in the calendar AND only having a single week open in the calendar (aka when moving from the month view to the week view)

Would it be hard to

1. Widen the time blocks into overlapping event lozenges a la Chandler and Apple iCal while
2. Fading-in the event titles inside the time blocks and simultaneously
3. Fade out the free-form overlayed event titles from the month view?

I'm thinking this might feel more natural than simply cross-fading the "month-view" display style with the "week-view" display style.