If you haven’t upgraded yet, download it from the Plugin Directory or directly from within WordPress.

Here’s a quick breakdown of the new features introduced in this release:

Usergroups

Version 0.3+ adds in what are called usergroups. On the outset, they’re similar to “Roles” built into WordPress, except that (at this stage) usergroups are simply ways to associate groups of users together. Edit Flow adds a number of sample usergroups for you to get started (as shown above) and get a sense of what sort of groupings you can create. However, the main power of usergroups comes with…

Notification Controls

Much of the feedback Edit Flow received since the email notification were introduced centered around having greater control over who receives notifications. Previously, post updates were emailed to authors, editorial commenters, and any roles that had been selected to receive notifications. Many people were drawn to the notification feature but were forced to keep it disabled since they didn’t want all their editors or administrators notified on every single post update.

With the new release, you can specify on a post level, what users and usergroups should receive notifications, so that only relevant individuals and groups of individuals receive updates.

Note: with the introduction of this feature the “Notify by Role” option was removed. In its place, a new feature was added “Always notify admin option” which includes the blog administrator in all notifications. To all overly protective, nosy admins that want to know everything: you’re welcome

This is just the beginning of notifications. Some interesting ideas that we’d like to integrate in future versions of Edit Flow include:

• Giving users the ability to subscribe to posts themselves
• Have specific users or usergroups automatically subscribed to posts based on categories or tags assinged to posts.
• Make the UI a bit more efficient. The UI for this new feature is something that was unfortunately rushed. My original vision didn’t quite make it in (due to various impracticalities, changes, and lack of time), but it’s very much a high priority on my list to make it easy to select users/usergroups (especially for installs with hundreds and thousands of users).

More Useful Notifications

On the topic of notifications, the new release introduces emails that are slightly more descriptive in terms of the action taken on the post. The subject line of the email will specify whether the post was created, published, unpublished, etc. Although a small change, it should hopefully help users manage incoming emails more effectively and not get inundated with a barrage of “Post Status was changed” emails. (Interestingly, I’ve found that this new change comes in handy even on my personal blog which is a simple on-user blog. I find these notifications fairly useful especially since I make aggresive use of WordPress’ future scheduling functionality.)

Additionally, the action links in comment notifications now take the user directly to the editorial comment form (e.g. clicking on “Add editorial comment” will open the post and take to directly to the Editorial Comment form). Again, not a major feature but something that should hopefully save you some time, scrolling and future dealings with Carpal Tunnel.

I’d like to extend this feature even further and allow users to reply to comments via email and not have to go into WordPress to do so. (As you can see, there’s a bit a time-saving trend going on here.)

New widget: Posts I’m Following

Still a little crude at this stage, this new widget gives you a list of the most recently updated posts that you’re following. However, this widget will likely form the basis of the activity stream, which will provide an audit trail of activity happening within the WordPress admin.

Knight News Challenge Round II

While not really a feature introduced in 0.3+, here’s a bit of news that may be interest: we’ve submitted our 2nd round application for the Knight News Challenge. Check out it, vote, and leave us some feedback.

What’s Next?

Apart from some of the ideas already mentioned, with the next couple of Edit Flow releases, you can expect to see some great features such as:

• Post task lists (a la Basecamp, namely a list of tasks that must be completed in order for a post to be published)
• Better Post Management (to help you track and manage your content better, such as snapshots of how far along existing content is)
• HTML emails (because emails should always be pretty — but always fallback to plain text for people still living in the ’90s)

Your Homework

As always, your feedback is much appreciated and vital to our development. Let us know what about Edit Flow works for you and what doesn’t and what else Edit Flow can do to improve your organization’s WordPress experience.

We’ve already had discussions with several online and print publishers and newsrooms interested in adopting Edit Flow and would love to include you in that conversation. Why not get in touch?

After a long hiatus, CoPress finally released v0.2 of Edit Flow this past weekend. Those who have it installed should have seen a notification to update; for those who haven’t jumped on the Edit Flow bandwagon yet, grab it from the WordPress Plugin Directory.

We’ve got some cool new features in this new version, outlined below:

Post Metadata

