An interesting problem with an e-shop

I wanted to order something from a major Czech computer e-shop. When making the order I chose online payment as the payment method, was redirected to my bank, paid the order and then … nothing. My money was transferred and no order got created. I was without my money and without any order!

I guess the problem might be caused by security features of my Web browser preventing leaking information from the payment portal back to the e-shop. If this speculation is true and it wasn’t just a very weird random error then there are two interesting observations:

For first, the order is created only after successful payment. Definitely not a good engineering practice.

For second, user client assistance may be needed to create an order after successful payment, in addition to internal communication between the bank and the e-shop. It’s more speculative observation but in case it applies it indicates other stupid engineering decisions.

How did the story continue? My situation was covered in the e-shop FAQ so I followed their instructions. After writing three e-mails to their hotline about the problem my situation was finally acknowledged and they promised to check and handle it. After next three hours my payment was assigned to a new order and later on the goods was sent.

Persons on the hotline were helpful but communication with them revealed other technical issues. Their e-mail/ticket processor cripples e-mails sent in plain text. Moreover it apparently can’t handle forwarded messages inserted as MIME parts and discards them. The staff probably doesn’t have (easy) access to previous communication related to a given ticket. And communication related to a single ticket was handled by different persons each time. All that makes problem handling a bit more complicated and frustrating than needed for both the staff and the customer.

Finally, my previous experience with the e-shop is that just browsing their Web pages results in occasional errors.

I’m not going to make online payments at the e-shop again. I can choose offline payment instead which is basically the same except that I make the payment only after the order is actually created and that I have to copy the payment data to the payment form myself.

To be fair, the e-shop is not as bad as it might seem from my story, it works well most of the time and I’ve made several orders there without any problems in the past. But the observed problems indicate something.

We can be frustrated at our jobs by various constraints hurting software development and resulting in misfeatures of the software we make. But even a big and profitable computer e-shop runs on a software of very questionable quality. Not counting unofficial horror stories about software problems in banking or accounting systems. Many people here could experience embarrassing problems on Web portals of multinational phone operator companies with excessive profits and no shortage of money. There are well known stories about failures of software ordered by the government. So it’s difficult for any institution to obtain non-trivial working software. It’s nothing surprising but I’m still sometimes surprised by the level of stupidity of particular engineering decisions and processes in expensive software.

Using Firefox

I’ve been using Uzbl Web browser for a couple of years. But I’ve recently switched to Firefox. Why?

I was using various Gecko based Web browsers before switching to Uzbl, most notably Conkeror. Being annoyed by Gecko problems, switching to a flexible WebKit-based Web browser was a big relief. But things have changed through the time.

The first problem is that I’ve actually never managed to fully utilize Uzbl flexibility. Uzbl hasn’t become popular enough so far to get proper mainstream support so the user ends up basically in a do-and-fix-it-all-yourself situation. This is time consuming and I couldn’t catch up.

The other (and more important) problems are the current Uzbl/WebKit limitations. The number of problems with Web page handling in Uzbl has increased recently (for reasons unknown to me) and I’ve been using Firefox as a backup browser more and more. So when I started to experiment with display color management, which is not supported by Uzbl at all, I decided to try using Firefox as my primary Web browser. Why not to take relief from Uzbl/WebKit bugs and enjoy the Gecko ones again? 🙂

I’m positively surprised by Firefox so far. I can see a big progress. Firefox works well enough (although not perfectly) and there are many useful free software add-ons available. The add-ons are crucial, I couldn’t use Firefox without them as its basic functionality is too limited. But with a few basic add-ons Firefox looks like a relatively comfortable, stable and secure Web browser.

Buggy bug handling

I’ve experienced an especially nasty MythTV bug. It took me significant effort to diagnose the problem and to find the corresponding place in the source code. I decided to report the bug. Looking at the MythTV BTS I’ve found the bug has already been reported but without further explanation and without any attention from the developers. Although I didn’t have a patch I could provide a hint to solving the problem. I was careful enough to proceed with reading bug reporting instructions, stating I should post further comments on bugs to a mailing list rather than to the BTS. So I looked for the mailing list address (not provided in the instructions) and sent a mail to the list providing clue about the given problem.

I’ve received a reply explaining that I’m not on the list and so my message is awaiting moderator’s approval. Well, I can understand that. But what I can’t understand is that my message hasn’t been passed nor rejected so far, for more than 3 weeks. I suspect the moderator’s queue is simply ignored. If it is so then it is impolite to bug reporters and it harms bug fixing. Although I could subscribe to the list, disable incoming e-mails (I’m not interested in the list at all) and send my message again, I’m not going to go through such obstacles just to send a single hint. Free software projects should encourage cooperation and welcome bug reports instead of requiring unnecessary registrations from occasional bug reporters. Too bad it isn’t always so.