At lunch, I learnt I was to lead a small group breakout on “the future of the CMS.” To keep the discussion going, we started out by brainstorming the things we liked and want to improve our respective software, and then did a roundtable to identify our six month personal goals.

Some things people like about their CMS:

• Drupal done well is easy to use; there are a ton of modules
• Affordability, open source is cheap
• Community to work with
• Many different homepage templates to choose from depending on the stories of the day

What people would like to improve (lots of conversation, as expected):

• Data portability
• More headless; produce output other than HTML
• Scalability, faster when many people are working in the admin
• Less steps for completing common, simple tasks
• Integration with story budgeting, calendaring; API for story flow
• Magical WYSIWYG editor; auto-save that works; track changes
• Support structured data / semantic markup
• Customization for story layout
• Small pieces loosely joined; better integration with other services

Given the short notice, I thought the breakout session went quite well. About twenty people showed up. In terms of what worked:

• Small group discussion; knew enough backgrounds to call out different people to talk
• Noted salient points on the whiteboard as a way of plotting direction
• I enjoyed the “what are you going to work on in the next six months” takeaways at the end

Next time, we should:

• Figure out the location ahead of time so we don’t waste time finding it
• Have people introduce themselves if they haven’t spoken yet
• Every fifteen minutes, have something for everyone to participate in so people don’t check out

At WordCamp Phoenix on February 25th, I’m presenting “Mastering WordPress Development.” The title lends itself to a number of discussion topics, possibly including coding standards, how to perform migrations, writing bin scripts to manipulate lots of data, participating in open source projects, how to review your code, common mistakes we see at WordPress.com VIP, etc. If you have opinions as to what I should cover, I’d love to hear them in the comments.

On February 27th, Mike Bijon and I will be taking the Portland WordPress Users Group through using Git (and SVN) for version control and working within a team.

At CMA NYC March 18th through 20th, I’ll be leading three sessions (one per day):

• “I Want To Learn WordPress – An Introduction To Key Concepts” – All of the basics you need to get started, including the WordPress interface and key concepts like themes, plugins, PHP and MySQL, and how to choose a good web host and design for your site.
• “Hacking WordPress In The Newsroom” – How to take your WordPress development to the next level. We’ll review version control, coding standards, performance and optimization, debugging, and other best practices.
• “Making The Switch To WordPress” – Everything you need to know about switching to WordPress from CMS X. Well, most everything.

Shaun, Erica, and I will also be hosting a mini-Happiness Bar for a few hours on Monday to help attendees with all of their WordPress questions.

Sweet!

This is a quick post I’ve been meaning to do about the work we did this year on the ONA11 conference website.

Background: last year, I was late on getting a conference pass and ended up volunteering for an entire day in the student newsroom. ONA’s student newsroom produces stories, video, and other coverage related to the conference. I had so much fun that I volunteered to do it again this year. I planned to work on it over the summer, but 90% of the work ended up being done in the last week.

The goals for the website varied depending on the context:

• Before the conference, the focus was convincing journalists to purchase tickets and attend.
• During the conference, there are two audiences: those who are physically at the sessions and those who want to participate virtually. The former probably want a backchannel for conversation and capturing the highlights, whereas the latter probably want to participate in realtime as much as they can.
• After the conference, everyone wants to access a historical archive of the content presented in sessions, either to catch those they missed or find the link they heard referenced.

With this in mind, we worked on making the website dynamically reflect these needs. It was helpful, although somewhat distracting from the experience, that I was working on the website during the entire conference.

What worked this time:

• Session pages as a custom post type. This gave us a structured database of all sessions and allowed us to easily build a session listing, etc.
• Using Posts 2 Posts to associate posts and presenters with session pages. Our realtime curation crew could easily publish content from the WordPress admin, associate it with a session, and have it automatically pulled into the session page. Furthermore, every presenter had a dedicated profile page and their information could automatically be pulled into other contexts on the website.
• Auto-showing the livestream player on an individual session page based on timestamp. Every session was associated with a track and I had a bit of logic to pull in the correct livestream based on current time, session start, and session end.
• Showing the session updates in reverse chronological order during the event (because the user is most likely refreshing the page and wants the most recent updates at the top) and then flipping to chronological order 15 minutes after the event.
• Leveraging the Zoninator on the homepage for featured stories and events. Editorial loved that they could have full control over which stories were highlighted. WordPress normally lists headlines in reverse chronological order, and developers hack this with “featured” categories, etc.
• Post formats presented content exactly as it was intended to be presented. I was particularly proud of my gallery implementation, even if there weren’t the visuals to go with it.

Next time I’d like to:

• Get started earlier so these features are actually fleshed out before the day of.
• Build an interface for posting updates from the session page so it’s brain dead simple to update (no associating with session post, choosing post type, writing a title if you don’t need to, etc.)
• Allow for “featured” session updates a la NY Times Editors’ Picks for commenting.
• Guest session update submissions with a moderation queue.
• Live update the session page so it’s essentially liveblogging with rich media.
• Show the bylines/avatars for people covering the event, so you know how well it’s going to be covered (e.g. one person versus five people participating)
• On the all sessions page, show the number of updates an event has, whether it’s currently live/being livestreamed, etc.
• Order content on the single session page based when it was published (e.g. you can assume everything 30 minutes after the session is coverage of it, whereas during the event is realtime updates on it).

Lastly, I have one more idea I’d like to pitch: a way of indicating who you want to meet at the conference. Every attendee that registers get access to a page on the website listing every other attendee. Then, they can go through and indicate whom they want to meet at the conference. It’s a double win; you get to notify who you want to meet that you want to meet them, and you get to see in advance who wants to meet you.

For archival purposes, I’ve captured a gallery of screengrabs from the website too.

WordPress Multisite – In a nutshell, how it works and why it will make your life infinitely more manageable. If we have a group of people who quickly get their heads around the basics, I’d also love to share tips and tricks for pimping a multisite instance. For instance, using plugins like Restrict Multisite Plugins and customizing your admin bar to give easy access to the network admin for super admins. (People I should bump in to: Emma McCreary, Kayleen)

Test-driven Development – WordPress doesn’t do it, and I’m terrible at it. I should find a mentor with fountains of knowledge. (People I should bump in to: Michael Fields, Than Taintor, Toby McKes)

WordPress for Publishers – More and more newsrooms are using WordPress for all parts of their workflow. From experience, I know that journalists tend tolerate crappy technology. I’d love to hear from users about their current frustrations and pain points. (People I should bump into: Joe Boydston, Toby McKes)

Dogfooding It – We love WordPress and sell to our clients, but a lot of us developers don’t actually use it on a regular basis. Why? How should we fix this? (People I should harass to no end: Nacin)

If you see me there on Friday, Saturday or Sunday, say hello! I look like this but with much shorter hair.

GitHub is a social coding site. You can host your code in a repository, fork others’ code, merge others’ code back into yours, and get social. GitHub has one of the best interfaces for accessing various facets of a code project.

Version control is similar to Wikipedia in that you can see all of the changes that have been made. Seeing revision history in Wikipedia makes the text, and people contributing text, more trustworthy.

“Version control is your safety blanket.” If your screw something up, you can easily revert back to a previous version and recover the content.

Greg presented a few ideas for Git in a news setting. It would be tied into your CMS, have a  simple interface, and not necessarily rely upon code knowledge to use. This opens it up to non-coders as contributors.

Flashbake is “source control for ordinary people.” From Cory Doctorow’s announcement post:

This is a set of Python scripts that check your hot files for changes every 15 minutes, and checks in any changed files to a local git repository. Git is a free “source control” program used by programmers to track changes to source-code, but it works equally well on any text file. If you write in a text-editor like I do, then Flashbake can keep track of your changes for you as you go.

I was prompted to do this after discussions with several digital archivists who complained that, prior to the computerized era, writers produced a series complete drafts on the way to publications, complete with erasures, annotations, and so on. These are archival gold, since they illuminate the creative process in a way that often reveals the hidden stories behind the books we care about. By contrast, many writers produce only a single (or a few) digital files that are modified right up to publication time, without any real systematic records of the interim states between the first bit of composition and the final draft.

Copyright and ownership over data becomes a concern when introducing ideas like forking and merging stories. Whose story is it? How do certain changes reflect back upon the organization that created the story?

“Forking is a Feature” (Anil Dash):

There are several related technical concepts that can answer to the name “fork”, but the one I reference here is the dramatic moment when a software project undergoes a schism on ideological or technical grounds. Instead of merely taking their ball and going home, those who forked were taking a copy of your ball and going to a new playground. And while splitting a community could obviously cause an open source community’s momentum to grind to a halt, even the mere threat of a fork could cause significant problems, by revealing conflicting goals or desires or motivations within a previously-united community.

Starting with the “talk to me like I’m stupid” approach lets the building blocks be put in place so that the story can be expanded going forward. Different branches and layers of a story can then be overlaid to provide additional context.

Episodic updates to a story can be left as separate branches or merged back into the trunk to tell a more complete story.

On a technical note, Git is much nicer than Subversion because it has a much better system for managing contributions. Submitting a pull request is easier than creating a patch file and having to email it somewhere, upload it to Trac, etc.

