[RESOLVED] Simple Aesthetic Question

This is an easy question to answer, but I feel that it is a hard question to answer well. I'm looking for opions, and, if possible, reasons.


The question has to do with the behavior of a grid. I have a simple grid on a form. The user may not interact much with this grid in normal usage of the program, but the grid is there so that they CAN interact with it if they choose to, and interaction would be either reviewing the contents, deleting record, or editing records. Adding records cannot be performed in the grid. A few other controls located elsewhere are used to add records. While a single record can be added at any one time, it is FAR more likely that people will use the other controls to blast in a whole bunch of records at one time. In fact, it will be common for a person to enter so many records that it will be more than can be displayed in the visible area of the grid, which will result in scroll bars.

So the question is this: If you were using this, and entered a whole whack of records, where would you want the display to end up? The two options that seem most likely would be: 1) The first of the records you just entered. 2) The last record in the grid.

I would say that i'd want/expect them added to the bottom of the grid, with the grid scrolled to the bottom, so i guess number 2 for me. Possibly with some indication of the number of records added.
If i'm not interacting with the grid much and am mostly adding in a bunch of records i think it'd be counter-intuitive to have the gridview appearing to be focused somewhere in the middle (as option 1).
Although it does depend on what i'm doing with that data once i've added them all in. If i need to check that they're added or perform some other operation then possibly number 1 would be appropriate.
Another option, combined with 1 or 2 is highlighting newly added records in some way until the next batch are added.

I think this could be argued both ways. I personnal like the newest info on the top of the grid as an example E-Mail. My newest email is always at the top of the list. My wife on the other hand likes to have the oldest email (record) at the top of the list and any thing new at the bottom.

I guess is that the users will give you the same basic answer if you ask 10 of them you'll get a mix of preference.

If these is for a bunch of engineering types I think I would order newest to the top and let the users be able to change the sort order.

Go to the last record added.... regardless if it is at the top or at the bottom, or the middle (depending on the sort, it could happen).

-tg

Quote:

---

Originally Posted by GaryMazzone

I think this could be argued both ways.

---

Yeah, me too, which is why I posted it. Right now, I have the last N records displayed if new records are added. They are added to the bottom, though, and there is no sorting. I suspect that would be most appropriate in this case, rather than adding them to the top. The concept being captured by the grid is more of a list than a stack.

If you're always adding via a separate mechanism then I'd say you definitely want to go to the last record in the grid (I assume this will correspond to the last record entered - is that right?).

I would seriously question why you don't want the user to add rows directly to the grid though. To me that's the most instinctive thing for a user to be doing and usually when I come across a system that uses a different aproach it was because the developer couldn't work out how to get all the functionality they wanted from a grid when adding. Certainly in VB6 it was nigh on impossible but in .Net it's very achievable with a bit of work and it means you don't need separate input forms (which lead to extra keystrokes) or a 'new record' pane somewhere on your form (which eats loads of screen space). I championed this aproach when I got to this company and, while my devs may have wanted to punch my lights out at first, even the most cynical of them (SpudGun) now agrees that this is definitely the way forward (actually, Spuddy probably did more work than anyone else to really get them working at full tilt).

The features we've got (just to show they can be achieved) include:-
Datepicker Columns
Combo Columns (which can show obsoleted values for existing rows but only allow current values for new rows)
Automatic colour coding of uncommitted changes so the user can see what has and hasn't been saved to the DB
Greyed read only columns that are automatically skipped as the user tabs through cells (this makes data entry a breeze)
Ability to set whether new rows can be added and/or existing rows ammended as a property on the grid.
Defaulted values on new rows.
Validation on cell, row and grid exit.
'Binding' to sproc to populate and save data automatically.
Loads of other bits and pieces

Seriously, we're at the stage where we drag our grid onto a form, set a couple of properties, write a bit of code to govern column widths, hide unwanted columns and set read only columns... then we walk away. It takes us about ten minutes to add a grid to a form and it's fully functional for the user. In case you can't tell, we're really rather proud of it at this stage.:cool:

I can't post the grid (though I'd love to) because it's owned by the company, but if anyone wants any help getting different aspects of a grid working I'd be more than happy to oblige.

The user CAN add using the grid:

Quote:

---

Originally Posted by Shaggy Hiker

While a single record can be added at any one time, it is FAR more likely that people will use the other controls to blast in a whole bunch of records at one time.

---

-tg

Not if I'm reading this correctly:-

Quote:

---

Adding records cannot be performed in the grid.

---

I think what Shaggy's saying is that a user will add single or multiple records using the other controls but not directly into the grid. Presumably, once they've finished adding records they'll click save (or something similar) and the grid will get updated with everything they've just added.

There is very little data, so the space needed for data entry is fine. TG had the right idea. It would be a very rare case where a single record needed to be added, so the functionality is targeted at the common case, which is where a series of predictably related records will be added in one big batch.

I decided against direct entry into the grid because the chances of error seemed higher than the advantage of entering the data that way. One of the fields is text, and screwing it up is just too easy, though a pick list is out of the question, as there is no possible list to pick from.

It's a design decision which is, of course, specific to your scenario but I'd argue that direct entry to the grid is perfect for batch entry. As the user tabs off the last cell of each row it adds the new one automatically (I seem to remember we had to override the ProcessCmdKey method to get stop the tab moving to the next control instead of the next cell but it was a while back and I might be wrong) so they don't need to reach for the mouse to click an OK button. You can set any default values on the new row (including those based on user entry in the previous row for related data). You can validate that something sensible was entered in any of the fields either as the user leaves the row or leaves the individual cell so it shouldn't be any more prone to error.

Come over to the darkside, Shaggy. I am your father. (Well, probably not but I never could resist a star wars reference)

By "batch entry", I mean that they fill in three fields, press a button, and any number of rows are written. Since they only have three fields to fill in (and often only two), this will be faster than direct entry for any number of records above two. Since the typical number will be 20-200, the route I have taken will be faster.

I toyed with the direct entry as a viable alternative, and rejected it, eventually, though I don't remember the exact reasoning.

It is specific to the situation, though, and the choice was ratified by the user group.

Ah, then you're right. Presumably one of those fields is a 'number of rows' field, right?

We had a similar situation and we just put the number of rows field as a column on the grid. You can't view individual rows on the main form level but you can drill into them by double clicking on a row. This worked well for us because it's consistent with the rest of the interface but it did involve some extra work.

Actually, the whole form is kind of silly, and attempting to describe it rationally may be a futile undertaking. After all, the only piece of data 99.9% of users want is the number of rows, so I originally implemented the whole thing as nothing but a single count field in a different table in the DB. However, that last 0.1% want to be able to give individual names to things that have no other identifying characteristic in this case. Therefore, the rows consist of these fields:

1) A primary key.
2) A name.
3) A field that is always 1 or 0 (though it theoretically could be greater than 1).
4) A field that is always 1 if field 3 is 0, and 0 if field 3 is 1.

The name holds no significance of any sort in this case, so they are being virtually autogenerated, and all anybody cares about, in this case, is the sum of field 3 or field 4. If that sounds absurd, it is. The reason for the table is that most people will be automatically entering records where the name ties the record to a GPS waypoint. I just needed to add a way to blast in records for those rare cases where the user didn't have a GPS file to load, but in those cases, the names are almost utterly meaningless, and only the sum of fields 3 and 4 have any meaning, though field 3 will be 1 and field 4 will be 0 with such predictable regularity that I considered not even asking the user for a value (if they ignore the value, that's what they get).

That table is the most hard to justify, thing I have ever written, yet it was totally essential for that 0.1% (who aren't actually identified, it's just that everybody thinks they must exist....somewhere) who needed it.

I find it entertaining, but I think I shall say that this is resolved.