WP Late Night Episode 2 recording tonight at 8PM EST

The WP Late Night crew is back for another episode! Tonight at 8pm EST Ryan, Brad (that’s me), and Dre will be recording their second episode of the video podcast LIVE! As always you can watch the recording on the WPCandy Stream.

Make sure to catch the first episode of WP Late Night (dubbed the Shame Edition) so you know what to expect.

If you have WordPress questions or comments to send in to the show, you can do so by:

• Commenting on a show post (like this one)
• Leaving a voicemail at (815) 322-WPLN
• Emailing us at wplatenight@wpcandy.com
• Tweeting using the #wplatenight hashtag.

We’ll see you guys tonight!

WordPress.org and .com join the SOPA protests with blackouts

Earlier today WordPress.org announced its participation in the January 18th protests against the USA’s Stop Internet Piracy Act (SOPA) and the Protect IP Act (PIPA). Earlier this evening the blackout went into effect, and will block access (initially) to all of WordPress.org including the Codex, support forums, plugin directory and theme directory. The blackout will be in effect for 24 hours.

For more about the acts and protest in question visit sopastrike.com.

But the blackout on WordPress.org is not unavoidable. Scrolling to the bottom of a page will give you a link to clear the blackout for an hour and continue on to the website. On her blog, Jane Wells explained that while she originally wanted to see the whole site blacked out, instead the WordPress.org team opted to make the blackout only partial for the sake of those who depend on WordPress.org:

The reason we did this instead of a full shut-down is that there are many businesses and people who help drive the independent web that need access to the WordPress Codex, forums, plugin/theme repos, and APIs. We wouldn’t want to penalize them in our protest, so we just made it impossible to ignore instead.

In addition to WordPress.org, Automattic’s hosted blogging service at WordPress.com has selectively blacked out its “Freshly Pressed” section, where normally visitors can find hand-picked blog posts across WordPress.com to read. WordPress.com users can also join the protest in a variety of ways by visiting the “Settings ? Protest SOPA/PIPA” page on their dashboard. If you blog at WordPress.com visit their explanatory post for more about how to add it to your site.

The plugins in use on WordPress.com are also available to WordPress.org users via the WordPress.org plugin directory. If you’d like to pick a specific one up, just visit the “sopa” tag on the directory.

WordPress isn’t the only large website out there that’s protesting in this way. What others have you heard about? Will you be protesting using your blog?

WP Late Night 001: Shame Edition

I’m excited to (finally, I know) post the recording of the first episode of WP Late Night, a production that myself, Brad Williams, and Dre Armeda put together. If you missed the live recording—and let’s face it, relatively speaking the world did—you can check it out now, lovingly crafted into a variety of media formats.

The video (yup, we recorded video for this podcast) is embedded at the top of this post’s page. Alternatively, you can listen to the audio only just after the jump. I’ll have an iTunes subscription available soon.

Episode 001: Shame Edition

In this episode (which is embedded above, and also on Vimeo and YouTube if you prefer), Brad and Dre and I discussed:

• The release of WordPress 3.3.1
• 10-year-old Jesse’s first WordPress plugin
• Dre’s tattoo
• Twenty Twelve
• WordPress.org’s recent improvements
• The Top 10 Reasons WordPress is not a Cult
• Mailbag: WordCamp sessions, speeding up websites, and WordPress security

We’ll be recording future shows live as well, so watch this blog for news about when to catch our recording.

If you’d like to get in touch with the show for the mailbag, or anything else really, here’s how:

• Leave a comment on this post, we’ll see it.
• Shoot an email over to wplatenight@wpcandy.com.
• Leave a voicemail for us at 815-322-WPLN.
• Tweet about us using the #wplatenight hashtag.

Gravity Charge will integrate with WooCommerce

Late last year we first learned about the next rocketgenius project called Gravity Charge. Carl Hancock, founder of Gravity Forms and rocketgenius, recently mentioned that he has already been in discussion with the WooThemes team about integration between Gravity Charge and WooCommerce.

I caught up with Carl about the new integration, and this is what he had to say about it:

