>Hello,
>
>I just wrote an article about building user friendly interfaces, maybe that is of interest for some of you or you have some ideas to add from your own.
>
>http://cisberner.wordpress.com/

I think the trick is to have a correct data model and a User Interface that really works. I call it a holistic approach. There are very few ways to relate tables, but I don't think I've seen a catalog of the UIs that correspond to those.

Here's one example.

I have a parent-child relationship. Member to Employment history. Having a current employer and a start and end date on the member record would only be correct on or after the member started at the current employer. Some people would argue to copy the current employer and start and end date to a history table if it changed. The UI is easy to build. There can be a user-collision. Two users could want to alter the member record at the same time - one to change the employer/start/end dates and another to change something else on the record. I think the data model is wrong. The current employer, state and end date are duplicated pieces of information across two tables. That is a also mistake.

So....

I put a set of fields in a cell of a grid. The grid is directly from the history table. The users can all add to the history table without collision or locking issues. The UI shows the current employer/start/end date with little extra screen real estate. Also, the scrollbar on the grid means the user can walk through the history - if desired. A separate tab can present a more normal grid or just a lot more records with the same set of fields in a cell.

[ADD MEMBER] [SAVE MEMBER]
Member Name Date of Birth Current Employer Start Date End Date
Joe Blow 1965-12-10 [NEW EMPLOYER] UT 1999-01-01

But - the trick is how to make it clear to the user. An edit of the member's current employer/start/end date is not an Add to the history table - it is only for fixing mistakes. I had to teach the users the [NEW EMPLOYER] button was to change the current employer. It works well enough. But it's not exactly ideal for heads-down data entry. I could make it begin with a new blank history record while adding a new member - which would be good if the user was heads-down batch adding new members with their current employer - like those members who just graduated from training.

The [SAVE MEMBER] button saved all changes to the member record and the history table so the user didn't have to hit a separate save for the history. But the [NEW EMPLOYER] button made it clear. I only use [NEW EMPLOYER] here to show the intent. A button with an picture could be used throughout the system to represent add a new work history record.