re:thoughts on Drupal 6.xx


Warning: Use of undefined constant the_modified_time - assumed 'the_modified_time' (this will throw an Error in a future version of PHP) in /homepages/45/d244356241/htdocs/lukevandeman/wp-content/themes/960bc/single.php on line 18
October 21st, 2009    

After working at an agency as their only online designer and developer, I spent some time researching a platform I could use for 90% of our projects. I finally decided on Drupal after experiences with custom built CMS, wordpress, joomla, and other systems.

What Interested Me the Most

  1. Open source – it was free to try, use, break and build. I liken Drupal to Mozilla, the modules to the add-ons, etc.
  2. Extensibility – with over 3,000 modules, great documentation and constant improvements from tons of people meant that things would only get better.
  3. Seperation of code, theme, modules and content – don’t touch the core, themes and subthemes, modules for one or mutiple sites, and all the content in the database, easy to back up, update, migrate, restore.
  4. I18N – I wanted to build sites that allowed for translation of both content and admin interfaces. Drupal offered robust value.

However, after a hiatus from Drupal after I left the agency, I began to miss building sites, hunting for Drupal help and stumbling thru their clunky, scroll-happy interface. Well, now I’m back, both building and bullying Drupal, but also thinking of things that could make the platform better.

My strength is in design and UX. While working late last night on a side project, I noticed several things that Drupal struggles to solve.

What Could Make Drupal (Even) Better

Installing Modules
Besides the time required to setup Drupal’s many necessary modules, there is also the problem of downloading, unpacking and uploading. In comparison, in the WordPress admin interface you can search, view, select, and install plugins right from one screen. Now I understand the security flaws involved with doing this on a live site, but while building from localhost, you still could easily access, download and update modules from the admin interface in Drupal. This would be an excellent feature that ramps up initial start-up time. I know that in Drupal 7, many of the most used modules will be included in the core, but given that this problem will always exist for any additional modules, and that Drupal 8 will surely add more modules to their core, I’d like to see this inclusion built into core sooner than later.

Fieldset memory
This is especially true when working with long pages like the modules page. Drupal should add a flag to the database for all fieldsets, and on a page save, keep the fieldset either expanded or collapsed depending on how the interface appeared on the save of that pages. This would eliminate a great deal of scroll and prove to be a more intelligent interface feature. Additionally, following the likes of the windows explorer save windows, the fieldsets could be triggered by a number of times collapsed to update their default settings. For example, if you close a fieldset and click save in the page 3 times, that fieldset would then be triggered to be closed by default now.

Naming and Wayfinding
There is a general inconsistency with naming across the core and modules of Drupal. For example in views, you can filter on Node: Node:Type but in the admin navigation menu, it is displayed as content management -> content type. This would be fine if it were isolated cases in little used modules and work flows. However, there are some many common work flows that represent this problem, but also so many work flows that you do only occasionally, not repeatedly, so you forget and are left with the failed user feeling not that of support from the application.

Save button
Countless times I would have loved to have an additional “save” button at the top of my page, much like gmail has the “send” button above and below the email frame. This would be an easy additional and greatly improve the in-and-out of pages and nodes experience.

Link thru
Drupal is certainly feature-rich. However, I feel trapped by using the admin menu. I do agree that it is better than the page click, page click, of the default left side admin navigation menu in core, but why not offer cross linking where appropriate. For example, if I’m setting up a content type and have added a custom field of a image and proceed to setting up the image properties and display qualities when I realized I haven’t setup my imagecache values that I want. So, I have to leave this setup process, then using the menus system, get over the image cache and set that up, then return to select the imagecache from the dropdown. Why does Drupal assume, or rather force a one way street to get tasks done? It may be easier to code and develop initially, but as time wears on, so too does the back tracking to run thru another short setup and then return to the task at hand. One example where this works perfectly is views. If you are logged in a on a node that displays a view, when you hover over the block, the view “edit, export clone” links handily appear.

What do you think? Do you know any workarounds or solutions to the above list? Leave your comments.

Leave a reply