[Design] Thinking out of the box idea: Fish-eye Dashboard with Tiles

selva r selva11r at yahoo.ca
Thu Jan 12 10:33:57 PST 2006


Additional comment on this part of my previous email:
  
  "This is why I had previously suggested that when any items are “stamped” as other Chandler subapplication items, whether by drag and drop on a multi-framed Dashboard, or by a separate stamping menu system, a dialogue box should always appear querying the user whether they would like the original event deleted."
  
  Furthermore, the dialogue box that appears during stamping actions should include a second query.  The additional querry should ask the user to indicate whether the newly created event should be unlinked to the original event.  
  
  I mentioned 'unlinked' rather than 'linked' since most stamped events are likely to be linked by the user so they wouldn't have to perform an additional mouse click just to link the two items.
  
  If the user chooses to delete the original message in the first querry, then obviously the second querry should be greyed out and unavailable for selection.
  
  Selva

selva r <selva11r at yahoo.ca> wrote: Hi Mimi,
 
 I think there was a previous poster, Phillip J. Eby (?) who last year brought up the topic of “Conceptual model for stamping” where he questioned Chandler’s current vision on the whole stamping issue.  I did not participate in this thread but mostly tended to agree with his opinions.  
 
 In most day to day occurrences, most  “stamping” needs are not really true stamping actions at all.  For example, an email request for a meeting proposal does not get converted into a Calendar event with the original email message then lost.  
 
 Rather, the email message, or more often, only a certain part of the entire email message in this example, gets copied and then pasted into a new Calendar event and the original email event remains intact so that further correspondences can be made to the sender on the subject if needed. 
 
 Hence, the more practical workflow might be as follows.  The user would highlight the part of the email message that needs to be pasted into a new Calendar event.  They could then right click and be presented with the option to paste contents into a new event in another Chandler subapplication.  
 
 For those novice users who do not know that they can right click here, a tabbed toolbar system as I had described recently on another thread could present a visual cue by having it’s tab light up when the user highlights some text on the email message.  The user could then click on the right click toolbar tab and then be presented with the same right click menu options there.  
 
 If there was a framed layout for Dashboard, then the user could also be advised on the right click menu bar that they could, as a shortcut, simply drag and drop the highlighted text onto the Memo frame or the Tasks frame to create a new Memo or Task event respectively with the highlighted text automatically pasted onto it.  To paste the highlighted text into a new Calendar event, they may have to simply click the New Calendar Event option on the right click menu.  Additionally, if the framed Dashboard had an optional slide out / slide in Calendar Day view on the side of the Dashboard window then, the user might also be allowed to drag the highlighted text onto the Calendar Day view if it is pulled out.  I mention that the Calendar Day view should be a slide in / slide out system so that users with smaller computer screens could pull this out only when needed.
 
 In daily usage, the main scenario where an event truly becomes “stamped” as another event with the original event being deleted is when users capture roughly thought out ideas as memos and then come back later to organize them into more coherent memos or emails.  
 
 Most of the other “stamping” activities encountered in daily usage, as Phillip Eby described, is actually a form of user friendly copy and paste into a new event process while the initial event remains intact.
 
 This is why I had previously suggested that when any items are “stamped” as other Chandler subapplication items, whether by drag and drop on a multi-framed Dashboard, or by a separate stamping menu system, a dialogue box should always appear querying the user whether they would like the original event deleted.
 
 In sum, I do not feel my view (or Phillip Eby’s) view of stamping is tangental but rather more accurately reflective of workflows encountered in practical situations.
 
 Regarding my previous comment on possibly allowing the Fish Eye Tile model as an optional viewing mode for Dashboard, I am withdrawing this recommendation as it is probably inefficient even for this purpose due to it’s inability to clearly present large volumes of data such as may be encountered in any email handling interface.
 
 Regards,
 Selva

Mimi Yin <mimi at osafoundation.org> wrote: Dear Selva,


Let me start out by saying that we have appreciated some of your posts in the past that have provided interesting information and links to other projects that Chandler should be aware of.


However, your last two posts on the Dashboard have been off-topic and reveal a fundamental misunderstanding of the design principles guiding Triage and Chandler's PIM workflow designs in general.


