Fog Creek Software
Discussion Board




Common UI design/methodology for deleting records

I am presently working on a database program that makes extensive use of the Grid component for finding, filtering, and grouping records as no editing is done inside the Grid. As the program allows for editing and adding new records from a RecordViewDialog that is accessed directly from the Grid, my question is: Is it better/common practice to allow the user to delete a record from the view containing the Grid or the RecordViewDialog? Thank you ahead of time.

Marty Potokar
Monday, June 24, 2002

You can always offer both.    Deleting from the grid would be useful if users can select multiple (or all) records to do a mass deletion.

Think about how most email programs work.  You have a grid view that allows you to delete a message (or messages) by highlighting them and clicking an icon on the toolbar.    You can also double click on a particular message and have it appear in a new window, which also has a delete icon.

anon
Monday, June 24, 2002

I also vote on being able to highlight several records and hit the delete key. As mentioned, email (OE) works that way, and so do files in a "list" view in the explore also work that way.

In addition, in ms-access you don't have a grid, but you use continues forms in that place. Again, this allows multi-record selection and deletion (with zero lines of code I might add).

Since a good many products work this way...I think it is a good approach. I prefer a continues form since you can then also allow a button with a text caption to be repeated. I find is the *best* approach, as each row in the grid thus has a delete button (the learning curve for users is zero). To bad you don't have repeating buttons in the grid, but this approach is the most user friendly that I have found.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Monday, June 24, 2002

Marty,

It all depends on what your circumstances.  What are the implications of a record being deleted?  Should it be allowed for all users, and perhaps be restricted to the user.

Perhaps the easiest option is to add the delete facilitie, and then control it with permissions to the back end database.

Ged Byrne
Monday, June 24, 2002

Really mast ptoof wead

Ged Byrne
Monday, June 24, 2002

I hate using the mouse.  Please allow the user to press 'delete' on the keyboard, then press 'Y' to confirm.  Always have a confirm dialog for destructive actions.

Bella
Monday, June 24, 2002

The problem with "always confirm" is that people get so used to automatically pressing the OK button that it loses it impact very rapidly. People will hit delete followed by enter to confirm without thinking after  a while.

The alternative of course is to offer undo. And yes, this is much more difficult to do, so is it possible to justify the extra work by pointing to some ease of use return? Maybe no for your app, but maybe yes for some other.

Alex Moffat
Monday, June 24, 2002

I would rather see the UNDO option.  A confirmation dialog seems to me just a way that the developer can place the blame on the user.

Joe AA.
Monday, June 24, 2002

Choice == good

Why not give a multi-level undo (maybe with a history window/dialog somewhere), and allow the user to disable confirmation?

Mike Swieton
Monday, June 24, 2002

When the connected data is in a database and may be part of a whole set of rows and tables you need to take into account the knock on effects of cascaded deletes.

If your form and grid is working on a cursor of the data (which it should be), then any regular commits should happen after the whole form is confirmed by the user, so you have roll back/undo through the life of the form.

Preferably you should also have roll back on the database itself outside of any form or application, so that a DBA can restore the data to a known point.

Deletions in this case aren't such a problem because normally deletions themselves persist until after a rebuild of the table/database.  There are always hidden gotchas though, if someone has deleted one set of data and created a new set of data to logically replace it, restoring the deleted set and maintaining the new data is frequently tricky, and frequently what the organisation wants.

You also have to be wary of databases that are structured to reuse deleted records (or rather their space), for new records.  Personally I hate that kind of parsimony disk storage is cheaper than air, just use it.

Simon Lucy
Tuesday, June 25, 2002

I like Simon's suggestions...Personally I love undo functions wherever I go - and if you can track history that would be fantastic. In fact, that would be exactly what I'd be looking for in a DB because I want Version control...so anything you can do to get closer to it would be just about the grooviest thing ever.

I'm not fond of alert boxes, but they have saved my butt from time to time with an errant click (I use a graphics tablet as my mouse, so periodically I tap when I just meant to move).

Triple redundancy in the delete key, right-mouse click method and a button on the toolbar/interface would be good as well - I hate it when any one of those is taken away because i use all of them depending on what else is in my hands at the moment.

Good question :-) Thanks!

Bevin Valentine
Tuesday, June 25, 2002

*  Recent Topics

*  Fog Creek Home