That hardware will be more reliable if you stop stabbing it all day By the end of the working week, many a tech support worker feels like bashing the hardware with which they work. Which is why The Register each Friday offers a less aggressive outlet for any workplace frustrations that have accumulated, in the form of a fresh instalment of On Call – the reader-contributed column in which you …
This is why you don't give end users something to test to just 'see how it works' and then roll it out. You need to work with them and see how many different ways they will attempt to use that item then use that feedback to get to a working solution.
At a previous employer, I was asked to be part of the user acceptance testing of the new incident ticketing system which had been under development for about five years. Half of the team doing the testing immediately rejected the application because the part they used had gone from a two step process to something like six steps and having to flip back and forth between two screens as well as duplicating data entry. The part I was testing worked but again required the re-entry of data on two different screens,. However, due to 'security concerns', the new application had to be accessed over a secure connection using an RSA token and a VPN which made login take almost three minutes, and the latency when using the new application was about eight seconds per screen which made it completely unusable, so it was roundly lambasted as being unfit for purpose.
It was eventually fixed and rolled out, but that took nearly another two years and involved the complete removal of the requirement for using an RSA token and the VPN as well as other things to remove the latency and give it adequate performance.
"You need to work with them and see how many different ways they will attempt to use that item then use that feedback to get to a working solution."
That sounds like the agile methodology. Build the basic thing and put it in front of users to see how it goes, then itterate on that each sprint adding in new features based on the user feedback.
You like Agile you do.
It's not agile. It's basic common sense.
Back in the Days Before Agile we had users involved in all parts of a system build. I was quite annoyed when it stopped happening, because end user input was so useful.
Most of the time it worked quite well - the the users spotted things that would be a problem, we had advice from people who knew what the system was supposed to do, and we had engagement from the target audience from the very start. On the user's side this whole computing thing became less scary as they saw how it worked and could actually get changes made when things weren't quite right.
Or, as is apparently about to happen at my place of work, a room booking system which has always been complained-about is to be replaced. Over the years people have got used to the quirks of the existing system but are quite excited to have something "better". Said new system has been in development for about three years by now and is due to be rolled out over the next few months. First users to receive training discovered that there is no "overview" so its impossible to see a representation of room bookings on one simple screen. If I understood what one person was telling me they instead have to check each room individually. We have lots of rooms.
"Oh no," they were told, "you have to buy a different module for that."
Most of the time it worked quite well - the the users spotted things that would be a problem
In my experience, you also got to find out how remarkably varied users were in their thinking. I had quite a few conversations along the lines of "Sorry, you did what with it??? Can you show me? Hmm, I'd have never thought of that.(*)".
(*) Half the time that was the polite version of "Are you a complete idiot?", the other half it meant "God, that's genius!"
Sometimes, especially with internal software written specifically for one set of users, that is the best approach. You can get away with the opposite under either of two conditions:
1. The people specifying what they want are very knowledgeable and have already designed something perfect. You just have to make sure your code does exactly what they said. If you're working in an environment like this, I have one piece of advice for you: don't wake up.
2. You don't care whether it works. You get paid if you build what they asked for, so you build that. If it's broken, that's their problem.
If you're not in either of those, you will need to work with users to figure out what they need, and if you can, presenting them with a partial solution and getting them to fill in some blanks is more efficient than talking to everyone and trying to distill what you need from the conversations. It doesn't always work, and trying to be Agile when you can't do that is a recipe for disaster. However, sometimes the other options also don't work, and doing Agile right can be easier to force than getting perfect requirements.
If you're building something else, this may not apply as strongly. Mass-market software still needs some user testing, but a different kind than internal use. Since you'll be selling it to a larger number of users, it needs to be more generally useful rather than narrowly targeted to your testers, even if it means that their tasks aren't as simple as they could be.
You get paid if you build what they asked for, so you build that. If it's broken, that's their problem
Back in the 1980s I was taking an O-level Computer Studies course. BBC BASIC was flavour of the week.
One programming task was a drill-and-practice multiplication "game". The instructions were quite clear, something like "when the user gets an answer wrong, the program should display 'wrong' for ten seconds and then allow a second attempt. If the answer is correct the program should display 'correct' and carry on after a pause, or when the user presses a key."
Because I was in a pedantic mood, I programmed in a non-interruptible 10 second wait, exactly as in the instructions. And got down-marked for it, because what the teacher actually meant was that the "wrong" text should also be interruptible. Shame you didn't say that then, eh?
M.
That reminds me of a case in school - doing a control technology class.
The (paper based) problem was to design a traffic light control system - and the instructions said something like the green phase should be 20 seconds in light traffic or 30 seconds in heavy traffic. So to meet the laid down criteria, I had drawn a box labelled "computer" and it had inputs from traffic sensors. Oh how I'd love to be able to go back in time and tell myself to have a bit more conviction and say what I wanted to say when my solution was declared over complicated. You see, my solution actually implemented what the problem statement required - while the teachers stated method of "we just use a cam switch driven by a motor" didn't.
OK, he could have had traffic sensors that introduced a 10 second stop on the cam motor under heavy traffic, but he didn't.
Also, as I now know, setting up a complex cam switch (for a simple crossroads it's six channels to switch) with precise timing is "tricky".
On the other end of this, I was assisting a professor and marking assignments. The assignment involved taking a blank file (of a specific format) and performing several different operations to it before closing it. I was running the answers to see if they met all the requirements, and a few students did successfully do all the things they were supposed to, but only if there was an existing blank file. If there wasn't, their programs crashed. I marked them down for that. When one of them complained, we debated whether that was a legitimate way of completing the project as assigned. I still maintain that it wasn't, because the instructions said "open a blank file" and the function you call to create a blank file is open(), but we ended up returning the points I took away. Fortunately, I convinced the professor to modify the assignment to clarify that they should create one so the next time, students could be safely marked down if they didn't.
A lot of people think specs will include enough details that you don't have to think, but I've almost never actually seen such a spec. You either have to ask for instructions at unspecified behavior or you have to figure out what would be logical in the case. Of course, we also have your example of a spec that did clearly specify behavior but they didn't want it, which is quite common but at least they can recognize that when you point to the error.
Yes, I mean, had I been doing this "for real"* I would have made both options the same, and both interruptible in the same way despite what the spec. said; it's the logical way to do it and probably what most users would be expecting and if the person who wrote the specification actually meant what they wrote, it wouldn't take too long to change. Then again, I was never a particular fan of drill-and-practice.
M.
*I did actually go on to do something similar a year or so later. I created a "matching" game which drew a picture on the screen and moved on when the correct matching picture was pressed on the attached Concept Keyboard. Wrong answers allowed a more-or-less immediate second attempt, after a short pause to prevent users just banging away at the CK.
And when we consider "government IT" we have the problem that option 1 is supposed to be the case, but of course the systems are very complex, civil servants are underpaid (anon because I is one), and usually the project isn't correctly funded and managed to allow people who fully understand to spend the time getting everything right. Oh yes, and did I mention politicians changing things on a whim and setting unrealistic timeframes ?
Then we hand it over to one of the usual big consultancies who apply option 2 rigorously, fully knowing that the spec is wrong and they can milk the customer on changes.
during my Computer Science degree one of the things was SSADM (https://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method)
one of the components is speaking to the people who will use the thing and ensure the system is compatible with the use case etc.
"I'd like to say we just told everyone to stop taping knives to laser terminals and the problem went away, but that didn't work," he told On Call. "We ended up actually redesigning the LRTs to handle this type of use."
my first thought was that the scanner should be redesigned to be more rugged and incorporate a cutter.
its far better to go with & enhance the flow than against the grain.
It might be a case of the users not actually grasping how they'd use it if you just told them about it - and even if the customers had been consulted it would probably have been the management who answered. With hindsight they should have made up a few prototypes and let the end users loose with them. Even then it might not have worked as from TFA only some branches came up with taping the knife to the reader so they might not have learned from that.
People naturally use a box knife using one hand to hold the box steady (particularly when the box is small or not extremely-heavy), and the other to wield the knife. Giving them a LRT means that without the LRT/box knife/duct tape modification, users have to put down the LRT, pick up the knife, cut the box, put down the knife, pick up the LRT, scan the box contents, put down the LRT ... because it is awkward to try to hold the LRT and steady the box with the LRT-holding hand whilst wielding the box knife with the other hand. It also is awkward to hold both the LRT and the box knife in the same hand while steadying the box with the other hand.
You can bet your booties that if the LRT/box knife/duct tape mod had been prohibited, and the LRT had not been re-designed, users would be dropping their LRTs -- with the LRTs taking damage -- because dropping the LRTs is much-faster.
And there are a number of possible solutions to that. For example, you could attach the scanner to the user so that they could drop it without it landing on the floor. Or you could give them places to put it down which are convenient for picking it up. In fact, they probably used the taping method only because this scanner was shaped conveniently for use as a handle. I've seen such devices in a variety of shapes, not all of which would work very well taped to a box cutter. There were a number of good options, and although making them more robust worked in this case, there are times where it might not be a feasible option and a different workaround is preferable.
A number of things changed.
In those days, there were people called systems analysts - other role names also came to be used, including business analyst etc, partly because the roles undertaken were refined and broken down in a more detailed way, not least to sell a particular methodology.
But I digress - the point is that someone spoke to the actual users about how they did their job. And the analyst worked with the end users, not against them; and if possible would try to make their job easier and more efficient, not harder.
But those analysts came to be seen as expensive and unnecessary and the approach of firing stuff out of the door as cheaply as possible came into favour. One reason this happened was because the market got cut-throat and the salesman had usually won the development contract by saying the system could be built for a fiver and installed by Tuesday which didn't leave much room for stuff like analysis or proper testing. But the salesman got his bonus and then left the company 3 months so he was ok and never carried the can for the resultant pain trying to deliver the system.
Around the same time, systems came to be specified by senior managers at the customer end, who had no idea how their own staff operated and simply assumed that they knew what was best, because after all it was they who were paying for it. Design, and such analysis as still happened, happened in conjunction with the purse-string-pullers, not end users. The resulting system was then foisted on the end-users who'd had no input into its design.
And yes, I am (was) SSADM qualified.
"one of the components is speaking to the people who will use the thing and ensure the system is compatible with the use case etc."
The way this ON CALL is worded it sounds like they waited until a week after the rollout before thinking to actually visit the people who would be using it. This is something they should have done right back at the very start. They probably never talked to anyone lower than management, who had never opened a box in their lives.
The true idiots here are the ones who completely failed to consult their end users at any point during development and production.
While I agree with you in a general sense, I highly doubt that would have helped in this case.
You'd see them with the box opener attached to a small clipboard (whatever they used for their paper based solution) and it wouldn't even register in your mind as a factor you need to consider anymore than the pen or pencil that was probably connected to the clipboard with a piece of string. You wouldn't see them and immediately think "oh wow we need to make these things really rugged because that box cutter is going to be taped to the reader!"
This is one of those things would only become apparent in hindsight.
Now maybe after visiting a few such sites one might think "hmmm, I wonder if we could build a boxcutter into the reader so it is more convenient for them" but it would inevitably have been vetoed by some higher up over concerns of durability for the display lol
"Why would it be any more dangerous than the box opener tool alone?"
Its not a problem of danger to the user, bit to the company.
If the user uses your laser-with-a-box-cutter and cuts themselves you may be liable
If they user uses your laser with a box cutter taped to it and cuts themselves you are not.
"Where in your imagined visit is the point where you stop staff watching, trying to guess what they need and how it might work, and talk to them?"
Quite near the beginning, after a little observation so you aren't immediately biased by what the users have already come up with. This fails to solve the problem once you get to the part where you don't miraculously think to ask "Are you going to tape this to our reader?" and the user doesn't magically think to say "Oh, I should tell you that I'm going to tape this to your reader." because neither side has figured this out yet. You would talk to them, and they would say that they use the cutter to open the box and then they note the contents, and now they will scan the contents. I can pretty much guarantee that they hadn't taped the cutter to the clipboard or to the pen because both of those things make for terrible cutter handles. They might have tied the cutter to something, but that would work fine because if they had tied the cutter to the scanner, the scanner wouldn't be moved very much. My guess, having not seen any of this, was that someone figured out the speed advantages of taping the two together after they were using them, not preemptively, and others saw this and decided they either could or had to do the same (had to if there was speed tracking and their colleague had gained by attaching them that way). The fastest way to figure this out is to come watch and talk to the workers after they have the scanners because it wasn't known before they had them.
My guess is they had the clipboard attached to their cart on a stand or something so it was more convenient to write on, leaving both hands free constantly. The scanner was a semi-permanent loss of one hand which they clearly felt they had to work around to keep up their existing work rate.
If they'd watched the actual users of the system, then they'd have seen this coming.
The task is not "scan the barcodes". The task is "stock take". Scanning barcodes is merely one part of trying to open every box and count the contents.
Where else can they safely put the blade needed to open the box?
You have to remember that the UPC standard wasn't that flexible initilly. Manufacturers had an uphill learning and unless there inventory was already computerized and able to deal with multiple UPC for the same product but packaged differently really threw the screws to some of those charge that couldn't see the forest because of the trees.
I must recommend here an episode of Managing the Micro from 1981, available as part of the Computer Literacy Project archive on BBC Rewind.
M.
I thought that too, then and I thought "mixed palettes", a common thing and therefore maybe mixed box contents too. On the other hand, the central distribution hub or the suppliers could be asked to change their systems so the main box could have barcodes on the outside describing the contents when packed. The "worlds biggest retailer" should have that sort of power and, if anything, would streamline their own unpacking operation, passing any extra packing costs onto the suppliers, something upper management would likely be pleased with.
This was actually one of the things that led to writing, back in Babylon time. A shipment would be accompanied by a clay pouch, sealed and baked. Inside were tokens, one for each sheep, or jug of wine, or whatever. At journey's end the recipient would break the pouch and compare the contents against the items delivered.
Clever, but what do you do with trans-shipping? If the destination has laws about punishing a ship captain when the items coming off the ship don't match the token count, as a captain taking on a shipment, do I trust that Joe Shepard bringing me a herd from the interior hasn't lost a lamb along the way? That the token count is what he says it is? I can't break open the pouch because (a) then I've destroyed the manifest and that kingdom Really Frowns on that, and (b) I don't have a cylinder seal or the time to forge a new pouch.
Solution? On the outside of the pouch, before baking it, impress images representing each of the tokens inside and by extension the actual items in the shipment. Intermediaries verify using the symbols on the outside, the eventual recipient uses the legally-binding tokens within.
Back to the alphabet. The symbol for a goat: a downward pointing triangle with horns coming off the top two corners. Upside down, it looks like this: A.
Learned this from my sister, when she worked at U. Chicago. I visited and had just spent a fascinating afternoon wandering through the U's Oriental Institute Museum (and seen some of the very things mentioned above). Her husband was a grad student in the Oriental Institute.
So put a barcode on the outside of the box.
This whole process sounds badly thought out. Every box that goes into the warehouse has to be opened and each item scanned when previously they just read the outside of the box? How could that ever improve efficiency?
That works equally well no matter how you note the contents. Under the theory in the comment, when they were using paper, they only cared about the outside of the box, but with scanners, they now cared about scanning each of the contents. That theory doesn't make a lot of sense. I think it is likely wrong.
Instead, I assume that the people cut open the box, put the cutter down, and wrote down what they saw inside. Then they got scanners that looked like they'd work just fine as handles and decided they could speed this up a bit. Requiring them to put the cutters down wouldn't have decreased their speed relative to the paper method, but making them more robust would have helped with speed at least somewhat. Of course, my theory is only another one and I can't prove it either.
During my late teens and early twenties, I worked a few months as a stock boy for department stores. I don't remember us every opening boxes until it was time to put the goods on the shelves.
(This was the days before much of the store's work involved computers. The second stint was the first time I saw computerized cash registers. I was impressed, but I was not allowed near them.)
Having worked part time in the stock room for a department store during uni, I can say that it depended entirely on who was delivering and what it was as to whether the box was checked on arrival.
If it was paper towels - no check. If it was Electronics - absolutely checked and counted. There were also certain suppliers whose boxes were checked because they had a bad "habit" of not including quite as many items in the box as the label on the outside said. Or others who had a bad habit of mixing the wrong items in amongst the correct ones.
On a good day, it was maybe 10% of incoming got a full count, with maybe another 30% to check that what was in the box was what should be. On a bad day, you would be counting EVERYTHING...
We used to have to deal with a company that had a habit of, if the order was, say, 9 widgets, they would take 2 boxes of 5 and removed one from one box but not change the label... so, if you weren't careful, you could book 10 widgets with 10 serial numbers instead of 9
This is one of the reasons I was always taught to put a big fat cross on the end of any box of widgets in the store-room if it was opened(*). Individual widgets came from that one vs just grabbing a box
(*) Over the label, sometimes both ends, but our stores guys were insistent on labels facing outwards for readability and efficiency - it was only an issue when new juniorswere being trained and the worst offenders would be put on "fetching" duty, which quickly taught them the value of having the labels where they could be read
A certain central heating equipment manufacturer (probably the one infamous for a combi boiler that had to run the exhaust fan at half-speed all the time just to keep the pilot burner alight and consuming several hundred watts of gas) told their electronic controls supplier that a 1% failure rate on motherboards was acceptable.
The controls supplier eventually discovered it was costing them more to randomise the position of the faulty one in each crate of 100 than it would have cost them to fix all the rejects .....
If you are Cisco and you ship a device with options pre-fitted then you put a label on the outside of the carton the lists all the options, with serial numbers, etc, normally BAR one item!
2 boxed routers, one with 2 fibre SFPs, the other with 3 SFPs... which one is which?
At the end of the first week of my current job I spent 15 minutes re-arranging the stock in my van and practising loading and unloading, so all the bar codes were facing upward so my weekly stock take was just beep beep beep beep beep.... The other engggiiiii ennnnngggg (cough!) can't say it. The other technicians just chucked everything in their van, and so took half an hour to drag everything out and scan it each week.
Clearly there were still a few dying embers of common sense in Lionel's day.
Today the manglement would install video cameras, hire a casual, or more likely, compel a salaried line manager to review the footage and sack any storeman that affixed his box opening bayonet to the LRT gun.
Your typical grizzled cantankerous storeman usual sports something a bit more robust than your $2 Daiso plastic handled box cutter (~Stanley knife [AU]) which is also insanely sharp so I imagine quite lethal.
If you were spending 40 hours a week opening cartons and for forty years you would have long ago stopped ffaffing around with blunt or fragile cutting tools both of which are like to cause injury. (I have only ever cut myself with, usually other people's, blunt knives.)
A common form was a piece of broken (hand) saw blade, roughly like a massively oversized #11 scalpel blade, mounted a wooden handle which In turn was wrapped in layers of gaffer tape (for grip.)
Saw blade steel takes and retains a decent edge, I am told.
In one job, I had to box up items for shipment occasionally. Rarely had just the right size box, so sometimes modified a big one myself. A very dull, finely-serrated sawzall blade, wielded by hand, made short work of corrugated cardboard.
Then Health and Safety saw it and had kittens!
In most retail environments, particularly Walmart, only approved knives are allowed for opening boxes. Walmart's are blunt ended though still sharp utility-style trapezoidal blades, and self-retracting for safety. Slightly more useful than bare hands, but only just.
Having spend a huge amount of time doing User Acceptance Testing in IT following various testing vai written steps/scripts/spreadsheets I still believe the quickest and easiest way to test a product is to get it in the very hands of some of the very people who are going to use it.
Having ticked off huge swaths of tests in my time, and rolled out said products only to find with in hours or days X,Y,Z issues exist and weren't picked up in testing and the reason being most tests don't account for how users actually work day in day out. This approach would have saved many post roll out face palms.
Who's the idiots?
The people trying to make their jobs quicker, or the people who put unsuitable equipment into a situation it wasn't fit to cope with?
The people using the equipment are just doing their job too.
"I'd like to say we just told everyone to stop taping knives to laser terminals and the problem went away, but that didn't work," he told On Call.
This would have been the wrong solution. You'd built a product that wasn't yet finished.
"We ended up actually redesigning the LRTs to handle this type of use."
This is the correct solution. You've now got a product that not only brought the hoped for efficiencies that funded it in the first place, but you've got a product that is usable by the people who use it.
If you design products like this you'll always get a much better product. Even 'in business' products have users too, if those users feel like they've been listened to or considered then they'll be much happier, and also much more likely to be receptive to changes or suggesting improvements.
If you just force something on people that doesn't work for them, then they won't.
If you just force something on people that doesn't work for them, then they won't
The textbook case would be UK side street junctions, where some experts still think it makes sense to have a small patch of lawn where people would naturally cross and steer them down the side road to a designated crossing point.
I don't think I have ever seen such a layout without an ugly dirt path carved through that lawn. If they put up a shrubbery it will be divided by that dirt path. If there's a fence it will be kicked through..
There are enough examples that I would have thought whoever designs these things would have realised that people prefer to walk in a straight line - and will.
But it seems not.
I absolutely agree. Not only "human nature" but crossing at the corner allows you look down both sides of the junction. Going 10' or more down the side road to the "designated crossing point"is very likely to obstruct your view of any vehicles coming around the corner.
I prefer to go a short way from a junction now my mobility and balance aren't so good, so as to reduce the amount of looking around. On a T-jungtion as described, crossing at the corner requires looking behind, down the side-road, and forward. Moving down the side-road reduces that to just left and right, with a reduced chance of losing balance compared to looking behind.
Not necessarily. Fortunately, the equipment could be built such that it didn't fail when moved violently. If that wasn't feasible, it could be a correct design to require that people not move it violently and design around something else, for example building in something so the user can quickly drop it to start using the cutter instead. Sometimes, the thing a user wants to do is not the one correct usage which must be accommodated, which is good because sometimes what the user wants isn't feasible to give them.
We had a new tool to enter our end of year achievements, so we could do the annual assessment etc.
I entered my data, and told my boss. He came back and said it was empty... please do it again. I did... and again it was empty.
I raised a problem and spoke to the help desk.
Them: Press the save button
Me: I don't have a save button
Them: Make the window full screen
Me: Ah a save button has appeared. The buttons only appeared when the window was more than half the screen size
Them: The help tells you this
Me: What help
Them: Use the help button
me: Ah - it only appears if you make the window full screen
Me: If you use the help button - it loses all you have typed in
Them: That's in the help.
Them: Why did you use it with a small screen
Me: Because it is so slow, I do other work at the same time, so shrink it to a small window.
I had a 2 hour call with the package manager and raised so many "problems" and usability issues. (Dark grey writing on a black background is not very readable) ( Why is there no hover text over the strange, non standard icons ) I tend not to use a mouse, and prefer to use the keyboard, why cant I do this?
They admitted that they had a set of testers whose job was just to test this (so they ran in full screen) and knew all of the quirks.
As so-called experts in this field - they did not seem very good.
Sort of the opposite problem. Software designed (not by us -- we just configured it) in the days of 640x480 screens when expanded to full-screen on an 800x600 monitor had a whole load of empty space. When the users wanted more options on the screen, we had to tell them that the empty space was imaginary and couldn't be used.
"They admitted that they had a set of testers whose job was just to test this (so they ran in full screen) and knew all of the quirks."
Yup. Standard problem.
Also a standard problem that nobody outside of the group is willing to act as tester because they have better things to do
In a job I wrote a script to automate patching of the RH boxes (all VMs). The bit I thought was clever was that I included a powershell script with powercli to take automatic snapshots with a date stamped name. Then another job would look for those snapshots four days later and delete them. My colleagues then started using those scripts when they were working on boxes outside the patch process so as not to have to remember to delete the snapshots before the VMware guy got all snotty about them.
Initially I was a bit annoyed but then started doing the same thing myself.
to my world (cue 5 minutes of deranged laughter interupted by the occasional sobbing)
Where the operators do their utmost best to **** up anything we've just built.
The casting that only fits one way in the carrier plate..... unless you use a 3lb lump hammer to help it in... then ignore all the noises as the poor old robot smashes it and itself to bits.
Down to the plug with the "DO NOT UNPLUG" sign... yupp you've guessed it... followed by "Why does'nt the calibrated electronic guaging system work any more?" while back in my office I get a call from QA downstairs.... "Why is the SPC data sheet showing blanks instead of measurements?".
Luckily for me , I have a PFY to help....hide the bodies
All I really know is that Murphy was an optimist.
When I started working as a field service engineer with a company that made cheap and nasty cheque encoders I noticed that some of them had a piece of string hanging from out of the front of the machine.
The machines were based on a mechanical adding machine, the numbers were entered on the keyboard and when the cheque was pushed into a slot the adding machine went through its cycle, being stopped half way by a solenoid to allow the printing mechanism to print the amount on the cheque. The solenoid didn't always release, which resulted in a service call, so some engineers tied a piece of string to the armature so the operator could give it a tug and carry on her merry way.
About 40 years ago one of the other teams in our development centre was involved in the commissioning of an early trading desk system in the City of London. It had a touch screen, not the capacitive ones we use today but a far more basic one, with infrared LEDs & photodiodes in a bezel around the CRT. Low-resolution, of course, but it captured the position where the screen was touched sufficiently to identify a box on a grid, corresponding to a virtual button.
Seeing an unexpectedly high rate of failures, mainly of the comms gear, someone was tasked with watching how the traders used it. Remember that this was in the 1980s, think back to the films of the day when a trader sat at a desk with old-style landline phones, one C-shaped handset in each hand. These were held at the microphone end, with the earpiece ends held against each ear. Every time a call ended they were to press a new virtual button on the screen to select the next trade/trader they wanted to deal with. Of course, setting the handset back on the cradle, touching the screen, and picking the handset up took too long for these high-pressure guys. At the end of a call they just sharply pivoted a handset away from their ear, smacked the receiver end (hard!) against the required screen 'button', brought it back to their ear and carried on with the next call. The screens survived pretty well, being very tough glass, but IIRC the handsets didn't last. Attempting to retrain the traders was pointless, the handsets were made less fragile...
"The screens survived pretty well, being very tough glass, but IIRC the handsets didn't last. Attempting to retrain the traders was pointless, the handsets were made less fragile..."
The alternative in that scenario is to temporarily make the handsets MORE fragile, such that they actually smash
Once the traders are broken of the testosterone-fuelled habit you can return to more normal ones
A long time ago there was a practice used in manufacturing called time and motion.
It was often used in environments where wages were based on items produced (piece work).
When a new task or process was introduced it was often given to what were perceived as the laziest workers, after a few hours at the task these workers would have determined how to do the task with the least physical effort. Their actions were documented and given to the most energetic workers. Their output was used to set the time for the task!
This post has been deleted by its author
So the process is cut a box open and scan the items in the box. So attaching the box cutter to the scanner speeds things up does it? Do the staff retract the blade when the box is open reducing the chance of damaging the items being scanned? How was pen and paper faster with a simple box cutter than writing down SKUs? Pen and paper insured less mistakes and wonky stock numbers? I've worked too long in IT not to ask questions and just assume people are not trying to blow smoke up my behind. Don't get me wrong, I've worked for enough businesses to know there are lots of things you don't try to automate, but pen and paper being faster than a scan that does not require data entry after? Maybe I'm missing some important details, but assuming what's been related and of sufficient detail. Maybe we are dealing with unionized staff not liking the fact that a computer system can now track rate of scans per person, and comparisons can be made between stores on how well receiving is performing.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
