Ok. Have the regular web interface accept anyone without a password, but if you try to edit repair tickets, your keystrokes are saved to a mirror page that doesn’t actually change anything unless you finish by entering a special “save changes” password.
Apparently, logical fallacies fall into this category. I was having a discussion with someone who was just unable to make a logically consistent argument to support his point. A lot of his arguments would end up boiling down to various well known logical fallacies and, as they would show up, I’d point them out and tell him he may want to reconsider how he’s making his argument. His response was along the lines of “logical fallacies don’t apply to me, you just can’t counter my points.” Umm… no, logical fallacies DO apply to you and I can’t counter your points because you haven’t made any because they’re not logically sound.
I did finally get him to actually look up some of them and some of his reasons for why they were okay to use were just bizarre. For instance “I don’t recognize Chewbacca Defense as a logical fallacy because I don’t like South Park.” Or, perhaps most amusing for it’s irony, when I pointed out that one of his points was just a tu quoque (and a false accusation at that) “Yeah, well you use logical fallacies too, so tu quoque right back at you.”
I can understand that these sorts of things aren’t necessarily intuitive, but I would think when they’re explained they ought to be pretty easy to understand why they don’t support an argument.
And just exactly how much time did you spend arguing with this guy? I think it would have been right around the time he said those things that I would have admitted defeat.
Nope, wouldn’t fly. Because then ordinary end users would be able to READ the repair tickets and would only be prompted for a login if they tried to make changes to them.
So it would have to be a way for someone logged in as an ordinary end user to log out and back in as a tech, except that
a) It would have to be totally invisible and undiscoverable by anyone who isn’t a tech but
b) It would have to be easily discernable and hassle-free and effortless and transparently obvious in every way to the techs who can’t be arsed to do anything as complicated as modifying the URL in their freaking address bar.
I also once had a computer-illiterate professional demand that I set up the computer so that if she started typing a letter, it would open what she started typing in Word. But if she started typing rows and columns of numbers it should open what she had started typing in Excel. Because it was too damn complicated to remember which labeled icon on the computer she was supposed to launch for which purpose, and she shoudn’t have to know that stuff anyway, the computer ought to be able to figure it out.
I am saying a silent thank you that my boss is not like that. I do tech stuff for a living, and recently had to clean up after a program accepted values for a field which it could not then display. So once the mistake was made, the poor user could not fix their error.
There is a failure at every stage in the SDLC anytime this happens. I suppose it seems superfluous to put in the requirement that the software should only accept a value that is valid for that input, and if that is not explicitly stated, then the test designers won’t test for it. The developers should code that in automatically, but if no one puts that in their process document, they won’t. Test designers only test explicit requirements, and QA only follows the test scripts.
Oh, and in the example in the OP there should be two sets of tests done on that input. The first is this really a number, and just a number? And the second is this an appropriate number for this field? Otherwise some mother can come along and mess you up but good.the
tdn, do you work healthcare IT? That job is a nightmare–I am so glad I am no longer near it. Just reading the OP was giving me hives, recalling many similar conversations.