UI Improvements for Evolution 2.6

(Under Progress)

--Srag 11:03, 11 Nov 2005 (EST)These are initial ideas and more will be added as it goes (Please create appropriate sections to add more)

Features

• Autocomplete contacts every where possible (Contact list creation)

• Improve the Name Selector entry

     - Better way to browse addresses in composer (Ideas to be explored)
     - Support to select / deselect emails in contacts, lists
     - Option to view either names or emails or both (?)

• Evolution for 'Wide Screen Laptops/Monitor'

     - The three column view of mail/tasks/contacts would be very nice to utilize the extra width of the screen.
       Also along with this, a provision to hide the folder tree and switcher button would be nice.

• Simplification of dialogs

     - More easier and simplified account creation
     - [[Evolution/User:Kaushal]]: This could be simplified by About-me integration with evolution. 
     The account creation dialog could have a checkbox option, to pick up data from About-me.
     - ''more to be identified''

• Identify and Fix some important UI bugs/enhancements (IDENTIFY)

Harish:

     - Menu items should be context-aware. Mutually exclusive menu times should not appear on the same menu - 
       Eg. Mark Junk/Not Junk on the toolbar and the right click menu. 
     - A Key Board shortcut to hit Search Edit box. (Just noticed that Karsten (guenther) had touched upon the same in [[https://bugzilla.gnome.org/show_bug.cgi?id=259064|bug 259064]])                          

Surf : For the "Menu items being context-aware". I dont think so this is a good idea. Since this would entail an added overhead of learning to the users. Instead, always show all the menu items, but enable or disable [ basically grey them off ], based on the context. From the discussions that i heard on this, i guess the main idea of proposing this was to avoid having a huge list of menu items in the first place. Well, to solve this, we can go with another approach. Group the menu items, and have shortcut keys for them.

--Srag 01:25, 17 Oct 2005 (EDT): To a extent, it would be nice to hide, like junk/not junk, delete/undelete but not for all i guess. That would ease to a extent.

• Provision and frame work to remember / show history of previous values for entries.

     - Autocomplete server names, search filter from history (?)
     - ''More to be identified''

• Slideshow of image attachments (?)

     - Either implement one or provide a option like 'Slideshow using GThumb' or some other application.

Evolution/User:Andre: please the latter one, providing a slideshow in evo codebase is a total waste of time, there are a lot of more important things to do than adding gadgets... :-/
Evolution/User:Shreyas: Hmm.. When you have inline view of messages, this feature is just eye candy. Proabably should just be some hackfest material

Surf : I second Andre's thoughts here. This is just an overhead.

--Srag 01:25, 17 Oct 2005 (EDT): OK. But still would love to have a cairo based slideshow, which can be a real hackfest stuff.

• UI Split. (Calendar/Tasks, Mail, Contacts)

Evolution/User:Shreyas: Probably worth elaborating ?

Each component invokable like a separate application a la KMail/KOrganizer.. This merits at least a debate. Can somebody who is in favor of this - add their case here ? Jeff ? Harish

Surf : To start off, i would like to know the reason for even having a UI split. What is the problem with the existing behaviour ? One thing that i can think of for now is ... user's might most probably want to use only one component for most of the time. This just means that the users want the components to be manually enabled/disabled. Currently, we load all the components in the shell at startup. Probably, we just need to provide an option to let the user decide which component he wants to load at runtime. Since mail is definately something which is almost always used, i would propose to load only the mail component by default. And then based on user input [ probably a menu item again ? ], load the component the user wants to move to. And yeah, we should also provide mechanism to remove the component, the user doesnt want to use. This would make the shell more configurable.

• Provide a optional summary of saved files for Save all Attachments

• Evolution/User:Kaushal: 'Save all attachments' should prompt the user to modify the filename if such a filename exists already. Basically, it should try to emulate gedit behaviour here.

--Srag 01:25, 17 Oct 2005 (EDT): It shouldnt prompt. it should save with diff file name like _1 or (1) and report it. it doesnt report as of now. Surf : I percieve this as an unwanted information to the user. By default, users expect the attachments to be saved. We should be prompting only when we recieve an error, and *not* for a success condition. And for duplicate filenames, it looks more intuitive to go the mozilla way of appending integers to the file name, as "download-1.html" or "download-2.html", etc etc

• Exit gracefully, Make the UI intutive at exit time to convey to the user that some server operation is in progress from the current greyed out hang mode.

     - Make the upsync code run in a seperate thread to the ui thread. Call the ui destroy while the upsync continues.

Surf : I guess the current behaviour is more intuitive and informative. The problem of not exiting fast lies with the components not getting killed sooner. The problem should rather be fixed in the components, and probably might boil down to the backends, but not the UI.

• More usable Filter Options

     - Option on right clicking any folder to apply saved filters / new filter.
     - Option to filter on Subject and Sender on r-click menu in the message browser with shortcut.

• Evolution/User:Kaushal: Provide search mail option at a global level, i.e. in all folders.

• There are a lot of issues related to copy and paste in composer window.mail addresses can't be copied from one field to another.Copy Paste toolbar buttons are almost ineffective. Copy something from some other application and try pasting it in any field using toolbar paste button, it will always paste into message window. These are serious usability issues.
• There must be a way to select font in the composer window. For an end-user, it is common scenario to sending different mails using different fonts.
• There must be a check-box to enable/disable copying sent items to sent folder

• There must be an option to attach vCards to messages. See bugzilla bug #200676

• Adding an "Open With..." menu item on the right-click menu of an attachment, so that even if the MIME-TYPE matching is not done, we can open with the desired application. For eg., the ODP files are not mapped to Open Office by default, if we have this option we can open any attachment with any application we want

Polish

• Tooltip every where possible to make it easy to use.
• Revisit the error messages / text labels to make it more appropriate
• Consistentcy across dialogs wrt colors, button order etc (More compliant to HIG)
• Better responses for operations, using status messages, BUSY cursor for time prone operations instead blocking the UI.
• Button Accelerators for all buttons in all dialogs

• Evolution/User:Kaushal: Put icons in all buttons, as appropriate.

• Evolution/User:Kaushal: Make all/most dialogs resizable.

• MFU operations should be accessible easier and faster (IDENTIFY).

  [[Evolution/User:Harish|Harish]]: This has often sparked up inconclusive debates in the past. I would like to see specific suggestions.

• Evolution/User:Cshilpa: Title bar of evolution should show the number of unread mail count: bug #260354

• Evolution/User:Cshilpa: Search textbox should be disabled when the search criteria is "Advanced..."

• Evolution/User:Cshilpa: There should be an 'edit as new message' option for messages in the Sent Items folder on the server.

Calendar UI changes

• Redesign the tasks/event editors.

     - Having menu and tool bars for the editor.
     - Having free busy as a user triggerred action.
       [[Evolution/User:Harish|Harish]]: This would really go a long way in improving user experience for remote calendar accounts.
        --[[Evolution/User:Srag|Srag]] 01:25, 17 Oct 2005 (EDT): Mocks are on the way ;-)
     - Show the necessary fields required for creating a meeting from a general users perspective. The others
       can be added as optional settings.
       [[Evolution/User:Harish|Harish]]: Mock-ups ?

• The right click menus needs to be activated on source-groups present in left had side of the calendar view (eg:"On this computer") and in the empty space for calendar, task list views.
• Enable the selection of multiple appointments.
• Adding a preview pane for calendar would be nice.

  [[Evolution/User:Harish|Harish]]: The ESources view wastes a lot of screenspace while a DayView misses out information starving for space (Eg. displaying Locations along with Summary).  

• Having the tool tip for appointments to display useful fields such as Summary, description, start and end dates.
• More sleek alarm notification is required. Users do not want to be banged on the head with alarm (Evo currently pops up a big window obstructing current workspace which is really ugly). A small window that pops up in a corner showing essential information is more elegant. The window top bar may flash to capture attention. This is much like the mail notification one gets when logged on to Yahoo Messenger.
• Having all holidays and other festivals already marked on the Calendar according to the country. This could be part of localization. But it will be a cool feature to add for calendar.
• All day events are shown at the top in the day view. A separate box for all day events (as in KOrganizer) will look aesthetic.

*Evolution/user:Poornima When evolution is waiting for a Free/busy response from server UI should show progress message like 'updating free/busy ...' or some message.

Misc

• Evolution/User:Andre i guess many issues to be solved can also still be found at Evolution/UIHackfest page...

• Evolution/User:Kaushal Redundancy in signature addition should be removed. Currently, signature can be added/chosen from the Account Editor, as well as, Composer Preferences. While setting a signature in Account Editor, a user normally would assume this is the only place for 'signature' handling. Thus, missing out on the full functionality which lies in Composer Preferences->Signatures.