A couple days back, I sat down to do my Christmas shopping. I'm not a big fan of shopping, but I do somewhat enjoy doing shopping for this one occasion, if only because I know I can it all in one place: Amazon. Plus, I've put in time over the preceding months marking off ideas for what to get people. This means the process should be relatively quick and painless. I went about gingerly putting items in the basket, along with my co-worker who decided now was the time to get hers done as well. I decided to get a Kindle for my aunt (shh...) and there was a checkbox for getting the power adapter and a $10 gift card for books for it so I went ahead and got those as well. We were going along at a good pace, and my co-worker finished up her shopping before I did. Finally, about 3 hours later, everything was ready to go with about $500 of gifts in my basket ready to be bought and sent. I put gift notes on each item, and proceeded along to what I thought would be the finishing step.

Then, the problem began. You see, I had previously bought a sizable Amazon gift card for myself so I could have the money set aside in the account and ready to go for this, and so it was when I checked my accounts page. However, as I came upon the final checkout page, I was told I did not have enough credit to make my purchase. I began to get worried, did my money somehow disappear? Having been an early adopter, I've used Amazon for many years, and I remember the days when there were problems. However, lately everything had been so smooth that I didn't anticipate any problems here. Yet, here was the screen I was greeted with (well my recreation of it later):

The first thing I did was try to click continue, which I could not do, it was disabled, then I hovered over it, which produced the image you see above. I scanned along the payment options trying to figure out what the problem was. No dice. I opened a new tab and checked my balance, yep still plenty of money for the purchase. So, what was going on? I went back and deleted any items not shipping from Amazon from the order. Still nothing. Finally, I gave up and clicked on help. At this point, I was close to just giving up and resorting to offline shopping. However, the wait for help was only 3 minutes according to the ticket, and sure enough it only took 1 minute for the customer service representative to appear (a nice Indian man by all appearances and name). As usual with Amazon support, and most support these days, I braced myself for patience, as the language and cultural divide produce some lengthy conversations to explain problems to someone who is usually halfway across the world. Eventually, after providing a fair amount of details, he found my order and discovered the problem was that I had the $10 gift card for Amazon in there (remember earlier when I put it in as part of my Kindle purchase). I did not have a credit card attached to my account, and one cannot buy gift cards with other gift cards on Amazon, so the system was refusing to let me pass without entering some more payment options. All that is fine, except there is absolutely no visual indication of that anywhere on the basket screen. Look again at the screenshot, could you tell before that it was the problem? Can you tell now? This problem could have easily been avoided with a very simple message box indicating which item in the order was holding up the purchase.

So, I finished my order, got the confirmation, and chalked it up to the trials and tribulations of online shopping...but then something happened today. I was standing in line at the grocery store, having popped in to grab one item. I deftly maneuvered through the holiday crowds and into a relatively short express line. The cashier was finishing ringing up a couple, and I was two people back. Then, disaster struck. There seemed to be a problem with the couple's purchase not going through. A little observation, and it began to become clear they were short on credit for finishing the purchase. But why was this? There was a discussion, and the acronym "EBT" slipped out, which made me realize this was a foodstamp purchase. I'd seen my fair share of people trying to buy alcohol or cigarettes with food stamps and coming short and puzzled when they couldn't. That was an obvious user failure. However, in this case, the couple had all food items, so what was the problem. There was some shuffling about, more questions, and the cashier ran over and asked a few other people. The couple began looking for things to take out of their bag. The guy was thinking, and he removed two "hot" food items, a roasted chicken and something in a paper bag. The cashier ran over and got a key/fob, ran it, and bam the order was ready to go. Apparently, one could not purchase "hot" food items on an EBT card. What a silly problem though! Had the register simply indicated which items were not purchasable by the card that were on the order, then everything would have taken maybe 1 minute as opposed to nearly 15. The register was not content with its confounding yet though. The next customer stepped up and the cashier began to slide his items along the register. Then, a problem. There were small onions to be bought, but what code were they? "Shallots" the customer helpfully supplied as the cashier began to pull out a list. As I glanced at the list, I noticed the font was about 6pt, but bold for dubious reasons. The headings were slight larger at about 8pt. So, there's this huge list of all vegetables and such and the cashier spends 3 minutes thumbing through it, and then gives up, yells over to another cashier, who helpfully rattles the number off the top of his head. What a terrible design! The cashier should have a nice flipbook with pictures of the vegetables and the codes below them in big letters. Humans can easily visualize and absorb pictorial data of this sort, at least much easier than thumbing through long lists of small print. The order goes on. Finally, 20 minutes after having stepped into the line, I'm at front and can make my purchase and leave.

There were numerous design failures in the cashier line, but even those could have been avoided had the lines themselves not been poorly designed as well. A great dissection of shopping lines found here shows how among other things, a single line leading to many cashiers would have been far better than the typical grocery store setup I had fallen into. At the very least, I would not have had to wait 20 minutes (or was it 10 and my perception was just off?).

