Sunday, April 27, 2014

Why stuff has to work seamlessly.

For a while, I was starting to get the impression that the idea that things have to work correctly nearly 100% of the time with respect to computing was a ridiculous standard. I thought it was some sort of outcropping of the behavior of spoiled kids.  The first times I really heard it mentioned specifically were Jobs talking about the new macs, about how they needed to 'just work', and in Zuckerberg's comments about how facebook needed to be up all the time or that people wouldn't come back to it.

I later realized that this is not a progression of vanity or of unreasonable expectations, but merely an expression of trying to keep up with an existing standard.

Clay tablets and stone chiseling might have been unforgiving media, perhaps. They did give us a media where data could be archived for far longer than a human lifetime. We have learned substantial things about languages no longer spoken and mathematical systems no longer used merely from clay tablets and chiseled stone.  They are a bummer to carry around, but that's why you invent the library, and then thousands of years later you invent the steel-toed shoe.

We've had paper and pencil for a decent amount of time, and it's still a functional system. If the power goes out, you can still read it. If they make a new kind of paper, you can still read the old paper. You have a visual indication if a pencil is about to fail. You can feel if a piece of paper is about to rip when you're writing on it. Large amounts of paper can be bound together to make books, holding more information than tons of stone and clay tablets can.  If somebody found something interesting, you can make notes in the margins, or perhaps scrawl an idea or reference between the lines of text. If you mess something up, you can erase it and then recheck your work.

In the early days of computing, input was done via mechanical means. At that time, that mechanical input usually ended up being punch cards, since those were used for automated machines from the previous era.

The next step in local computing was the keyboard, an outgrowth of the existing typewriter. With the keyboard, we also got what we commonly refer to as the command line. It's just a prompt for us to type something into the computer, and the computer can act on that single command, or the command can ask it to start a larger program with hundreds and thousands of commands in it. If a single command failed, our feedback was immediate, and usually the failure was located somewhere between the chair and the keyboard. The syntax - the organized system of how a computer expects input in this case - can be tricky to memorize, but if needed we can also ask the computer what the syntax it expects is.  

My personal all-time most common ones were "fdisk /? and chkdsk /?" since you didn't want a catastrophic failure or a gigantic waste of time after messing up the syntax. Never hurts to check. 

As computing got larger, the need for standard libraries became apparent, since nobody wanted to reinvent the wheel every time they built a program, and there are lots of functions that people wanted that you weren't just going to build into the hardware or rewrite into the program every time - but this is where a lot of computing starts getting difficult for the users - and this was about the time we had a big influx of people using computers that weren't programmers of any sort. Having a library interfere with the program running or the operating system because of an unforeseen interaction is what caused the infamous "Blue Screen of Death" in Windows versions 3.1/95/98 most of the time, leaving a using wondering when the Feds were going to come get them for performing an 'illegal operation'.  While the information provided on those error screens were of great use to people familiar with troubleshooting Windows problems, it left the average user feeling frustrated a lot of the time because you don't know if it's because there's something wrong with the program, the data, or the hardware (or any combination thereof).   Apple has done a good job historically in mitigating a lot of these problems by allowing fewer hardware configurations, but it can't protect them from the problems that happen subsequently.

Once you get to large scale distributed computing, you've almost separated the user interface from the program. The user interface is a little tiny part of the program that the user's machine deals with, and it gets data from and sends data to the actual program, wherever that may be. For most of us, a lot of the web is this experience. Facebook, Amazon, Google, Mapquest, eBay, and the list goes on and on. For some of us, the programs we use at work are like this. In larger companies, all of the ordering and inventory management are done on offsite computers that local offices just call in to. Your printer in your office can let someone halfway across the country that's in charge of your company's office supplies know that it's out of toner, and place an order that's automatically routed onto a delivery truck and email you a tracking number so you know when it's going to show up. Your checkout terminals at a store can tell a corporate warehouse when you've sold the last copy of the new Beyonce album or the last piece of furniture from the collection that you're no longer going to carry.

When these things fail, however, it usually goes back on the people. Nobody waiting at the customer service desk wants to hear "Well, the computer said we had one..." when it would be easy enough to go out to the shelf and check, and no manager wants the employees having to rush around and personally check every inquiry when they're spending big bucks on a presumably good inventory management system. Nobody wants to show up to an establishment with cash in their hand and the product there available and get told "Well, we can't sell it to you, all the computers are down. Not only can we not record the sale, but we can't be 100% sure how much to charge you for the item."  It's not because they don't understand anything about computing, since computing has infiltrated the lives of a large portion of the world, but it's because the old way used to work just fine and didn't have a failure mode like this. If the customer has cash, you can ring him up. If you weren't sure how much to charge, you could open up your ledger and either check the previous sales, or figure out a fair price from the cost of the item when it was purchased.

Now, though, we have 'middleware'. It's not the input, and it's not the output - it's all the stuff happening under the hood on the way from A to Z. That makes it the stage where you really don't want to have problems, and can't afford to have problems, because it's the sort of thing that can turn a customer away from a product or service fairly quickly. Customers are far more likely to be forgiving with an inexperienced employee standing in front of them than they are to be forgiving when a computer error makes a simple transaction for a couple of items take half an hour.

On a related note, I had a chance to try out a wireless mouse/keyboard combo from digital innovations just recently. The keyboard works well enough, even if I didn't entirely like the feel of the keys. The mouse had an odd habit where left clicks were not registering all the time. How many times can you left click with a mouse on a computer (oh, I'm sorry Apple users - just ignore the word 'left'...) to no effect and put up with it? Since it's a wireless device, you wonder if there's an issue with where the receiver is placed, but then you remember that you were typing just fine a second ago, and rolling the scroll wheel and moving the pointer just worked. You think, could it be the batteries?  But there again, the other things were working. Maybe you hadn't pressed firmly enough? If you felt the 'click', you would think that you had. I wasn't even going to address the issue of drivers, since I'm not sure that it had asked me to install them in the first place and Windows rarely asks for them for basic functionality any more. (A left click counts as basic functionality, right?) Each of the kids had tried it on their machines (one XP, one Win7) with similar issues with the left click and no other issues. I thought it would do better or fail entirely on my Ubuntu machine if it really were a driver issue, but it exhibited pretty much the same behavior. Everything worked find except the left click. So, it's probably a mechanical failure and we'll have to tear it down and see if we can fix it. It's not going to get much use in the meantime, though. I don't actually remember having this sort of a failure with a mouse before.

After switching keyboard/mouse setups around a bunch of times in the house to get everyone to try it out, I ended up short on the Linux machine again so I found something that I really like that was only $30 (and I'm using it right now.) It's the Logitech K400r, which is a wireless keyboard that has a trackpad where the number pad would usually be. Ubuntu didn't have any issue with it at all. The track pad is smart enough to know if you're using two fingers, so you move the pointer with a single finger, but scroll with two fingers, similar to other multi-touch devices. It also had no problem doing the 'zoom' in the browser gesturally. My only actual complaint seems rather petty in that the right Shift key is located in a strange spot and I've hit the up arrow by mistake quite a number of times. 

One of the other unusual features is that in addition to tapping on the track pad and using the dedicated left button on the bottom of the track pad, there is a button at the top left hand corner of the keyboard above the escape key that also functions as the left mouse button.

I guess somebody realized how important it was for that to work.

No comments: