netCase Editorial Workflow System Final Report by Kristen Gladiuk

netCase Editorial Workflow System

net Case over the transomâ&#x20AC;&#x201D;onto the web

Kelsey Everton, Kristen Gladiuk, Liz Kemp, Eva Quintana, Shannon Smart, and Chelsea Theriault

over the transom — onto the web

netCase - 2

Contents Meet netCase �� 3 Audience Definition �� 4 Collaborative Editing Environment �� 4 Project Overview: Macro Goals �� 5 Goal 1 �� 5 Goal 2 �� 6 Goal 3 �� 6 Summary of Research and Development �� 7 netCase and nEWS: understanding the project �� 7 Editorial Workflow Research: what works, what doesn’t �� 7 Authors and Editors: understanding our users �� 8 Realizing the Goal: paper wireframing and experimentation stage �� 8 netCase Wireframe Development Wall �� 9 Getting Intimate with WordPress: the platform and the plugins �� 11 Rethinking the WordPress Experience: back to the basics ��13 The Final nEWS Prototype: reevaluating and refining ��15 Conclusion ��15 nEWS Glossary ��16 Appendices Appendix A: Analysis of Other Editorial Workflows ��17 Appendix B: Glossary of WordPress Plugins Used in nEWS ��19 Appendix C: WordPress Plugin Directory ��20 Appendix D: Glossary of Relevant Terms �� 22 Appendix E: Web Resources �� 24 Appendix F: Screenshots and User Documentation �� 27 New Author �� 27 Returning Author �� 33 Reader ��36 Editor ��40 Appendix G: Before and After Screenshots of WordPress �� 56

over the transom — onto the web

netCase - 3

Meet netCase Although most businesses have “gone digital” in order to make their workflows and office tasks more efficient, many small magazines still rely on paper submissions and inefficient editing processes. While an online submissions and editorial system would lead to faster editorial turnaround, most editorial workflow systems do not appeal to small magazine publishers, as they are often rigid or expensive to implement. Open Journal Systems, for example, is a system that lacks flexibility: OJS users are unable to create custom roles or modify document statuses. Drupal, on the other hand, is a system that offers a vast development platform for web apps, giving users an overwhelming number of options. It is too complex to be used by many small magazines. netCase hopes to circumvent these obstacles by focusing on the most straightforward workflow and tasks. Our goal is to replace the paper submissions process used by small magazine publishers and to bring their workflow online by producing a simplest-possible, task-oriented editorial workflow system (netCase editorial workflow system: nEWS) using the WordPress platform. We endeavour to create an intuitive system that can be easily implemented and can function in multiple editorial contexts. nEWS is specifically designed for small magazine publishers. We want to provide an easily adoptable option that causes minimal complications during implementation, and requires little to no training for its users. For the past few years, student groups from SFU’s Master of Publishing Program have been prototyping editorial workflow systems specifically with small magazines in mind. These prototypes build on one another, and map out a basic system for handling submissions online, tracking various editorial processes, and providing automated notifications and prompts to members of the editorial team. A problem with some existing editorial workflow systems, including OJS, is that the data model was developed first and the user considered second. This has led to problems with user experience. netCase saw this as an opportunity to do the opposite: to start with the core needs of the users (their roles and tasks), and create a system that corresponds to those needs. netCase’s prototype addresses all submissions and the steps that occur when each enters the system. nEWS openly tracks every submission through all stages of the editorial workflow, each of which is represented by one of four statuses: Pending Review, Declined, Accepted for Editing, and Published. In order to be free, open-source, and flexible with a simple user interface, our system needed to be built on a widely-used platform. WordPress (WP) is an intuitive (taskoriented) and easy-to-use blogging platform and web content management system that has the flexibility and openness required to design a usable, easily adoptable system with single- or multi-user capabilities. WP is a widely accepted platform that works well in all web browsers and operating systems; while many rely on the free blog hosting at

over the transom — onto the web

netCase - 4

wordpress.com, users who want more functionality can take advantage of WP’s easy installation, and download the software to any web host that supports PHP (4.3 or greater) and MySQL (4.1.2 or greater). When hosted, WP allows users to customize their site with a multitude of plugins, many of which can be used to streamline the editorial process. The legion of developers behind WP are constantly updating and improving WP’s software, and new plugins are frequently created, modified, and reworked by amateur and professional developers from all over the world. Since its release in 2003, WordPress has become a ubiquitous fixture in online content management systems; from CNN and NASA to personal blogs, millions of websites (from obscure to well known) are adopting this flexible software. Audience Definition nEWS focuses on small publishers who are still working with paper submissions and whose primary option to upgrade from this process has been to adopt a complex, expensive, or rigid editorial workflow system. netCase has produced a basic, flexible system that is appropriate for a magazine such as subTerrain. Our editorial workflow system serves authors and editorial staff at magazines ranging in size from roughly one to twenty staff members (including interns and volunteers). This audience will benefit from a simple and centralized way to automate the various stages of processing and editing submissions – no more errant or missing documents and versioncontrol issues. While we built nEWS intending it to be adopted by a single magazine, WordPress Multi-User (WPMU) could alternately allow nEWS to be implemented at many magazines simultaneously through an umbrella organization such as the BC Association of Magazine Publishers (BCAMP). WPMU is an administrative platform for multiple WP sites that, essentially, allows an online community to be built and maintained by one administrative entity. BCAMP could easily fill this role, hosting nEWS for small local magazines and providing WP support and training to all its members. Using nEWS and WPMU, BCAMP could manage a community of magazines, with each publication’s workflow system as a separate branch. The magazines’ workflows would be autonomous from each other but directly connected to the central administrator (i.e. BCAMP). Collaborative Editing Environment To keep it simple, nEWS assumes that submissions are received into a collaborative editing environment, and has built in options for individual publishers to modify the system and add roles to address their specific needs. In collaborative editing, submissions are rated by a collective (of volunteer readers or editorial staff) and those rated highly are accepted and move along to the editing process. The reader role acts as a filter for the editor, immediately removing pieces of writing that are not suitable for the magazine.

over the transom — onto the web

netCase - 5

nEWS considers the small magazine’s editorial process from three perspectives: the author submitting work online, the reader receiving the submissions and attributing a personal rating to the piece between one and five, and the editor moving the accepted pieces through the editorial stages to final approval. We took into consideration various types of writers (i.e. first-time contributor, regular contributor, commissioned writer) as well as different types of editors (i.e. working remotely versus working in-house, copyeditor versus managing editor, etc), not to map out defined roles, but to explore various user needs in creating an uncomplicated system that is accessible from multiple points of view. Project Overview: Macro Goals Our approach has been to define and research our project in a broad sense before narrowing down to concise, specific, and obtainable goals. There were three key components to our action plan: gain an understanding of editorial workflow, gain an understanding of WordPress, and come up with the best way to integrate the two.

1. Understand and define an “ideal” editorial workflow system from multiple perspectives of author(s), reader(s), and editor(s).

We became familiar with the theoretical editorial management system proposed by last year’s MPub group, Fl!p Systems. We used Fl!p Systems’ project report and paper prototypes (or wireframes) as a rough guideline, but did not want to get caught up in the details of their structure. Based on what we learned from Fl!p, from John Maxwell’s Online Management Model for Magazines (OMMM) prototype, and from additional research, we created our own wireframes of an uncomplicated, basic nEWS. Wireframes helped us to understand and test how different types of users would work through the system, and allowed us to identify problem areas as we tested the system’s functionality. We were fortunate to have Brian Kaufman from subTerrain and Mary Schendlinger from Geist to work with us in testing our wireframes. Both provided extremely valuable feedback. We also analyzed and compared other editorial workflow systems, including Adobe InCopy Live Edit and Hotbed (another SFU student project), to better understand their strengths and their limitations. This research enabled us to prioritize the functions we wanted to include in nEWS (or not). Please see Appendix A for a summary of our findings. After developing our background knowledge and expanding on the functions of a prototypical editorial workflow system, we narrowed our project down to include only the simplest tasks in the editorial process: submitting, accepting/declining, and editing. Because

over the transom — onto the web

netCase - 6

we did not want to require magazines to reorganize their editorial process in order to adopt nEWS, our system had to be simple and flexible enough to accommodate them.

2. Learn how to apply the relevant and practical functions of WordPress to nEWS.

netCase learned about WP and became comfortable using it as a multiple-user platform. netCase had a multiple-user, collective editorial process that was not altogether unlike that of a small magazine, so our team used the http://www.ccsp.sfu.ca/editorial blog as a starting point to gain hands-on familiarity with WP and its plugins and to test some of its features for collaborative editing. We compiled a list of potentially useful plugins (taking special note of those plugins with positive user-comments, a high number of downloads, and earlier dates of creation), ranked them in order of importance and relevance to our system’s goals, and evaluated them through a trial and error testing process. The criteria for a plugin to be considered for nEWS were:

• • • • •

compatibility with the latest version of WP (2.9.2 or higher) a simple installation process (no extra embedding procedures, etc.) no bugs or error warnings when in use uncomplicated administration (should be easy to change settings) absolute necessity for nEWS; its functionality must be a high priority, not a trivial extra

For a glossary and directory of the plugins we considered and used, please see Appendices B and C.

3. Create a simple editorial workflow system using WordPress.

After receiving comments from our test users, we revised our wireframes and began to realize nEWS in the WordPress platform. We decided on three editorial workflow user types— Author, Reader, and Editor —and customized screen options and enabled plugins so that each user type would have the capabilities and functionality needed to complete their stage of the editorial process. We narrowed our short-list of plugins down to the essentials, the top three of which are Edit Flow for custom submission statuses, Capability Manager for defining what each user is allowed to do within the system, and Adminimize for hiding WP features from certain users (please see Appendix B for a summary of all plugins nEWS uses). For aesthetic but functional WP changes that there were no plugin for, such as changing button colours and increasing font size, we hacked the source code and customized the site ourselves. Our short development time meant that nEWS’s overall simplicity and functionality was our highest priority, so we worked to simplify and test the user experience as much as possible and continually tweaked the system in response to our findings.

over the transom — onto the web

netCase - 7

In the end, the building blocks for a straightforward nEWS prototype in WP were a combination of plugins that let us edit the default document statuses, tweak the capabilities of each user type, and customize the page features to remove superfluous widgets. Summary of Research and Development netCase and nEWS: understanding the project Upon receiving our assignment, we named our group netCase, and came up with the tagline “over the transom – onto the web.” Both our group name and tagline tie into the idea of taking an existing, on-paper editorial process and seamlessly and painlessly converting it to an online system. Right from the start, our biggest priority has been to come up with a system that is dead simple to use – one that is easy for publishers to adopt and understand so that they aren’t deterred by a steep learning curve, rigid structure, or complicated interface. Our project’s goal was to move a magazine’s editorial workflow online for efficiency, while respecting their methods of moving a text through their in-house editorial process. We wanted to provide a viable alternative to the overwhelming editorial workflow systems used by (and designed for) large publishers. Editorial Workflow Research: what works, what doesn’t Our first task was to familiarize ourselves with the way small magazines, such as subTerrain and Room, currently handle editorial workflow. We quickly learned that each magazine has a different editorial process, but there were certainly commonalities, as documented by Fl!p Systems. Fl!p outlined four common steps: evaluation (does a piece proceed for consideration or is it declined?), negotiation (between members of the editorial team and with the author to discuss a submission’s acceptance), editing, and output. netCase chose to design a system that could take a document from submission through the first three stages – up to the point when a document is edited and ready for publication, but hasn’t yet been typeset or designed in the magazine’s page layout. Our rationale for these stages was to keep it simple, and to keep the scope of our project realistic and easily implementable. We also wanted to avoid the rigidity of constrained stages that a submission must flow through in order to reach completion. At the same time, we looked at other online editorial workflow systems to get a sense of how they handle submissions and the various steps of the editorial process. In particular, we learned that OJS, a system built for academics, is heavily data-dependent and too tied to the academic model to work for magazine publishers – its roles and requirements are inflexible and are not adaptable. We compiled a list of the pros and cons of several different editorial workflow systems to inform our project as well as generate ideas to keep in

over the transom — onto the web

netCase - 8

mind while we were building our system (please see Appendix A for “Analysis of Other Editorial Workflows”). Authors and Editors: understanding our users A key step in our process was for each member of our team to think through an ideal editorial workflow environment from a different target user’s perspective. Our intent was not to build different “roles” into the system, but to carefully consider what different users would expect and want from an editorial workflow system. We called this brainstorming “playing Barbies,” taking our cue from a presentation by Monique Trottier (of Boxcar Marketing). Through this process, we explored the perspectives of different types of contributors and different types of editors. Each member of netCase took on one role to explore the different user experiences. Our roles were first-time author, seasoned author, commissioned author, first reader/intern/ volunteer, assistant editor, and managing editor. When “playing Barbies,” the idea is to create a persona for your hypothetical user to understand what they want and need from the system and anticipate their needs and potential frustrations. We brainstormed from these perspectives to identify which features each user would expect from an editorial workflow system. The Barbies exercise let us identify key expectations for each role that we kept in mind for wireframing nEWS. As we started wireframing nEWS, a key decision that we made was to look at the editor’s side of things from the position of the “omniscient editor” (or managing editor). This means that instead of providing many different levels of editor permissions, we focused on what an editor with access to all administrative features will be able to do. We feel this is the most flexible and adaptable model – and magazines will need these qualities in a system. By making this “omniscient” stage as simple as possible, it can only get simpler for users with decreased levels of access; the goal is to make nEWS the “simplest thing that can possibly work.” Realizing the Goal: paper wireframing and experimentation stage With a concrete understanding of what nEWS should provide for its users, we put pencil to paper and got visual. Beginning with an Author submitting an article, we started at the login page and progressed screen by screen. After registering as a user, the path for a submitting author was designed to be linear and uncomplicated.

