Design for more compact Contacts
An identified problem is that while it is very desirable (customer
requests) that contacts support a diverse range of fields, our
presentation of these fields sucks.
The principles of an ideal interface for contacts are:
- Single page view of relevant information.
- Use case: You're driving to see the contact,
where do they live? Work?
- Use case: You want to communicate with the contact,
need to know what options are
available, decide which is appropriate at
the current time/situation (talk, email,
SMS, etc.).
- Use case: If the device has the facilities to
make the connection, the details of the
connection are not very important.
- Use case: The first few lines of the Notes
could be a critical warning like
"Never call on Sunday morning".
- Single page editing of data entered on-the-go.
- Use case: Person gives you there phone number in a meeting,
you must record it very quickly to avoid disrupting the meeting.
- Details of all attributes.
- Use case: In preparation for a meeting, you review the
personal details you have recorded, including full notes.
The main problem with the current design is that when entering details,
large amounts of data is presented as individual fields rather than
using forms more familiar to humans.
Multi-field Widget
Implement a widget that combines the input of multiple fields into a QLineEdit
or QMultiLineEdit, parsing them into the separate fields, but
providing a way to edit and/or view the parsed result as individual
fields. Support a wide range of input possibilities, including a
very unambiguous form.
For names:
- name = [known-prefix] given-name [nick]
{middle-name} family-name [known-suffix] [pron]
- name = known-prefix family-name [known-suffix] [pron]
- name = given-name [known-suffix] [pron]
- name = family-name ',' [known-prefix] given-name [nick] {middle-name} [pron]
- name = locale-dependent-form
- pron = '"' same-number-of-words-except-affixes '"'
- nick = '(' nickname ')'
For addresses (linebreaks count; postal-code contains digits, state does not):
- street-line
{street-line}
[ city ',' [state] [postal-code] ]
known-country
- street-line
{street-line}
[ city ',' [state] [postal-code] ]
- locale-dependent-form
The user doesn't need to know this syntax: it usually "does what I mean", and when it
doesn't, they are shown how to type entries such that it does. For example, someone
who uses nicknames a lot will soon learn to enter "Robert (Bob) Dylan" (in reality
they'll only bother doing this on a nice keyboard such as with Qtopia Desktop).
Rather than a "..." button, the lineedit should have a "Details..." option in its
context menu, which brings up a small dialog allowing each field to be explicitly
edited.
Note that the FileAs field is not even presented in the non-detail view,
since only a tiny fraction of people need an additional identifying
mark in their FileAs. The user chooses the FileAs form they like, and
all but a few should automatically be set. The exceptions can be set
in the Details dialog.
Compact phone fields
A contact can have very many possible phone contacts, and Qtopia currently
supports 7 (if you include faxes and business pager); all of these are conceivable
first-contact details and therefore belong on the first page, however in reality
you usually only receive one or two phone details for a given person, especially
in an on-the-go scenario. Therefore, there need only be one or two phone fields,
but some way to say what sort of field they are: a combo box is the simply way.
In some countries, it is possible to get a hint about the type of number from
the leading digits.
Use menu for Emails
The "..." button should be removed from the Emails and instead put in the
context menu. This saves having to tab over the rarely-used option.
Use a "business" hint
There are different needs when entering a business contact has different needs
to a personal contact. For a business contact, you will often only have a
single phone contact, but you will likely want to record their company name
and job title. For a personal contact, you will often want to enter as many
phone contacts as possible, but their company and jobtitle can be left on
the ancillary pages.
Move key fields to first page
Once the name field (currently 9 fields) is compacted to a Multi-field widget,
there is plenty of room on the first page for the key fields from other tabs.
The first page becomes:
- Name - multi-field, parsed as above.
- Business - checkbox membership in Business category.
- Phone - default default is country-code of owner.
- PhoneType - default to Work if Business checked.
- AddAnother - button to add another Phone+PhoneType.
- Emails - context menu to add multiple, or use commas.
- CompanyName - only if Business checked.
- JobTitle - only if Business checked.
Note that all the details except name and Emails are probably
duplicated on the relevant Business and Home pages. Certainly the
CompanyName and JobTitle must be if they are made invisible by the Business
checkbox!