[Usability] Inlined Evolution 2 feedback



> It is a little annoying when people post external links and dont
> include
> at least a preface or outline of their suggestions inline as it makes
> it
> much more awkward to respond to the points raised.
> 
> I am saying this not to you specifically but because quite a few
> people
> have done it recently and I can only assume that people write to this
> list
> because they do want feedback and do want to ask questions in the best
> way
> possible in order to encourage the best kinds of answers.

Being one of those people, I will keep this in mind for future feedback
and apologize for breaking the feedback loop.  I have inlined my
Evolution 2 feedback/suggestions below.

The link to the related OpenOffice presentation file is:

http://blog.wilsonet.com/mockups/Evolution2Suggestions.sxi

A General Comment Regarding Toolbar Display
The display of toolbars should be controllable in the manner of GEdit,
which provides a sub-menu of the View menu that allows the user to pick
from the Desktop default (as specified in the Menus and Toolbars
window), Icons only, Text for all icons, and Text for important icons
only. Here is the relevant section of the GNOMEHuman Interface
Guidelines (version 2). I think titling this sub-menu “Toolbar Display
Style” makes more sense than the GEdit title: “Customize Toolbar".
Customize implies (to me) the user modifying the button set or
rearranging existing buttons - changing the display style is more
descriptive of what the controls actually do.


Mail
     1. An “Ignore Thread” menu option (probably implemented as a menu
        toggle) would be nice, automatically marking existing and
        subsequent messages in a selected thread as Read.
     2. The “Automatically check new mail” interval preference has the
        same problem (in my opinion) as the Task Status incrementer - it
        is too fine grained for most users. Make it a drop-down menu of
        10 minute intervals and allow advanced/picky users to directly
        input any numerical value in the box.
     3. The Send button in message composition windows should be dimmed
        until one or more recipients are chosen or input by the user.
     4. For recipient names, I think it would make more sense to use
        contacts’ File As name rather than the full name: Mr. Daniel J.
        Wilson, Esq. vs. Daniel Wilson. File As names are generally
        easier to visually scan.
Contacts
     1. Evolution really needs a “Me” card - a contact card the user
        creates to be the definitive source for their personal contact
        and collaboration information. The creation of this card could
        be a walkthrough shown the first time the application is run. I
        think I saw somewhere that work on this was underway, but just
        thought I would highlight this as a big deal.
     2. Drag-and-drop of VCF files into the Contact List area would be a
        welcomed and logical feature (the GNOME HIG does advocate
        pervasive direct manipulation, after all). To add a contact to a
        specific list, VCF files could be dropped on contact list names
        in the lefthand list. Dropping to LDAP servers would have to be
        handled based on LDAP authentication.
     3. Support for the importing of group vCards seems problematic. I
        attempted to import a group vCard (version 3.0) exported from
        Apple’s Address Book application which imported fine in Kontact
        1.0; Evolution produced a single contact with miscellaneous
        information from different contacts. Individual cards are
        imported without issues.
     4. The Contact Editor 
             1. Immediately after selecting a month and day for a
                contact’s birthday or anniversary, it might make sense
                to automatically select just the year portion of the
                date as it is likely that the current year is not the
                correct one.
             2. Keyboard navigation of the available text fields is
                somewhat unpredictable in the Mailing Address tab;
                Return and tab work like they do in a text editing
                application when the Address box has focus, but they
                change field focus and activate the default button when
                other fields have input focus. The most logical solution
                would be to force the Address box to use the same key
                behaviors. The HIGrecommendation is for the Return key
                to move among fields in this kind of data input
                scenario, but I think using the Tab key makes more sense
                - it is commonly used in other desktop environments and
                in web forms for field navigation. Return should
                activate the default button.
             3. Related to the above: pressing the Tab key while the
                City field has focus takes you to the Address box, which
                traps you by capturing subsequent tabs. Keyboard
                navigation quicksand!
             4. Having the Manager, Assistant, and Spouse text fields
                autocomplete based on existing contacts would be great.
                Not a huge problem as this is likely only a one-time
                input, but still of use.
             5. Zip is an abbreviation for Zoning Improvement Plan, so
                it should be capitalized as ZIP.
     5. The Contact Preview Pane 
             1. In the preview pane, it would be nice if instant
                messaging names were links that would allow users to
                open new IM conversations in the protocol’s default
                handler application. I know AOL Instant Messenger uses
                the “aim:” protocol, but I don’t know about other IM
                systems. Online and availability status indicators would
                also be cool.
             2. IM protocol names (AIM, Yahoo) could also function as
                links to the web pages of clients for the appropriate
                service.
             3. Actions for addresses: get map, get driving directions
                (the user’s address would be drawn from their card),
                print mailing label. Alternatively, addresses could be
                formatted as links to open maps at Yahoo! Maps or
                MapQuest.
             4. The type of e-mail address should be indicated:
                “joe smith com (Work)".
             5. The contact editor uses the wording “File under", but
                the contact list view column uses “File As". A very
                minor difference, but a difference nonetheless. Yes, I’m
                that anal retentive.
Calendars
     1. It would be great if the view switching toolbar buttons more
        clearly indicated the active mode. This could be done by
        coloring the active icon and/or adding a frame around it. See
        Slide #2.
     2. The red text coloring of the current day in the month view is
        deficient in several ways. First, red is one color that some
        people with colorblindness cannot see well. Second, it just
        doesn’t stand out, even with normal spectrum vision. I suggest
        adding a differently colored one or two pixel thicker frame
        around the current day and perhaps bolding the day number (which
        might be better displayed in INSERT COLOR HERE). See Slide #3.
     3. For birthday reminders, it might be nice to automatically insert
        a note stating the age of the person.
Tasks
     1. The Task Editor 
             1. Why a 1% incrementer for task completion status? Why not
                intervals of 10% in a drop-down menu? Allow the user to
                directly input single percentage increments using the
                numerical input box.
             2. A disclosable section (like that used for the latest GTK
                + file picker’s “Browse for other folders” widget) that
                could reveal the user’s bookmarks in a two-pane
                interface similar to Epiphany's bookmark manager.
             3. Drag-and-drop of bookmarks from browsers (bookmarks or
                address field) to the Web Page field should be possible.
             4. The “Group” label within the new task creation window
                should use the assigned task group color. See Slide #4.
             5. Putting the Start date above the Due date seems more
                logical to me, but that might just be my way of
                thinking.
             6. For task group coloring, wrap the task group’s label in
                the chosen color, which would have the effect of forming
                a more easily identifiable relationship between color
                and grouping.
     2. The contextual menu that appears when right-clicking on an
        existing task list should include a “New Task” command that
        creates a new task with the group set to that which was clicked
        on.
     3. When creating a new task by selecting the New Task command from
        the contextual menu displayed when clicking on a specific day,
        automatically set the start date to that day, with the time set
        as the default beginning of the work day as specified in the
        preferences.
     4. Provide at least one or two other columns by default in the Task
        view, particularly since the width of the creation window’s
        Summary field is unlikely to lead the user to write a summary of
        such length that it requires the entire width of the main
        window’s task list view to be fully displayed. Priority and Due
        Date would be my suggestions.




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