[drupal-devel] A collection of usability problems
Richard Archer
drupal.org at juggernaut.com.au
Fri Sep 23 13:10:00 UTC 2005
I wrote this up earlier today, and although Dries has already identified most of the areas I have problems with, I'll post it here anyway in the hope that it offers some insight into the way someone new to Drupal approaches the task of learning and working with it.
I'm a web site developer and I'm trying to set up a system where instead of building and maintaining a static HTML site, I build the site in Drupal and then hand it over to the site's owner to manage. The "manager" would be a CEO, sales manager, marketing manager or receptionist depending on the size and type of the company.
I must admit, I'm finding Drupal's admin interface and usability to be a real problem. I myself can work out how to do everything, but I am not at all confident that the manager would be able to maintain the site in the long run.
In the thread http://drupal.org/node/31896 gpdinoz offered the suggestion of setting up a manager role and making custom blocks to hide much of the Drupal interface. While this may solve my immediate problem and allow me to roll out a Drupal-based solution, I really do stop and wonder whether I should really adopt a system which needs to have much of its interface hidden from the user.
Here's a run-down of my system requirements, sorted by priority:
* Easy for the site owner to maintain the site
* Search Engine Friendly URLs (URL rewriting)
* Placement of images on the page with nice formatting
* Site navigation is automatically updated as new content is added
* Some sort of wysiwyg formatter, ideally cut/paste from Word
* Contact form to email and database
* Allow file downloads from pages (e.g. catalog.pdf)
* Automatic syndication (RSS) for news items only
* Bread crumbs with the option to hide them.
* Minimal additional features (to keep it simple)
* Additional modules which can be enabled if needed
After installing Drupal, the first thing I did was to try to base my site structure around the Taxonomy system. This looked ideal for managing the menu and breadcrumbs. Unfortunately Taxonomy in its standard state is lacking some features and even after installing the patches and additional modules discussed on the GreenAsh site I decided that the process of creating vocabularies and terms and then having to create the content and then link it all together would be completely impossible for a CEO to cope with.
At this point my experience with the Admin interface had been so frustrating that I actually dismissed Drupal as a candidate for my project and went and installed and tested a bunch of other CMS systems... but eventually the promise of the power and flexibility of Drupal lured me back.
This time I used only the page and story modules. Page to be used for the static pages in the site and with attachments enabled and "post information" disabled. Stories to be used for News and have the date and author "post information" enabled. Ideally, as Dries has identified, the Create Content page for each node would have the option of hiding the post information in the same way that User Comments can be disabled. But there needs to be a way of setting the default values by content type. Currently the "display post information on" option is hidden away on the theme configuration page, but this probably belongs on the content>configure>content_types>configure page (settings>content_types in HEAD).
While we're on the issue of Theme Settings... this area of the admin interface is in dire need of attention. Hardly any (none?) of the options in there are relevant to a theme.
Logo... should be moved to the ?q=admin/settings page. Name, Slogan, Logo. They all belong together. And favicon in HEAD belongs there too.
Toggle Display... likewise, this all belongs on the Site Settings page.
Primary and Secondary links... where do I start? Almost everything about this feature cries out that it is still alpha:
- The settings page where these are configured contains a warning and talk about incompatibilities.
- I don't want to see a textarea full of HTML code (addressed in HEAD but now I have less control over the layout).
- The "I need more primary links" checkbox is a kludge. The rest of the Drupal interface has "add" and "delete" and yet this feature has a "more" checkbox!
- "primary" and "secondary". Straight away it seems that this needs refactoring. What if I only need one links section? What if I need three? What if I want to give them more meaningful names? There should be a way of adding and deleting these link sections as blocks.
- The content of the link "blocks" should be managed through the create content page like menu_otf.
- The link blocks should be positioned on the page through the Blocks admin interface.
So now I've moved all the options out of the Theme configuration, what would I actually expect to see when I clicked on "themes" in the admin menu?
- the ability install new themes
- a way to enable/disable themes
- and to set a theme as the default for the site
I would also like some way of customising the colors of a theme through an admin interface and that would belong here too.
As Dries has indicated, the menu_otf module has been merged into the menu module. This is great as it will allow my site owners to manage their navigation panel(s) through the same interface they manage the content. I would like to see the settings panel and the jjeff patch also included in this module to make it so much more useful. Allowing the user to control the order of their menu through the Content interface is essential.
The built-in upload module does not allow comments and titles to be added to files. This is included in the attachment module (which requires one of the file management modules) but I think this is should be a core feature. I include this "feature request" in a usability discussion because without this functionality in the core module I need to install the attachment and filesystem modules, increasing the complexity of my sites and therefore reducing the usability.
There is a good deal of confusion with terminology used in the path module. On the Create Content page the heading is "path alias". You then specify an "alternative URL" but are then warned about the "URL alias" not working. It took me a good while to work out that this was all talking about the same thing and that the "url alias" admin menu option was managing the path module. I'd be happy to see this all changed to "friendly URL" throughout (including the module name) because the only reason to use this module is to make your URLs friendly to both humans and search engines.
...Richard.
More information about the drupal-devel
mailing list