Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

September 02 2013

Ghost : Just a Blogging Platform

Ghost : Just a Blogging Platform
http://tryghost.org

encore un #CMS en #JS avec #Markdown ; ceux-là ont levé 125k$ de #crowdfunding

August 14 2013

Camlistore — un CMS tout simple : je dépose mes fichiers dans un répertoire chez moi, ils sont…

Camlistore — un CMS tout simple : je dépose mes fichiers dans un répertoire chez moi, ils sont indexés, versionnés, synchronisés vers un serveur web, et affichés comme une page web en utilisant un template...

http://camlistore.org/docs/overview

Une démo :

http://youtu.be/yxSzQIwXM1k

Vu dans les commentaires de http://linuxfr.org/news/sortie-de-paperwork-0-1.

#camlistore #cms

June 30 2011

How one newspaper rebooted its workflow with Google Docs and WordPress

Bangor Daily News Google DocsDigital media not only forces newsrooms to face economic challenges, but also workflow issues. In a recent post, Todd Benoit, director of news and new media at the Bangor Daily News addressed the root of the workflow problem in his newsroom:

Like many newsrooms, until very recently we were production heavy because we had to be. Moving stories to the web was a copy-and-paste affair, but that's not where the trouble started. If you begin with a print-directed front-end system, as we did, how does that system accommodate a story being updated from the field? Or how would the full possibility of story assets land online, to be chosen among for print? Even simpler: When do reporters add links? The answers, as countless journalists know, are: It can't; they won't; they don't. From there, it's all production, not creation.

The Bangor Daily News attacked the problem head on, incorporating Google Docs and WordPress into a new front-end system that handles the flow of news in the digital era. As Benoit describes the solution:

... the guiding ideas we have put into practice are to match the tool to the job we need done (rather than the reverse), reduce the number of steps required and anticipate how our audience will want the information next. And the cost should be next to nothing.

To find out more about how the project came about and how it works in practice, I reached out to William Davis (@williampd), the online editor at the Bangor Daily News and the architect of the new system.

Our interview follows.

How did you end up gravitating toward a Google Docs / WordPress / InDesign system?

William-P-Davis.pngWilliam Davis: My boss [Todd Benoit] has a great post on our dev blog on the topic, and I talk about it a bit on one of my blog posts as well.

We picked Google Docs purely for its ease of use and its collaboration tools. We wanted a place where reporters could work on their articles easily from wherever they are — we have quite a few bureaus, and our reporters often file from events. The collaboration tools are terrific and have really proved useful, for example, when we're editing articles on tight deadlines or when reporters are working on stories together. On Election Day we had three reporters at different campaign headquarters all working in one doc, and it went very smoothly.

We chose WordPress because we wanted a content management system (CMS) that allowed us to develop components quickly and easily. WordPress has a great API and it's very extendable — we've been able to easily change pretty much any part of the CMS without hacking the core, which allows us to maintain the integrity of the system.

Both systems are quickly evolving and pushing boundaries in their fields, without any prodding from us. WordPress has frequent updates that push the platform to a new level, and Google Docs' collaboration tools, for example, are second to none.

Finally, we chose InDesign because it is the industry leader in page design software.

TOC Frankfurt 2011 — Being held on Tuesday, Oct. 11, 2011, TOC Frankfurt will feature a full day of cutting-edge keynotes and panel discussions by key figures in the worlds of publishing and technology.

Save 100€ off the regular admission price with code TOC2011OR



What was involved in developing the system?


William Davis: We started development in August [2010] or so, and it's still ongoing. We launched things on a rolling basis by department, and started with sports, which turned out to be the hardest because it's the most complex. We then rolled out politics in time for the elections. We got the entire newsroom using Google Docs early this year.

The display desk transitioned to InDesign in April, and then earlier this month we finished the website transition and turned off our old systems. As we developed the components needed for each department, we would move them over, test and tweak things, and then move on to the next department.

What are some of the major challenges you've encountered?

William Davis: We've had a few instances where Google has changed the way they structure their content in Google Docs or changed the way a part of the API works and we've had to adapt. We've also faced the usual technical problems that come with hosting any large website, but we haven't really encountered any challenges that we weren't able to solve fairly quickly.