netCase Wireframe Development Wall

over the transom â&#x20AC;&#x201D; onto the web

netCase - 9

over the transom — onto the web

netCase - 10

Our main concerns from the Author’s perspective were:

• Creating an account as a user (by supplying basic information about themselves

and the submission) • Submitting the piece in a convenient format (cut and paste from MS Word) • Providing a thank you/confirmation notice to reassure that the piece was submitted successfully Our proposed editorial wireframe was inherently more complex than the Author’s. The editorial perspective lacks a linear path as it deals with more than one submission at a time. After establishing what the Editor’s homepage should look like (a comprehensive view of the pertinent information for every submission, not including the full text), we determined the different statuses that a submission could be in. By using the word “status” rather than “stage,” we are implying that submissions do not have to pass through a rigid editorial process. nEWS originally included six statuses, but feedback from industry experts helped us narrow it down to four:

• Pending Review - The default status for each new submission. Readers read and

evaluate submissions while they are Pending Review • Declined - Indicates that the submission has been deemed unsuitable for the publication • Accepted for Editing - Indicates that a submission has been accepted for publication to the magazine and is entering the editing process • Published - Indicates that a submission has completed the editing process and is ready to move from nEWS to production The status of a submission is not restricted to a pre-established path (like the aforementioned “stages”) and can be changed at any point by the Editor. We wanted the Editor to be able to select any piece of writing to view or edit from the Homepage. Ultimately, the page view should be the same no matter what status the submission is in – however, we designed a label at the top of each page to indicate the status. When inside an active document, our Editor’s primary concerns are changing the status, commenting on the piece, editing in the document, or looking at the history of the document. With the exception of editing in the document, these functions would be performed in a pop-up window that has the option to “Save” and the option to “Close,” which returns the Editor to the active document. To return to the comprehensive document view (homepage), there is a “Home” icon at the top of the page, allowing the Editor to return at any point. Our focus was to present and carry out the most fundamental tasks in as few steps and as few windows as possible.

over the transom — onto the web

netCase - 11

Initially, it was difficult to separate the basic needs from the novelties when sketching our wireframes. For example, should the system send an email to the author to inform them that their piece is being considered for publication? No— our mantra throughout was to “keep it simple” and that is what our first nEWS wireframes reflect. There is room to build on the foundation that we have laid out, but nEWS goes from submitting to accepting a piece of writing for publication without veering off course or confusing its users. Our next step was to test it on people from outside of the netCase team – because as straightforward as it was to us, we were keen to test an audience that could help us find and fix anything overlooked or confusing. After testing our wireframes with some other MPub students, we met with Brian Kaufman of subTerrain, who gave us some extremely valuable input on our wireframes and project plan. His suggestions included:

• Referring to pieces as “Declined”  instead of “Rejected” • The editorial aspect needs a “Reader” ability – giving the ability to vote or rank

pieces and add comments but little else (i.e. not change the submission’s status) • The managing editor might not be the only person with the power to reject or accept submissions and customize acceptance/rejection emails (i.e. some Readers might be able to do this) • Brian would like to have a record of all acceptance and rejection emails sent. In subsequent discussions, netCase realized it would be much simpler to autoforward a copy of each email sent from nEWS to an in-house email address rather than build all that into the system Our meeting with Brian was very productive and he indicated that he would like to remain involved with the process as we continued to develop nEWS. Getting Intimate with WordPress: the platform and the plugins When we began working in WordPress, we started by compiling our short-list of potentially useful plugins, searching for those that would allow us to adapt the content management system WordPress offers into the editorial workflow system we envisioned when designing our wireframes. One of our challenges was that we didn’t always know how to make WordPress do the exact things that we had outlined in our theoretical wireframes; however, we knew we would get a better idea of what exactly we needed to learn in the following weeks, as we integrated our theoretical workflow system into WordPress. Working in WordPress gave us an opportunity to troubleshoot and experience exactly what nEWS users will encounter. We received occasional error messages that said “a more recent auto-saved version is available” when page edits were saved. This issue

over the transom — onto the web

netCase - 12

resulted in lost work that reverted the document to earlier versions. Upon investigation, we found several forums online expressing similar concerns about complications created by the auto-save function. We adjusted the frequency of the auto-save, which appears to have resolved the problem. In addition, after we became more familiar with WordPress, we realized that all auto-saves can be viewed and reverted to, so there should be no fear about losing edits. We spent substantial time navigating the plugins and applying them to our WP blog. Initially we had enabled them on our netCase blog, but were concerned that changing the settings of an enabled plugin would irreversibly change the settings of our blog. As we used the netCase blog to house all of our notes and assignments, John suggested that we start a new WordPress site that would only be used to play with plugins. Our new WordPress blog (our metaphorical sandbox), “subTerrain Submissions,” was used to experiment with the plugins and bring our wireframe to life. According to online resources Tripwire (a reputable magazine for web developers and designers) and WPBeginner (a comprehensive online resource for the WP user community), the most useful plugins for multiuser blogs are Edit Flow, Role Scoper, and Capability Manager. The first plugin we enabled was Edit Flow, which introduced five default statuses: Assigned, Draft, Pending Review, Pitch, and Waiting for Feedback. Edit Flow allowed Authors to submit a post by way of a “Submit for Review” button where the standard “Publish” button is, edit the post after it has been submitted, and delete it. Authors could also see what other pages are associated with the blog but could not edit or add pages. From the Editor’s perspective, Edit Flow made it clear that a submission had come in from an Author and that it was Pending Review. The Editor could edit, preview, or trash this story. Edit Flow was undoubtedly an important plugin that we kept in mind as we sorted through the rest of our plugin options. The following were among Edit Flow’s strengths:

• The Author doesn’t have access to change the status— only the Editor does • Submissions that are Pending Review aren’t displayed publicly on the blog • There is an option to send email notifications to the contributor as well as all administrators

We had a few concerns with it that we wanted to keep in mind:

• We felt that the Author was seeing too much on the dashboard— all the post