The two activities you have listed below are actions that users perform in PIMs, but they say nothing about why users 1) bother to record data into PIMs in the first place and 2) why they come back to retrieve data later on.


At OSAF, we are trying very hard to develop an open  design process within a framework of user goals, use cases and workflows, not features and widget descriptions.


We are aware that not everyone is comfortable or familiar with this design methodology. If you feel you have questions about it, feel free to post them to the list and we will try our best to answer them. However, unless you are interested in participating in the spirit of the design process we have set up, please refrain in the future from posting off-topic and tangential descriptions of functionality we have repeatedly said we do not have plans to implement.


Thanks, 


Mimi

On Jan 11, 2006, at 1:53 AM, selva r wrote:

After further consideration, I'm going to make some further comments on  this topic.  When a user opens up a PIM app, whether it's on a Treo or on the desktop, they have only one of two purposes:
 
 1) To look up previously inputed PIM data as a day to day reference source.
 2) To edit existing PIM data as new information becomes available in the course of day to day life.
 
 While the Fish eye model described previously has some major problems with being able to replicate some important day to day activites such as drag and drop stamping of roughly captured memo's, it does provide a unique viewing perspective for providing an overview of the various items and collections within the PIM sorted according to triage status.  
 
 Hence, when the user is in reference mode (as opposed to edit mode), they may be offered an option to view Dashboard in the Fish Eye view using a toggle switch mechanism.  If they later decide to make edits, then they could toggle back to the multiframed Dashboard view where they could locate all the unsorted memo's at the top of the Memo frame and then proceed with drag and drop stamping activities to further process these PIM data.
 
 --Selva

selva r <selva11r at yahoo.ca> wrote: So how would this system allow for easy locatability of roughly drafted memo's that are destined for final stamping processes at a later date to convert them into emails, inserting into documents, and the like?  
 
 By providing a separate frame for memos, Tasks, Email, Datebook,  (and in longer term future, for Writer docs), stamping functions could be ridiculously simple.  All the roughly captured notes would be lined up in the memo frame automatically, and the user just has to go there and drag and drop the items into the final destined frame for stamping processes.  Fish eye system outlined previously on this thread would make such crucially important activities in a PIM unneccessarily complicated and as such, would probably end up being used very little or not at all for some users. Users would have to go looking back and forth through all the collections for their roughly captured memo's scattered everywhere and then go through some unncessary complex button system to stamp the memo's into emails, etc.  This then also entails the addition of a stamping menu bar to futher complicate the user interface.
 
 Fish eye should be thrown on the scrap heap pronto IMO.  No point in wasting time with this nonsense.  JMHO.  Sorry to be blunt but it would a waste of developer time and resources as it does not parallel real life PIM activities.  If one really insisted on proceeding with this, then it should be just offered as one optional configuration setting that the user could select.  User preferences patterns later be surveyed and, depending on user pattern data, we might decide whether it would be worthwhile continueing development on this.  My guess is that it would probably be used very little compared to a multi-framed Dashboard design option.
 
 The main weakness of the framed model for Dashboard as I had described previously is the lack of display of collections on the first level window.  However, if the user's monitor is large enough, then they may be allowed to include a frame for displaying collections of a  selected item within Dashboard level 1 as well.  
 
 For those with smaller monitor screens, it would still be pretty easy to access the collections side bar view by simply double clicking an item from any of the frames into a second level Dashboard window with the more typical layout where collections are presented on the left sidebar.  The fact that an item within a frame on Dashboard's level 1 view may be part of a collection may be indicated by a "collections icon" embeded within the item's title bar. (ex. a small green Cactus symbol).  
 
 The other main weakness of the framed model fo Dashboard as I had described previously is that each member of a collection would have it's own entry within Dashboard which may make it look like there are more items on Dashboard overall than there should be if thinking in terms of projects.  One way around this issue is to include only the lead items of collections within Dashboard.  For example, a lead item mignt be "Meeting with boss on project progress update".  Other items within the group.  Hence, users wil need to designate a lead item fo all collections and since collections are organized bits of data, this should not be too dificult to do.  To access the other members of the collection, the user simply needs to douple click the item within the frame and this could then explode another window on top which shows the collection the item belongs to, including the individual triage status colors of each item's title bar within the collection.
 
 The fish eye view, in my opinion, looks fancy but will significantly limit usability of Chandler in day to day office life.  It just doesn't represent the way most people work IMO.
 
 Sorry to be so blunt but when a fish stinks, it's pretty hard to  ignore the smell.
 
 I do appreciate the author's innovatively new design as it does have aesthetic appeal and I would encourage more model proposals like this as it gets us all to think in new paradigms. However, unfortunately, as it stands now, it fails miserably in providing a basic foundation for further replicating the most useful office PIM routines.
 
 Regards,
 Selva

