What’s new? All of this.

Good hunting, all you testers.

Search engine optimisation (SEO) is the process of creating content in such a way that search engines naturally see your content as valuable and of interest to the user.

By running a pay per click (PPC) campaign, you can be sure that you’ll be included in the SERPs. Most PPC ads are displayed either at the top of the page, or just to the side of the top ranked results, with the advertiser only paying when his ad is clicked.

Some fundamental rules of search engine marketing (SEM) include:

•    Use consistent keywords and synonyms when necessary.

•    Use your keywords in meta data, headings, sub-headings, links and body copy.

•    Link between the pages within your website or between individual blog posts.

•    Create external links pointing into your site. The more relevant the link text and the destination page content, the more benefit you’ll receive.

Top Tip: Have patience. SEM is an ongoing process. Although PPC can be implemented immediately, it might take a while until SEO’s full rewards are evident. In this case, one can use the former to supplement the latter while it gets up to speed (or to cover the keywords that SEO can’t reach).

“Why won’t they put feature y into core? It’s rated really high in the Ideas forum!”

“It doesn’t matter what I think, all the decisions get made by an elite crime-fighting squad funded by an anonymous millionaire. Er, I mean the four core devs.”

These sentiments, and others like them, are the focus of today’s post. Setting aside the similarities between Ryan, Andrew, Mark and Peter to Charlie’s Angels for a moment, the question of how decisions about features are made needs to be addressed. There are a number of mechanisms in place for communication between the community and the core team, but with so many different channels, it’s hard to keep up with them all and still focus on production. Here’s where we are now…

#wordpress-dev IRC channel: The IRC channel used to be more active. These days there’s rarely more than a dozen or two people online at any given time, and hours go by with no activity. When a question pops up, it’s often a tech question from a less experienced developer or site manager looking for help, as opposed to ongoing discussions about the best way to approach core code and features. When core-focused discussions do occur, they tend to fade out as time zone variances cause people to log off before a core dev enters the room.

wp-hackers list: The hackers mailing list reaches thousands of contributing developers, plugin developers, and lurking interested parties. Discussions range from how to use hooks to whether or not something in core should be changed to troubleshooting for other list members. Conversations on this list sometimes can get heated and occasionally stray into rudeness, which makes some people hesitate to utilize this communication channel.

This dev blog: This blog is used mostly for “official” announcements, and more recently, for surveys and polls intended to give the core devs an idea of community opinion on things being considered for future versions. Posting is irregular, sometimes with new content every other day, sometimes with nothing for a couple of weeks.

wpdevel.wordpress.com: Another blog, also an “official” outlet, in which the core team posts about any big code changes they’re working on. This gives plugin authors and contributing developers a heads-up, and provides a place for community discussion around specific issues like the new widgets API.

Trac: The ticket system used for active development has gotten out of control. Hundreds of tickets are already lined up for future versions because they were punted from current releases; many aren’t even relevant anymore. Trac has wound being a place where people report bugs, suggest code changes, request features and debate methodologies; some of these conversations are years old. This broad use of the system makes it harder to power through tickets and get bugs fixed.

Ideas forum: The Ideas forum is a place where anyone can suggest a new feature, rate features suggested by others, leave comments, and generally discuss the future of the WordPress application. However, like Trac, some of the items here are years old. Because of the way the rating system works, older items remain at the top of the list. Some threads are simply he said/she said preference arguments, as opposed to contructive discussions about the value of implementing certain features or changes. There’s no direct connection between the Ideas forum and Trac.

WordPress is an open source project, successful because of the community that both develops and uses it. At the same time, some people find it difficult to become involved in the project, and are unsure of how to engage with the core team and community at large. The channels listed above can be overwhleming to someone just joining the community, and/or frustrating to longtime community members who feel like they used to have more influence. We need to fix this. The WordPress project needs to be welcoming, easy to navigate as a contributor, and provide useful feedback to help grow the expertise of its community members.

I think we should figure this out together. You, members of this community, know how you feel about the communication channels available to you. You probably have ideas about how to make it better. Some of you may even have sketched out digrams of systems that you think would work better.  Link Ideas to Trac? Change the Ideas rating algorithm? Close Trac tickets that don’t get resolved within a certain period of time? Just do everything through Trac? What do you think? What would make it easier for you to keep up with development progress and get involved with the varius contribution opportunities? I *know* you have an opinion.

