Help me pick a framework!
Posted: Sat Sep 16, 2006 8:43 pm
Obviously, there's no one-size-fits all. Therefore, I'm going to ask you guys for some recommendations based on the nature of the project I have been enlisted to do. Learning a framework is a very time-consuming process so I'd rather not pick the wrong framework and have it fighting with me the entire way. Know an app that fills these needs? Even better!
The application will be something like this:
Workflow Software for a School Newspaper
Background:
The essential timetable for producing a newspaper is thus: editors for each section of the newspaper create lists of articles that they would like to have in the next issue. The Editors-in-Chief approve the list, and then they then notify their writers through email the topics. The writers write the articles and email them back, and by a certain time all needed articles for the newspaper are done.
The editors then go through the first iteration of revising and editing the articles. After they've finished, they get submitted to the editors in chief for superreview. With that done, the content can now be laid out on the spreads. Final superreview, and then the spreads get sent for publishing.
There are a few dedicated artists for illustrating stories, stock photos are also occasionally used. Advertisements also must be managed.
The Problem:
Without a centralized repository for documents, the drafts, spreads and images are notoriously fragmented throughout many places such as email account and library computers. Ever gone home from a layout to do a few final touchups and realize that the advertisement was left on the desktop of a library computer? Overzealous staff accidently delete your files? Need to get that photo that's on that other person's email account? Sorry mates, you're out of luck.
Furthermore, having the documents scattered all over the place makes it a lot more difficult to publish a web-version. Doing this sort of thing becomes an exercise of copy and paste, a tedious process that isn't very appealing.
The Solution:
In the past, we've used FTP to some extent for thigns that absolutely must be accessible everywhere, for example, the final layouts. However, we've found that FTP is not the most intuitive interface, and something easier to use would probably nicer for people.
The solution, then, is to create a web application that manages the workflow of the newspaper. The amended workflow would then go like this:
1. At the start of the year, the application is fed the new set of contact information (especially emails) for all staff members, as well as the departments they are assigned to. Accounts are given to all staff.
2. At the beginning of a newspaper cycle, the editor-in-chief sets deadlines for the articles on the web interface and all editors automatically get notified (most actions will result in automatic notification)
3. When editors have article lists, they post them on to the web-interface
4. The editor-in-chief reviews the lists and approves/disapproves items
5. Editors then can click a "send topics" button which notifies all writers under their jurisdiction which topics are available
6. Writers log on and accept topics: as they are accepted, they become inaccessible to other writers (first-come-first-serve). They are notified of article deadlines.
7. When writers have finished their articles, they copy paste the text into a rich text editor (which preserves formatting) and saves them on to the website.
8. Editors then are able to access initial copies and perform the first revisions. They make the changes to the draft and save. Using version history, we now have the original writer's version, and the amended editor's version. A "difference" feature will be enabled allowing anyone with proper priviledges to see exactly what was changed.
9. After initial edits, the editors-in-chief perform a final review, making minor corrections as necessary
10. The version is finalized, and accessed by editors during layout to be placed on spreads. We can optionally mandate that any formatting edits be merged back into the central repository
11. With one click, all approved articles can automatically be published on to an online Hawkeye website, perhaps at the same time or before the publishing of the hard-copy newspaper. There is also the possibility for out-of-cycle stories that get published only on the webiste.
So... any comments? I'd also like estimates on how big the application would have to be to fit these needs.
The application will be something like this:
Workflow Software for a School Newspaper
Background:
The essential timetable for producing a newspaper is thus: editors for each section of the newspaper create lists of articles that they would like to have in the next issue. The Editors-in-Chief approve the list, and then they then notify their writers through email the topics. The writers write the articles and email them back, and by a certain time all needed articles for the newspaper are done.
The editors then go through the first iteration of revising and editing the articles. After they've finished, they get submitted to the editors in chief for superreview. With that done, the content can now be laid out on the spreads. Final superreview, and then the spreads get sent for publishing.
There are a few dedicated artists for illustrating stories, stock photos are also occasionally used. Advertisements also must be managed.
The Problem:
Without a centralized repository for documents, the drafts, spreads and images are notoriously fragmented throughout many places such as email account and library computers. Ever gone home from a layout to do a few final touchups and realize that the advertisement was left on the desktop of a library computer? Overzealous staff accidently delete your files? Need to get that photo that's on that other person's email account? Sorry mates, you're out of luck.
Furthermore, having the documents scattered all over the place makes it a lot more difficult to publish a web-version. Doing this sort of thing becomes an exercise of copy and paste, a tedious process that isn't very appealing.
The Solution:
In the past, we've used FTP to some extent for thigns that absolutely must be accessible everywhere, for example, the final layouts. However, we've found that FTP is not the most intuitive interface, and something easier to use would probably nicer for people.
The solution, then, is to create a web application that manages the workflow of the newspaper. The amended workflow would then go like this:
1. At the start of the year, the application is fed the new set of contact information (especially emails) for all staff members, as well as the departments they are assigned to. Accounts are given to all staff.
2. At the beginning of a newspaper cycle, the editor-in-chief sets deadlines for the articles on the web interface and all editors automatically get notified (most actions will result in automatic notification)
3. When editors have article lists, they post them on to the web-interface
4. The editor-in-chief reviews the lists and approves/disapproves items
5. Editors then can click a "send topics" button which notifies all writers under their jurisdiction which topics are available
6. Writers log on and accept topics: as they are accepted, they become inaccessible to other writers (first-come-first-serve). They are notified of article deadlines.
7. When writers have finished their articles, they copy paste the text into a rich text editor (which preserves formatting) and saves them on to the website.
8. Editors then are able to access initial copies and perform the first revisions. They make the changes to the draft and save. Using version history, we now have the original writer's version, and the amended editor's version. A "difference" feature will be enabled allowing anyone with proper priviledges to see exactly what was changed.
9. After initial edits, the editors-in-chief perform a final review, making minor corrections as necessary
10. The version is finalized, and accessed by editors during layout to be placed on spreads. We can optionally mandate that any formatting edits be merged back into the central repository
11. With one click, all approved articles can automatically be published on to an online Hawkeye website, perhaps at the same time or before the publishing of the hard-copy newspaper. There is also the possibility for out-of-cycle stories that get published only on the webiste.
So... any comments? I'd also like estimates on how big the application would have to be to fit these needs.