12 Hacks for Picking Web Apps

The world of web services has mushroomed in the past few years. This is great for buyers, except the vendor selection process has become more time-consuming.

You can easily build a comparison chart in a spreadsheet with feature comparisons, integrations, support and prices, but you’d miss the qualitative part of the story.

[Read more...]

Six Questions to Ask Your Web Developer About Technology

My morning’s reading started with a brief discussion on Reddit about the relative capabilities of two website content management systems, WordPress and Drupal.

There is no definite conclusion to that battle, but the prevailing sentiment is that WordPress is easier to learn and cheaper to build, and Drupal is more powerful. Excuse this oversimplification, since my topic today is a bit higher-level.

If you’re a business owner intending to build a new website, what should you first ask potential web developers about the choice of system that would power your website?

I’m only listing questions about the choice of technology package — not about the web developers’ business track record, design chops, cost, and familiarity with comparable clients.

The obvious first question, of course, is “Can the CMS do what we need it to do, now?”

Asking these additional questions about the technology will give you a better picture of the total lifecycle cost of your website, and the tradeoffs associated with each.

Six Questions

1. How extensibile is it? After you launch the new website with a given feature set, how easy will it be to add features later on? Examples would be discussion groups, a non-English language, user commenting, a blog, more social media integration, and photo slideshows. Most popular CMS’s have plugin code modules for these features which make future upgrades easy. But ask your developer to investigate how their choice of system will support of your future needs. This discussion would be most productive if you have a rough 24-month roadmap for your site.

2. How well does it support mobile users? Your website needs to look good on iPhones and iPads and Android devices. Does the CMS have a good reputation for supporting this kind of alternative display?

3. How much trouble will it be to migrate my data out of the system? Website CMS’s have a lifespan. What was cutting edge five years ago (e.g. Movable Type, PHPNuke, ColdFusion) is now functionally obsolete. At some point you will need to rebuild your site using a new system, and the portability of the data on your web pages has a nontrivial impact on the upgrade cost. The good news is that most of today’s popular CMS’s store website content in a database, which fundamentally supports data portability. “Flat” websites built by the likes of Dreamweaver are not as futureproof.

4. Will my marketing manager find it easy to make changes to the website? A well-designed editorial interface reduces the risk of mistakes, and reduces the incidence of support calls to your developer. Make a list of the content that you might need to modify on the website before asking this question. Note that if you intend to outsource all your website changes to the developer (or his delegate) then the editorial UI shouldn’t impact your decision much.

5. How big is the development community for a given CMS? Put another way, how many people are available to work on a given system? Your web developer may eventually disappoint you or get out of the business altogether, leaving you with a temporarily unmaintained system. If you have a popular CMS, then it’s more likely that you will find a solid replacement person to work on it. Success is a virtuous circle for software. WordPress is the leader on this score, since it built a broad developer base during its early years as a solid tool for basic blog sites. See this Google Trends chart for one measure of the relative popularity of CMS’s.

6. Does this CMS have a good reputation for security? No web developer will admit to offering an insecure CMS which allows your website to be compromised, but there is a question of degree. Generally speaking, the inherent security risk of a CMS decreases with its developer base. Linus’s Law says that, “given enough eyeballs, all bugs are shallow.” (Another benefit of success.) On the other hand, the most popular CMS’s are bigger targets and thus more inviting to the hacker community.

Bonus Issues

These topics are less critical to the choice of technology, but perhaps worth covering with your developer.

Cleanliness of code. The issue here is whether your CMS builds its pages with tidy code to save bandwidth and display quickly to the user. Drupal, as much as I like it, can produce giant hairballs of HTML & CSS on each page unless the developer is rigorous when building templates. On the other hand, throwing a little extra money per month at the problem (as I mentioned here) can alleviate the problem. I should add that rendering pages for mobile devices is an exception: you want those pages to be lightweight. A good modern CMS should be able to build mobile-ready pages with a more limited set of markup.

Search Engine Optimization. While SEO is obviously important for most websites, the differences between the major CMS’s in their SEO-friendliness are either marginal or overshadowed by factors like your domain name, the quality of your content, the number of inbound links, and site speed.

Accessibility for viewers with disabilities. This in practice usually means legally blind people with screen-readers. See here and here for more.

Don’t Get In the Weeds

Addressing all these issues will help you make a better choice of back-end system for your website, which reduces your total cost of ownership and makes customer acquisition more efficient. These technical questions may also sharpen your online marketing plan itself.

Yet the technology choice shouldn’t outweigh the business issues, as pointed out by the fellows at this web agency. Choose a web developer mostly based on trust, track record and cost.

