how do you guide / control user movement? (1 Viewer)

vba_php

Forum Troll
Local time
Yesterday, 21:17
Joined
Oct 6, 2019
Messages
2,880
I remember using Oracle back 15 years ago when I worked in accounting, as I was just as frustrated using it as I was working my client in England who made ridiculous requests that were impossible to comply with. What I remember about Oracle was that for virtually every accounting task, we had to open up at least 3 forms, 1 on top of each other, to enter specific pieces of data into a record. It was the same when needing to view records. I spose this makes sense for accountants who need to view a lot of different data, like drilldown numbers, etc...

I didn't start out in Access programming that way cuz I hated it so much as a user, but eventually I started doing things similar to that and eventually it ended up as a case where most of my access apps operated in this way. I use popup form on top of popup form usually (and modal too, but I can't remember which combo of the 2's usage i used), as a way to guide users through the process of conducting transactions in the app, regardless if it is ADD, REMOVE, UPDATE, MERGE, etc...

I find that I get a lot more support calls and texts if I make the user go exactly through a specific process that way. It cuts down on the bugs too.

Anyone else?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 21:17
Joined
Feb 28, 2001
Messages
27,148
Actually, Adam, you hit a sore spot with me, but not in the way you might have intended. I learned a long time ago that controlling users is about like herding cats. Great in theory until they get outside, then all Hell breaks loose. I'm guessing I learned this particular skill over 40 years ago.

The real skill isn't in controlling the users in they way they do things. It is in not worrying if they do stuff in a crazy order; not worrying because you have sufficient ingenuity on your own to understand the end goal is to SERVE the users, not train them like puppy dogs and bark or salivate on command.

Do I actually CARE about the order of data input? That was actually a rhetorical question for which the correct answer is "Only when it actually matters because the business model demands it."

For cases where order of entry DOES matter, let's say a "cascading combo box" case, you just don't make the next item visible until a selection has been made from the prior item. Any other time, who cares?

You worry only when your user is about to save something or take / trigger an action. Then you invoke your sanity tests, checking for readiness - and disallowing the action when not ready.

Which is why I NEVER EVER allowed anyone to save a record via navigation. I ALWAYS had a SAVE button and if you didn't use that, you didn't save squat. Further, I made it so that until you were READY to save (i.e. had enough data), you didn't SEE the SAVE button OR the CLOSE button. You only saw UNDO and some highlighted text boxes that showed you what was or wasn't critical to enter at the moment. You couldn't even close the form if it was half-way done. But you could still enter data in any order. If you tried to tab off the end of the form, you found yourself back at the top again. I.e. cycle mode with no auto-navigate. I also turned off all navigation controls the moment the form got "dirty" so that nobody could force the issue.

I guess if you made things happen one control at a time and didn't show anything except the next control in YOUR idea of the right sequence, you wouldn't need a sanity clause, but I'm a firm believer in sanity clauses.

The only time that micro-controlling user actions is right is if your paying customer who commissioned the work wanted it that way. Not that you suggested it because that is all you know how to do, but that it was vital to the customer's work flow for very good logistical reasons. So the answer is, unless it is mandatory for the business process, I don't bother to control user movement.
 

Micron

AWF VIP
Local time
Yesterday, 22:17
Joined
Oct 20, 2018
Messages
3,478
I don't bother to control user movement
Leave THAT up to Ex Lax :D

Seriously, I liked your answer - I just couldn't resist.
It made me think that I would have loved to try to break one of your forms/processes. It used to be a function of mine, but that isn't really bug testing when it gets to that point, I guess.
 

vba_php

Forum Troll
Local time
Yesterday, 21:17
Joined
Oct 6, 2019
Messages
2,880
Further, I made it so that until you were READY to save (i.e. had enough data), you didn't SEE the SAVE button OR the CLOSE button. You only saw UNDO and some highlighted text boxes that showed you what was or wasn't critical to enter at the moment. You couldn't even close the form if it was half-way done. But you could still enter data in any order. If you tried to tab off the end of the form, you found yourself back at the top again. I.e. cycle mode with no auto-navigate.
i run into this all the time on the web filling out various forms, including employment apps.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 21:17
Joined
Feb 28, 2001
Messages
27,148
Micron said:
It made me think that I would have loved to try to break one of your forms/processes.

Thanks, but the end users are the best 'test to destruction' group I ever found. And they are fast. I've had cases where within 24 hours of deployment, my Navy system had five people who found bugs in the report generator that had been my pride and joy. But "pride goeth before the fall." Or in my case, simultaneously with it.

I can recall situations where a new product was tested by a customer who brought in one of his night operators (to give him a break and let him visit New Orleans). We were doing a mid-build test (mandated by contract to see that we weren't just claiming to have hardware, but that we had it and that it was up and running.) The guy got to our work area and sat on the keyboard, crashing our keyboard monitoring task. Apparently the operators would lean against the equipment and if it was near a keyboard (and they had big butts) they would trigger auto-repeat on various functions. The next iteration of the keyboard monitor had a test for filling the buffer and would not allow anything bad to happen. Note that this was the 1975-1980 time frame and the ubiquitous PC was even in existence yet.

You want to test something to see if it is rock solid? Give it to one of your end users. The only way to test whether something is rock solid is to give it to someone who is dumber than a box of rocks.
 

Users who are viewing this thread

Top Bottom