User interface for a “mapping” table

Question

I have the following problem. I need to provide an interface for users inserting/editing "mappings" in a database.

A mapping is a record as such:

[Field A, Field B, Field C] --maps to--> [Field X, Field Y, Field Z]

At the moment I am using a grid as such:

1 Field A, Field B, Field C, Field X, Field Y, Field Z  
2 Field A, Field B, Field C, Field X, Field Y, Field Z  
3 Field A, Field B, Field C, Field X, Field Y, Field Z

However, I don't think I am using the best possible user interface:

• There is no clear indication that the fields are split in two
• It's hard to see if the mapping is complete (i.e. if all possible A, B, C combinations have been mapped to something)
• Since the records are saved all at once, and not by row (it's a requirement), it's really hard to show intuitively what went wrong in case of error (multiple rows can be causing an error, e.g. for duplicate mappings)
• It's hard to show validation errors (people entering a string in an int field, for example)

The mapping rows can be in the range of 1,000-10,000 rows. The application is a WPF application.

Is there a more usable way of presenting and editing this kind of data?

Answer 1

• I had to do something similar for mapping virtual channels in an ATM switch.

Adapting this to your situation:

• Check-as-you-go: Remove the restriction of all rows changing together by working on a shadow table. This is the only sane way to make your warnings and error messages be timely and make sense. When everything is OK, then the user can commit the changes.
• TWO Tables: My experience is that you need to show the mapping organised both sorted in terms of ABC and sorted in terms of XYZ on the same screen. It is no good switching back and forth between the two orders. It's too disorientating.

Finding Unmapped Items

One feature users loved was having a compact display for the available ABCs / XYZs. Rather than a list 1000s long, I was able to condense the lists by showing ranges of allocated (or unallocated) items.

Can you do that?

Perhaps you can. Condensing is a must have. 1,000 rows is close to unmanageable without summary information. Paging through 10,000 at 100 per page - no thanks. If one of your fields is numerical, you can show a range in that field. If [Alfred][Barry][ 1 to 97 ] are all in use, you don't need 97 rows to say that. That's essentially what I did. From your question I suspect that's not possible for you. In that case there is another way to condense.

Condensing Using Tree tables

You can condense by using a tree table with three levels, one for A, one for B, one for C. (same thing with a second table for X,Y,Z,n too ). In the table part you show summary information, e.g. that for [Alfred][anything][anything] there are 579 combinations of which 179 are free. When you drill down all the way to node [Alfred][Bertie][Charlie] it might show 'unused', if it is unused, or 'mapped to [Xavier][Yoda][Zebra]' if it's mapped to that element.

The 'n' in X,Y,Z,n was not a typo. In that tree table [Xavier][Yoda][Zebra] might say 'used 21 times'. Expanding that node gives the 21 subnodes with the actual ABC mappings.

---

Making or Breaking Mappings

Now we've got tables showing the state of the mapping, all we need is a way to add or remove a mapping.

For that you want six fields A,B,C --> X,Y,Z. Connect

In your first pass you can make the user enter those values. In a later refinement you can fill in ABC or XYZ through clicking around on the two tables. I wouldn't try and do this data entry actually in the tables.

---

In Sum

Make no mistake - It is a lot of work to make a good usable mapping table. It is also very rewarding. If users have been using a less good mapping table interface a lot, they'll be delighted with an improved one.

Answer 2

It sounds like you basically have a tree, where the nodes are XYZ and each can be related to a number of ABC. How about something like this?

You can play around with different ways to create new nodes and leaves, and this one may not suit your needs, but I think that a tree-like layout would simplify things a lot.