options made the submission process seem unnecessarily complicated (but we

over the transom — onto the web

netCase - 13

were confident we could resolve this with a plugin) • We didn’t want the Author to be able to edit or trash their own submission once it had been posted The next plugin we enabled was Role Scoper, which promised to limit the capabilities of our user groups and roles. Unfortunately the user guide was outdated and not helpful, and we decided that its set-up process was much too difficult for nEWS. We chose to explore other options, since there are many other role control plugins available for WordPress. Finally, we enabled Capability Manager, which we found to be much more intuitive than Role Scoper. Capability Manager uses a basic screen with simple check boxes for limiting the capabilities of each user role in our blog. We weren’t able to get the Author to just be able to submit a piece without being able to edit or delete it— the “Publish Post” capability seemed to have no effect when enabled. Otherwise, this plugin was extremely useful and nearly perfect for nEWS. To keep track of the plugins (i.e. which ones we rejected, considered, or used in our final prototype), we created a plugin spreadsheet, which can be found in Appendix C. Rethinking the WordPress Experience: back to the basics netCase tried to activate Adminimize, a WordPress plugin that seemed to have many of the features we need for nEWS, including hiding unnecessary items from the administration menu and hiding post meta-controls. We soon discovered that on a WPMU site, only an overall administrator (like John) could activate Adminimize. After we gained access to Adminimize, we tested, customized, and restricted three of WP’s built-in roles: author, editor, and contributor (which we used to realize netCase’s roles of Author, Editor, and Reader, respectively). netCase created an Author profile, “Yann Martel,” and began going through the steps of account creation, article submission, and the other steps in the nEWS Author process. We created a separate landing page for Authors that is different from the one the editorial team will see when they log in. We also took screenshots of the entire process in order to document the development of nEWS. (Please see Appendix F for full visuals and documentation). We experienced a considerable amount of frustration with finding a plugin to allow readers and editors to rate unpublished posts. In our meeting with Brian Kaufman, he expressed interest in a review system where members of the editorial team could rate

over the transom — onto the web

netCase - 14

submissions on a scale from one to five; a rating plugin will help magazines wade through the “slush pile” of submissions, using a collective process to judge whether a submission should be declined or accepted. One of the first plugins we tried was GD Star, which initially seemed far too complex for our purposes. However, after exhausting the other rating plugins out there, we ended up back with GD Star Rating, and have manipulated its capabilities to suit our purposes. It is working well, and provides a “click-tovote” rating bar at the bottom of each post, when viewed in Preview. We have successfully used Adminimize to hide the GD Star Rating dashboard from the author. When the netCase team wasn’t hard at work mastering the art of plugin manipulation, we addressed the various other goals that remained outstanding. netCase met with Mary Schendlinger of Geist magazine to run some of our ideas by a professional editor, as we did with Brian Kaufman in Week 3. As a result of our user testing with Mary, we made some critical changes to our wireframe and theoretical editorial workflow system:

• An “On Hold” status is unnecessary.

We had intended this to mean that a document was being saved for future consideration, and that its activity was intentional. But Mary pointed out this would just lead to documents being ignored, and it imposes “our” editorial workflow on magazines, rather than answering to the magazines’ specific needs. An effective editorial workflow system could, as Mary suggested, assign an issue number to every accepted article; that number would specify the issue that text is for, even if it’s far down the road. This way the editors can forget about the article until the moment they need to start editing the new issue.

• An “New” status is unnecessary.

Mary pointed out that Readers shouldn’t be able to see either other’s rating or comments, because that could affect how they critique and rate them. Instead of a separate New status, submissions could go straight to Pending Review, which would mean that an article is being read by the different Readers. A Reader would click on a text he had not yet rated and was marked as Pending Review. Brian, on the other hand, would be able to see that there were new submissions (under Pending Review) and whether or not they had yet been rated.

• Change status terminology to “Pending Review,” “Accepted for Editing,” and “Ready to Publish.”

Mary pointed out that acceptance happens much earlier in the process than after editing is completed, as we had in our original wireframe. Changing the status to Accepted for

over the transom — onto the web

netCase - 15

Editing will generate a customizable acceptance email, and indicate that the document is now entering the editing process. The Final nEWS Prototype: reevaluating and refining We chose to recreate our final netCase prototype in a brand new site, http://press.ccsp. sfu.ca, which is not connected to any other SFU MPub sites through WPMU. This gave us the opportunity to document our settings and further restrict unnecessary options. We enabled a plugin called FV Clone Screen Options, which allowed us to limit the view of extraneous plugin control boxes that could not be hidden by use of the Adminimize plugin. As we had simplified nEWS to the best of the abilities of our plugins and user settings, the next step was to go into the actual CSS code of our WP site and customize the site by removing uniquely WP features, changing font sizes, colours, button names and locations, etc. to mimic our wireframes as best as possible. We redesigned basic aspects of the WP site to be more friendly to magazine authors and editors by incorporating words like Submission, Issue Number, and Pending Review in place of the WP’s default use of Post, Tags, and Publish, respectively. To assist editors who like to print out submissions, we created a CSS print style sheet so that printing from the website was nicely and properly formatted. After conducting further user testing with our MPub colleagues, we made additional semantic and aesthetic changes — removing profile options, including instructions, etc. — to make the author experience more straightforward. The final stages of our project were dedicated to polishing the mechanics of the system through further hacks of the CSS style sheet to make the site’s language and layout consistent with the traditional editorial workflow of a small magazine. Conclusion After seven weeks of research and development, netCase achieved our three macro goals of understanding editorial workflow, learning to use WordPress, and creating nEWS (a simple editorial workflow) within WordPress. We feel that our prototype is the simplest thing that could possibly work. Overall, we are confident that we have created a basic, flexible framework for editorial management that met our initial specifications. Our result is nEWS: a simple, intuitive system that an Author, Reader, or Editor can navigate easily without any egregious barriers to use. If we had more time to continue development, there are a number of possible areas for expansion. Ideally, nEWS would be visually consistent with the host magazine’s own website, creating a seamless interaction where users don’t feel like they’re on a separate website. This would require creating personal theme templates with magazine branding, which is certainly possible within WordPress. Additionally, with more development time, we would consider creating our own plugins to address nEWS-specific challenges,

over the transom — onto the web

netCase - 16

such as a practical “Track Changes”–like plugin, very simple rating system, or a way to automate the manual aesthetic changes within WordPress. Also, we would have enjoyed working in-house with a magazine (such as subTerrain) to oversee the actual implementation of nEWS. The future of nEWS is filled with opportunities. Our final result — a prototype with no frills and the basic functionality needed for an editorial workflow system at a small magazine publisher — can be viewed as a building block for the next generation of MPub students creating and customizing an editorial workflow system. nEWS Glossary Accepted for Editing - The status of a document that is actively being edited in the nEWS. Author - Someone who submits their written work to the magazine; may be involved in a collaborative editorial process. Declined - The status of a document that has been submitted and will not be accepted for the magazine; can occur if either readers have assigned it low ratings, or at the managing editor’s discretion. Editor - The magazine’s “highest level” nEWS user; they have ultimate authority over acceptance, editorial, and administrative decisions. Pending Review - The default status when a new document is submitted to nEWS. Submissions remain in this status until all ratings have been received and it is Declined or Accepted for Editing. Reader - The magazine’s “lowest level” nEWS user; they are tasked with reading submissions and rating them, which indicates whether they should be Accepted for Editing or Declined (can always be overruled by the managing editor). Published - The final status for a document that is done the editing process and will be passed on to the next step in production (external to nEWS) and will be published in the magazine. **Through a plugin called Capability Manager, we’ve modified the default Wordpress roles of author, contributor, and editor to reflect the nEWS editorial roles of Author, Reader, and Editor, respectively.