Making Website Tweaks Easy

A recurring theme for 2010 is the increasing availability of web tools that make effective online marketing more accessible. Hot categories include a/b testing, mobile website maintenance, content management systems, and the interoperability of social media tools.

Yesterday I found another modest, but elegant, service that fits right in.

Sweaver is an new add-on for the Drupal CMS that dramatically eases the pain of making visual changes to your website. (As compared to content changes; that should be easy or you need a new site.)

Watch a minute of the developer’s video – begin at 0:45 or so.

Granted, sweaver isn’t an original idea. There are other visual website builders around, and it’s quite similar to the CSS editor in Drupal Gardens. But sweaver is built for one of the top three content management systems, and in good functional shape. It’s also free and appears to have the active support of a stable contributor. I love it.

The important point here is that visual tweaks are becoming less costly in terms of money and time. Either they now can be done by a less-expensive person, or in less time by your existing web person.

Drupal module for tracking attachment downloads per-user

Not long ago I built an extranet for a client, which was a secure repository of documents. The client wanted to know which files were being downloaded by which users, but Drupal didn’t offer that out-of-the-box. So, I had this very modest module written by a nice fellow in the UK.


Untar, upload and install as usual. Then you’ll be able to see something like this:


Your download method has to be set to private, and it’s only for 6.x.

I’m not putting this in contrib at drupal.org because I’m not a developer and can’t maintain it. Sharing it here is my small thank-you to the Drupal community.

If you like it, I’d appreciate a link or a tweet or a follow.

Importing Content Profile data in Drupal

A short post, illustrating a gotcha I encountered while importing Content Profile user data in Drupal.

Scenario: You’re building an intranet or extranet, and want to load their users into the system. First use the User Import module. To load their Profile data (e.g. company, mobile#), go for the Node Import module. You are aiming to import user data as a node of type “Profile”, associated with the user.

You might encounter this error:


Here’s the fix, which is one of the eight steps in the Node Import flow:


“Username” is in your .csv file; it’s the username of the already-imported user. Set that to be the “Authored by” value. You want that person to be the author of the Content Profile, so it’s associated correctly with the user itself.

If it’s not checked, Node Import thinks that you, the admin (uid 1), would be the author. That’s why it complains with the above error.


Migrating from Movable Type to Drupal

Movable Type was my content management system (CMS) of choice in 2004. Installation and configuration was easy enough for a non-developer like me to handle, and I had a couple of reliable business partners for coding and design projects.

However, the open-source movement captured interest and attention of the development community, and Movable Type began an inexorable slide into comparative irrelevance. (Evidence at Google Trends.)

One of my clients has several Movable Type websites, and this month we’re moving them all to the very solid Drupal platform. All but one of the sites have a manageable amount of copy, making it  feasible to copy and paste the content. The last one had 181 blog posts, which demanded an automated solution.

This post illustrates how I moved the blog content from Movable Type to Drupal.

Three Methods

I found three ways to migrate the content, in decreasing order of elegance:

  • Use the new Feeds module to scrape an RSS file and publish nodes.
  • Use the Import Typepad / MoveableType module, which imports nodes in a batch from an MT export file.
  • Migrate first from Movable Type to WordPress, and then use the WordPress Import module to get the content into Drupal.

I wasn’t sure if Feeds would import the blog’s comments along with the posts, and the two-step option seemed clunky.

Down the Import Typepad / MoveableType path I went, and in the process I learned:

  • The 6.x version doesn’t work. So I installed Drupal 5.x with the 5.x version of the module, and then upgraded to the 6.x branch.
  • The module expects to import into a content type called “blog”. Any other name will prevent you from editing the nodes. For simplicity, I wiped out the other content types from the 5.x install.
  • Set up your Drupal categories in advance. Taxonomy CSV import/export worked for me.
  • Set up your users in advance, since the import module wants to map the Movable Type author to the Drupal author.
  • Tidy your markup tags and oddball ASCII characters in the export file, before you do the import.
  • Also in the export file, change PRIMARY CATEGORY: to CATEGORY:. Honestly, I don’t know if this was necessary but it took less time to do that than to type this sentence.
  • Drupal 5.x is fast, compared to my contrib-laden installs of 6.x.

With all that in place, kick off the import in your 5.x install.

You may be greeted with an “ERROR 1 State = 5″ error code at the top of the review page, and this charming screen after confirming the import:

Yet a visit to the admin/content/node page brings relief:


So the import does work.

Adios, Movable Type.