So, it's not just the online world, but the brick and mortar world too where design can greatly affect a purchase. It's not just others either, plenty of people contact us at Kiva and complain about things that are too complex on the site. Granted, at least here I know we're working to fix areas of complexity :)

So, at this point, I know what you are thinking: What does this say about Drupal? Well, for one, Drupal is often overly complex. Everyone who works with Drupal knows this and a big part of Drupal 7 and Angie's work on it was reducing complexity. However, when further steps were taken to further simplify core by removing a number of modules from it they were met with a lot of resistance. Resistance on issues such as these tends to fall into three modes:

1. What problem? There isn't really any problem
2. There is another way to solve this problem
3. We could do things as they currently are, just better

The third one is especially relevant when thinking about the issue of support on Drupal.org. The forums on d.o. suck and everyone knows that. However, there is disagreement on how to fix that. Fortunately, as I have previously written about , some enterprising souls went and created a Drupal site on StackExchange. This was such fortuitous event! I had previously asked and answered some Drupal questions on StackOverflow but having a site dedicated to it would make it very quick and easy to find the right questions and answers. Now, we just needed to point users to this place to find answers simply as StackExchange had done a very good job of making an easy to use Q&A site. They do one thing, and they do it well. However, again there was vast amounts of opposition to moving the support forums to instead be the Drupal StackExchange site. Some key gatekeepers on drupal.org don't ascribe to the "do one thing and do it well theory" but instead to the "Drupal can do anything" theory. That's fine, I've fallen into that trap before, thinking Drupal is my hammer and I can solve all problems before me with it. However, just as a good programmer will eventually branch out from their first language and come across others for different use cases, it behooves Drupal maintainers and developers to realize that it doesn't solve *all* problems in the *best* way. It's the old adage, "use the best tool for the job". Yet, we don't seem to want to do that as a community. Instead, we continue to fall into the mindset of, "We could do it better." Given enough time, I believe that. However, time is a limited resource, and the web is moving forward at lightning speed. Why dream of utopian futures where we eat our own dogfood for everything when we can have things better now?

Of course, this doesn't just apply to Drupal. I've had to fight these battles at work on occasion. The classic battle is asking to allot time, perhaps 2 weeks, to fix a piece of software that we only plan to use for the next 6 months. Many people, and they would not be alone, would think it foolish to waste two weeks on something that is most likely going away soon. However, there is a problem with that line of thinking. Humans, or at least most of my fellow humans that I've had the pleasure to work with, are bad at meeting deadlines. Dan Ariely discusses this at length in his second book, The Upside of Irrationality: The Unexpected Benefits of Defying Logic

We can look back at Drupal 7 and see the timeline lesson as well. Dries originally called for a code freeze that would go into effect September 2009. However, this date slipped, as did the release date. Many of us were expecting a release in early to mid-2010, however weeks of delays rolled into months and eventually it became "we will release when the critical bug queue drops to 0". Even that took some magic, but we finally shipped in January of 2011. Now, this isn't to say that delays in scheduling are all bad, indeed it helped to make Drupal 7 a better product. However, it's important that we realize just how long things can take and not to put simple time estimates on projects in order to justify building our own as alternatives to established solutions. Surely, the people who built StackExchange dropped many thousands or tens of thousands of hours into making a very good product. Is it really worth man-years of work, literally taking weeks, months, or years out of people's lives, just so we can build something in Drupal? I don't know if StackExchange is the best solution for support, but I do know that I don't agree that we should focus on solving that problem. The Drupal Problem is to create a simple to use product that millions of people will use to create wonderful websites. There are many different directions being taken right now on how to do just that, some of which, such as the Snowman project, are being used to justify keeping complexity in Drupal. Yet, the Snowman project appears to be moving quite slowly as well, and I don't know that there is agreement in that it will be a real solution to a real problem. Only time can tell with that one. However, when it comes to support, we should leave it up to others who know how to do support to do it for us, especially if it can be done for free. Maybe that means UserVoice, maybe that means StackExchange, maybe that means something entirely different.

It's not just support that we have to take a critical look at, but many problems that we are trying to solve. Let's always ask ourselves, "How can we solve things simpler?". In the case, where we don't know what the simplest solution is, let's let the users decide. They will take the path of least resistance. This should especially be true when thinking about whether or not a module should be in core. Look out at the real usage numbers for contributed modules. If we can see that many users figured out how to download and use Homebox, is dashboard really necessary? Maybe the real problem with thinking of simple core is not, "What needs to stay to make it easier for new users to create a site in Drupal?", but rather "How can we make it easier for new users to get the contributed modules (building blocks) they need to make an awesome site with Drupal?" Personally, I think we still have a ways to go in making the process of adding modules to a site simpler, and with some ingenuity I bet we could come up with some really awesome solutions.

As always, feel free to tell me if you think I am completely off-base, I usually accept criticism graciously. I'll note that I've temporarily turned off Mollom, because for the past few months it has done very little to stop spam. Perhaps the paid version does a better job? Rest assured though, legitimate comments will make it up as soon as I get the chance to approve them.

Tags: Drupal Planet