Some basic fields have been added to allow users to capture additional newsroom-related data for each article. While it’s pretty sparse right now, the feature is something we’d like to flesh out once we get further details on how people hope to use this functionality. Additionally, it ties in really well to QuickPitch (described below). The fields we’ve added include:

• Description
• Due Date
• Location

Quick Pitch

A near-clone of the QuickPress Dashboard widget, the idea behind this was to allow reporters to propose new story ideas conveniently from the WordPress dashboard. Submitting a new pitch using QuickPitch creates a new post with the post metadata populated (based on the fields entered) and assigned the default custom status specified in your Edit Flow settings. The cool thing here is that an email notification is automatically triggered when a new pitch is created. (Notifications described below.) With the next release we’d like to add more control over who gets QuickPitch notifications as well as a template tag to make it visible on the front end.

Editorial Comments

Edit Flow now supports editorial comments. With this feature, discussions on posts/articles can now take place between editorial staff within the WordPress administration interface. This can cut down on long-winded back-and-forth email threads as all comments are conveniently displayed within the Edit Posts page to better facilitate online workflows. Threading is supported (assuming it’s enabled on your site — to enable threading, turn on the option to “Enable threaded (nested) comments” found under Settings > Discussion). We display gravatars for all users.

Notifications

Basic email notification support has been added, as well. Email notifications are delivered when a post’s status changes or when an editorial comment is added to a post (see screenshots above and below). Notifications are delivered to:

• Post author and Administrators, by default;
• Any specified roles (under Edit Flow > Settings); and
• Any users that comment on posts.

As with QuickPitch, we’d like to introduce the ability for more granular control over who gets post notifications, such as the ability for users to click a button to follow a post, or for notifications to be delivered to certain users based on the category of each post.

Internationalization

As promised, support for internationalization has been included in Edit Flow v0.2. For anyone interested in translations, the POT file is included in the plugin when you download it from the WordPress Plugin Directory. It’s not perfect, but we’re getting there. If you have a translation that you’d like to share, please send it to us and we’ll gladly include it in future releases of the plugin.

Phase 3 and onward

Okay, so what’s next? We’ve got some ideas that have already outlined above. Outside of that, we’re looking at things such as additional Dashboard widgets (e.g. editorial comments), personalized activity streams and RSS feeds, and maybe taking a crack at some of the bigger workflow pieces (e.g. user groups). We’ve deviated a fair bit from our original plans but we’re still on track to continue building Edit Flow and improving the WordPress admin interface for newsrooms.

What we need to move forward, though, is your feedback. Are you using Edit Flow? Let us know what about Edit Flow works for you and what doesn’t. Not using it? We’d love to hear why not. Finally, what other areas of the WordPress admin do you think we could help improve for your newsroom or multi-author blog?

We’re all ears.

• Facebook news application source code open to college news sites – NewsCloud has open sourced a Facebook application specifically for student news organizations. The application reportedly incentivizes activity around the news org’s content through a point system and rewards.
• TWiT 197: Steal This Diploma – Jeff Jarvis joins Leo Leporte for a discussion on newspaper collusion, Google Wave, and education.
• How the Web and the Weblog have changed Writing – Detailed, enlightening essay on how the web has changed writing formats.
• The Daily Tar Heel’s new social media policy – Sara Gregory, incoming Managing Editor for Online, lays out the DTH’s remarkably open and earnest social media policies for the coming year.

Around the network

Conversation on the forum was light this week with Daniel asking about different styles of navigation. Joey quickly replied with:

My point: think about nav bars from the user’s perspective. I’d propose http://newser.com as a good example of a newsorg nav bar.

• It’s dynamic: content changes based on what the top stories are.
• It links off to topic pages. Only the most timely and relevant topic pages are easily accessible.
• You can still get to the traditional sections if you really want to navigate that way.

Max Cutler also offered his opinion,

In my experience/opinion, the reality is that that most college news orgs publish about the same limited set of topics repeatedly, and that’s why the section model can make some sense. That’s not to say that tags shouldn’t be used; they definitely should, and virtually all college news sites could do a better job of integrating tags into their navigation and exploration flow.

On the wiki this week, Daniel edited the Edit Flow Page with the latest info on the project.

