Editing in grids vs. detail forms - how smart are end users?

Question

I love grids - especially the cool third party ones like Devex, C1 etc..

Our programmer doesn't think end users can handle them - so he always designs his forms with read-only grids (with read-only classes). Choosing to edit an item in the grid opens up a detail form that allows editing.

This app is going to be used by general business folk - not geeks. But they are all very good Excel users - which I think is kinda 'grid' like. Should I trust my lead developer, or go with my gut which says that users like fast editing - which the grid does much better than the detail forms? I do want to have a consistent feel to the application, so prefer not to mix it up too much.

Answer 1

Users can totally handle grids. It's more intuitive than an edit button and a detail form.

However, is this application a multiple user application? Could the underlying data be changed by more than one user at a time? If so, then you have some concurrency design decisions to make, and sometimes, that can be easier to solve when users can only edit one row at a time.

It smells a little fishy though, and I suspect your programmer is making convenient excuses because it's easier for him to design read-only grids in a master / detail pattern.

Stick with your gut instinct. :)

Answer 2

In my experience, grids with editing can be hard on both the programmmer, the tester, and the user because typically the trigger for validation is the kill focus event. That is, the user tabs off a cell and is stopped dead with an error in that cell until he corrects it.

Is that ok? Depends.

If the data in each cell in the grid can be validated w/o referencing other cells and especially other rows, then maybe that's ok. But if one cell's validity depends on the value in another cell, then a validation triggered by kill focus can be tricky. Your user can end up in a situation where they have to put SOMETHING in a cell just to be able to leave that cell and navigate to the real cell that causes the problem.

Another advantage to a dialog is that there's lots of screen real-estate for helpful text, longer labels, multiple error messages at the same time, all next to the fields in error. In a grid, sometimes all you can do is change the cell color and popup a modal dialog for just that one cell.

I work on an app that replaced an app that had editing in grids. Every programmer involved with the older app agreed that in the new app there would be no editing in the grids, and it's not that we're lazy. We just wanted to ship something we knew we could make solid, that would be easier for our testers to test.

I do agree that user with Excel experience are comfortable editing in grids, but then you better make sure your grids are as well behaved as excel's grids.

Answer 3

This is mainly a matter of taste, but my preference is in line with your developer's (and Corey's answer, above.) I much prefer a read-only/edit model over a big editable grid, for most applications. But I work a lot in Excel and it would kill me to have to open up a row at a time. Different purposes! If you're primarily going to be doing a large amount of random-access editing, I'd stick with a grid. For everything else (including sequential entry) I'd use a read-only model with a break-out form. Various apps I've worked on have shown that users can deal with either in the appropriate context.

Answer 4

If you don't trust your lead developer completely, they shouldn't be your lead developer.

Aside: If your lead developer has a degree in Computer Science (or other similar degree), don't call them a "programmer". It's negative to a professional engineer.

If you override their decision, they won't feel the love to say the least. Be very careful about stepping on toes of your software engineers. Only do so if you are 100% certain they are making a mistake. Even then, you might approach the issue in a way that makes them realize it's a mistake without you actually overriding one of their decisions. Help them make the better decision by asking them how they would solve the particular case you're worried about. If they aren't worried about the same case, let it go. That's why they are the lead developer. As long as they are smart and understand your concern, that's the best you can do as long as you are hiring the right people. The damage you could inflict on your relationship and their productivity by overriding your lead developer's decision could be far worse than the editable vs. non-editable grid view.

Answer 5

Edit-in-place on the grid whenever possible and never have an edit dialog. I can think of no advantage to having an “edit mode,” and it wastes users’ time and adds complexity to app (from the user’s perspective). Having an edit dialog makes it harder to learn the app than edit-in-place because the user has to learn two windows and how to navigate between them.

As experience with Excel, Access, and other desktop apps reveal, users do not have a problem editing a grid any more than editing anything else. You shouldn’t have a problem, especially if make your grid look like an Excel worksheet or Access table or form, and not like your typical “Click here to update” web app.

I think the tendency of some developers to make read-only grids is a holdover from the early web app days when there were no editable grids or no grids at all --there were html tables and any editing required a form. I see no excuse for edit mode with today's technology.

As for validation, inform the user of any validation error when focus leaves the cell, but do not use modal error indications (marking the field with color is one way to do this, but not on the only way). Let the user correct it whenever one wants, perhaps by fixing other fields. This solves the dependent validation problem.

If it can be done asynchronously or in less than half a second, consider automatically posting record changes with the loss of focus on the cell or (alternatively) the row. This addresses the concurrency concern for multiple user apps, plus gives your users implicit save, another usability improvement web apps could use.

Direct manipulation has been a proven usability principle since GUIs were invented. Modes have long been recognize to present usability problems. It’s high time web apps caught up with a 1980s level of usability.

BTW, lots of explanatory in-window text (e.g., long labels and multiple messages) is an indication of a usability problem, not a solution.

Answer 6

Why don't you do some user testing and find out the answer that way? Mock up a couple of simple prototypes or use existing examples and get them to carry out simple tasks. You'll quickly see how good users are and the choice from there should be pretty straightforward.