Sean Reiser

Recently there has been an interesting debate about Drupal’s user Experience and how it should be improved in Drupal 7. I was responding to that post and realized that what I was saying might be too verbose for a comment over there so I’m blogging my entire thoughts here and excerpting it on drupal with a link back. Actually, I fear this is too verbose for my blog, Were I normally post entries of 500 or so words, this is topping at over 1,000.

As I’m turning 40 this June, I realize that my days as a “young coding stud” are long over. It’s sad but true, except in retirement homes, the terms young and stud will never be applied to me again. I have however done a lot over these past 25+ years of coding and have seen a lot when it comes to the application development. My experiences with Drupal remind me of the first half of my career and this debate is similar to one I witnessed 15 or so years ago.

So, pull up a chair, sit down and listen to Grammpa Sean tell a story. It begins…

A Long Time Ago, On a Platform Far Far Away………..

xBase - Some Personal History

In the late 1980s, I started my professional career at Computer Associates, working on big iron in computer operations, help desk support and writing some JCL. Although CA was a powerhouse at that time, they focused on mainframe software. I knew the future of the industry was desktop computing. One day I found out that CA had purchased a company named Nantucket which sold a dBase compiler for PCs named Clipper. After a little positioning I got myself transferred to that team doing some support and some coding. Eventually I struck out on my own as an application developer writing apps in Clipper.

I know you’re thinking, “OK, What does this all have to Drupal?” I’m getting there… give it a moment, I promise.

Clipper and other dBase compatible compilers (FoxPro, Quicksilver, Flagship, Harbour and others all affectionally called xBase within that community) were interesting niche languages. The data and interface layers were rather linked together into a Mish-Mosh, which would give an MVC purist a heart attack but if you structured things properly you could develop and support applications quickly and easily. They abstracted many of the lower level language calls making it so a developer doesn’t have to write things like print drivers in order to get a job done. “Copy File.txt to LPT1:” would print a file (assuming that the printer was on LPT1:)

Because xBase sits somewhere between lower level languages (like C) and simple Desktop Database (like Filemaker) there was much confusion where it lived. There was a segment of hardcore developers who chose these platforms because they realized that could elegantly express business logic and quickly deliver applications to their clients. There was also a segment of people who were power users. They found that they could build programs through sheer will power. These might not be the prettiest programs but they worked and you didn’t need to understand the nuts and bolts of computer architecture to get them to running. The companies selling these language had issues that there were service dynamically opposed masters.

Any of this sound familiar to you? Ron Moore was right… all this has happened before and all this will happen again.

One year at a Clipper developer convention there was some contention between these groups. In one session, which featured a number of the product architects, there were 2 questions which stood out for me. Now remember this was the late 1980’s or early 1990’s so disk space mattered and the visual programming revolution really hadn’t taken off yet. We wrote code, pure and simple.

The first was from a big name developer:

A Clipper executable is huge! A Hello World program is over 300KB in size, a similar program in C would easily be only 1/10th of that. Can we expect to see something done to streamline Clipper apps?

The Dev Teams answer when something like this:

Yes, there’s a lot of overhead in Clipper Applications. The exe pulls contains many routines including screen, file, printer and database drivers. We would agree that if you’re trying to write professional “Hello World” applications, Clipper would not be the tool of choice.

A little later on someone asked:

When will there be a screen and database designer? Something that will generate code for me perhaps.

And the dev team answered:

We think that’s an excellent idea for an add-on product and would expect that a member of the 3rd party community to step up and look into that. If not we hear that Filemaker makes an excellent product for this kind of thing.

These 2 answers said “we know we’re a niche product and we plan on staying in that niche and build a better developer experience, if you need something outside of that niche feel free to enhance this product or look elsewhere”. At that moment it seems arrogant, but today I know that there are applications written in xBase languages still up and running 20 years later, so maybe this was the way to go. Sure, their front end have morphed into something graphical. They are now talked about in hushed whispers because what major bank wants to admit that their financial system is based on a 25 year old unsupported technology?

Drupal

Now you’re thinking, “Finally he’s going to talk about Drupal!”

Recently, I got to thinking about how I got into Drupal. I needed to build some tools to communication within a dev team, but didn’t have a budget. Since I couldn’t get a server for the project, I ran a LAMP stack in a VMWare appliance and setup a Drupal site. I needed a quick blog + wiki tool and realized that I had that out of the box with stories and book. Later on I needed to add OG. Any time I’ve had to play lead developer since then I’ve repeated these steps and have slowly fallen in love with Drupal (the second love of my Life, Clipper was the first).

Stepping back I quickly realize why I’ve fallen in love with this little drop. It sits in the same place, somewhere between Real Languages (like PHP, Ruby, etc) and End User Tools (like Wordpress). Because of this its a little niche and quirky. The community is the same mix of high end developers and power users. And, at the end of the day, the debates are the same because we’re serving the same 2 masters.

I can sense your patience growing thin, “Oh, this is great, but is he ever gonna talk about UX?” Trust me, I am, and I have been this whole time.

So the thread on UX is basically the same as the convention session from 20 years ago. I think the answer lies in that debate. Drupal 7 should be mostly about build a better development experience. From that easier to use admin tools can be built by the community at large.

Drupal and Wordpress

Often times in this process Drupal had been compared to wordpress as far as easy of setup and use are concerned. I’ve always found this comparison to be troubling. If you think about it, these tools are different beasts. Wordpress is a blagging platform that you can squeeze other things out of, Drupal is a development platform that happens to have blog built into it. In many respects we’re comparing Minivans and Mac Trucks. If people should are looking to blog and that’s it, they should be looking at wordpress. (I know this will get me in trouble). Why would you use a Mac Truck to pick up your kids from school (unless you’re the tetradeca-mom or have one really heavy kid). That doesn’t make Minivans a better vehicle, just better for picking up a reasonable amount of average sized children. I’ve often pointed out that it wouldn’t be a major task to write Wordpress in Drupal. The inverse isn’t true.

Drupal Terminology

OK, Drupal’s terminology requires some learning. Although, if you ever want to see a librarian drool tell them that Drupal allows you to implement proper taxonomies. The concept of a node is so deceptively simple that people don’t get it at first. And the blocks vs modules thing is always a battle with new folks. But anytime I’ve learned a new tool I’ve had similar issues. How many switchers have spent hours trying to figure out what the “Services” menu is on a mac? This is one area where we can improve and make life easier for everyone.˜

Drupal Setup

To be honest, now that I think about it, it surprises me that no one has written wizard-like install.php for drupal. Not just installation profiles but series of questions (Are you going to Blog, Do you Keep Pictures on Flickr, Home Many Static pages will you need, what are their names, do you want them in the menu, etc). The tool could then do the install for you. But I think that’s an effort that should be outside of core and D7. A separate distribution, perhaps?

Anyway I think I have gone on long enough on this. I’d love to hear feedback.