Re: [Evolution-hackers] component information area.

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?


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.
> 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:  . 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). 
> 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]