Over the next few weeks, we’ll be gathering your input about how we can improve communication and participation, and then we’ll embark on a project to fix/create a system for collecting ideas, opinions and feedback that will allow WordPress to grow as an inclusive community. Here’s the plan: Gather ideas from people via IRC, forums, live chats, surveys, etc. Assemble a small group of interested parties to help figure out possible approaches, put suggested approaches to a community vote. If redesigning something (like the Ideas forum) is deemed necessary, utilize community designers to create layouts. Beta test it to see if it does work as hoped. Launch and make everyone happy with the new, improved communication/ideas/feedback system!

Up First

Use this forum thread to post your suggestions about this. What do you think needs to be changed or improved? How would you structure it? How do the existing channels fit into your suggestion?

On Tuesday, May 12 at 21:00 UTC (5pm New York time), hop into the #wordpress-dev IRC channel (irc.freenode.com) and talk about your suggestions for how to improve communication. I’ll be there, taking notes and answering questions, and asking follow-up questions when someone pitches a good idea. An hour later, I’ll be joining the WordCast Podcast to talk about this issue. They’re trying to set up a call-in format; if that pans out, we’ll post the call-in info in the dev channel. Otherwise, A call-in number has been set up through TalkShoe.

1-724-444-7444
Meeting ID: 50127
Pin (if you don’t have a TalkShoe account): enter 1#

We’ll also read off suggestions being made in the dev channel and discuss them.

More opportunities to weigh in on this issue to come. Also, further investigation into the similarities between the core devs and Charlie’s Angels.

For readers who aren’t familiar with the process behind usability testing, here’s an overview. First, determine the scope of your test and create a test protocol/script. Determine the audience segments to be included in the test group(s), and begin recruiting. Recruiting may mean hiring an agency to find participants, but for testing WordPress, it makes more sense to recruit from within this community, so that means making a screening survey, reading all the responses, segmenting the respondents into categories and contacting people until you’ve filled your desired quotas (for whatever segments you’re seeking, such as newbie, experienced user, developer, CMS user, photoblogger, mobile user, etc. ). Then come the test sessions.

Depending on what is being tested, these last anywhere from half an hour to an hour and half apiece. Sessions are generally recorded using screen capture and web cam, with a video camera for backup. The moderator(s) generally take notes during sessions and/or (depending on what software is being used for the session capture) set markers in the video to indicate task completion, comments of interest, etc.  In some cases, auxiliary test methods such as eye-tracking may be included. When the sessions are complete, the results are analyzed. All the notes and videos are reviewed, patterns are identified, and ultimately a report is written and the feedback informs the next round of revisions.

Some people think it shouldn’t take much time to do all this. I’ve lost count of the number of people who cite an old article by Jakob Nielsen that says you don’t need to test with more than 5 users because usability issues become clear right away. While I’ve found that to be generally true, when your user base is as diverse in experience level, usage, platform  configuration, language (right to left languages have a pretty different experience) and demography as the WordPress community is, 5 users really isn’t enough to get a clear picture. We try to test with at least a dozen people each round, but then we are limited to a geographic region (test in NY, test in SF, or test wherever we can schedule enough people back to back to make it worthwhile), while WordPress users are located all over the globe.

To address this, we’re introducing a set of new contribution opportunities to expand our usability testing program. As with development and graphic design, we’re going to create an infrastructure to allow community participation in usability testing on a regular basis and in a much broader capacity than existed before, when it was limited to announcements that we needed participants in x city on y date. We’ll be looking for volunteer moderators as well as participants, hopefully from all over the world.

Moderators. Observational usability testing isn’t rocket science, but neither is it a simple task to reduce bias. Because of this, at first we’ll choose only moderators who have professional experience conducting usability tests. People who conduct testing for design agencies, software companies, usability consulting firms and the like will be our first round draft picks. In the future, when we have a group of regular volunteers and have ironed out any kinks in the process, we’ll ideally match up experienced testers with aspiring ones, using a mentorship model to increase the number of people who can contribute in this fashion.

Participants. If you use WordPress, chances are you could participant in a usability test at some point. In some cases we’re looking for particular behaviors (people who upload large video files, people who blog from their iPhone, people who manage more than 5 blogs, etc.), while other times the behaviors we’re looking for are much more common (do you have widgets in your sidebar, have you changed themes in the last 6 months, is there more than one author on your blog, etc.).

So how will these opportunities come into play, and how will it make WordPress better?