over the transom — onto the web

netCase - 17

Appendix A: Analysis of Other Editorial Workflows Positive features From Fl!p Systems: (in priority order) - Colour-coding, intuitive presentation of ideas - Choice to Copy & Paste submission into WYSIWYG editor or upload Word .doc file or other file types - Sidebar with Comments/Suggestions that moves along through editorial process with submission - Editorial projects can be viewed by “All Projects” or by issue (likewise, can view by status) - All actions are logged/tracked by each user’s unique ID - Centralized repository for submissions, edits, images etc. - Submission of manuscript is accompanied by basic ABI information, supplied by the author - Automatic Confirmation email to Contributor once Submission is uploaded The OMMM Project: - Emphasizes Tasks over Roles - Attention given to the fact that not everyone uses Word .doc formats Adobe InCopy LiveEdit:

- Team can follow each other’s progress

- Team members are prevented from overwriting one another’s work – useful feature, in a modified form - Can make notes on text - Takes very little time to import a file, and is compatible with many file types

over the transom — onto the web

netCase - 18

Hotbed: - Outlines the needs of a small magazine: user-friendly and intuitive, open-source, self-policing workflow, version control, built-in workflow w/ designated roles, tracking & overview, email notification, designed for literary publishers Aspects to improve Fl!p Systems: - Rating system, may just need to be expanded on or reworded - Can submissions in Text Edit be edited with track changes? Comments/Suggestions panel eliminates need for bubbles if so - Dislike the term “bucket” for different stages of the editorial process - Reader “retrieval” during the submission stage (unclear whether the Reader is prompted by the EMS when new doc comes in) - Unclear who the “Reader” is, and how texts are assigned to different Readers - Meeting is part of workflow’s submission acceptance sequence – maybe we could have a built-in scoring system or some other mechanism that allows everything to be done remotely? - Doesn’t seem to consider the step before evaluation, which is submission: also needs to be intuitive and workable for the submitter Adobe InCopy LiveEdit: - Different file names (.indd, .inca…) to contend with - Because it’s not web-based, extra steps have to be taken for editing outside of the local network Hotbed: - Dependant on a programmer who knows HTML and PHP for set up and maintenance - More complicated system than we want to work towards

over the transom — onto the web

netCase - 19

Appendix B: Glossary of WordPress Plugins Used in nEWS Adminimize: lets you hide unnecessary items in the WordPress administration menu, submenu and Dashboard according to user role. Capability Manager: allows admin to change the capabilities of any role, add new roles, copy existing roles into new ones, and add new capabilities to existing roles; this helps to structure the custom use-cases seen in the nEWS, such as by author, reader, and managing editor. Display Widgets: adds check-boxes to each widget (as long as it is written in the WordPress version 2.8 format) which will either show or hide the widgets on every site page. By default, Hide on Checked is selected with no boxes checked, so all current widgets will continue to display on all pages. This plugin is useful to customize the nEWS site in order to make it appear as simple as possible. Edit Flow: improves multi-user editorial workflow through adding/editing/managing custom statuses, visualizing content and priorities at a glance in a dashboard widget by tracking meta data, and sending email notifications. It was created to improve the administrative interface for a multi-user newsroom’s editorial workflow, and addresses some of netCase’s key concerns about highlighting the meta data that indicates where a project is in the workflow, as well as building a way to visualize content in the workflow. Email Users: allows you to send an email to the registered users of the site. Users (in this case, only editorial staff) can send personal emails to each other. FV Clone Screen Options: lets you manage Screen Options of all the users on your blog by setting your own Screen Options and then cloning them across all users; a great timesaver. GD Star Rating: allows you to set up a rating and review system for posts. You can set many options for displaying the rating stars, and add widgets into the sidebars for displaying top ratings and other statistics generated by the plugin. Includes advanced settings panels that will allow you to control many aspects of rating. This plugin allows readers to vote on which posts should move forward into the editing process. Show Post Busy Status: Adds a new column to the post-management list that lists the status of a post as “busy” when another user is editing that post. This is useful for nEWS since it saves editors from entering a post when the author or other editors aren’t finished editing it yet.

over the transom — onto the web

netCase - 20

Tiny MCE Advanced: Enables advanced features and plugins in TinyMCE, the visual editor in WordPress. Allows us to customize the tools available to users when they need to edit a post.

Appendix C: WordPress Plugin Directory Plugins used in nEWS

Version

Last Update

Compatibility

Useful?

Works?

Description

Adminimize

1.7.7

Mar-10

WP 3.0.0

Yes

Hides items on Dashboard

Capability Manager

1.3.2

Feb-10

WP 2.9.2

Yes

Change role capabilities

Display Widgets

1.1.0

Mar-10

WP 2.9.2

Yes

Show/hide widgets on each page

Edit Flow

0.3.3

Feb-10

WP 2.9.2

Yes

Multi-function editing tool

Email Users

3.1.8

Aug-09

WP 2.8.4

Yes

Emails single or multiple users

FV Clone Screen Options

0.2.0

Feb-10

WP 2.7.0

Yes

GD Star Rating

1.8.6

Mar-10

WP 3.0.0

Yes

Show Post Busy Status

1.0.0

Aug-08

WP 2.5.1

Yes

TinyMCE Advanced

3.2.7

Dec-09

WP 2.9.2

Yes

Advanced features on visual editor

Plugins for extra functionality

Version

Last Update

Compatibility

Useful?

Works?

Description

Audit Trail

1.1.5

Jan-10

WP 2.9.2

Perhaps

Tracks user actions

Cimy User Extra Fields

1.5.2

Mar-10

WP 2.9.2

Perhaps

Limit user fields, access

Cleverness To Do List

1.5.0

Mar-10

WP 2.9.2

Perhaps

Private/shared to do lists

Dashboard Heaven

0.1.0

Mar-10

WP 2.9.2

Perhaps

Hides dashboard widgets

Peter’s Collaboration Email

1.3.4

Jan-10

WP 2.9.2

Perhaps

Sends email as post status changes

Revisionary

1.0.1

Feb-10

WP 2.9.2

Perhaps

Simple Nav Archives

2.0.3

Nov-09

WP 2.9.2

Perhaps

WP Status Notifier

1.3.0

Sep-09

WP 2.8.4

Perhaps

