Item4651: Suggestions for improving usability

Right now, the EditRowPlugin has solved the slow case of someone wanting to make a change on one row of a really big table. But what about wanting to make several changes in a big table?

Possible scenario:

A TestRun Table is 32 rows long, 16 of are test cases I need to run, and I have 2 updates I want to make to the table:

1. I click on row 1, make changes
2. Click on row 3 to make more changes

Currently, row 1's changes got lost. I spoke with a few people in my group and they agree with me that losing your changes when you click on another row can be annoying. Ideally, the other buttons on the other rows should be disabled if your changes are discarded when you click on another row.

I could of done 2 possible things instead:

1. Edit the entire table to make the two changes, but then I can't take advantage of the by row edit.
2. Edit Row 1, save. Than click on Row 3 to edit - which can be time consuming as well

It would be nice to have the following functionality:

Once you go into row edit mode, save the changes made between clicking on rows. The row edit mode would end once you hit the save button. To make this clear, the edit icon on the rows can have a tool tip similar to the following: "edit this row - will save any open row".

I believe that when I demoed this plugin to the testing group they mentioned this functionality would be nice. I don't think its necessary to have this for prototyping/rolling out to the users but it would be nice to have. I think this addition would speed up tester data entry even more. How hard would this be to implement? Would it slow down the plugin?

-- TWiki:Main/PaulineCheung - 12 Sep 2007

I think that either changes should be batched up, or there should be an "if you navigate away from this row your changes will be lost" warning in that scenario. I need to investigate the feasibility of doing that.

-- CrawfordCurrie - 17 Sep 2007

I ended up detecting changes and warning of data loss. I think that works pretty well, myself!

Of course it requires JS, but no harm if it's not available.

CC

Doesn't work for date fields

CC

Does now.

CC