Because Gravity Charge will have extensive and powerful content access control capabilities, one of the logical integrations would be to use Gravity Charge for controlling access to content, files and downloads and enabling WooCommerce users to use WooCommerce for the checkout process itself.

With those plans in mind from Carl, there’s no doubt in my mind that this is going to be a powerful and functional plugin, providing a great utility for e-commerce website owners.

NASA code site built using WordPress and Bootstrap framework

Recently NASA announced that it was launching a new Open Source section of its website: http://code.nasa.gov. This is just another step that NASA is taking to help make its code available to the public. The web team over at NASA looked at a number of content management systems available for the website. At the end of their search they decided on using WordPress.

To take it a step further, they ended up using the Twitter Bootstrap framework for building their theme. One really awesome tool that they get to use with this framework is something called “Less.” Less gives greater control over CSS, which allows for the use of variables and many other things within the CSS itself. Normally those kinds of things are not available in CSS, but Less makes that happen.

They also decided to use Super Cache as their caching mechanism for the site.

As I’m such a huge fan of WordPress, I can easily say they made a great choice and that I’m looking forward to seeing what they release on the NASA code blog.

PressTrends out of beta Tuesday, releasing plugin for users

George Ortiz presented at WordCamp Birmingham today, and announced that PressTrends will be coming out of closed beta this week on Tuesday. The public launch will also bring the launch of a plugin for WordPress users that will offer statistics and analysis based on information gathered by all sites tracked by PressTrends. PressTrends has been in private beta since November, serving statistics to selected theme authors and shops.

Based on the brief demo Ortiz gave (see the photo below) the upcoming plugin will track a site’s posts, comments, and active plugins. Based on performance, Ortiz said, he hopes that the stats will be able to offer bloggers tips for how to improve the number of comments and success that bloggers see.

Currently PressTrends works with only theme authors and theme companies, but as of the plugin’s release on Tuesday they will begin to gather statistics on how users are using their WordPress sites as well. The example of the plugin that Ortiz demonstrated (pictured just after the jump) showed a breakdown of the number of posts, comments per post, and plugins in use compared to the rest of the tracked PressTrends community.

The PressTrends API, Ortiz said, will also allow theme developers to track custom variables like theme options and shortcode usage, for example. Many themes nowadays will integrate a lot of shortcodes, and using Ortiz theme authors can discover just how many users are actually dropping them into their content.

According to Ortiz, by the end of the day today 5,000 websites will be sending back data to PressTrends. One thousand new sites are sending data to PressTrends each week since the beginning of the year. He said that over 100 themes have integrated PressTrends reporting with their themes from providers like WooThemes, and the Mojo Themes marketplace will be rolling it out to their theme authors soon too.

In addition to themes, plugins will be trackable by PressTrends. Ortiz talked more about this in a blog post published not long after his presentation:

Yup, we’re adding plugin support. We’re really excited about this as this will allow developers to get aggregated insights and how their plugins are performing. Granted, plugins do a wide range of functions, they way those functions are implemented can be aggregated. We’re also including support features that will allow developers to provide better support for users based on new metrics.

For the theme and plugin developers: what kinds of statistics would you like to learn about the way your users are using your themes? Will you be signing up for PressTrends once it comes out of private beta? For the users, what would make you interested in trying out another statistic/analytics plugin?

Nathan Ingram shares his WordPress backup comparison chart

Nathan Ingram shared a chart at his WordCamp Birmingham workshop session, literally minutes ago, of many of the available WordPress backup solutions, their features, and their prices. It’s really quite handy. Ryan and I have been here all weekend (well, I actually live here) and it’s been a great time. This is one example of the great things people put together when they go to WordCamps.

How to manage a proper multi-author WordPress blog

One thing I spend some amount of time thinking about each week is managing my multi-author blog at WPCandy. There are only a handful of authors that have joined WPCandy in the last year, but we’ve still spent a good deal of time improving our workflow as a multi-author blog. I’ve even picked up a few (what I would call) tips in the process.

If you find yourself in a similar position, hopefully some of these tips will help you along. If you run a blog with a number of authors, be sure to jump down into the comments and share your experiences too.

Establish a team blog