Question from Zach Seward: What type of story works best for this concept?

Albert Sun thinks breaking news might be a good candidate for this approach, as there’s often conflicting information, quick corrections, etc. When the story is changing on a regular basis, readers want to see what has changed and why.

Via Greg, Marginalia is a tool for visualizing historical information about a Wikipedia article. It also seems to be an open source, Javascript-based web annotation system.

There is a WordPress plugin for publicly displaying the revision history of a post. Scott Rosenberg supported its development and wrote about it last August.

Andrew Nacin brings up the concept of licensing. The big problem is media companies are largely protective of and restrictive with their content. They want to maintain full ownership over it. Users contributing changes back to the original document is different than a user contributing back to WordPress because the licenses are completely opposite.

Will Mitchell says the biggest thing he has to grapple at the Washington City Paper with is custom metadata. For instance, stories often have multiple authors who need to be attributed in different ways. They want to persist this data both to keep it structurally sound and for presentation purposes. WordPress is restrictive currently because it doesn’t handle data outside the schema out of the box. Also for the things WordPress doesn’t work well for, he needs to establish the best way to interface an external application with WordPress.

JSON API is an awesome plugin for getting data in and out of WordPress. Makes it much easier to use WordPress as parts of larger contexts. The plugin was originally written at the Museum of Modern Art for a blog served with Ruby on Rails. They made a decision to use RoR’s templating system for the frontend and WordPress’ admin for the backend.

Sweet: learned it’s already possible to associate custom taxonomies with users and other non-post objects. You just need to build the admin interfaces.

Will Davis talked about how he’s customizing WordPress for the Bangor Daily News, particularly the admin.

Question: What’s the state of the art as it comes to search?

Lavallee says NPR spent a fair bit of time thinking about it for the Argo Project. They came to the conclusion they didn’t need to worry about it until the traffic was there. They still haven’t done anything to modify WordPress’ core search.

I mentioned IndexTank as a search-as-a-service option. Mitchell wants “SearchPress”, or a search utility that’s easy to install as WordPress. Google Custom Search doesn’t work for me for a couple reasons: it drops pages randomly from the index and doesn’t offer faceting. Also, it’s not possible to tweak the relevancy algorithms.

Unfiltered HTML is a WordPress MU plugin I wrote to disable the KSEs filter. It allows users to include potentially unsafe Javascript and iframes. Embed.ly is also pretty damn cool. Embedding rich media from 160+ sources is as easy as copy and pasting a link to the resource, like this one:

http://www.slideshare.net/andrewnacin/best-practices-in-plugin-development-wordcamp-seattle

WordPress.com offers 24/7 support via email to anyone who signs up for a blog. Automattic views customer support as essential to building a community. Happiness leads directly to using the product more.

Few ways of getting feedback from your community:

• focus group
• usability testing
• going to events to hear what people are thinking

Nacin: “The vocal minority is a bad thing in many cases.” You shouldn’t allow them to guide the course of the community.

Google recently launched a feature in search that supports recipe metadata from publishers. WordPress.com saw an uptick in support tickets from food bloggers requesting the feature to be added.

If you’re building a community, you need to think about the needs of each facet. Designing for a monolithic majority leads to poor results.

“If I was a fresh reader to The New York Times and wanted to start following stories on X topic, where would I start?” asks Spittle. WordPress.com has an email address anyone can email to and receive a response. Nacin argues against email as a way collecting feedback because it’s unstructured and most news organizations don’t have the support staff to respond quickly.

Setting expectations with your community if you want to build a relationship with them is very important, explains Spittle. If you offer an email address anyone can send to, the expectation is that the community member will receive a response.

According to Nacin, “if you want a thriving community, it comes down to engagement. If you aren’t willing, don’t bother.”

Blogsmith, a blogging tool used internally by Aol, has a terrible commenting system. Engadget, controversially internally, switched to Disqus and saw the quality of engagement go up significantly.

Pivoting to a conversation about user experience lessons we can take from software development and apply to news websites. Nacin reflexively types in nytimes.com every time he opens a new tab. Ideally, this is the attitude of every reader. You want to be the homepage.

Question: How can news organizations shift from publishing information to inform, to publishing information to be used?

Nacin: “Readers should be more than visitors.” We need to think of more compelling reasons for them to stick around. Facebook centers the user experience around the user. Personalized recommendations increase relevancy. What if the headlines on nytimes.com were determined based on your past reading history?

Lastly, when you’re tracking data, you should define what “success” is beforehand. It’s much easier to figure out when you’ve hit it.