PPD and Apps are planning to meet on Friday to discuss Sidebar issues related to Overlays in the Dashboard View. We are reviving a thread that we discussed on the list in June: http://lists.osafoundation.org/pipermail/design/2006-June/004818.html in the hopes of finalizing the Beta Sidebar Design. The design we've implemented for Alpha 4, turns off Overlays in the non-Calendar app areas. We're proposing that we stick with this design for Beta until we have better visibility into 1.0 planning. Philippe and John have expressed some concern that if we do not support Overlays in the non-Calendar App areas, the sidebar and corresponding summary pane behavior as the user moves from App area to App area will be confusing. Overlays will turn themselves on and off when you move in and out of the Calendar App area. As a user, you may not figure out this association. All you know is without rhyme or reason, sometimes overlays work and other times they don't. One way we could address this issue is to provide the same visual feedback that we provide when users select an OOTB collection and we 'turn off' overlays in the Calendar App...we de-activate the collection overlay icons on the left-hand side. This way, you at least get some visual feedback that overlay functionality has been turned-off or is not supported when you enter and exit the Calendar App. You at least have a chance of associating overlay support with the Calendar App area. John and Philippe, do you have any thoughts on this? Does this sound like a feasible and reasonable compromise for Beta? === Below is the Agenda for our meeting tomorrow. GOAL + Do we do overlays in the Dashboard in the Beta timeframe? (We're assuming that having a way to overlay collections in the Dashboard is a useful thing.) OPEN ISSUES What would it take to get Overlays in the Dashboard to work? + Add a column to display swatches + Visually differentiate between the swatch representing the selection collection (more saturated and bigger) and swatches representing overlayed collections (less saturated and smaller) + Greying out the text of overlaid collections + Automatically switching selection in the sidebar to match the item being selected in the Dashboard DEPENDENCIES If we are able to implement overlays in the Dashboard, then we need to consider the following: + The Dashboard should be reinstated as the true ALL collection, containing all content items in the repository, regardless of whether they are Mine or Not-Mine + Instead Mine and Not-Mine-ness become a way for users to specify whether events should affect their free-busy report. + Users will use Overlays rather than the Mine-ness to specify which collections they want to focus on. Note: In the future, when we have a more sophisticated notion of Spheres and Perspectives (My Stuff versus my Spouse's stuff versus My Working Group's stuff), we may re-elevate the notion of Mine-ness to be a 1st class user concept. + If we reinstate the Dashboard as the ALL collection, this will also change the workflows for the Unified Data In and Out stuff, because we will assume that everything you subscribe to (shares, RSS feeds, IMAP folders, email accounts) will get streamed into your Dashboard: http://wiki.osafoundation.org/bin/view/Journal/UnifiedDataInAndOutProposal + Option we should wait on until we get more user feedback: Persist overlays on a Per App Area basis. For more explanation of user motivations and screenshots, see: http://lists.osafoundation.org/pipermail/design/2006-June/004818.html + Jeffrey and I had a misunderstanding about the Dashboard collection and he has implemented a bunch of stuff (mostly free-busy) assuming the new paradigm (Dashboard = ALL items, Mine and Not-mine). As a result, if we don't implement Overlays in the Dashboard and we don't move to this new paradigm where Dashboard = ALL items, then he estimates that he has about a day's worth of work to make things right. |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
