To Show All Records, or not Show All Records...

[Rich S]

As I edge closer to finishing my latest solution I have a question for you seasoned developers:

In many of my scripts--where a user can perform a Find before a print request to pare down a found set--I don't include Show All Records script step at the end of scripts since a user may want to do something else with the found set he or she created.

Then I got to thinking, "Wouldn't that annoy the end user?" because s/he would frequently have to manually click on Show All Records to bring back their full set of found records after a script executes.

So the question is, should I just add Show All Records and assume that end users won't recycle the found set to do something else--to keep them from being annoyed--or force them to take control and manually show all records?

[amgdba]

"Wouldn't that annoy the end user?"

That is a philosophical question, and my opinion is the user is an exchangeable part of the equation. They should have little bearing on the solution. What is important is the business model specifications. What is the workflow attempting to achieve. End users will run a system into the ground, quickly, if left to dictate how they think it should function. If the management finds it conducive to the workflow, then by all means, you should keep the found set. If the business logic says, either by explicit, or implied rules, that the users work will be more in line with the business rules by forcing them back into the entire record set, show the entire record set.

This unfortunately oftentimes gets missed in the design planning stages of an application. There needs to be some sort of channel between who is specing the app and the designer, so when questions like these come up, there is a clear process of comparison of the original app intent to determine whether or not an unexpected topic should be handled one way or another.

I know there are many schools of thought on design in general, and no doubt many who would disagree, but at the end of the day, the person writing the check is usually writing the spec, so if you want a happy client, make the users do what he/she wants, and never defer to the opinion of end users.

With that said, if the end users want to make their case as to how their thoughts are superior to the another course of action as it pertains to achieving the goal of the application and the business rules it intends to enforce, then by all means, present that to the client, as end users usually have a vast amount of insight that the management usually does not necessarily available. You might even surprise the client with some tidbit that they find useful in general, and that will always help to earn happy points.

[bruceR]

As I edge closer to finishing my latest solution I have a question for you seasoned developers:

In many of my scripts--where a user can perform a Find before a print request to pare down a found set--I don't include Show All Records script step at the end of scripts since a user may want to do something else with the found set he or she created.

Then I got to thinking, "Wouldn't that annoy the end user?" because s/he would frequently have to manually click on Show All Records to bring back their full set of found records after a script executes.

What makes you think they are always showing all records? Seems very doubtful. Why would you want to mess with their found set and show all records when that was never what they intended?

[Rich S]

See, that's why I'm stuck. The solution I'm building is one I'm going to market so the end user _is_ the client--potentially many thousands of them--with some of them being database savvy but the majority most likely not. How often they'll even think of creating/using found sets I haven't a clue so that's why I'm second-guessing how or if they'll actually that function.

I guess the smartest thing to do is find fifty or so beta testers and just ask them what they like or don't like about the solution the way it works. It'll be interesting to see what they come up with.

[amgdba]

If the end user is the client, and the lowest common denominator is NON tech savvy users, present them with the same data set as when they started the script. This gives an air of consistency, and allays fears of using the system in a way that will leave them in a spot there were not in just moments ago.

Always expect the worst, especially from users.