Today’s post is about the optional use of issues in Courant News. I was originally going to write about articles, but the Flyers game went long and I’m running out of time in the day to do due justice to that topic. That will hopefully be tomorrow’s post, but now on to issues.
As much as some people would like to believe that the future is web-first, and possibly web-only, the reality is that, at least in the college news sphere, there are many news organizations which have and will continue to have print editions which dominate their organization’s practices. I’m rooting for small web-first news organizations as much as the next person, but I also realize that that just doesn’t make sense for some organizations.
In light of that fact, it was important for us on the Courant News team to make sure our system could support both scenarios. The way we have implemented this is by treating issues as an additional (optional) container type for articles and media items.
The data relationship is ultimately pretty simple and inconsequential, the more important part is what it means for how the site handles the homepage. Originally, we had the homepage represent the latest issue for sites configured to use issues, and to just represent the latest x items when not. However, upon further reflection recently, I realized that this is actually far from ideal in many respects.
The homepage is arguably the most important page on a news website, and it requires special treatment. News orgs need the ability to define and reconfigure the homepage on a daily basis to meet the ever changing nature of the news.
As I mentioned in one of my first posts, we already have an “issue display type” system, which allows you to define (in advance) a set of templates representing different issue layouts. This works well to a certainly extent, but it still doesn’t allow for easy layout on a rolling basis, as it requires new template work to change or add a new one.
What I’d like to see, and what I need some community input on, is a system that allows editors to arrange the homepage layout in a graphical manner in the admin, just like you’d rearrange a layout in InDesign or similar graphic tool. If anyone has ideas for how such a system should work, I’d really like to hear it so we can build in support in the code and start making UI mocks. I think this is a really fundamental bit for a news site, and I’d certainly like to hear the range of community input before we commit to any one path.
I think there’s only so far you can go with providing customization and making sure things look consistent across editions or different homepage designs. Being able to customize the homepage entirely is clearly no easy task but just because it’s hard doesn’t also mean it’s the right thing.
In terms of being able to design the homepage graphically, the most impressive thing I’ve ever seen was SquareSpace. You could check out http://manual.squarespace.com/videos/ I especially find their structure editing mode pretty attractive.
I think the main ideas could go like this;
* In order to allow for some consistency at least, you should definitely use a grid system. Modules could span across certain number of rows and columns. Some modules could be shrunk and expanded. FB used to allow that kind of behavior and it’s not especially hard to pull off with some CSS.
* The parts of homepage should be modular. There could be modules that allows you to pull in links to articles with snippets and you could scope it with tags. I think your get tag makes this kind of behavior pretty easy.
* You should be able to drag and drop modules around.
These comments do not really take into consideration of the technical aspects of how my ideas might be implemented. I kind of assume unlimited amount of manpower and time at hand. If I were to pick one thing to focus on; I’d go with a grid system. That just makes other kinds of things relatively easy to implement.
The Tartan’s CMS is built around editions. The home page and all of the section pages just list the latest stories for the latest issue. This was fine when we were just publishing new stories online every week with the print edition, but is becoming a huge problem when we want to print stories online mid-week. To get them to appear, we have to add them to the previous week’s edition, even though they’ll appear in print the next week.
The way we’ve decided to fix that is to drop editions entirely. The CMS will let editors specify a publication date instead of an edition, and then the templates will display all stories within a certain time period (e.g. from the last time we published until now). By default, the UI will suggest a pub date of next Monday, since we print on Mondays.
Similarly, I don’t think you really need issues in Courant. You just need an easy way for editors to choose a publication date that aligns with the issue publication date.
I agree with Can Duruk on this: a grid system with drag/drop widgets makes it easy for a non-technical editorial staff to lay out the homepage. The SquareSpace drag/drop structure editing looks like exactly how I would envision such a system too.
One question/request that’s slightly related to this topic: for newspapers that still publish on an issue cycle, will the software allow for a workflow where an entire issue is pushed out at once?
For instance, at the Herald, editors typically put article “skeletons” online first (in a non-public way) and then fill those skeletons in, making them public once they’re done. We recently moved to CP5, which has meant adding another step to that process; the editors now have to lay out the articles in the proper sections after publishing them. It would be really great if Courant allowed editors to lay out pages before the articles are public and then publish all of the articles at once, updating all of the pages at the same time.
Thanks for the great comments everyone. You’ve given me some ideas, and I’ll post a followup sometime.
@Neil: Yes, there are provisions for publishing all articles/media in an issue at once. That will also be a post at some point in the future, although the details will change with my new workflow proposal (also coming soon).
@Neil: Good point about publishing everything together. I hadn’t thought of that yet in my plan to get rid of issues in the Tartan CMS.
I would solve it by having a way to search by date, and bulk publish the stories. You’d need a workflow state like “Ready for Publication”, then search for all “Ready for Publication” stories from the last week and set them all to “Published”. You could even automate that in the UI somehow (saved searches?).
@Max: Sounds excellent, thanks for the quick reply.
@Marshall: Yeah, that’s essentially what we do. In CP5, every article is a draft until we’re ready to publish it (and they have a “publish all drafts” button). Unfortunately, some CP5 elements rely on having a published article for display: you can’t lay them out with a draft and then publish the draft for the public to see.