Manages Screen Options of all users A star rating system for posts Post status is ‘busy’ when in editing

Submit changes for editorial review Groups archives by month/year Notifies contributors of accept/ reject

over the transom — onto the web

netCase - 21

Plugins we discarded

Version

Last Update

Compatibility

Useful?

Attachment Extender

0.2.0

Aug-08

WP 2.5.1

Update files in Media Library

Author Exposed

1.0.0

Mar-08

WP 2.3.3

Shows author info

Co-Authors

1.0.0

Jul-09

WP 2.6.2

Links authors to post

Contestant Rating

0.2

Mar-10

WP 2.0.2

digress.it

2.3.0

Nov-09

WP 2.8.4

Dynamic Widgets

1.2.3

Mar-10

WP 2.9.1

Favourite Posts

0.0.1

Oct-07

WP 2.3.0

Stars posts as “favourite”

Future Posts Calendar

1.0.0

Mar-08

WP 2.5.0

Shows future posts

Get Author Profile

0.5.1

Jan-06

WP 2.3.0

Access author profile info

Display author’s gravatar

Gravatar Plugin for Authors

Works?

Description

Allows users to rate posts No

Comment in margins Gives control over widgets

Hide Admin Panels

0.9.8.3

Mar-10

WP 2.7.1

Hide Dashboard

1.5.0

Dec-09

WP 2.9.0

Highlight Author Comments

1.0.2

Aug-08

WP 2.6.1

Custom comment styles

I Like This

1.7.1

Mar-10

WP 2.9.2

Visitors “like” posts

IWG Hide Dashboard

1.0.3

Apr-08

WP 2.5.0

Hide dashboard features

List Authors

1.2.0

Jul-09

WP 2.9.2

Displays a list of authors

Our To-Do List

1.3.1

Aug-09

WP 2.8.4

Share ideas/to-dos in a list

PollDaddy Polls

1.8.5

Mar-10

WP 2.6

Post Avatar

1.2.7

Feb-10

WP 2.9.2

Choose from list of images

Post by Author

1.7.0

Feb-09

WP 2.8.0

Shows list of author’s posts

Post Reminder

0.2.0

Mar-09

WP 2.7.0

Notifies when a post is needed

Pre-Publish Post Reminder

5.0.2

Dec-09

WP 2.9.2

Reminder list for posting

Leave messages on Dashboard

Related Posts by Category

0.6.0

Mar-10

WP 2.9.2

Order posts by category

Report Posts

1.0.0

Jan-09

WP 2.7.0

Report inappropriate posts

Role Scoper

1.1.7

Feb-10

WP 2.9.2

Access control

Starred Review

1.4.2

Sep-09

WP 2.0 No

Send email to users

Simple Yearly Archives

1.1.3

Jan-10

WP 2.9.2

Lists archives by year

Subscribe to Comments

2.1.2

Dec-10

WP 2.3.1

Receive comment notifications

User photo

0.9.4

Dec-08

WP 2.7.0

Assign a photo to profile

Limits users to categories

Colourful tag cloud

Quick Notes on WP Dashboard

Send Private Email

Userextra

Hide panels for specific users No

Hide dashboard from users

Manages polls from Dashboard

Posts reviews to website

WP-CMS Post Control WP Colorful Tag Cloud

2.0.1

Feb-10

WP 2.9.2

WP-Polls

2.50

Jun-09

WP 2.8

Includes polls in blog

over the transom — onto the web

netCase - 22

Appendix D: Glossary of Relevant Terms Content management system (CMS): a web CMS is designed to simplify the publication of Web content to Web sites, in particular allowing content creators to submit content without requiring technical knowledge of HTML or the uploading of files. Dashboard: an administrative homepage on WP that allows quick access to useful tools through blocks called modules (Right Now, Recent Comments, Incoming Links, Plugins, etc); also provides glimpses into other areas of the WP community. Editorial workflow: the life cycle of an editorial submission and the tasks that accompany each stage, from the time a work is sent in to a publication, to the selection and preparation of the submitted material, to when the material is ready to be published. Editorial roles: different functions performed by users in an editorial workflow, such as Manager, Editor, Copyeditor, Proofreader; may be organized hierarchically and have varying access to files or areas of a database. Editorial management system (EMS): see “Editorial workflow system.” Editorial workflow system (EWS): a CMS that organizes editorial submissions and manages editorial workflow; a.k.a. “Editorial management system (EMS),” with EWS being netCase’s preferred term. When referring to our project we use nEWS, which stands for netCase editorial workflow system. Fl!p Systems: a theoretical EWS created by a group of last year's MPub students based on commonalities between several magazines’ editorial processes. The Fl!p Systems model involved four overall stages: evaluation, negotiation, editing, and output. Gall’s Law: a law that states that a complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system. Hotbed Editorial Management System (EMS): a content management system created by a group of 2008 MPub students based on Open Journal Systems (OJS) software. Meta data: “data about data,” whether descriptive (keywords used to search and locate an object), structural (a description of how the components of the object are organized) or administrative (technical information including file type).

over the transom — onto the web

netCase - 23

MySQL: a relational database management system (RDBMS) that runs as a server providing multi-user access to a number of databases; used by WordPress. OMMM Project: the Online Management Model for Magazines is a project of the Canadian Centre for Studies in Publishing focused on creating a workable editorial workflow system for small BC magazines. It has looked at expanding OJS and the theoretical framework of Fl!p Systems. Open Journal Systems (OJS): open-source software for the management and publishing of scholarly journals. Open source: software where the end product (and source material) is available at no cost to the public; enables peers to produce enhanced versions, and encourages diversity. Plone: a free and open source content management system built on top of the Zope application server. Plone can be used for any kind of website, including blogs, internet sites, webshops and internal websites. It is also well positioned to be used as a document publishing system and groupware collaboration tool. The strengths of Plone are its flexible and adaptable workflow, very good security, extensibility, high usability, and flexibility. More at Plone’s website (plone.org). Plugins: a computer program that interacts with a host application (a web browser or an email client for example) to provide a certain, usually very specific, function “on demand.” Revision (or change) tracking: tracking what was added, edited, or deleted from a document, and who made the change as well as when they made it. Use-case scenario: an account of how a user accomplishes a particular task when interacting with software or other systems. Version control: the management of multiple revisions of the same document. Website Wireframe: a basic design draft used to suggest the structure of a website, its user paths, user interface elements, their position, and the relationships between pages. A wireframe is brought together in a sequence of pages to illustrate paths of navigation and interactions on the page. Wireframes allow for the development of variations of a layout, visually arranging the most important elements of the interface. This is an important part of the initial development stage because it creates user expectations and helps develop familiarity with the site. A wireframe is also useful in establishing the type of language, content, and structure of various user interactions with the site (i.e. in regards

over the transom — onto the web

netCase - 24

to netCase website language: “submissions, manuscripts, drafts, etc”). It is a practical tool to understand the functionality of a site and how a hypothetical user works through your system and where engagement begins. A wireframe precedes the surface design but comes after the strategy, creating a paper trail of the decisions that are made in between. WordPress (WP): an open-source blog publishing application powered by PHP and MySQL which can also be used as for basic content management. It has many features including a workflow, a plugin architecture, and a templating system. WordPress-MU: stands for WordPress Multi-User. This builds upon the original WP model, which supports one blog per installation (site). WPMU allows any blogger to start their own blogging community, as it supports multiple blogs per installation. It also allows that one community-starting blogger to moderate all the blogs from one dashboard. Workflow: a sequence of connected steps, or a depiction of a sequence of operations, declared as the work of a person or group of persons, an organization of staff or one or more simple or complex mechanisms. WYSIWYG: an acronym for What You See Is What You Get. Content on screen appears as it will when printed out. A WYSIWIG editor lets you easily format text (for example, bold, bullet points, justify text, etc.)