Mimi Yin <mimi at osafoundation.org> wrote: Hi Mike,

Welcome to the list. I wonder if you could elaborate a little on your  
question about "What is the important part of anything."

In the Dashboard design, it would be the same set of attributes than  
any table displayed, with the additional option of enlarging the item  
tile so that you could see content from the body as well.

For the scalable fabric design from MSR, I think there  are some  
heuristics they follow that were quite successful. (ie. If you have  
and Inbox window open, showing the sync status and # of new  
messages). You could also imagine a UI where the user could draw a  
boundary box around the area they wanted to clip.

You're right to say that what you want to focus on is going to change  
depending on context, but I think that can be derived from which  
items you decide to have "open". If you think about it, the windows  
you have open on your desktop at any given point in time are the   
things that are currently in your FOCUS. That set of things is  
constantly changing, the idea however, is that a UI that allows you  
to have more gradations of open-ness between:

"Open and in my face and therefore obscuring other windows" and
"Docked so that I can't really see anything"

would be useful for allowing people to control "degrees of focus" and  
also to feel less like they're  constantly switching context,  
replacing one view with another...Instead the metaphor is more like  
zooming in and out and around on a map.

Mimi

On Jan 5, 2006, at 1:20 PM, Mike Pence wrote:

> Hi. My name is Mike and I am a programmer. Scott Rosenberg turned me
> on to this project.
>
> Two things I have observed:
>
> 1 - The DesktopManager for OS X 'feels' right as a context switcher --
> especially when I tell it to use the cube transiton. Then, when I
> switch to another deskotp, it feels  like I am just turning to look at
> another side of something, and that maps well to my general
> humanishness.
>
> 2. Creating another visual representation of something for a fisheye
> view is confusing. What is the 'important part' of anything? It really
> depends on what I am doing and what I am thinking about. How will you
> know -- or how can I even tell you -- what the  important part of a
> window is going to be at any instant in time?
>
> 3. Try Google Earth. (Windows only for now...sorry.) It is *fun* to
> navigate because you have a sense of place. If I could open a bunch of
> windows on a giant virtual desktop and zoom in and out with my mouse
> wheel, that would be the ultimate context-switcher for me, because,
> again, it just like the Real World. Isn't that essentially what Google
> Earth does with the map? When I want to find something in real life, I
> take a step back.  So, give me a way to take a step back, to zoom out,
> and throw in something that at least *feels* 3 dimensional.
>
> Hope that wasn't too obvious is pedantic.
>
> Best,
> Mike Pence
>
> On 1/5/06, Heikki Toivonen  wrote:
>> Mimi Yin wrote:
>>> *A Fish-Eye View of the Dashboard: Focused on the NOW  section.*
>>
>> The design says (for example) "less and less important as you move to
>> the right and down", but we almost certainly need to make it
>> configurable depending on the locale/localization. Languages that  
>> read
>> from right to left usually want to switch other UI components from  
>> left
>> to right as well.
>>
>> --
>>   Heikki Toivonen
>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications  Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design


   

---------------------------------
Find your next car at Yahoo! Canada Autos_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design


   


---------------------------------
Find your next car at Yahoo! Canada Autos


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design


   

---------------------------------
Find your next car at Yahoo! Canada Autos_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design



		
---------------------------------
Find your next car at Yahoo! Canada Autos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060112/324f0702/attachment.html


More information about the Design mailing list