If you want your team to feel like, well, a team, they need a place to come together and chat about what they’re working on. One hundred percent of my team of contributors is distributed all over the planet, so if we didn’t have a team blog of some sort we all wouldn’t have as many chances to talk.

I’ve opted to use the P2 theme from Automattic, because like many others I think it fits nicely between the traditional blog and a chat room. I’d recommend setting up a private P2 instance at a sub domain of your site, like at team.yoursite.com, and making sure that everyone on your team is always able to use it.

In addition to P2, I’ve found that using Subscribe to Comments and Subscribe2 cover our bases when it comes to post notifications. This is also just a matter of preference, but I like to keep a list of useful links in the sidebar of the P2 blog along with a list of all the authors on the blog.

Of course you don’t have to use P2. The key is to have a location where your team can easily chat about what’s going on. Do whatever works best for your particular group.

Establish proper author/editor capabilities

This one will highly depend on your needs, but in my case I’m kind of a (what’s the word?) control freak. Because of this I still personally edit every word that gets published on WPCandy, so authors on WPCandy don’t have the ability to publish but can only submit posts for review.

There are a couple of ways to do it, but I opt to manage capabilities using Members by Justin Tadlock. Really I haven’t done much more than remove the publish capability from authors.

Just as important as the technical side of things is making sure that roles and abilities are known by your editorial team. Make sure everyone knows what’s expected of them and what they can do on their own, either using a team blog (see above) or help text (see below).

Use Edit Flow

I tried the Edit Flow plugin around a year ago, and just didn’t think it was quite there yet. I’m happy to say that wherever the aforementioned there is, Edit Flow is squarely in the middle of that location. The developers, led by Automattician Daniel Bachhuber, released version 0.7 this week and it brought some features that really got me excited to use it—features like a drag and drop editorial calendar:

In short, Edit Flow is a plugin that gives your WordPress Dashboard a newspaper-like editorial workflow. Along with the editorial calendar I mentioned above, Edit Flow gives more granular control over post statuses (like Pitch, Assigned, and Changes Needed in addition to Draft and Pending Review), enables author-only editorial discussion of posts as they come together, and  allows authors and editors to be notified when changes are made to posts.

Before Edit Flow the WPCandy team was using a ticketing system—on a sub blog using WooThemes’ FaultPress, actually—but the changeover was worthwhile. The old system, while it worked, also required a layer of translation between the ticketing system and WPCandy itself. When a post was started in one place, a ticket in another place had to be updated. Notes for the post (sources, contacts, etc.) had to be pulled from the ticket and used to write the post. And when a post was published, the ticket elsewhere had to be updated again.

Kind of a mess, right?

There’s nothing wrong with FaultPress, of course. Edit Flow is just perfect for multi-author blogs because it streamlined this process so that it all happens in one place.

Author checklist for post submissions

This is one of those tips that is useful not only for your site’s authors, but likely for yourself (at least it was for me). As you edit and publish content on your blog, pay attention to the steps you take over and over. If there’s a way to streamline those steps, such as setting a new default category to better represent the majority of your content, then definitely do that. But for other things it’s worth maintaining a checklist.

I’ve resorted to posting the checklist to the team blog or our help section (see below) but I’ve also see options like Blogging Checklist before. I haven’t tried it myself, but it could be something useful if your authors need to run down a few key steps for every post they write.

In general, though, communicate best practices to your authors to make the editing process (and hopefully the writing process, in the long run) as efficient as it can be.

Proper author attribution

If you have other authors on your blog it’s important to give them credit where it’s due. You want them to know they are receiving proper credit for their work, but it’s also important to make sure readers know who they’re reading.

Bylines are the most important thing to get right here. As an author, seeing your name presented prominently next to your work is important. It’s important at such a basic level, really, that it’s weird to mess this one up.

And as a reader, I can’t tell you how disappointed I end up being when I find out a post I’m looking at doesn’t have proper author attribution. I want to know who I’m reading just as much as what I’m reading.

If you wonder exactly how you should pull this one off, a good rule of thumb is to put other author’s names in the same place you’d put your own. In addition you might consider an area, perhaps beneath the post, where more information about the author is given. We have used these on WPCandy for a while and they tend to work pretty well.

