Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

This question already has an answer here:

I need to create a HTML/JavaScript code to edit hiring/firing records for a given employee (the software receives a constant employee ID for the UI to deal with one employee at a time).

One employee may be hired and fired several times during the history of our company. (For example she may go to a parental leave and return to the work later.)

The table has the following fields:

  • employeeid (the ID of the employee)
  • hired (date)
  • fired (date)
  • firereason enum('fired','left','parental','vacation','sick','death')
  • comment text

As you see there are a number of fire reasons:

  • 'fired' (forced to be fired by the boss)
  • 'left' (left the job by his own will)
  • 'parental' (left for a parental vacation)
  • 'vacation' (non paid vacation)
  • 'sick' (sick leave)
  • 'death' (death)

I want to present the list of pairs of hire/fire to the editor as a table, sorted by hire date.

Note that for the last hire/fire record fire date may be missing (null), if the employee for hired but not yet fired.

I am lost about more details how it should be presented and interacted.


After some additional thought I decided that it is best to present the information as a static (non-editable) table with "Edit" buttons in every row.

Now an additional question is arisen: Should "Edit" open a modal window above gray background or an additional row in the table? Which of these two variants is better? Also which buttons should be present in this additional row: "OK", "Cancel"? Can we switch to editing an other row without pressing "OK" or "Cancel"?

share|improve this question
    
Your company fires parents? Yikes. As for your question, can you provide a visual? Based on the description, a table sounds like a perfectly reasonable way to display the information. Is there a reason you're avoiding a table? –  DA01 Aug 3 '13 at 14:15
    
Parents are temporarily fired –  porton Aug 3 '13 at 14:18
    
@DA01: See the edited question –  porton Aug 3 '13 at 14:23
    
@Porton: If you are asking about modal vs. inline editing I would consider looking into the following question: ux.stackexchange.com/questions/6559/…. Apart from that your question seems a little too narrow and/or of no interest for the rest of the community. –  Fredrik Aug 3 '13 at 16:23
add comment

marked as duplicate by 3nafish, Charles Wesley, JohnGB, rk., ChrisF Aug 16 '13 at 17:11

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

A modal is generally a good approach for following reasons:

  1. User context is maintained
  2. Adding and editing experience is the same

I am curious though, on why not do inline editing and auto-save ?

share|improve this answer
add comment

This is data which is quite sensitive. You shouldn't be able to edit any data, really. The only thing you should be able to do is add an overriding record. That obviously has a link back to the original incorrect reason, plus an explanation why the update was made.

The one obvious exception is that you can edit the "fired" data of a record which didn't have that yet. But it might be easier to manage the list as a list of all changes, so you can add "promotion" and "transfer" records as well. In that case, all records become immutable once created. Also, it makes it easier to deal with status changes such as "Sick leave"=>"disability" (a realistic sequence of events). With separate records, you just add another record, with a new date. Currently you can't have two "fire" dates.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.