Some components we've rebuilt a few different ways and will probably rebuild again. The wire feeds are an example. Those were originally running directly into WordPress. We decided we didn't want to put the strain of tens of thousands daily stories and photos on our website and so we tried running the wires directly into Google Docs. We encountered problems there, as well. I`n the third iteration, which we're using now, we have a separate script that ingests the wires and provides a way to browse them, then sends the stories we want into Google Docs. That's worked pretty well, though that's not to say we won't rebuild that component or others in the future as needed.

The great thing about building our own system is that we can tailor it to our needs. Because we're doing it all in-house, we can change quickly, rather than waiting for a corporation to adapt with us.

Was it difficult for people to adapt to the new system?

William Davis: With a transition to any new system, there are of course going to be problems, but I think the ones we've encountered have been pretty minimal. Reporters seem to have had a pretty easy time adapting to writing in Google Docs — many of them, especially bureau reporters, were already using the system to write their articles. They understand why it's important to move content quickly through the system so their articles have the best chance to succeed online.

Can you give us a walk-through of the publishing steps involved — from story idea to final web and print versions?

William Davis: Reporters start their stories in Google Docs, and when they're finished, they drop them in a folder for their section — Metro, State, Business, etc. Editors read the story and move it on to a copy editing queue, where a digital desk editor reads it before sending it to WordPress.

In WordPress, the digital desk editors will categorize it, attach media such as photos and video, and then they will publish the story. This is done throughout the day — we have digital desk staff on from 5 a.m. until midnight. When the display desk comes in to lay out the paper, all they have to do is find the story in the InDesign plugin we built and bring it onto the page.

Everything comes onto the page fully formatted, though the digital desk is responsible for writing their own headlines for print. They can do this either on the page or in a module I built for WordPress that provides a WYSIWYG headline-writing interface.

Davis offers a tour of the new system in this screencast:

How many people actually touch the copy before it's published?

William Davis: As is the case in any newsroom, that varies by article. The digital desk editors, in addition to being copy editors, sometimes act as backfield editors, such as on the weekend. Other articles are seen by four or five editors before they're published. In general, though, articles go from reporter to assignment editor to at least one digital desk editor before being published.

How much manual labor is involved?

William Davis: We've managed to do away with pretty much all manual labor. Previously, all stories were written in our print CMS, and the web staff was responsible for copying and pasting the story into our web CMS, finding and adding links, writing a web headline and, quite often, doing that multiple times for the same story after it was updated. The copy editing was all print-centric, so at the end of the night, most of the stories would need to be updated. Now there's no copying and pasting — everything flows from one step to the next.



Related:


  • The line between book and Internet will disappear
  • Metadata isn't a chore, it's a necessity
  • Writing a Book with Google Docs

  • The secret to digital publishing success? Don't start with the book

  • November 12 2010

    The iCalendar chicken-and-egg conundrum

    If you're running a website for a school, or a business, or a band, or a club, there's probably a tab on your site's home page labeled Events. The calendar that shows up on that page is most likely driven by some kind of content management system that collects your events using a form, stores them in a database, and renders them through an HTML template to produce your events page.

    One of the premises of this series is that publishing calendars as HTML, for people to read on your events page, is necessary but not sufficient. You should also want to publish events as data for computers to process and for networks to syndicate. And you should expect your content management system, which already has the data in a machine-friendly format, to do that for you. But this almost never happens, and so we have a classic chicken-and-egg conundrum. Nobody expects that a website's events page should offer a parallel data feed, so nobody demands that CMS vendors provide one, and as a result hardly any do.

    Hannah Grimes calendarConsider the case of the Hannah Grimes Center in Keene, NH. Its events page is provided by the Constant Contact service as part of a package of event marketing features that include registration and social media promotion. But there's only an HTML page; no companion iCalendar feed is available. That means the Hannah Grimes Center's events aren't available as a stream of data that can syndicate through networks and merge with other calendars.

    The irony here is that a previous version of the Hannah Grimes site did provide an iCalendar feed. That version of the site was based on Drupal, which has a calendar module that publishes event data two ways: as HTML, and as iCalendar. Last week I happened to meet the site's coordinator; she wondered why their event stream had dropped out of syndication. I explained, and she wrote back the other day saying: "We're in the process of converting back to Drupal for events!"

    Drupal is a great system, and that's fine, but it shouldn't be necessary. Every CMS that produces an events page should also produce an iCalendar feed. When I talk to CMS vendors they confirm what I've said here: Customers don't ask, so vendors don't provide. What I also hear from them, though, is that producing an iCalendar feed seems like a lot of work. It isn't. Libraries are available to simplify the translation from programming-language data structures to iCalendar feeds. And even without such libraries, it's not hard to whip up a simple iCalendar feed.

    My vision for a network of iCalendar feeds is inspired by the early blogosphere's network of RSS feeds. Content management systems, like Radio UserLand, produced those feeds automatically. But many of us also produced our own feeds without the aid of kits. We did it "by hand" -- that is, by interpolating variables into XML templates. It was easy to do, and it worked well enough to enable our homegrown feeds to participate in the emerging RSS ecosystem. In this week's companion article I show how the elmcity service uses a library to produce iCalendar feeds. But if you look at the sample feed at the end of that article, you'll see that -- like the RSS 0.9 many of us created by hand -- it isn't really rocket science.

    There was, of course, another reason why the homegrown approach worked as well as it did. It's true that we didn't have tools to help us write RSS feeds, but we did have a tool to validate them. The Feed Validator, originally created by Mark Pilgrim and Sam Ruby, was -- and remains -- a pillar supporting the RSS (and now, RSS/Atom) ecosystem.

    When I set out to bootstrap an iCalendar network, I realized that there was no analogous service to validate iCalendar feeds. So I reached out to Doug Day. He's the author of DDay.iCal, which is the open source library that the elmcity service uses to parse the iCalendar feeds it gathers into each hub, and also write iCalendar feeds that merge all of the inputs to each hub. Doug thought there should be a validator for iCalendar feeds, so he stepped up to the plate and created one at icalvalid.cloudapp.net.

    If you're a school or a business or a band or a club whose website sports an Events tab that doesn't offer a companion iCalendar feed, I hope you'll ask your CMS vendor why not. If you're one of the vast majority of CMS vendors whose systems create events pages but don't produce iCalendar feeds, I hope you won't wait to be asked. With or without tool support, it's not hard to make them. (See this week's companion article for a C# example based on Doug Day's DDay.iCal library.) And, thanks to Doug, there's now a validation service to help you make them right.



    Related:




    Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.

    Don't be the product, buy the product!

    Schweinderl