Enjoying the Experience, Part Two

Okay I promised it yesterday so here it is, the followup.

I posted that information hoping to give some background on why I feel justified in mentioning this particular pet peeve. Hey, I did say that it would loosely tie to that experience issue...and it does. Every time I run into this issue it kind of leaves me peeved.

I was recently involved in troubleshooting an issue with some software in which part of the problem was tied to printing. In talking to the tech person, who also happened to be one of the developers of the product (good hint this is a smaller software vendor, but it's a mixed blessing...yes, you get good support from someone who knows the intimate details of how the software goes about a task to accomplish a goal, but you also have to deal with people who are juggling fixing bugs and issues with your incessant neediness to have a product that works and your subsequent whining when it doesn't). I'll call the developer Carl.

We had a printer, shared from a Windows print server, set up on the computer. Try sending the print job and it acted like the program was getting "stuck" and the program would hang. Killing the application would corrupt some data files. Real pain in the rear issue.

I looked at the logs on the printer server system and it was seeing the print job; it listed the username under which I was logged in and a document called "no name" followed by a job size and then it said it printed zero pages.

Huh?

"The server sees the print job and it has a size with it, but said the job was zero pages long. Could there be an embedded code in the print job that's keeping the printer from rendering it?" I'd run into issues like that before with bad PDF files and certain print jobs on particularly buggy drivers.

"No, that's normal. We don't use the Windows GDI or anything like that to render the print job. We send it straight to the printer in PCL."

Uh oh.

Carl is basically telling me that their print system from their application is bypassing Windows for certain things...I have to have the printer set up on Windows, then open their app's settings, select the printer, at which point their software is doing something to render the print job and send it to the printer rather than a "good" application which hands the print job to Windows and says, "Here, print this," and Windows runs off giggling to do just that. A second system didn't have the printers installed that the application said it was pointing to in order to print...and the application worked on that machine.

Let me reiterate. Windows did not have the printer installed. But the application had it in the printing settings. And the application worked. Carl speculated that at one time the printers were set up in Windows and that's how the application got the initial settings and so deleting the printer from Windows didn't affect the application...

Adding to the confusion was the fact that despite Carl telling me their product doesn't interact with the Windows printing system, it was obviously doing something with it or else I wouldn't see it showing up in the Windows logs on the server. Going directly to the printer would bypass this step. What was showing up was goofy (it printed fifty pages, but the logs said it was a 0-page job. Figure that one out.)

Ugh.

This is where user experiences come into play. I get a bad taste in my mouth whenever a developer decides he or she knows better than the OS "way" of doing something and boldly leaps forward with their idea of how something should be done, everything else be damned.

One of the few things Windows did right was unifying the printing system for applications. In the DOS days every app that wanted to print had to include some set or subset of drivers and you configured each application to see your printer. If your word processor didn't support your particular printer or you couldn't find a driver for your word processor to see your printer you prayed that the word processor had a printer driver that was "close enough" to work. Then you repeated this process with your spreadsheet software. And any games that happened to print maps or scores. It was a nightmare at times.

Once Windows hit the personal computing scene every application could just include a library that allowed them to hand the job to Windows. Windows needed a driver to print, and from there it took over and did the grunt work. One driver! Not fifty! Yay!

But there were people who insisted this wouldn't do. I remember WordPerfect ported their word processor from DOS to Windows and it had its own printer spooler system. You printed, it handed it off to the spooler (their own stuff) which rendered the print job and then I think it handed it off to Windows to finally print. I hated having to troubleshoot wonky print jobs that would get stuck in their rendering engine or crashed because of some weird bug in their print system.

How does this tie to my previous post, aside from the fact that my experience with this WordPerfect architecture abomination left me with a bad taste in my mouth for other programs trying to go rebel with dazzling me in programmer cleverness?

Because I'm not entirely sure how the program at hand was actually working (the program I was just troubleshooting). The application had to deal with software that was really meant to run on "old iron"...mainframe type stuff. Basically this program was to take output from another application mean for human resources stuff and render, format, and print that to a printer system (confused yet?). To put it in simple terms I'm working on software that was a port...an evolutionary step with roots in mainframe computers. Non-graphical, probably. The culture behind such designs is one of "I don't wanna change and you can't make me unless I absolutely must," so all the software with roots in IBM mainframe-type systems definitely shows the heritage.

So maybe there's a good reason they chose to do something weird with the printing.

Maybe their programmers were just more comfortable playing with the file contents directly. Maybe they had source code on hand and just wanted to port the software to a Windows graphical interface, and never quite left that mentality.

But please, for the love of whatever deity you subscribe to...please stop trying to fight what few usable features Windows has. Or any operating system on which you're developing. They are there to make life a little easier for you and the end user, and it seems that almost every time someone comes up with some clever enhancement to the way things "should" be done, something ends up breaking and your clever little whiz-bang improvement becomes a detriment to the end user.

My user experience has been horrible with such schemes. Of course Carl would defend his decisions in the way he chose to code his contributions to the application...he's invested in the product. Others at the company he works in are equally invested. It seems that eventually developers are so close to their "baby" that any user having issues with things like this become regarded as morons or it's just a case that the user's computer is misconfigured; their system is an improvement on the crappy Windows way of doing things, after all! It's obviously my fault.

Developers totally lose perspective of what it's like for their users. Whether Carl had good reason or not for how and why this was implemented...aside from the fact that I was working to troubleshoot the issue as a system administrator, the reasons that he and his team did this don't really matter to me. I'm the customer. I just wanted to use the product. He can justify the design by all their meetings or directives or "it works for me" or even the voices in the heads of the development team. I don't care. What I care about is that I need those print jobs working and they're not.

Which means my user experience is leaving me with a really bad taste in my mouth for your product as well as your company name.

I had another issue a few years back with a certain point-of-sale company while consulting for a cafeteria. The company that was initially decided to get the contract...not my choice...put in a product that was experiencing issues with transactions to the database being unreliable. While troubleshooting I found that they were using Microsoft Access as the back end.

We were feeding data from about ten registers in different locations to this central point-of-sale system. And they were feeding it into MS Access. I'm not a database programmer or architect, but I never heard of this being a good idea.

The vendor wanted us to keep throwing hardware at the problem. It was obviously because we were short on RAM, our switches weren't configured to handle the traffic reliably, even power fluctuations were causing issues so they were having us put line filters and UPS's on various systems and equipment before finally someone...like yours truly...wrote up a nice long report on why the bottleneck was the way they built their system and there was no fix without replacing it. A replacement vendor was using a database based on Advantage, and later MS SQL server, and for the most part issues disappeared.

That vendor has a permanent black mark for making what, in my experiences, was a very stupid design decision and then trying to shove the problem onto us. Bad customer experience.

So keep these things in mind if you're offering a product and service. It can take a very very long time to make a loyal customer but only one bad experience to make an enemy who is very willing to share their opinions of your product with others looking to spend a lot of bucks on a product in your industry...