Does anyone want to look into a widget to do this? Otherwise i'll open a bug and write it, and put it in the mailer for all to see.
I'd like to have a widget to do it so it is consistent across all apps (and probably save code). I wouldn't mind it being able to reconfigure its content depending on what fits in the allocated space, and not just simple truncation of the text (i.e. alternatate texts). I was thinking of using pango markup to do all the formatting for the label (which rules out e-clipped-label :-/). Is there a list of items we want to show for each component, or should it just copy 1.4? Michael On Wed, 2004-03-31 at 13:43 -0500, Anna M Dirks wrote: > Regards all. > > As you know, in Evolution 1.4, we presented the user with information > about her currently selected folder in a grey bar, which stretched > beneath the app's main toolbar. This grey bar was called the > "component information area"; refer to the following screenshot to see > it in action. http://primates.ximian.com/~anna/greybar.png > > In 2.0, we are lacking the functionality provided by this bar. In > order to include this functionality, my team (Product Design), > proposes the following. > Overview > The component information area should be used: > * To indicate the actively selected component. > * To show additional information related to the actively > selected folder or component node. > What the Component Info Areas is NOT for > The information area isn't going to replace the status bar. The status > bar is a place to inform the user of currently running tasks such as > indexing folders, grabbing mail, expunging mail etc. > > It is also not an alternative to the executive summary, which in 1.4 > brought together the important information from all components into a > sort of a day-view. > Sample Tasks for the Component Information Area > Albert is an unemployed plastic surgeon, with computer geekish > tendencies. > > * Albert wants to tell his friend how much e-mail sucks these > days. He needs to know how many spam messages he has received > today. > > * Albert wants to see how many tasks he has to do, including how > many of these are overdue. > > * Albert wants to see how many contacts he has in his > addressbook to see if the synchronization to his palm worked. > He's interested in contact lists as well. > > * Albert loses track of the flow of time. Being a computer nerd > makes it tough to figure out what day of week it is. He wants > to see right away what day it is when using the calendar and > what events are ahead of him. > Analysis -- How These Tasks are Accomplished in Evo 1.5 > 1. Albert is able to see a total number of messages in a folder, > a default spam vfolder in particular, by clicking the > properties item in the folder context menu or by selecting > File>Folder>Properties menu item. The dialog also lists number > of unread messages. It may be a bit difficult to find this > context sensitive dialog. To see spam received today, he needs > to create a custom vfolder to match messages marked as spam > and received within 24 hours. Another solution is to make sure > to make all spam messages marked as read at the end of the > day. That way Albert can see new spam messages the next day. > > 2. It's possible to have an overview of how many tasks are > pending in the tasks view of the shell. Overdue tasks are > colored red and tasks due today are blue. > > 3. Unless Albert wants to count them manually, there's no way to > see the number of contacts or contact lists in his > addressbook. > > 4. Albert can use the go to today button on the toolbar when in > calendar component. > > Heuristic Analysis > (for a complete list of the Product Design team's heuristics, please > see: http://primates.ximian.com/~anna/heuristics.html . Basically, > heuristics are principles -- they define the tenants that my team > believes in. Every design we produce is measured using these > heuristics, to be sure that it is appropriate.) > > Consistency: There isn't a common information area in Evolution 1.5 > currently. Each component has a different way of presenting the data > needed for tasks outlined above. > > Minimal design: N/A > > Limit memory requirements: Because the properties dialog is hidden > most of the time, it's required for the user to revisit it or remember > the information. > > Constructive error handling: N/A > > Task based design: Most of the tasks couldn't be accomplished with > Evolution 1.5. The 1.4 status bar works well except it requires to > change the components if the user wishes to accomplish all the tasks. > > Appropriate language: N/A > > Help and Docs: We could not locate any data about the folder > properties dialog. > > Proposal > > Keeping the above tasks and analysis in mind, we propose using the > following design to provide information about the currently selected > component (and folder). > > http://primates.ximian.com/~anna/component_info.png > > I know that this screenshot is very blurry -- I copied it from an open > office document. Obviously, if this design is implemented, we will use > razor crisp text, etc. > > This design, we believe, facilitates the tasks discussed above, while > respecting our heuristics. > What do you think ? > > Anna > > > _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
