I have a lot of grid entries in my applications and I struggle with the paradigm because I feel that grids are hard to use for data entry for my users. Whenever they see a grid, they think "Excel" when they should be thinking "Access" (except they never use Access).

By 'Access' do you mean Microsoft Access? I've never used it (and I'd guess that others haven't either), so perhaps you could explain how it's different from Excel?
–
Scott NewsonAug 9 '10 at 21:07

2

Whats the issue. Do the users don't find features in this grid because they think it Excel? Or try to do things which are not possible?
–
GamlorAug 9 '10 at 21:25

You end up with a lot of blank space and the semantics for adding a row (using an insertion row) are not always clear. A lot of grid implementations have icons in the row headers too that most people aren't used to dealing with I believe.
–
Garo YeriazarianAug 11 '10 at 12:19

It's not so much a problem with presentation as it is with interactivity. Users assume that you can enter data into rows all willy nilly when there really is an implicit requirement to enter data one row at a time.
–
Garo YeriazarianAug 11 '10 at 12:20

The biggest clue that a grid should behave like excel is if it looks like excel.
Seeing data in tabular form alone should not be enough to fool users into thinking it's excel.
Perhaps you could style the cell backgrounds with a gradient or use different color schemes.

If you are allowing data entry in your grid, however, users would naturally expect that tab would move them to the right and enter would move them down (and even Shift-Tab move left). It's kinda like driving a car... I expect a wheel, not a joystick.

A good practice for datagrid entry, when only one set of data can be entered at a time, is a form.

This is more inline with the Access reference you mention.

If the datagrid display is important and helpful, then perhaps you use the form for the data entry and the datagrid to display the entered data. Giving users the option to toggle between, hide, collapse or otherwise remove from the UI is helpful.

If the primary need is to display the data in the grid, then use the grid and provide an "Add" or "Edit" button in close proximity to the grid. The "Edit" button will take the user to a form loaded with the selected row of information; the "Add" button will launch a blank form, allowing the user to enter the new data.

If users expect the grid to work like Excel, then why not make it work like Excel? You can't expect your users to think 'Access' if they are not familiar with that usage pattern. If your users are used to and comfortable with the Excel pattern, then I think it might be a mistake to try to force them into a different pattern instead.