Editing in grids and data forms - how smart are end users?

Question

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

Our programmer does not think that end users can handle them, so he always develops his forms with read-only networks (with read-only classes). Choosing to edit an element in the grid opens a detailed form that allows you to edit.

This app will be used by general business folk, not geeks. But they are all very good Excel users, which I think are a "grid" like. Should I trust my lead developer or go with my gut that says users like quick editing - that the grid does much better than the shapes of the parts? I want to have a constant feeling for the application, so prefer not to mix it too much.

Answer 1

This is mostly a matter of taste, but my preference matches your developer (and Corey's answer above). I prefer the read-only / edit model on top of the large editable grid for most applications. But I work a lot in Excel and it will kill me to open a row at a time. Different goals! If you are basically going to do a lot of random access editing, I would stick to the grid. For everything else (including sequential input), I would use a read-only model with a breakdown form. The various applications I've worked on have shown that users can deal with the appropriate context.

Answer 2

In my experience, editing grids can be complex for both the programmer and the tester and user, because the focus focus event is usually the trigger for testing. That is, the user picks up the cell and stops with an error in this cell until it fixes it.

This is normal? It depends.

If the data in each cell of the grid can be checked without reference to other cells and especially to other rows, then perhaps this is normal. But if the reality of one cell depends on the value in another cell, then the check caused by the kill focus can be complicated. Your user may be in a situation where they must put SOMETHING in a cell in order to be able to leave this cell and go to the real cell that causes the problem.

Another advantage of the dialog box is that at the same time there is a lot of screen real estate for useful text, longer shortcuts, several error messages, next to the error fields. In the grid, sometimes all you can do is change the color of the cell and a pop-up modal dialog box for only one cell.

I am working on an application that has replaced an application that has been edited in grids. Every programmer associated with the old application agreed that there will be no editing in the grids in the new application, and this is not that we are lazy. We just wanted to send something that we knew we could do firmly, which would be easier for our testers to test.

I agree that a user with Excel experience is comfortable editing in grids, but then you better make sure that your grids also behave as strong lines.

Answer 3

Change the place on the grid whenever possible and never have an edit dialog. I don’t think that I have an “editing mode”, and it spends time on users and increases the complexity of the application (from the point of view of users). Having an editing dialog box makes it difficult to learn about the application than editing in place, because the user needs to learn two windows and how to navigate between them.

As experience with Excel, Access, and other desktop applications shows, users have no problem editing the grid, except for editing anything else. You should have no problem, especially if your grid looks like an Excel worksheet or an Access spreadsheet or form, and not like your typical Click Here to Update web application.

I think that the tendency of some developers to create read-only grids is a break from early web applications 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 editing mode with today's technology.

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

If this can be done asynchronously or in less than half a second, consider automatically posting recording changes with loss of focus per cell or (alternatively) row. This relates to the concurrency problem for multiple user applications, and also gives them implicit preservation of your users, and can also use other applications for ease of use.

Direct manipulation has been a proven usability principle since GUIs were invented. Modes have long been recognized to represent usability issues. Its high-performance web applications reached usability levels in the 1980s.

By the way, a lot of explanatory text in the window (for example, long labels and several messages) is a sign of usability problem, not a solution.

Answer 4

Users can fully process grids. This is more intuitive than the edit button and detailed form.

However, is this application a multi-user application? Can basic data be changed by more than one user at a time? If so, then you have several concurrency design solutions, and sometimes it may be easier to decide when users can only edit one line at a time.

It smells a little suspicious, and I suspect your programmer is making convenient excuses because it is easier for him to create read-only grids in a master / detail template.

Stick to the gut instinct. :)

Answer 5

If you do not completely trust your lead developer, they should not be your lead developer.

In addition: if your lead developer has a degree in computer science (or another similar degree), do not call them a "programmer." This is negative for a professional engineer.

If you reverse your decision, they will not feel the love to say the least. Be very careful to step on the toes of your software engineers. Only do this if you are 100% sure that you are making a mistake. Even then, you can approach the problem in such a way that they realize that it is a mistake, and you do not actually overlap one of your solutions. Help them make the best decision by asking them how they will solve the particular case you are worried about. If they are not worried about the same case, let it go. That is why they are a leading developer. As long as they are smart and understand your concern, the best thing you can do while you hire the right people. The damage you could do to your relationship and its performance by overriding the decision of your lead developer can be much worse than the editable or uneditable grid view.

Answer 6

Why don't you do some user testing and find the answer this way? Highlight a couple of simple prototypes or use existing examples and ask them to perform simple tasks. You will quickly see how good the users are, and the choice there should be fairly simple.