We’ll start with the moderators, and try to get volunteers with a decent geographic spread. Then, we’ll start signing up potential test participants in those areas (though we’ll also allow at-large registrations, since traveling testing will still be happening). We’re working on a registration process for potential participants. You’ll enter your basic info (location, contact info) and answer some questions about your WordPress usage to be entered in the database, and when there’s a testing opportunity coming up that’s appropriate for you, a local moderator will get in touch to see if you’re interested. Further down the road we may experiment with remote testing and other methods, but for now, this approach will broaden the geographic scope of our testing.

All moderators will follow the same test protocols and script, and their results/reports/video will be reviewed and collated, with a composite report (including the protocol/script that was used) published to the community. This will provide designers and developers with broader feedback during the dev cycle, and will allow the wider community to both understand and participate in the testing program.

If you’re interested in being a moderator during this initial phase (meaning you do it professionally), send me an email and introduce yourself. If you’re interested in signing up as a potential test participant, watch this space. We’ll post a link to the registration survey once it’s ready.

BuddyPress is an official sister project of WordPress. The idea behind it was to see what would happen to the web if it was as easy for anyone to create a social network as it is to create a blog today. There’s been an explosion of social activity on the web, it’s probably the most important trend of the past few years, but there’s been a dearth of Open Source tools that enable the social web.

In WordPress we have a robust and extensible base that can scale to many millions of users, and BuddyPress is essentially a set of plugins on top of WordPress that add private messaging, profiles, friends, groups, activity streams, and everything else you’ve come to expect from your favorite social network, like a Facebook-in-a-box.

I don’t think BuddyPress will be something you use instead of your existing social networks, I mean all your friends are already on Myspace, but if you wanted to start something new maybe with more control, friendlier terms of service, or just something customized and tweaked to fit exactly into your existing site, then BuddyPress is a great framework to use. Maybe even someday you’ll be able to connect your BuddyPresses to each other and to the existing monolithic social networks.

This is just a 1.0 release and it’s not for everybody yet, for example it currently requires using MU which is a bit trickier to get set up than regular WordPress, but regardless I’d recommend diving into the community at BuddyPress.org, which is great example of the software in action.

Here’s Andy’s official announcement post.

As several people have rightly pointed out, the Fluency-style designs not only took the top spot, but in combination added up to a higher percentage than any other. We’re not focusing solely on that statistic, though, because had other designers submitted multiple versions, the numbers might have looked different. What was most interesting for me was checking in on the votes over the course of the two days the poll was open. The top three (Fluency-dark, Current 2.7, MT) kept beating each other out for the #1 spot as they cycled back and forth through the top three slots, and had the poll closed on time (left it open a little longer in case anyone translated the time zone incorrectly), the order would have been a bit different.

What’s more interesting to me is the overall style that seems to be preferred among voters, as Matt’s comp has some stylistic similarities to Dean’s (see image at left). It also would be interesting to know how many of the votes for the current 2.7 interface were based on thinking it looked the best vs. how many were votes against changing the interface at all so soon after the 2.7 redesign. If you want to comment on what you liked best and/or least about any of the designs, this thread is a good place.

So what happens now? However we look at it, the Fluency-style designs clearly have a lot of fans. Then again, so do the designs of Matt Thomas (he’s behind the current style of 2.7, remember, in addition to the comp labeled MT). To give the interface the attention it is due, and to take seriously some of the interface feedback around usability and accessibility, we’re going to leave the looks alone for 2.8. It’s our guess that a revised style will make into 2.9 early in the development cycle to allow us plenty of time for user testing and revision. How close it winds up being to the comps submitted in this design tweaks challenge will depend, but in the meantime:

Congratulations, Dean J. Robinson, on winning the vote!

Below are the links to the screenshots that were submitted. Please review each one (I’d open them all in tabs so I could look back and forth while they are all large size, because the voting poll just uses thumbnails), then choose the one you think looks the best/is the most usable.

This poll was supposed to close at 8pm NY time on Tuesday (today), but we’re going to leave it open for an extra day. The voting poll will now be closed at 8pm NY time on Wednesday (that’s 2am Thursday, UTC). If you want to discuss the entries’ pros/cons, this thread would be a good place.

Current: The existing interface, for reference

KM: Current nav, header elements moved

AN: Current nav, file folder style header

KD: Current nav, modified header style

JJ: Swap blog title and favorites menu

DR1: Fluency style, dark

DR2: Fluency style, medium

DR3: Fluency style, light

IK: Nav layered over dark background

GB: Modified nav/header intersection

MT: Modified nav and header

Which style do you prefer?(answers)

Results will be posted the day after the polls close.