Appendix E: Web Resources “The Flexibility of WordPress,” http://blog.themeforest.net/wordpress/the-flexibilityof-wordpress/ This article lists some of the ways WordPress has been used so far: for example, as a Content Management System, to design professional portfolios, for real estate business, and for film reviewing. The text broadens the readership horizons, letting them know new ways for using software that is usually viewed as a blog publishing tool only.

Fl!p Systems Editorial Workflow Model from PUB607-09, http://thinkubator.ccsp.sfu. ca/wikis/PUB607-09/editorialWorkflow/FinalReport In 2009, Fl!p Systems interviewed a variety of publications and presses in order to identify a common, underlying editorial workflow process. They consolidated their findings into a model consisting of four basic stages: evaluation, negotiation, editing, and output. This model clarifies the various stages of editorial workflow which netCase needs

over the transom — onto the web

netCase - 25

to address through our WordPress system. Page three of their report outlines last year’s model for how a flexible EWS could work. It can be viewed here: http://thinkubator. ccsp.sfu.ca/wikis/PUB607-09/editorialWorkflow/uploads/FlipPresentation.pdf.

Hotbed Editorial Management System – Project report from PUB607-08, http:// thinkubator.ccsp.sfu.ca/HotbedsFinalPresentation Hotbed, a team from the 2008 MPub class, devised an editorial management system (EMS) intended for use by small literary magazine publishing operations. They worked with BCAMP (BC Association of Magazine Publishers) and Room to research and prototype a content management system (CMS) based on Open Journal Systems (OJS) software. The model requires some knowledge of HTML and PHP, and also some graphic-design skills. The EMS was intended to increase efficiency, move submissions and rejections to an online forum, and allow for contests and subscriptions to also be handled on the web. In designing the EMS, Hotbed took into consideration all the same issues that netCase did: simplicity and ease-of-use, that it is inexpensive, that the workflow automatically moves forward based on designated roles, that changes can be tracked, that emails notify the next editor in the workflow, and that it is specifically geared towards small, literary publishers.

John Maxwell, The OMMM Project documentation, http://thinkubator.ccsp.sfu.ca/ wikis/ommm/OMMMProjectTowardACollaborativeEditorialWorkflow The OMMM (Online Management Model for Magazines) Project was created in SFU’s Canadian Centre for Studies in Publishing to see if Open Journal Systems (OJS), a successful free/open source software, could help manage the submission of articles to small magazines. The project examines OJS’s editorial workflow and its limits in functionality for small magazines. The project also introduces Fl!p Systems, which netCase will consult for a structural understanding of its own task. This resource is the 2009 follow-up to Maxwell’s “Extending OJS into small magazines.”

Kirk Biglione, WordPress training videos, http://wordpresstraining.com/trainingindex/ Kirk’s training videos are numerous and detailed. They offer a good starting point for new WP users, and also allow those familiar with the software to expand their knowledge and improve the look and usability of their site. Topics include creating content, managing posts, creating pages, fighting spam, discussion settings, privacy settings, custom-

over the transom — onto the web

netCase - 26

ization through themes and plugins, widgets, upgrades, importing and exporting data, managing users, explanation of user roles, managing files, and the WP dashboard.

Tripwire Magazine, http://www.tripwiremagazine.com/ TripWire is a reputable magazine for web developers and designers that provides insight into new technologies and, in particular, WordPress plugins that have been prevalent throughout the course of our project.

User Pathways, “The what, when and why of wireframes”, http://userpathways. com/2008/06/the-what-when-and-why-of-wireframes/ This post provides answers to the important questions that lead to an understanding of what a wireframe is, why we use it, how we use it, when we use it, the different types and how we can make them. This is key post for our understanding so we have a clear objective when we begin to wireframe our nEWS.

WordPress, “The Features You’ll Love,” http://en.wordpress.com/features/ The various features of WP are summarized to give a big picture look at how many directions the software can move and how truly flexible it is. This is a good resource for our team to discover the features that are most pertinent to our nEWS.

WP Beginner, “21 Great Plugins to Manage Multi-Author Blogs Efficiently,” http:// www.wpbeginner.com/plugins/21-great-plugins-to-manage-multi-author-blogsefficiently-and-successfully/ This is one of the most useful resources for managing a multi-user blogging platform. This articles lists and describes 21 WP plugins that all have potential for streamlining our NEWS.

over the transom — onto the web

Appendix F: Screenshots and User Documentation New Author

A new author arrives from the magazine website to the nEWS landing page.

New author clicks on “Create an Account” and is prompted with a registration page.

netCase - 27

over the transom â&#x20AC;&#x201D; onto the web

New author creates a user name and enters her e-mail address.

Registration is complete and Kristen Hilderman is prompted to check her e-mail.

Kristen retrieves her automatically generated password and clicks on the login link.

netCase - 28

over the transom â&#x20AC;&#x201D; onto the web

netCase - 29

Kristen enters the user name that she created and the auto-generated password.

Kristen arrives at her Profile page and is prompted to fill in the â&#x20AC;&#x153;requiredâ&#x20AC;? information.

over the transom — onto the web

netCase - 30

Kristen enters the required information and clicks on the “update profile” button at the bottom of the profile page.

Kristen’s profile has been updated and she clicks on “Submissions” to submit her work.

over the transom — onto the web

netCase - 31

Kristen arrives at the “subTerrain Submissions” page to submit her piece of writing.

Kristen enters the title of her work, she pastes her story directly into the WYSIWYG text field. She selects a category as “Essay” and clicks on “Submit for Review” to send her piece to the magazine.

over the transom â&#x20AC;&#x201D; onto the web

netCase - 32

After submitting her piece for review, Kristen gets a message that her piece has been received and is prompted to either log out or submit another new piece. She decides to log out.

Kristen has successfully logged out of nEWS.

over the transom — onto the web

netCase - 33

