4 changes that would make WordPress even better

Starting with the HTML editor, there are several changes I’d make to WordPress.

I like WordPress. It’s easy to learn, makes developing standard-style blogs quick and simple and has a huge range of plugins and themes to integrate into websites. The back end is modern, easy-to-use and substantial new versions are released every few months.

The developers take a democratic approach to new releases: fill in the survey to register your preferences. I’m not sure I agree with this development by vote: I’d prefer the experts to use their knowledge to provide us with an improved product.

Anyway, if I had any say in 2.8, I’d make the following changes:

Make the code editor a code editor

The HTML editor: hard to read as code, no p tags

The HTML editor: hard to read as code, no p tags

The current HTML editing option is poor. Really poor. It suffers from two major problems:

  1. It doesn’t use a monospace font. Consequently, non-savvy users aren’t sufficiently deterred from messing with all that technical stuff, while those who do want to write HTML have to untangle unevenly spaced text. Why break such an established convention?
  2. Line breaks are converted into paragraphs. In fact, the HTML view is really a nearly-HTML view. It is incredibly annoying to useĀ  mark up that discards the most basic HTML tag of all, while thinking about line breaks.

Captions are not alt text

WordPress handles images pretty well. One thing that confuses me is the way in which captions also serve as alt text. alt text is meant to provide a textual alternative to an image for readers using a screen reader. A caption does not necessarily serve the same purpose. Take this example:

Garamond is an example of a poor font for body copy

Garamond is an example of a poor font for body copy

The caption only has any real meaning if you can actually see the image. The alt text should read something like The alphabet and numbers set in Garamond.

Additionally, screen readers will repeat the same phrase: first as alt text and then the actual caption.

Make widgets contextual

Some widgets only need to appear on certain pages. For example, I have created a theme that displays a list of posts related to the current post in the sidebar; obviously, this list should only appear on individual post pages. It’s quite easy to code this using conditional statements, but there’s no solution for non-coders, while it would save a lot of time for those who can PHP.

Fine tune what users can see

Theme users often have different needs. Some don’t know what a theme (or a CMS) is, others can use HTML and custom fields quite happily. It would therefore be really useful if theme designers could fine tune what options are available to users when they hand their themes over.

What do you think? How would you improve WordPress?

Comments

  1. I think making widgets contextual would be a great improvement. I’m envisioning two checkboxes at the bottom of each widget giving you the choice to have a widget appear on “post” pages and everywhere else. Anything more complicated should probably be handled by custom PHP conditionals.

    As for pie in the sky feature requests, I’d like to see custom data/post types like you can get in Expression Engine or Drupal (with the CCK addon). I would also love to see on-page AJAX editing abilities, like you get when using Flickr.

  2. Leon says:

    Maybe there’d be a way of assigning widgets to top level pages as well as certain templates. It’d take some thinking through.

    This article was going to be called “5 changes…”, with your pie–in–the–sky suggestion as number 5. WordPress is still blogging software at heart; your suggestion would make it a full CMS. There are plugins that can help do this (and enable AJAX editing).

    The problem with adding custom data types would be that it would perhaps lose its simplicity. But that’ll be the big change—I wonder when/if it’ll ever happen?

  3. You’re right that WordPress would lose its simplicity if it added custom data types. Maybe that means it should be a forked project?

    The thing about WordPress that makes it attractive as a CMS tool is that it’s easy for non-technical clients/users to operate. If the WordPress team created a full CMS application, I’m sure they’d make it easier to use than Expression Engine, Drupal or Joomla.

    But since that doesn’t seem to be on the horizon, I’m still hoping that Expression Engine 2 and beyond will bridge the gap. Right now it’s hardly an intuitive tool for backend users.

    • Leon says:

      WordPress would lose its simplicity if it added custom data types. Maybe that means it should be a forked project?

      Or maybe leave as is and encourage developers to write plugins that provide additional functionality, a la Firefox.

      There are lots of differences, though: WordPress is getting more and more feature filled (check out the work that php wp_list_comments() does in 2.8, while updates tend to entail a lot more development work.

  4. Kaspars says:

    For contextual widgets you might try the Widget Context plugin.

  5. Leon says:

    That looks great, Kaspars; thanks for pointing me to it.

    And it’s quite easy to make your theme act in this way (although not with all the options your plugin offers): just register a widget area and call it something like Single page sidebar and then make sure that only single.php refers to it. If you’re using sidebar.php then you’d need to use some conditional code with is_page.

Add a comment