ACT I

Jane: It is a thorn in my side that the blog name header is above the “dashboard” nav section in the admin, since in MU installations and with plugins (like stats), things in the Dashboard section span multiple blogs. Makes more sense for the header to head only the per-blog content area.

Mark: I agree about the header. “This is the menu, this is the content.”

All: Yep.

Five minutes later…

Mark: What do you guys this of this quick mockup I just did, playing with the admin header?

Jane: I like it that the nav is not under the header. Might need some styling help. I was also thinking maybe the favorites menu should drop down into the white h2 area by screen options/help tabs.

Ryan: Menu color to the top with blog title pushed over and favorites next to screen options sounds quite nice.

Jane: I’ll ask Matt Thomas if he could style it [ed. note: Matt Thomas created the visual style for 2.7], and we can see what people think, maybe post on wpdevel for feedback.

Ryan: If it’s quick, maybe we could even get it into 2.8.

ACT II

Matt T: Here are some comps based on what you told me.

Jane: Cool, but where are Screen Options and Help tabs?

Matt T: Still working on that.

Jane: Hm. Wonder if there’s time to open this up to community designers? I know we’re in freeze, and it’s no notice, but you didn’t get any notice either when we dropped this styling request on your lap a few hours ago. That’s the way open software development works: sometimes the best ideas come at the last minute!

Matt T: I’m all for letting the community take a stab at it. Especially if they come up with something brilliant to do with the Screen Options and Help tabs.

Jane: I’ll ask Ryan about release date and see if there’s time. I know they wanted your style recommendations today.

Act III

Ryan: Tuesday is probably doable, no later than that for final delivery of style and any gradient graphics, etc.

Jane: Awesome! People will hate me for the short notice after the has-patch marathon, but since it’s a small project and over the weekend, and wasn’t even something anyone was planning until a few hours ago, I’m *really hoping* people will take this for what it is, an attempt to give more people input into an upcoming visual change in the interface, even if it’s not a huge one.

Ryan: Would have the benefit of warning people that header and menu will be changed a bit.

Jane: And we can have a vote. If I can get all the materials together and post in the morning, that would give 2 days of design time for submissions on Monday, and if we do a day of voting Tuesday, that’s 3 days notice for the vote. I’ll make sure to post to all the lists, etc.

Ryan: Will we announce with comps from Matt T as examples of what we’re thinking?

Jane: I’ll write up the UX reasons for considering the change, and Matt T can provide some style guidelines and his original comps so no one will have to waste time mocking up the basic screen layout.

Ryan: That would help set the scope. We just want tweaks here and there, given the timing.

Jane: Woot!

On Your Mark, Get Set…
Okay, so here’s the deal. Modifying the nav/header to be a little nicer is was a last-minute design idea, and if it can’t be worked out in the time we have left before 2.8 (which is very little), we’ll just wait until 2.9 to work on it. But! If someone comes up with something the community really likes and it doesn’t break any of the design guidelines for the rest of WordPress, we could sneak it in.

UX and design guidelines for this mini-project are posted here (so as not to clog up anyone’s feed reader with big graphics). Read through the UX stuff, check out the comps Matt Thomas mocked up last night (with absolutely no notice, for the record). Use the .psd as your base, and when it’s time to submit your ideas, make a .jpg or .png and post a link to it in the comments on this post. (Note: Only comments containing a link to a design submission using this format will be approved. For general discussion about this design challenge or any of the submissions, please head into the #wordpress-dev IRC channel.)

Submit the link to your comps by 1am Tuesday, April 28 UTC (7pm Monday, April 27, New York time). If you have questions or want early feedback, we’ll be in and out of the #wordpress-dev IRC channel between now and then.

Once we’ve received the submissions, we’ll post a voting survey (much simpler than the icon survey; this one will be more of poll, just choose the one you like best) as soon as possible, and will post the link to it here as soon as it’s online. We’ll only keep voting open for one day because of the 2.8 deadline, so put it on your calendar if you think you’ll forget. Voting will close at 2am Wednesday, April 29 UTC (8pm Tuesday, April 28, New York time). Results will be announced the following day.

Go!

* Chats above are a conglomeration of actual chats.

Reminder: Only comments containing a link to a design submission will be published here. All other comments will be deleted.

If you want to leave a public comment about this contest, the design, etc., I’ve created a thread in the forums that you can use. Please discuss these things there. If you leave a regular comment here on this blog, no one will be able to reply to you, because only actual links to design submissions will be posted in the comments here.