Tomorrow at 5 p.m. Eastern (Tuesday, May 5th) Emily and I will record a new episode of This Week in CoPress with Max Cutler and Robert Baskin, discussing their Courant News CMS project. Courant is an open-source Django CMS that Max has blogged about extensively on his site. We’ll talk about main features, the installation process, theme capabilities, and what their vision for the future is.

We’ll be hosting the call on Skype. If you wish to call in, please contact me with your Skype name or phone number at greg [at] copress [dot] org. You will be added to the call and be able to ask questions.

We’re trying this as a higher quality alternative to BlogTalkRadio. Let us know what you think. We’re also still looking at ways to stream it live, so please leave ideas in the comments. Thanks!

As always, the full podcast will be available here on the blog on Wednesday.

Host(s):

Guest(s): Rick Martinez

Summary: A discussion about the development of FIUSM.com‘s content management system built on Ruby on Rails, Nameless CMS.

Links

• FIUSM.com
• Ruby on Rails
• Nameless CMS

Up next

Scott Karp of Publish2 on link journalism and how it might apply to student media.

Subscribe: iTunes | RSS

Host(s): Bryan Murley, Joey Baker, Daniel Bachhuber and David Estes

Guest(s): Anthony Pesce and Dharmishta Rood

Summary: A discussion about the development of the Populous Project – a Knight-funded college-specific content management system.

Links:

• Populous Project site

Up next: The relaunch of FIUSM.com with Rick Martinez

In an e-mail forwarded to the CoPress Googe Group, Dean wrote: (emphasis added)

I don’t like the idea of sharing a server with other papers, the primary reason being that if another site receives record traffic the response time of our site will suffer as an result. The specifications for the server hosting all the virtual servers is actually lower than what I was planning for our site only. To put it in perspective, the desktop in my dorm is much better configured than that server.

Their hosting plan also seems to be geared towards wordpress, which i much less demanding resource wise than drupal.

After receiving so much good press lately, it sure is refreshing to have someone take us to task on a technical issue — something that we’re supposed to be teaching other people about.

Dean makes some good points and got the CoPress team talking on New Year’s Eve. We’ve realized that there are several things that our organization, which strives for transparency, hasn’t made entirely clear.

We’re in beta

CoPress should have emphasized that our hosting plans our in a beta stage right now. We do have the server capacity to host three to five college news organizations and we will be capping our initial service there.

Yes, part of the reason we are doing that is because we don’t think that server can handle much more. Yes, it is possible that our server might not be able to handle even the relatively small number of organizations.

That’s why we’re in beta. That’s why we’re going with LiquidWeb, which will allow us to expand our server capacity almost instantly to deal with problems if/when they appear.

With all due respect to Dean’s dorm computer, LiquidWeb servers offer enough bandwidth to allow roughly 1.2 million visitors a month to a newspaper website. We think that’s plenty to start with.

CoPress isn’t trying to host the world, but we’re going to give a solid start to a few folks who sign up with us. If we become popular, we’ll be expanding our plans to more news organizations and thus increasing our server capacity.

We are equal opportunity CMS users

CoPress is currently focusing on WordPress-based solutions, but we’re not exclusive. As a matter of fact, we’re not in anyway convinced that WordPress is the long-term solution. It is, however, the best solution that we’ve seen that can be deployed now, and that is valuable for those who want a more dynamic site.

We’ve taken on a long-term project to evaluate many different CMS solutions available (there are several we’re excited about), but our priority to help organizations using College Publisher or other less-than-desireable platforms as soon as possible. WordPress offers a good, workable solution that does much of what we’d like.

If you’d rather host a Drupal, Django, Ruby on Rails, CakePHP or any other sort of site on our servers, please let us know! We’re not making any money off of our hosting — we just want to help you host your own site. It’s up to you what CMS you want to use.

CoPress = easy

Alex Klein, The Chronicle’s editor for new media, and the gentleman who forwarded Dean’s e-mail, said he’s a little disappointed with their progress developing a Drupal-based CMS.

Their project has a lot of support from the school, including a $100,000 budget (there’s politics associated with that number, but according to Alex it’s probably still there). Yet, despite the large budget and institutional support, and a working mockup of their new site, Duke’s nine-month project still hasn’t launched.

