For instance, Inline Google Spreadsheet Viewer is still a perfectly valid plugin, but hasn’t been updated since September 2010, has WP_DEBUG as true at the top of the file, and needs user input sanitization for it to be secure. These things I’ll fix for my own site; there should be an easy way to contribute these fixes back to the community.

Context: Non-technical users are generally only subconsciously aware of usability issues. Technical users know how the magic happens. When actively using their own software, they have greater visibility into usability issues, and what steps could be taken for improvement. In helping teach the Newbie workshop over the last two days, I’ve relearned just how painfully complex it is to learn how to publish with WordPress. If those who build or design with WordPress also published with WordPress on a daily basis, we’d have that much better software.

As an example: it would be awesome of all of these WordCamp San Francisco presentations were posted as WordPress galleries instead of as PDF or Slideshare.

“Each plugin speaks with it’s own voice,” says Wes. Sometimes they can produced cluttered and confused experiences for your users. The framework they’ve chosen as it relates to plugins is use, patch or build.

• “Use” means they install the plugin, activate it, and it’s live. They may make minimal modifications with CSS, but it’s generally fine to go out of the box.
• “Patch” means they may make minor modifications to the codebase, through hooks or actually changing core, and then try to push the improvements they made back upstream.
• “Build” means they take ideas and inspiration from other options in the WordPress plugin directory, and roll their own plugin.

Example: Navis Slideshow

The Argo team decided to build a photo slideshow plugin that leveraged WordPress’ built in gallery functionality, and looked and worked as a standard slideshow.

Their functional starting point was the Slides for WordPress plugin. Wes downloaded and activated the plugin, and made basic presentation tweaks with CSS and Javascript. Unfortunately, there were other behavioral changes they wanted too. They thought about patching but then realized it would too much work. So they went around to rolling their own plugin.

Two improvements worth mentioning are conditionally loading images and Javascript. For the first, the problem to solve is reporters that like 60+ image photo galleries. If you load all of these images on page load, it increases your bandwidth costs and load time for end users. The solution is to reference the image URLs in a storage div, and then only load them when the user is getting close to viewing them. For the second, there’s a global variable on every page load for marking whether a WordPress gallery was included in the post. If so, the Javascript gets added to the footer.

Improvements included reducing the footprint of the plugin from 39k/895 lines to 8k/244 lines.

Example: Jiffy Posts

To make their content more engaging, Argo wanted it to make it easy for their reporters to embed rich media. Initially, this looked like Embedly or oEmbed but they didn’t want to cede control of what was embedded to the content provider.

Solution: A custom post type called Jiffy Posts. Reporters could create a new post with a title, short comment, link to the referenced media, and can include source attribution. Doing it this way, instead of having reporters embed rich media in the post, ensures there’s presentation consistency from post to post and content type to content type.

Ultimate takeaway: The decisions and opinions of plugin authors can directly impact the user experience of your website. Think about this more holistically, beyond just reviewing whether the code is clean.

The slides from the presentation are available on Slideshare and download as a PDF.