95087 - [Meta] Improve UX of 'Import Address Book (from CSV text file)' dialog: Assigning source to target fields is too difficult, wrong by design and hard to discover - improve field matching etc.

Status: RESOLVED DUPLICATE of bug 1720042

(MailNews Core :: Address Book, enhancement)

Description

[Jesse Moorman]

I have exported my Netscape AB, converted it to dBase, and combed through it for
errors and inconsistent uses of the fields. I then exported it as a CSV file for
import into Mozilla 0.9.3. In Mozilla there is no control over how fields are
mapped into the address book, which would mean, I guess, rearranging the dBase
export _very_ carefully to match the default order of Mozilla. That probably
means creating a bunch of empty fields as place holders for the Mozilla table
structure.

Comment 1

[Håkan Waara]

-> Address Book

Comment 2

[Jesse Moorman]

It is still impossible in 0.9.4 to import CSV data.

Comment 3

[Jesse Moorman]

It is still a problem in 0.9.4.
Another thing is that the two columns overlap like this:

Address Book fi... Record data to import:
First Name  DISPLAY_NA
Last Name   LAST_NAME
Display NameFIRST_NAMENickname    NOTES
Primary EmailCITY
Secondary E*&%^ATE
Work Phone  EMAIL
Home Phone  TITLE

ET C.

Comment 4

[Jesse Moorman]

It is still a problem in 0.9.4.
Another thing is that the two columns overlap like this:

Address Book fi... Record data to import:
First Name  DISPLAY_NA
Last Name   LAST_NAME
Display NameFIRST_NAMENickname    NOTES
Primary EmailCITY
Secondary E*&%^ATE
Work Phone  EMAIL
Home Phone  TITLE

ET C.

Comment 5

[Quinn Yost (mythdraug)]

Mapping CSV fields WFM (although the mechanism for doing it is odd).

To map the fields, you must select the the destination address book field and 
reposition it within the list of destination fields.

I do agree though with your comment about overlapping fields.  

Comment 6

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 7

[Christopher Hoess (gone)]

reopening

Comment 8

[Ninoschka Baca]

Reporter, can you try again with a more recent build? Many changes have occured
in the address book recently. 

Comment 9

[Jesse Moorman]

Comment #8 asks me to try again. I have not been on the email list, but I've
tried again. [0.9.9 - 20020311, not a nightly build. At my stage, I can't
possible deal with nightly builds.] Although I reported this bug, I have not
been using Mozilla mainly because of bug 63389 and my being clueless how to
manage my old emails, and failing on successive releases to find the time and
energy to invest. Now I've invested the time this weekend, and I transferred all
my emails manually. (Not without some uncertainties about the process and final
result.) Now I'm making a major effort (because Netscape 4.77 is crashing too
much, Mozilla is more polished, and I don't want to reinstall 4.x (or 6.x) again
with all the unwanted AOL gifts).

I agree that destination fields could be moved, even back in 0.9.3. My mistake.
But this mistake suggests that others will have similar problems. There could
_easily_ be some mention of how to do it, right there on the screen when one
confronts the problem of matching fields. There is a bit of an art to moving the
items in the left column, even when you realize they can be moved. Even when one
moves the columns, it is a tedious process. It would help a lot if the scroll
box were BIGGER, even to the point of showing all the fields without scrolling.
Also WIDER, as the overlapping of field names is acknowledged. (Wouldn't those
two things be really easy?) It would be easier if the fields on the left did not
fill in the blank when another field is removed -- it's like playing a geometric
puzzle. (In short, the UI could be much better. I'm sure that's not a high
priority right now.:)

The default order of fields is not the same as one would infer from studying the
Mozilla address book, so a carefully ordered export of data in not correct when
one tries to import it. Specifically in the Work Address box, Title, Department,
Organization come first, but they trail the Address fields on import. Once an
import has been done, the order is messed up, so one doesn't know how to prepare
the data for another import. If you do more than one import, they can get
totally scrambled, and it is way too hard to try to move them to resemble the
starting point. A button to reset default order, or automatice reset, might help.

The check boxes on the AB fields are an unnecessary detail, as it seems that
nothing malfunctions when a check-marked field is not matched with a data field.
I've been making a valiant effort to see what happens when an unchecked line is
opposite data, but it is really too much effort, given the problems I detailed
with the order of the fields.