Returning Author (who has submitted to the magazine in the past)

Returning author arrives at the landing page and clicks on “submit your piece here.”

Returning author enters his user name and password – James Franco! What an honour!

over the transom — onto the web

netCase - 34

James Franco arrives at the “subTerrain Submissions” page to submit his new piece.

James fills in his title, the body of his work, checks “Fiction” as his category and clicks “Submit for Review” to send it to the magazine.

over the transom â&#x20AC;&#x201D; onto the web

netCase - 35

After submitting his piece for review, James gets a message that his piece has been received and is prompted to either log out or submit another new piece. He decides to log out. The editors are thankful for this decision.

James has successfully logged out of nEWS.

over the transom — onto the web

netCase - 36

Reader

Reader arrives on the nEWS landing page and clicks on the “Admin” tab to login as an employee/volunteer/intern of the magazine.

Reader clicks on “Administrator sign in here” to login.

Reader arrives at the login page.

over the transom — onto the web

netCase - 37

Reader logs in with her user name and password.

Reader arrives at the home page in preparation to read and rate new submissions and clicks on “pending review.”

Reader can now view all new submissions that are “pending review,” the default status in nEWS. She clicks on the “preview” button under the submission title.

over the transom — onto the web

netCase - 38

By clicking “Preview,” the submission opens in a new window and allows her to only read and rate the piece of writing. The reader’s task from here is to only read, then rate using the 5-star rating system built into the bottom of each new submission.

over the transom — onto the web

netCase - 39

After reading the piece, Reader gives the submission 5/5 stars and closes the tab to return to the “Pending Review” submissions.

Reader arrives back at the pending review submissions page and logs out.

Reader is now logged out.

over the transom — onto the web

Editor

Editor arrives on the nEWS landing page and clicks on the “Admin” tab to login as an employee of the magazine.

Editor clicks on “Administrator sign in here” to login.

Editor arrives at the login page.

netCase - 40

over the transom â&#x20AC;&#x201D; onto the web

netCase - 41

Editor logs in with his name and password.

Upon logging in, Editor arrives at the home page and clicks on the â&#x20AC;&#x153;Pending Reviewâ&#x20AC;? submissions link to check the ratings on the latest submissions.

Editor previews a submission to see how the interns and volunteer readers have rated it.

over the transom — onto the web

netCase - 42

Editor sees that the submission has received an average 4/5 stars and after reading it himself, decides that it will published in the next issue of the magazine. He closes the tab, returning to the “Pending Review” home page.

He clicks on the submission title to enter the editing screen in order to change the status from “Pending Review” to “Accepted for Editing.”

over the transom — onto the web

netCase - 43

Editor arrives at the editing screen and will first change the status of the submission.

Editor clicks on the drag-down menu and highlights “Accepted for Editing” and clicks “UPDATE.”

over the transom — onto the web

netCase - 44

After clicking on “UPDATE,” Editor must click “Save as Accepted for Editing” to confirm that he wants to move this submission onto the next status.

After confirming, the status is updated and Editor receives an update confirmation at the top of the page.

over the transom — onto the web

netCase - 45

After updating the status, Editor emails the author to notify them that their submission has been accepted by the magazine. He clicks on the “Email author that submission status has changed” button in the top right corner of the editing screen.

over the transom — onto the web

netCase - 46

Upon arrival at the e-mail page, Editor clicks on the “Email” button in the toolbar on the left to change the body to an acceptance letter. With the volume of submissions that magazines receive, they inevitably decline more submissions than they accept, therefore the default email template in the system is a declination letter.

Editor arrives at the “Send an email” page and clicks on the individual user icon to send an email to one user (with the alternative being sending to a group).

over the transom — onto the web

netCase - 47

Editor selects the author to whom they are sending the acceptance letter from the list of recipients. Editor pastes the magazine’s template acceptance email into the body text and personalizes it with the author’s name and some additional comments, then presses “Send Email” to send the acceptance letter to the author.

Editor gets a confirmation that their acceptance email has been sent to the author.

over the transom — onto the web

netCase - 48

Editor returns to the editing screen to begin working in the document and to assign the submission to the Fall 2010 Issue of the magazine. He begins typing Iss.... in the “Issues” text field on the right, and a list is automatically populated with the next two years of issue numbers of the magazine. Editor clicks on “Issue 2 - Fall 2010” and “Add.”

The submission is now assigned to “Issue 2 - Fall 2010” and Editor begins to make changes in the body text of the document. After making changes, he clicks “UPDATE” to save his edits in the document.

over the transom — onto the web

netCase - 49

After clicking on “UPDATE,” Editor must click on “Save as Accepted for Editing” to confirm these changes to the document.

After confirming the changes, Editor gets a “Post Updated” notice at the top of the page and knows that his edits have now been saved in the document. Next, he clicks on a link under “Post Revisions” to view edits that have been made in the document.

over the transom — onto the web

netCase - 50

Editor arrives at the “Post Revisions” page and is now able to choose the specific dates to view and compare revisions. He then clicks on the “Compare Revisions” button.

Editor can now selectively view and compare past revisions at his whim.

over the transom — onto the web

netCase - 51

After determining that the submission is done editing and is ready to move onto the production stage, Editor clicks on the “Publish” button to move the document out of nEWS.

Editor receives a confirmation that the submission has been “published,” the status has now changed to “Published,” and the document is now out of nEWS. He returns to the “Pending Review” submissions page.

over the transom — onto the web

netCase - 52

Editor returns to the submissions page to read another piece. Although the “published” submissions that have left nEWS are no longer needed by Editor, he can still view them by clicking on the “Published” link at the top.

Editor previews a new submission that is “Pending Review” and decides that it is not right for the magazine and he is going to send the author a declination email.

over the transom — onto the web

netCase - 53

Editor enters the editing screen to change the status from “Pending Review” to “Declined” and send the author a declination email. He follows the same status-changing process as he did for the last submission (sequence pictured below).

over the transom â&#x20AC;&#x201D; onto the web

netCase - 54

Editor follows the same process for sending an email, however, he already has the template declination email ready to be sent off. He selects the author whose work he is declining and sends the email.

over the transom â&#x20AC;&#x201D; onto the web

netCase - 55

Editor receives a confirmation that the declination email has been sent to the author. After a full day of reading and reviewing submissions, changing statuses, editing, and sending acceptance and declination emails, Editor is ready to log out of nEWS.

over the transom — onto the web

netCase - 56

Appendix G: Before and After Screenshots of WordPress Standard WordPress “Dashboard”

Customized nEWS “subTerrain Submissions” Homepage

over the transom — onto the web

netCase - 57

Standard WordPress “Add New Post” page

nEWS author-customized “Submit New Piece” page

over the transom — onto the web

netCase - 58

Standard WordPress “My Public Profile” page

nEWS customized “Profile” page