One of my favorite social WordPress plugins is WordTwit from BraveNewCode. WordTwit is a handy plugin that will tweet out messages (either automatically or manually generated) when you publish new posts. In a recent update they made it really easy to automatically mention the author’s Twitter name in the tweets, and we’ve started using that here for the bulk of our posts. For a site like ours, where a lot of our community and traffic comes from Twitter, I think it’s important to give credit to post authors there too.

Set up author emails

This isn’t something you can set up within WordPress itself, but believe me when I say it will make your multi-author blog all the more professional. I prefer using Google Apps to run my domain-specific emails, and I highly recommend it, but honestly use whatever you have to and get that done.

Not only will having theirname@yoursite.com give your authors a sense of ownership in the site, but it will make their emails with people for your site all the better.

Share a group RSS subscription

I talked before about the number of RSS feeds I follow to keep up with WordPress company and project blogs. It’s quite a few. One small but helpful way to make the process of tracking new and interesting stories a bit easier is to open it up to the rest of your team and allow them to review potential story ideas too. This one will take a good deal of trust in your authors, but it can really be worth it once you have more than a few feeds/sources that are updating daily.

For the group RSS account I use one of my Google Apps emails set up with a Google Reader account. I have intended to move the various Twitter accounts I follow into one that the whole team can use, but I just haven’t gotten to it yet.

Maintain author help texts

You can establish this copy anywhere you like, really, but I prefer to keep as much within the bounds of the WordPress Dashboard as I can. It keeps things simpler and, to be honest, I just like it better.

So I really like WP Help, a plugin by Mark Jaquith that lets you keep help text for the authors on your blog.

There are other ways to maintain this sort of information, but this one’s my favorite. In our help section we try to keep things like:

• what to do as a new author on the site,
• tips for writing posts,
• how to use our taxonomies properly,
• the types of images we generally like to use,
• WPCandy logos that authors can use, and
• how to modify the parts of the site they can modify.

How about you?

There are undoubtedly more things to consider when running a blog with more than one author. I’ve based these tips only on my own experiences, which aren’t even that expansive. If you’ve run a multi-author blog (using WordPress or even something else) please jump down to the comments and share your experiences and tips.

Matty walks through the transient API

WooThemes developer and sometimes-WPCandy-contributor Matty Cohen wrote a post explaining how to get started with WordPress’ transient API. The codex describes transients as “very similar to the Options API but with the added feature of an expiration time”, and developers can use them in a number of different ways.

WPCandy’s Completely Unofficial Guide to Plugin UI

On the 29th episode of the WPCandy Podcast we talked about the sometimes poor state of plugin user interfaces. Many WordPress plugins are inconsistent with the native WordPress user interface in how they implement settings in the administration area for users.

I’m writing this guide to outline a (completely unofficial) set of best practices for implementing settings pages that is consistent and current with the native WordPress administration user interface. I’ve based these guidelines on my observations and experiences with using plugins in WordPress. They’re also totally a work in progress—if you have suggestions, feel free to add them in the comments section.

Navigation

When utilizing the Settings API it is important to place the link to your plugin’s settings page appropriately, otherwise a user with even a moderate amount of plugins installed can get confused about where each settings page is.

As a general rule of thumb, unless your plugin adds significant functionality to WordPress, it should sit as a secondary item under the general “Settings” panel. If you aren’t sure what significant functionality means, ask yourself if your settings page has multiple pages and/or includes options to manage or view content that a user will need to navigate to often. These are only guidelines, of course, and answering “yes” to any of these questions does not mean that your plugin needs its own top-level entry.

Proper placement of navigation.

Above you can see two plugins that following this guideline correctly. The form plugin adds a new type of content, with settings to view and manage all that content. The plugin appropriately take a place as a top-level menu item. The caching plugin’s developer correctly determined that the page would not be accessed often enough to call for a top-level item.

If you do choose to include your plugin’s settings as a top-level menu item, you should consider where in the list it will go. The side panel is loosely divided into two sections: content management (top) and settings (bottom.) Where you put your panel should depend on what category it falls under. Placement within these sections is at the plugin author’s discretion, though it is probably best not to place your panel in a spot that disrupts the location of commonly used panels such as the Posts Screen. This can mean placing the panel above or below such items, depending on what section you’re in and what you’re trying to avoid.