Netscape 4.x users may be disoriented, once the data are carefully imported,
because the Preferences system does not give a choice, as in Netscape, to
display "Last Name, First Name" in lieu of "Display Name". I thought that I'd
have to redo the database to create such a field (not easy since email addresses
are for organizations without individual contacts, and some are for individuals
without organizations, so no single rule for filling that Display Name field -
I'd have to polish my SQL skills real fast....), re-export, re-import....
Luckily (?) I found that the View menu gives a handy choice. But then I cannot
move the columns, and I cannot put the "Organization" column at the left side.
So a lot of entries are blank in the left column. Is it too much to ask for the
ability to move the Address Book columns?

Comment 10

[Steve Meredith (gone)]

It is very awkward to assign imported fields to address book fields. A better
approach might be to list the address book fields with a dropdown next to each
one. The dropdowns would contain all the imported fields, plus <none>. This
would be way easier than trying to move the address book fields up and down to
match up with an imported field.

Comment 11

[(not reading, please use [e-mail] instead)]

taking all of chuang's bugs.  she doesn't work on mozilla anymore.

Comment 12

[Daniel Wang]

*** Bug 142411 has been marked as a duplicate of this bug. ***

Comment 16

[Yaron Yogev]

I need auto-detection of imported CSV fields for the following use case:
We want Thunderbird users in our company to be able to easily import the whole company address book (we're a small company) into their address book.
We don't have an address book server like LDAP in place yet.
Instead, we do this manually: we provide a link in our intranet that produces up-to-date list of contacts with names, titles, phones, emails and some other details, in a CSV file.

Since I can create the exported CSV file with column names that match the ones created when exporting from Thunderbird, I think auto-mapping of imported CSV fields could be done if field names match. Otherwise our tech support have to waste time in helping users do the manual import, or rely on manual export of LDIF file, which tends not to happen.

Comment 17

[hsv]

The lack of fieldname-matching is a problem to some users, as noted in this Comment #16, or in bug 385753. It is not enough to keep the ordering from earlier importing for default for later: it would be much better if not the order but the fieldname-matching were kept, if "First record contains field names" is checked. That is, if "Display Name" were matched with "Name", and "Organization" with "Company", then on the following instance of importing the same matches were offered. The first time, "Display Name" would match "Display Name", and "Primary Email" "Primary Email", and so on, and there would be a button for returning to this the import state (see bug 385753 Comment 1).

Comment 18

[Thomas D. (:thomas8)]

Let's try and start to sort this out...

Good summaries are an art! Current summary started from a wrong presumption that there's no field matching possible at all during import, which apparently has never been the case. Due to the multi-faceted problem, this bug has become a bit messy and hard to act on. I'm now converting this into a meta bug, hoping that we can identify specific and defined steps for improvement and correction in dependent bugs.
It might still be OK to dupe relevant bugs here.

The current text file import dialog is a total UX fail, screaming for improvements.
Matching csv source with target fields is...

• Hard to discover, hard to understand, and hard to perform (moving source fields up and down alongside target fields in fixed order creates temporary states where fields are jumbled; if you try to rectify that you'll never finish...)
• Wrong by design (bug 194095): If csv has more fields than TB, cannot assign them as they won't appear in the matching list
• Impractical (bug 1392059): Even for the most basic scenario where the csv has (at least some) field names which are matching TB's field names in the first row, fields will not be auto-matched.
• Poorly titled (bug 1687543): "Import address book" - should be "Import address book from text file"
• Buggy: Even importing a text file exported with TB 78 back into TB 78 currently fails with an error.

I imagine that enterprise who happen to have CSV data and are trying to import that into Thunderbird will not be amused...
(added to TB-enterprise tracker).

Comment 19

[Worcester12345]

You'd think there would be a standard for this stuff by now. Hopefully, this will be fixed in our lifetime.

Comment 22

[Ping Chen [:rnons] (away)]

Will be fixed soon, please see bug 1720042 comment 32.

Comment 23

[Thomas D. (:thomas8)]

(In reply to Ping Chen (:rnons) from comment #22)

Will be fixed soon, please see bug 1720042 comment 32.

You probably mean bug 1720042 Comment 38.
If I understand that comment correctly, matching the CSV header row is now implemented, but if your CSV headers happen to be different than TB's field names, or if you don't have a header row in the CSV at all, there's no field matching dialog any more to link imported fields to TB's target fields.

(In reply to Ping Chen (:rnons) from bug 1720042 comment #38)

I played a little with the current process of importing CSV file, the field mapping dialog is really frustrating and difficult to use. D140016 doesn't implement such a filed mapping dialog, we can introduce one later if needed. It fixes bug 1392059 and bug 95087 though. This benefits two cases:

1. if I exported an address book from TB before, now I want to import it back
2. if I edit a csv exported from another application to have the same field names as TB's exported csv file, but not necessarily containing all TB fields

Comment 24

[Ping Chen [:rnons] (away)]

but if your CSV headers happen to be different than TB's field names, or if you don't have a header row in the CSV at all, there's no field matching dialog any more to link imported fields to TB's target fields

That's right. Because the current field mapping dialog is difficult to use and affects later imports, I would either edit the CSV in another tool or just give up. If we receive complaints about missing the mapping dialog, I can introduce something similar later.

Comment 25

[Ping Chen [:rnons] (away)]

I've decided to also add a field mapping UI in bug 1720042, working on it.