Syllabus: Fall 2015
A short, focused tech project
PUB607 is the MPub program’s Publishing Technology Project course.
The course will be run in two 5-week sessions, one in September and one in March to precede and follow PUB605 Fall and PUB606 Spring project courses respectively.
The Publishing Tech Project’s goals are to provide a context in which MPub students can:
- gain hands-on experience working with a range of digital technologies;
- gain experience working on a decent-sized, structured IT project full of the kind of ambiguities and unknowns that typically characterize such projects;
- develop an appreciation of documentation-driven project management;
- experiment with new technologies without serious (business) consequences.
The backbone of the Project is documentation. You will begin with documentation, proceed by documenting what you are doing and why, and end with a document that reports on what you have achieved and what you have learned. This strategy gives you the means of organizing your priorities, keeping your team-members abreast of all new thinking and development, keeps a record of your decisions and rationales, and provides a means of evaluating what you’ve achieved.
During the course of the project you will learn the basics of how to produce an eBook. However, the focus of the course is not in teaching you all the ins-and-outs of eBook Production, but rather the key skills necessary to successfully work with and publish digital objects (of which eBooks are just one type).
We will devote a lot of time and attention to text manipulation and Web publishing skills, but along the way we will also look at file formats, document format conversion, version control, regular expressions, the command line, and even some unix command line tools.
The fall 607 project is at once simple and ambitious: you will convert a long-form story published online into an eBook. At a minimum, your eBook should be a readable version of the original Paul Ford story, but in the best instances it will retain some of the essence of the original, have some elements of your own, and be an optimized experience for an eReader.
There is a lot going on in the original story, and it will not be possible (or desirable) to replicate it faithfully. Therefore, the challenge before you is to learn the limitations of the ePub format, and then identify the key aspects that you want to focus on in your version. Then, of course, to implement those aspects as best you can.
We will meet every Friday afternoon. Additionally, your team will meet itself, and you’ll meet with the instructor as often as needed. Assignments from Friday are generally due Wednesday morning the following week, unless otherwise noted. The following is a rough outline for the project:
Session 1. Friday Sept 11
Logistics and plan, followed by a crash-course on HTML and CSS to help you break down what is going on in a Webpage.
- Name your team.
- Read What is Code?
- Clone or download the code to What is Code?
- Install a text editor and pandoc.
- Identify resources and tools you might use. Login to this site, and share them.
Session 2. Friday Sept 18
An overview of digital formats for the Web and offline. An explanation of the difference between proprietary and open formats, and a look the role of standards (why they are so great, and why so many people ignore them). On the practical side, we will look at what is involved in converting between them using Pandoc: “the Swiss-army knife” of markup format conversions.
- Write a project proposal: what is your overall plan and vision? What format/eReaders will you target? How will you divide the work? do you have a timeline of when things will be done by? (only partial/incomplete draft due this week).
- Make your first attempt at creating your basic ePub file from the source document
Session 3. Friday Sept 25
A look at text manipulation and an introduction to Natural Language Processing, with a focus on Regular Expressions and some unix command-line tools.
- Test your current progress on a couple of eReaders.
- Update your proposal as needed, submit final version.
- Regular Expression competition.
Session 4. Friday October 2 (all day)
Presentation coaching with Poh Tan
A Regular Expression Competition with guests John Maxwell and Alex Garnett.
A look at metadata, what it is, why it matters, and how it is used. We will look at DublinCore, ONIX, and think about how books move through a distribution network and reach their audiences.
- Update your proposal to include a brief distribution, discoverability, marketing plan for your book. By what channels and mechanisms will it find its audience, and will its audience find it?
- Prepare for presentation.
- Start your project report that summarizes the documentation of your process.
Final Session: Friday October 9
Presentation coaching with Poh Tan
- Finalize and submit your project report online.
Final Session: Friday October 16
The presentation will be in the afternoon of Friday the 3rd (room TBA). Each team will take the stage to show and tell about its project. Everyone must have a speaking role. You should plan your presentation to showcase your final product, but most importantly to highlight some of the decisions you made, challenges you faced, and the lessons you learnt.
Grades are divided as follows:
- Weekly assignments – 10%
- Proposal – 15%
- Final report – 45%
- Final product – 15%
- Presentation – 15%
The proposal will be graded on your team’s ability to think through the problem, foresee challenges, identify resources, and succinctly present your thinking in writing.
The final report’s grade will be based on your design decisions, your chosen areas of priority, along with their rationale, as well as your approach to implementation. The grade will also consider the quality, completeness, and level of reflection in your documentation.
The final product will be graded on the resulting outcome, based on your project proposal. Projects that do what was proposed successfully will be rewarded in this section. The level of complexity of your proposed design will be taken into consideration (i.e., a complex design that was not implemented perfectly may receive the same or even higher marks than a simple design that is flawless).