Improper use of colored icons

When setting up your admin menu icon, keep in mind:

• All icons should stay monochromatic gray until the user hovers over the panel. This is easily the most overlooked design convention of the side panel. Being the only colorful spot on the sidebar draws undue attention to your settings panel and distracts users.
• If you choose to display a colorized version of your icon on hover, try to use the same color palette that the other icons do. Use a color picker to find the hex codes in use on the menu.
• Try to use an icon that resembles the feel of the other icons. Please see the aforementioned form plugin to see this in action. If you can’t do this, it might be helpful to choose one of the default icons that is closest to what your plugin does.

Tertiary Tabs

If your plugin is complex enough to call for options spanning multiple pages but does not meet the criteria for creating a top-level panel, you should create a tabbed navigation on the settings page itself. This is a native WordPress user interface element that you can see in use on the Themes Screen. The developer of the aforementioned caching plugin has used this method correctly on his settings page, albeit with one abnormality.

Tabbed navigation

He has placed the title of the settings page above the tabbed navigation, as opposed to the left of it. This is acceptable in cases (and probably this case) where the title and tabs might be too wide and create a horizontal scroll bar for users on smaller screens. However, best practice is to put the heading (with an icon/logo) of the settings page to the left of the tabs. Below is the general markup of the tabbed navigation with the heading added in its correct place.

<h2 class="nav-tab-wrapper">
	Plugin Settings
	<a href="#" class="nav-tab nav-tab-active">Tab 1</a>
	<a href="#" class="nav-tab">Tab 2</a>
</h2>

Toolbar

The bar at the top of WordPress is a relatively new feature (a new form since 3.3, actually) meant to provide shortcuts to common actions in the admin area. It encourages plugin authors  to take advantage of this feature as a means of improving their plugin’s usability.

If you do choose to add an action to the bar, make sure that it is one that really belongs there. For instance, the author of the aforementioned cache plugin added an action to clear the cache to the admin bar in his latest update. This is easily the most common reason people navigate to his settings page and he saved people a bit of time. Do not assume that your plugins needs an entry on this bar, and please don’t add most of your plugin’s functionality to this bar.

If you believe you’ll have a few of these actions, create a drop down menu.

Dashboard Widgets

The dashboard’s purpose is to give users a quick look into important information on their WordPress installation. It is not meant as a way for you to advertise your services to users or publish a news feed from your site that is only tangentially related to the plugin itself. Although dashboard widgets are easily hidden and rearranged, not every user has the technical skill to do so. Please consider heavily whether or not your plugin really needs a dashboard widget before creating one. Another idea is to have the widget be opt-in, so that only users who explicitly want it have it.

If you decide to create a dashboard widget, the colors and styles should be consistent with the rest of the WordPress admin UI. The widget should attempt to display all pertinent information in the most efficient space possible. As usual, try to look at the standard widgets to get a feel for how yours should look.

Design of Settings Page

It should go without saying that the design of a settings page is extremely important to a plugin’s usability. While inventing interesting and unique interfaces might be a little much to ask of plugin developers, it is possible for every plugin to at least include a competent user interface by following a few guidelines.

Options page that is inconsistent with admin UI.

In general, keep this tips in mind for your settings pages:

• Make your page free of any custom elements that clash with the native WordPress administration UI.
• Infer structure of pages from WordPress core settings page designs. Be on the lookout for updates in this UI with each major version release.
• Use native WordPress IDs and classes for form elements. Not doing this is the number one way to have a bad settings page.
• Try to consider real use case scenarios when laying out the options. Not every single thing has to be changeable or customizable.

That’s it!

Still with me? Excellent. This completes a basic primer of plugin user interfaces. If you like the guidelines, be sure to check every plugin you submit against them and hopefully we’ll be on our way to a better WordPress experience for everybody.

Do you have any tips for plugin developers that aren’t listed above? Have you run into any inconsistent UI practices that are worth warning against?