15044 - Present this Address book user interface suggestion to UI team

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, enhancement, P3)

Description

[Michael Lowe]

Having a separate pane for the directory list in my opinion is a waste of space,
especially on small screens, since it usually only contains a few entries and it
is currently allocated a full column.   It also adds unnecessarily to the visual
complexity of the user interface, since the user will most likely only
infrequently switch between address books.  The users primary visual focus will
be on the list of cards and on the details of the currently selected card, so
having a full column pane for the directory list only pulls the users focus away
from where it should be.  These problems were not so much an issue in 4.x (where
there were only two panes), but after adding the additional pane for the address
book card in Mozilla, the space available for viewing the list of address book
cards becomes too small on lower screen resolutions.

Please find attached my suggestion for how I would like the address book user
interface to be implemented.   There are only a few, but I think significant,
changes I have made to the visual layout:

1. Changed the directory list from a full column list pane to a popup combo box
menu.   This gives much more room for the card list pane, providing space to
show more of the available columns in this list.   It also simplifies the window
making it easier for the user to focus on the most relevant parts and parse the
visual layout.

2. Reordered some of the toolbar buttons to group them together by semantics,
and added some toolbar separators.

3. Moved the "Show names containing" field from the top toolbar down to the next
row to give it more room.

Note that the first point also applies to the Mail Compose "Select Address"
dialog, and hence the same change should be made to both.

I hope you agree that my suggestion is an improvement over the current design,
and that it can be implemented in Mozilla.

Comment 1

[Michael Lowe]

Attachment: Screenshot

Comment 2

[hangas]

Michael: Thanks for the input, I have added German to the list to consider the
toolbar button order.  There are a number of items that may land in the left pane
of the address book.  At a minimum there are LDAP directories, once these are
added we also need a way to drag address book cards from one address book to
another, this left pane allows for this.  Users that need that extra space will
be able to click once on the gripper to collapse the left pane, which will allow
then to work without it taking up extra space.

Comment 3

[Michael Lowe]

Ok, how about a merging both approaches.   Maintain the three pane layout, but
add the toolbar from my proposal (which is almost how 4.x is currenty layed
out).   If the user has minimised the directory pane then they would still have
the option of having the my directory popup on the toolbar to see what the
current directory is, and change it, without having to open the full
directory pane.

Comment 4

[hangas]

I will present the toolbar suggestion to the UI team.  Changed the Summary to
reflect this.  The bug will be closed when the suggestion is presented,
regardless of the outcome.  Michael: Thanks again for doing this.

Comment 5

[Michael Lowe]

Attachment: 2nd revision screenshot

Comment 6

[lchiang]

cc: nbaca (toolbars) and esther (address book)

Comment 7

[Michael Lowe]

Attachment: 2nd revision screenshot for select address dialog

Comment 8

[hangas]

The UE group liked the button order proposed by Michael in this bug.  The spec
will be updated to have a new button order.  The left pane will continue as it
was.  Thanks again Michael.  Marking as fixed, since this bug was to present the
suggestion to UI and this is done.  The code will be updated to match the spec
after it arrives.

Comment 9

[Ninoschka Baca]

Build 1999112208M12: NT4, Linux, Mac
Verified Fixed because the buttons are present. There is a problem displaying
the Address Picker buttons but this problem is reported in bug# 19604.