Re: Fixed column width problem with scrolling grid
Thanks, Pete --
Looks like it is possible to do this, even after the update that messed up my original user-friendly data entry grid. This is no criticism of your approach, but my problem with row-by-row -editing is that the people who use my apps are, for the most part, "regular" people who barely know how to compose and send an email, or how to fill a simple web form. They have no clue whatsoever that the system expects them to click the pen icon on the left edge before they can edit data on the row, and they would get pretty frustrated with it pretty fast, clicking on text boxes and getting nowhere. Consequently, I don't have much of a chance to educate them on the finer points of editing grids (I used my wife as a tester, and she dismissed the row-by-row editing right off the bat. "This is way too hard, you have to change it" she said.) So, I need to have a grid that is readily editable on any row, so that people can click on a field, type a number or some text, click "Confirm" and be done with it. Anything else will get the end-users bamboozled and emailing me for help, which is not a good thing.
The tables that need scrolling like this in my app are pretty small, no more than 200 records, so scrolling through them like this doesn't put a lot of strain on the system in terms of data retrieval at once. If it was thousands of records I would probably need to use a different approach.
The way you format columns and the screen in your video might work for "all rows" editing, though, and I will definitely try it next. The old saying of "the last 10% of application development takes 90% of your time" is proven to be true over and over again. When you need to present your UI in ways that the framework never really intended, you start "fighting" the framework and it goes downhill from there pretty fast. But that's the price you pay for custom UI, which in turn differentiates you from the competition. Which is a good thing.
Thanks, Pete --
Looks like it is possible to do this, even after the update that messed up my original user-friendly data entry grid. This is no criticism of your approach, but my problem with row-by-row -editing is that the people who use my apps are, for the most part, "regular" people who barely know how to compose and send an email, or how to fill a simple web form. They have no clue whatsoever that the system expects them to click the pen icon on the left edge before they can edit data on the row, and they would get pretty frustrated with it pretty fast, clicking on text boxes and getting nowhere. Consequently, I don't have much of a chance to educate them on the finer points of editing grids (I used my wife as a tester, and she dismissed the row-by-row editing right off the bat. "This is way too hard, you have to change it" she said.) So, I need to have a grid that is readily editable on any row, so that people can click on a field, type a number or some text, click "Confirm" and be done with it. Anything else will get the end-users bamboozled and emailing me for help, which is not a good thing.
The tables that need scrolling like this in my app are pretty small, no more than 200 records, so scrolling through them like this doesn't put a lot of strain on the system in terms of data retrieval at once. If it was thousands of records I would probably need to use a different approach.
The way you format columns and the screen in your video might work for "all rows" editing, though, and I will definitely try it next. The old saying of "the last 10% of application development takes 90% of your time" is proven to be true over and over again. When you need to present your UI in ways that the framework never really intended, you start "fighting" the framework and it goes downhill from there pretty fast. But that's the price you pay for custom UI, which in turn differentiates you from the competition. Which is a good thing.
Comment