This is where CoPress can help!

We’re here to help you avoid these problems. We’ve designed our hosting to be about getting your paper online as quickly as possible on a platform that works.

We’re as transparent as Windows isn’t

(Pardon the geek humor in the subhead.) Here’s the point: we don’t want to make money. Our motivation is based on the idea that the more college media outlets that keep pace with the “new media” evolution, the better off we’ll all be.

Our hosting plan is just an extension of this philosophy. It seems to us CoPress folks that many schools have not been able to adapt to the Internet quickly due to a range of technical barriers.

We’re here to remove those hurdles.

Now.

Keep it coming

We really, really appreciate any and all feedback. The more honest the better. Keep it coming and we’ll keep using it.

What Dean’s criticisms pointed out to us it that

• We need to make it clear that we’re going to be taking just a few schools on our servers to start. We’re not trying to host the world (yet) but we think speed and reliability are critical, so rest assured, we’ll do our best to keep the servers at full speed.
• We think WordPres is a pretty darn good solution, but we know there are others out there. We’ll continue to look at them as they are developed. But if you want a site up quickly, WordPress is a great solution that is ready now.
• We need to step up our efforts to prove to college media that there is a solution to your technical difficulties. We’ve got it ready to go and are more than willing to help you out. Mostly because we’re hoping that you’ll jump far enough ahead to help us with the next big problem we all face.

CoPress is here to advocate for college media. One of the ways that we can do that is offering cheap, well supported, easy hosting. We’re still working on other avenues of support. Look to us to be the community that supports college media.

edited by Greg Linch

Update

Jan 1 14:36 PST — Link to The Chronicle test site removed per their request. Apparently, there was some miscommunication on that link being made public.

1. OK, you need two years and more money.

The first year, you can roll out a prototype school or three in the fall, a few more in the spring, and by the time the next summer rolls around, you have a service you’ve taken a school year to develop and improve before you bring it out on a larger scale.

To this, I partially agree. Currently, we’re asking for $70,000 from the Knight News Challenge and have a time scale of one year. I am opposed, at the moment, to asking for more money than I think is necessary. We have little understanding of what our costs will be (plus I’m sure they will scale over time) and the other applications in the garage that have asked for hundreds of thousands of dollars, or even millions, seem outlandish. I don’t want CoPress to be taken as an outlandish project.

For me, the one year qualifies the amount of time it will take to build part of something cool. CoPress, by no means, would be “finished” at the end of the first year. A year, though, sounds good for project scope and two years sounds too long.

Second, Ryan asks:

2. Other than it feeling warm and fuzzy, being based on open-source software and thus extensible, what’s the advantage to a student news org to use this instead of College Publisher? It’s free, and hosted, and if you ever get enough traffic, there’s a rev share on the national ads, right? How is this different. (I’d emphasize that it will be built on a platform that students can learn and adapt to their own needs, right?)

Boy, do I ever agree with you. As I’ve written before and before, “hackability” is critical. Student news organizations need to be working on an open source platform (or, bowing to Kevin, Ken, and Expression Engine, at least one with a plugin architecture) so that they have the ability to innovate as fast as they can. If anyone tries to argue with me that student news organizations don’t need digital distribution platforms they can innovate with, I won’t listen to you. The software College Publisher uses is, from all of my experiences, clunky, janky, and proprietary. We’ll win people over when we show them we have an easy-t-deploy, maintainable, and open and innovate platform to use. Hell, we’re friendly too.

At the moment, we’re not working on a national ad network, although ability to deploy ads will be functionality we provide in some capacity. I’ve heard rumors that there is another group working on the ad coop, however.

3. If you’re going to offer hosting, that’s going to cost money to maintain after a News Challenge grant would run out. What’s the business plan moving forward? And if you’re not going to offer hosting, what super-easy-to-install platform are you going to build the service on?

(WordPress or Drupal? Maybe… An Ellington-like Django-based CMS would actually be difficult, unless the student news orgs in question all have access to and control of their servers.)

The business plan is being worked out. Currently, we’re looking at a few different potential revenue streams:

• Fee for service: core CoPress developers offer technical support (database porting, site theming, temporary support if you don’t have an online editor for a term, etc.) for affordable rates.
• Flat rate fee for basic hosting, management, and support
• Grants and donation drives; foundation support
• Using The Point for raising money for plugins/add’l functionality; money raised will fund development by a web developer from the CoPress community

And it’s funny you ask about what platform we’re going to use. We’re in the process of researching the best one for our needs through our surveys and CMS audit. We’ve developed a list of what we think is critical functionality [Google Doc], and are in the process of researching how well Drupal, WordPress, Django, and/or Ruby on Rails could be hacked to fit these needs.

The million dollar question:

4. One of the winners last year is building a CMS/community network tool (plus some front-end print scheduling?) for student media. How is this different (hosting? other services?) and why is it (also) necessary?

Ryan, I think what you’re referring to is the Populous Project. We actually were talking with them about a month and a half ago, but haven’t heard anything since. What we’re doing is similar in the CMS sense (although we preferably won’t be building an entire CMS from scratch) but different in approach: we’re focusing on the technical ecosystem first. The medium to long term survival of CoPress requires a vibrant ecosystem of student Online Editors, etc. because they’re going to be the ones hacking away, educating and supporting each other, and advancing innovation in student news.

We’re working together in an open, transparent, and collaborative fashion, and that’s how we’re different.

Update: Oddly enough, the CoPress Google Group received an email from one of the Populous Project grantees a couple of hours ago in regards to why we shouldn’t consider Ruby on Rails. Hopefully we’ll hear more about their development soon.

Content Management Systems

In becoming involved with this project, I’ve come to realize that people have varying levels of technical expertise (duh) and misconceptions about the world of web design. Let me clear the air a little bit and try to dispel some of the common fears and misconceptions I’ve been hearing.

Designers are to Developers…

When someone introduces themself as a ‘web designer,’ ask them if they’re a designer, or a developer.
Yankees, Mets. Coke, Pepsi. Bush, Logic (kidding). Designers, Developers. In every Web site ever created, there has been a struggle between code and design.
Designers want a site that looks … pretty. But they also worry about HMI, UI, and accessibility — there’s a science to that.
Developers are engineers and immersed in the science that is code. But, make no mistake: clean code is an art form.
Disclaimer: I’m a designer. I specialize in clean, minimalist design that is user driven. I hate to make compromises in design because the code is messy. I believe that design should drive code, not the other way around.

CMS

Content management systems are the new way of developing Web sites. They allow developers to do all of the coding work so that the Average Joe can login and add content to the site without knowing any HTML.
Let your fears be assuaged — any CMS that we develop will be as simple to use as any system you’re on now; quite probably easier — if we do our jobs right.
The plan is to be better than College Publisher: faster, easier to use, more modern and ad revenue sharing free. We can accomplish this relatively easily — CP set the bar pretty low.

All your old stuff

A lot of folks have rightly voiced fears about porting their old content over to a new CMS. Rest assured, this can be done.
Folks like College Publisher can’t deny you access to your own (copyrighted) data. There have been several schools that have successfully transitioned off College Publisher onto other platforms. Our CMS will make this process as painless as possible.

Opensource

Ever have a piece of software that does 90 percent of what you want, but just refuses to have that one feature that would make it a killer app? Maybe you’ve been dealing with a really annoying bug in the program for years, and just wish the darn manufacturer would fix it. Opensource is a deceptively simple solution to a common problem: sustainability.
By giving the code behind an program to anyone that wants it, open source ensures that there will be a community of developers fixing bugs and creating new features.
Yes, you’ll have to know code to contribute — but at least you can. That feature you always wanted? It’s a snap to find/hire someone for the few hours of work it takes to add that feature. It’s a lot easier than creating a new program from scratch.
By making our CMS open source, we can virtually guarantee that it will be supported as long as papers continue to use it.

We’re all good

Changing something as critical as your Web site is a huge step — with inherent risks. The important thing to take away from CoPress is that we’re aware of these risks and are will minimize them enough so you won’t have to worry about disaster.

To Come:

• The Pro-Easy: Why WordPress is not a sustainable solution and Django is
• Populous: Pre-alpha impressions
• CoPress.com: How we’ll make this a sustainable solution