CategoryStudent Content

Project: Room. Team Promotion’s Final Document

 

Pub 607

April 11, 2016

Team Promotion

Amaris Bourdeau, Sarah Corsie

David Ly, Alanna McMullen, &  Zoë Tustin

Abstract

The purpose of this project was to create a podcast and e-newsletter as a means to promote the 2016 Journal of MPub. The podcast and e-newsletter cover different subjects related to publishing that have be addressed in student essays. While podcasts and e-newsletters are largely considered “unsocial” forms of media, we have exploited social media to create a dialogue between users. Our audience, to whom we’re promoting the Journal of MPub, can be found on the web. We therefore found the enablement of this discussion crucial. The promotional plan below will detail our promotional strategy, our financial summary, and the creation of our podcast and e-newsletter, including our SEO strategy and our relationship with iTunes.  

Continue reading

Team DAT!Analysis Project Report

Team DAT!Analysis: Project Report

Content Analysis & Data Visualization of MPub Project Reports and TKBR Essays

Alice Fleerackers, Monica Miller, Josh Oliveira, Alison Strobel, Zoe Wake Hyde

This project was conceived as part of a wider undertaking by the Master of Publishing class of 2015 to explore the creation of a new J​ournal of MPub,​showcasing the work they have produced throughout the year. Our team’s contribution to this was to collect the current work, as well as that of past cohorts, and see what insights could be drawn from them.

Our final report details the process by which our team collected, processed and analyzed three years worth essays from the PUB 800 and PUB 802 courses that are located on the school’s TKBR site, as well as fifteen years worth of project reports from the SFU institutional repository, Summit. Our goal was to gain a deeper understanding of the content generated by SFU’s Master of Publishing students.

Download the full report as a PDF

The Book of MPub 2016

The Book of MPub 2016 is the culmination of our efforts in MPub’s Digital Technology Project.

The idea behind The Book of MPub is the creation of a digital space where SFU’s Master of Publishing students can engage an interested audience with their project deliverables and the goings on of their cohort. We have collectively re-imagined what this web-based project might look like based on the original Book of MPub, published in 2010. We have used different tools and technologies to think through—not build—everything from production workflow to audience analysis.

This is the landing page for The Book of MPub’s Twitterbot. The Twitterbot aims to engage an audience on Twitter that may be interested in the ideas of these future publishers.

#bot: project plan & deliverables

A beautiful project by Katherine, Gillian, and Erik.

We are creating a Twitterbot to engage with people interested in the Canadian publishing industry. Our bot will publicize the work done in MPub—as a stand-in for The Book of MPub, we will use our colleagues’ essays on the TKBR server to engage our audience. We have broken our process into three steps: “The Manual Work,” “The Ideas,” and “Coding and Testing.” A tentative fourth step (time permitting) will involve an audience analysis of our bot’s followers or related networks.

Step One: The Manual Work

The first step involves researching the basics and collecting information. We are currently learning about Javascript, Twitter’s API documentation, and the twit Twitter API client. We are also researching general approaches to building a Twitterbot audience.

Further to this, we brainstormed key topics and hashtags for our Twitterbot, and created a list of important publishers for our bot to be following, based on people we (as individuals, and the existing MPub twitter account) are already following and thus aware of.

We emailed the mpub-15 list for permission to share the essays published on TKBR, identifying key themes of each and tracking responses in a spreadsheet. This will help us to select particular #topics to focus on.

Lastly, we each created Twitter accounts in order to practise our JavaScript skills. An account for our bot was also created separately from these accounts.

Step Two: The Ideas

Next, we brainstormed bot behaviours. These will include:

  • following relevant accounts on the basis of their description (key terms in bio), who their followers are (ie. important publishers), or their behaviour (tweets about a topic)
  • following back people who follow us
  • retweeting particular topics and certain specific #hashtags
  • tweeting @ new followers
  • tweeting out links to new essays posted on TKBR; tweet new podcasts, newsletter
  • tweeting old essays to people who:
    • follow us and then mention the relevant #topic
    • mention a relevant #topic enough times in a certain period of time (tbd)
    • tweet @ us and mention the relevant topic anywhere in tweet

Step Three: Coding & Testing

In this step, we will implement, test, and assess the utility of each bot behaviour. Independently, individual group members will use their own Twitter account to write and test each piece of code. Once we’re confident that it works, we will compile it into a single master document. This document will also include code necessary to keep our bot working within Twitter’s rate/access limits and run smoothly over a longer period of time. Ultimately, we will upload the bot to the TKBR server.

The Deliverables

Our deliverables will include:

  • our rough work (such as completed spreadsheets)
  • our functioning Twitterbot (JavaScript documents) with a number of behaviours
  • a specification sheet detailing bot behaviours and an assessment of their functionality (such as effects on audience growth and engagement)
  • our report, including:
    • our decision-making process for deciding topics and behaviours
    • documentation of our development and learning process
  • time permitting, an audience analysis of our Twitterbot’s followers

Project Plan: DAT!Analysis

By Alison Strobel, Monica Miller, Zoe Wake Hyde, Josh Oliveira and Alice Fleerackers

Overview

We at Team DAT!Analysis want to gain a deeper understanding of the content generated by SFU’s Master of Publishing students. We are curious how—or perhaps whether—MPub writing has transformed throughout the years to reflect changing societal and industry trends. We want to know how events such as the rise of social media or the financial crisis of 2008 have altered the kind of things we write about as publishing students and the way we write about them.

We are also curious how the kind of writing published on TKBR differs from that published in SFU’s Summit Research Repository. Are the TKBR posts more blog-like? Are they more closely tied to current events? How does the sentence length in TKBR posts compare to the Project Reports? The TKBR posts also present a unique opportunity to conduct some more detailed analysis using the associated metadata. Does the time of day published affect the sentence length of posts? Are the tags students assign truly effective descriptions of their essay topics? What factors (if any) influence the number of links and sources used throughout a post?

These are just some of the questions we might investigate over the course of our analysis. We hope that the results of our investigation will provide greater insight into what is being written in the publishing program and why—findings that could be used to inform acquisition strategy and site organization for the forthcoming Book of MPub 2016.

Plan

To conduct our analysis, our team will have to execute the following steps. For efficiency’s sake, these steps can be executed concurrently (using sample data) by different team members.

Collect & Extract

We will download the past three years of Technology essays from TKBR by using either the WP JSON API or by writing an SQL script to collect directly from the database. Josh and Alison will take the lead on the TKBR scrape.

At the same time, we will collect the 297 PDFs in Summit Research Repository’s Publishing Program – Theses, Dissertations, and other Required Graduate Degree Essays Collection. We will need to write a web scraping script with Python to download the PDFs. We will then use another Python script to download the PDFs and convert them to text files for analysis. Zoe will be heading this step.

Clean

While collection is occurring, Monica will investigate how to clean up the data using a small sample of WordPress posts. She will use Google’s OpenRefine to conduct the cleanup of the TKBR essays.

Analyze

Once the data has been cleaned, we will use MALLET (MAchine Learning for LanguagE Toolkit) to conduct our analysis. We will build identify common topics and examine their evolution over time. We will conduct analyses both between and across our two data sets (i.e. compare TKBR to Project Report data and investigate overall trends within MPub writing in general). Alice will take the lead on exploring MALLET’s capabilities.

Visualize

We plan to create some data visualizations of our findings using Tableau. This may include building word clouds, stacked bar charts, heat maps and more to chart topic frequency over time and visualize lists of terms that frequently occur together.

Document

We will document our work with frequent screenshots and notes which we will later compile into a formal report. We will structure this final document like a scientific report, with Introduction, Purpose, Methods, Results, and Discussion sections. It will include our most useful data visualizations, outline key findings, and offer some context for understanding our results. For example, we may choose to compare topic evolution in our dataset with the evolution of the same terms on Google NGram Viewer. At this point, we will also assess the usefulness of our analyses within the context of the Book of MPub 2016.  

Present

We will share our process and findings with the class in a fun but informative presentation.

Deliverables

  1. Web scraping script for locating and downloading  PDFs from SFU’s Summit repository
  2. SQL script for extracting text from TKBR posts from database OR steps used to interact with WordPress JSON API
  3. Complete data set: both cleaned and raw data
  4. List / detailed steps for cleaning data in OpenRefine
  5. Overview of MALLET analyses performed and results
  6. Tableau visualizations of key findings
  7. Final Report

Timeline

  • Mar 18 Proposal due (Alice)
  • Mar 21 Initial research due (all) and data collected (Josh & Alison, Zoe)
    • Each member has explored their assigned tool
    • We will use class to fill each other in on our findings
    • Data is collected and ready to clean
  • Mar 24 Data extracted and cleaned (Monica/all)
    • Data is ready to start MALLET analysis
    • Team has compiled list of questions to investigate
  • Mar 29 Data analysis due (Alice/all)
    • Team meets to discuss findings and conduct data visualizations
    • Start working on final report
  • April 4 Pre-final deliverables due
    • Start working on presentation
    • Revise and finesse report
  • April 11 Final document and presentation due

eWeavers’ iBooks proposal for “What is Code?”

Maggie Zhao | Daryn Wright | Susmita Dey | Joshua Oliveira | Kathleen Burckhardt | Alison Strobel

The eWeavers’ vision is to create an ebook for “What is Code?” using the iBooks application and marketing it on that platform. We chose this platform because iBooks works on multiple Apple devices, including iPads, iPods, iPhones, and computers. The application can be synced across all the platforms enabling transition from one device to another. In addition, these devices provide multiple features, not only book reading. For example, you can have access to your music library on the same device that carries your books. This is something that cannot be done on a Kindle or other dedicated eReaders.

We believe that the subject of “What is Code?” attracts a particular reader, one that is interested in learning more about coding to better understand how it is used in a professional setting. The iBooks application is particularly appropriate for this type of audience with busy lifestyles because of its accessibility from different locations (work computer, iPhone, home iPad etc.). With this audience in mind, we will transform the original article into an ebook that informs and entertains, maintaining its colorful and playful nature.

From online article to ebook:
Our aim is to maintain the spirit of the original article. The playfulness of the article is its main selling point, and our primary goal is to maintain the integrity of the original article while considering ways of making it better – and more enjoyable to read – than the original.
Our goal is to create an epub3 file that will be more interactive and will allow us to include moving GIFs and functional videos.
The original Pandoc-converted file reads on iBooks as a scrambled, less-than-cohesive mass of information and photos – and all under a single chapter. Chapter headings appear at the bottom of the previous page – rather than at the true start of a chapter – or between paragraphs, appearing more as a long-form article (its original form) than a book. Enabling chapter splits and starting each chapter on a fresh page will give the text room to breathe, and allow the reader to pause and absorb what she just read. In addition, the spacing of words and the alignment of paragraphs is inconsistent for a book. Put simply, we will make the text look like it fits in a book, rather than on a website.

There is also a problem with the way photographs are currently appearing. Most of them are left justified, which doesn’t always play to the strengths of the image or to the copy, particularly when the photos are small. It appears as if they were shoved aside and forgotten. We plan to amend this problem, and either place images center justified or create space for them within the text, as we see fit. We will also remove any images or graphics that don’t contribute to the book’s overall design or readability; the original imagining of the article was the right format for some of these graphics, but we find that they don’t necessarily work in this context. Another issue with the images is that they are not all automatically resized to fit the page or section, but instead some photos take up the whole page while others are small and hard to see. We aim to fix this inconsistency.

Design and style:
We value the importance of the design and original artwork and are interested in investigating how it relates to, and enhances, the article itself. This means we will incorporate elements of colour, where appropriate, and graphics into the body of our ebook. We believe this will maintain the spirit of the text’s playfulness. The overall presentation of the book is important to us, so we plan to spend a considerable amount of time working on the design and format.

Reflowablity:
We want to keep the epub reflowable, as is the default in iBooks. However, we intend to investigate the sizing of the pictures and the formatting of additional elements around the text so that the reflowable feature works well and maintains the readability of the book.

Table of Contents:
The book will feature a table of contents due to the text’s many subheadings and unwieldy length. To increase interactivity, and the ease of reading, the table of contents – main headings as well as the sub-headings – would link to the locations of their respective entries.
Moreover, having a TOC will also create a strong foundation for the form of the book. This will move away from the original long-form article style and give it the more traditional structure of a book.
We are also aware that the purpose the article serves is largely educational, and we feel that including clear chapters and subheadings will lend better to an audience that is looking for a clear answer to the question “what is code?”
In order to do this, we will split the document into individual chapters and then link these sections to the table of contents.

The pop-up question:
We plan to include the pop-up message that originally appeared at the beginning of the article as an epigraph. This will make the transition from website to ebook more apparent, and will contribute to the “bookiness” of the text as an ebook rather than as an article.
In regards to the pop-up side notes throughout the original piece, our goal is to use the epub3 pop-up feature to create a similar effect.
For the footnotes, our goal is to have them open up in a new window, so readers have the option to read them or not. This is less distracting than traditional footnotes at the bottom of the page and also lends to the appeal of the interactivity of the ebook.

Title Page:
The background on the original webpage for “What is Code?” is very colourful, something we believe works well with the dot com aesthetic. We plan to create a title page for our ebook based on these colours and the original typeface used for the title. This will act as a signal to readers that this ebook is, indeed, related to the online version. It is also a colour palette that is suitable for the content. Our initial approach to this will be to play with the html and see if we can create this colourful patterning. We might also look into the possibility of utilizing Photoshop if the html proves to be limiting.
Tasks:
We have assigned roles for each group member to research and test. While we each will be focusing individually on specific tasks, there will be overlap and support as needed. We plan to meet together as a group at least three times in the next two weeks to coordinate and discuss difficulties in person. In addition, we will work remotely with each other using email and Dropbox. These roles will be broken down as follows:

Text Formatting: Susmita, Alison, Kathleen

  • ­reflowable text
  • epub3 research
  • epigraph
  • table of contents
  • chapter & subheading breaks
  • chapter alignment and presentation
  • text wrap around images

Graphics: Josh, Maggie

  • graphs, tables, and footnotes
  • removing unnecessary logos, gifs, graphics
  • incorporating videos where appropriate
  • resizing images

Design: Daryn, Maggie

  • cover page
  • alignment of photos, graphics
  • colour framing in body of text

Projected timeline*:

Task Completed by
• gathering resources Friday, Sep. 18
• testing various readers/deciding on one Friday, Sep. 18
• finalizing division of tasks/overall focus Monday, Sep. 21
• draft I of proposal due Wednesday, Sep. 24
• decide on file format (epub3 vs. epub) Friday, Sep. 25
• draft II of proposal done Monday, Sep. 28
• removing unnecessary logos & graphs Monday, Sep. 28
• Submit final proposal Wednesday, Sep. 30
• cover page Thursday, Oct 1
• finish table of contents Sunday, Oct.4
• chapter, subheading breaks Sunday, Oct. 4
• epigraph Sunday, Oct. 4
• reflowable text Monday, Oct. 5
• pop-up footnotes Monday, Oct. 5
• alignment of photos, graphics Monday, Oct. 5
• colour-framing in body of text Monday, Oct. 5
• inserting videos, where appropriate Monday, Oct. 5
• report/documentation draft I Monday, Oct. 5
• testing of eBook on Apple platforms Tuesday, Oct. 6
• finished final written report Friday, Oct. 9
• presentation preparation Saturday, Oct 10

*Note that this timeline indicated due dates for tasks but most tasks were started in mid September that are “completed by” early October.

dot-commas’ ebook proposal – final

The dot-commas ultimately aim to produce an .epub that is as cross-platform compatible as possible. Specifically, our final product will be legible and comfortably-designed for as many different e-readers as possible, although we will prioritize its functionality in more common and more up-to-date software.

Broadly, we want our .epub of What is Code? to be as accessible as possible to multiple audiences. We acknowledge that the original article, written for and published by Bloomberg Businessweek, is targeted to a more corporate or “executive” audience (Bloomberg’s typical readers, and evidenced by the “Man in the Taupe Blazer” narrative), for whom magazine or web formats are highly appropriate. In .epub form, we want What is Code? to reach a variety of casual readers in addition to those reading for information; this necessitates a final document that holds legibility as its primary goal. For example, we agreed that many of the interactive features of the web version of What is Code?, though interesting, were distracting, and were in any case highly inappropriate to an ebook format. We believe that prioritizing general ease of use and access complements Paul Ford’s aim in writing, which is to educate on a topic that often seems confusing or complicated.

Major Changes

The online version of What is Code? incorporates several unique interactive features and animations, such as the interactive keyboard or the questionably-charming blue robot character, but these can often be distracting to the reader. They are entirely inappropriate for e-readers, especially given the smaller screens; furthermore, most are non-functional in all but the most recent technology, breaking completely in older readers.

In-line pop-ups are also a feature of the website’s HTML, which we are using to build our .epub. They contain both notes, which supplement the text, and acknowledgements of corrections or help, usually from github users. Pop-ups will absolutely not work in the most widely-usable .epub format, and while they will not display, they should nevertheless be removed. We will attempt to reformat the notes, and will attach a page of acknowledgements at the end of the .epub as necessary.

ss_wic_3 ss_wic_4 ss_wic_5 ss_wic_6

Finally, when most of the necessary HTML has been written, we will rearrange objects remaining in the text (images, notes, &c) to better fit the .epub layout. This will have to be done on a case-by-case basis, but will particularly apply to the larger images found near the ends of sections, or to supplementary info, such as the “productivity” object, whose size can cause them to mess up formatting or not display properly.

Functionality

Making our .epub widely usable as well as consistently attractive compels us to keep in mind the requirements of a range of popular devices, which differ not only in performance and compatibility (i.e. with specific EPUB3 features) but also in their displays, from low- to high-resolution and featuring a variety of e-ink, e-paper, and LCD screens. We questioned whether the document’s many colour images would render properly on monochrome devices, but this is unlikely to pose a significant problem. Taking this into consideration, however, we will try to avoid colour-coding aspects of the text.

Our goal of cross-compatibility requires a re-flowable layout (as opposed to a fixed-layout design, which does not allow text to be resized). This may present a challenge with respect to positioning non-body-text objects; ultimately, we seek to format the publication so that the design does not distract from the information.

Design

Our focus on making What is Code?’s content as readable as possible in .epub form applies not only to legibility but also aesthetic – the resultant text should be engaging and visually pleasing.

We plan to embed specific fonts (particularly for section headers and side notes) into the .epub, with the understanding that, while these may not show up in all e-readers, they will nevertheless display on some. We can also designate alternatives to embedded fonts in CSS; for example, an alternative to Businessweek’s header fonts is Helvetica, followed by Arial, followed by a generic “sans-serif” designation. We can therefore create styles that, while not always applied in e-readers, are nevertheless consistent cross-platform.

In addition, we will assign font sizes proportionally rather than use absolute values, as per this guide, since many e-readers allow the reader to increase or decrease font sizes. Working in ems also allows us to size smaller images in proportion to the text, such as these graph icons in section 2.4: beforeaftericons

We want to explore the possibility of including the supplementary information (i.e. pop-ups) and small images from the original text as side notes or (as a last resort) foot-notes. This seems possible using the “float” CSS property. Since it is generally inadvisable to include text (i.e. captions) as image files, likely due to compression, we plan to apply this property to containers of text as well as to images.

We’d like to keep the “letter from Josh,” a pop-up in the original web text, as an introduction/preface to the essay itself. It would be included as pseudo-frontmatter and formatted so as to distinguish it from the body of the text. We can achieve this either by breaking the text into multiple HTML files or by using the CSS selector “page-break-before: avoid.” This section would, of course, not be included in our table of contents. Other data pertinent to the epub, which in a traditional book would be found in the front matter, can be written into its metadata, since it is rarely relevant to the overall reading experience.

While importing the CSS from the web version of the article will allow us to keep many aspects of the original design, we must also be wary of constraining ourselves design-wise, and make choices specific to our format.

CSS

Our overall style will be derived from the Businessweek-original CSS, downloadable along with the HTML. It can be applied when using pandoc to create our .epub, or otherwise by simply cutting and pasting the code into the automatically-generated empty stylesheet. It is worth noting that this cut-and-paste method cannot be used for HTML, since the .epub uses XHTML, which is slightly different, and which pandoc converts.

Using this received CSS, though convenient on the whole, will require us to carefully check for unused classes or styles, especially if those styles don’t apply in .epub. Overlooking some residual broken code could have a disastrous and frustrating effect on our .epub, so it is vital that we understand what we are leaving in as well as taking out.

A well-formatted stylesheet will be instrumental to our .epub. To ensure consistency, we will try to apply styles using CSS rather than HTML as often as possible. This does not preclude a need for formatting in HTML, however, as we have found that some objects do not retain all of their designated styles in the actual .epub. It seems that some large images, for example, despite having a designated “max-width: 100%”, will still display too large unless the ‘width=”100%”‘ is applied within their individual HTML tag.

Images

We plan to include as many of the original pictures from BBW as possible; this includes the more “artistic” photographs as well as informative graphs and maps. We will also consider producing additional informative images (e.g. explanatory screenshots), to further supplement and break up the text, and finding alternative images for the animated .gifs and videos that we wish to remove. It is important that all our images be formatted correctly; we can resize each images as needed using  “width=%.”

Much of the image formatting will have to be applied on a case-by-case basis, although this is something CSS and RegEx can thankfully help with. Some of the document’s more unique visual elements, such as the array of conference photos or the “productivity” list, may benefit from being formatted as tables to better fit the page.

Both pandoc and Calibre allow us to create our own cover for the .epub and to identify it specifically as such. We found the website’s animated header far too gaudy, so we will create an original cover that is simple, attractive, and representative of the material. The image itself simply needs to be created in InDesign and exported as a .jpg.

cover option: incorporates major colours from web article

cover option: incorporates major colours from web article

cover option: simplified version fashioned after print magazine

cover option: simplified version fashioned after print magazine

 

Tools

To ensure usability on as many devices as possible, we will repeatedly test our .epub throughout the design process, using tools such as Calibre, Adobe Digital Editions, Amazon’s Kindle viewer, Kobo Desktop App, and iBooks, as well as the EpubCheck online validator.

After using pandoc to convert the web article’s HTML into a rough .epub, we will use Calibre to further refine the document. We can use Calibre to edit every aspect of our .epub, and to work backward from the original document rather than starting from scratch. Calibre shows a live preview of the .epub as we code, which gives us the ability to check for major errors while we work. In particular, it will allow us to view every file contained in the .epub, such as image files, font files, navigation files, and each .xhtml file in the spine. This feature will be key to our work, since we can divide the HTML into individual chapters in order to work simultaneously and together.

Challenges

In the final stages of .epub construction, we encountered a serious problem caused by floated objects, which are supplementary notes and images in the document itself. In some readers, floated text or images, if their container is too big to fit on the page, will cut to the next page, taking all following text with it and leaving large, awkward gaps in the main text.

The CSS selector “page-break-inside: auto” remedies the problem in some readers, such as Calibre and iBooks, but does not seem to be supported in others.

One option would be to cut down on supplementary material, slashing most floated objects to maintain continuity of style across readers and throughout the document. Part 2.4 in particular is full of notes that interfere not only with the text arrangement but also with lines of code, which don’t always wrap around them properly; it could benefit from some pruning. Elsewhere, however, the notes add some levity to an otherwise-dense text.

A final solution might be to consign our notes to the end of each section, where they won’t interfere with the overall flow of the text; this would be achievable through creative use of hyperlinks, but would be distracting to the reader, and is thus a last resort.

Table of Contents

Tables of contents in .epub seem to be created in two different file formats: nav.xhtml and .ncx. Both will be relatively simple to create. Calibre will even automatically generate a .ncx file from designated headings; though the nav file must be created manually, it consists of a simple ordered list, properly linked. The table of contents will be a final step, to be done once most other work is complete. We are unsure whether the inclusion of sub-headings will improve readability or make the text seem overwhelming; a possible solution to this is creating multiple levels within our table of contents, and thereby enabling readers to hide sub-headings as desired.

Timeline

To complete our .epub, we plan to work together in the same space, so that we can get things done efficiently and help each other when needed.

All group members will install and become familiar with Calibre, working with the .epub document created in pandoc (to be completed by Sept 20).

Alanna will investigate the matter of the title page, including both design and file format requirements (to be completed by Sept 25th). She will revise the book cover we made in InDesign to use the fonts we embedded into the .epub file (in the titles) which are the same fonts that were used in the online magazine article (to be completed by Sept 30). She will attempt the coding for implementing the ‘letter from Josh’ pdf she has made into the ebook as front matter (to be completed by Oct 1). This pdf may or may not be used in the final product because it might be easier to code the existing ‘letter from Josh’ in the text of the document to look like the rest of the .epub and exist as front matter.

To convert the existing footnotes into side notes, we will go through and input the footnote text directly into the ebook (to be completed by Sept 25, by Alanna, Zoë and Sarah). From here we will experiment on how to convert these into side notes using CSS formatting (to be completed by October 1, by Katherine). We believe that to do this we will have to remove the existing footnote formatting and put footnotes into separate containers (divs).

Katherine will look into creating the table of contents and how to create an .ncx document (to be completed by Sept 28), compatibility issues, and how to include such a file in an .epub (to be completed by Sept 30). She will also embed title fonts, split the main text into separate HTML documents (to be completed by Sept 23), and research image formatting (to be completed by Sept 28). Katherine will also be responsible for re-doing the CSS style sheets and uploading them to Slack so the rest of the group can apply them to our copies of the .epub (to be completed by Sept 25). As our team member in charge of CSS, Katherine will code the page breaks and flowing text using CSS (to be completed by Sept 25).

Alanna and Zoë will search for remaining Javascript left in the document and deleting it (to be completed by October 1). They, along with Sarah, will delete the presumptuous blue robot .gif (to be completed by Sept 25).

Once the HTML is converted to .epub using pandoc, Zoë will comb through it to remove remnants of interactive elements and animations (To be completed by Sept 25).

David will look specifically into how to format and size grids for images (with the intention of creating relatively unobtrusive sidenotes) (to be completed by Sept 25). He will also compile list of potentially-useful HTML tags for resizing images and document elements (to be completed by October 1).

Sarah will look into colour compatibility issues as well as different methods of testing the completed (or in-progress) .epub (to be completed by Oct 1). She will investigate using Adobe digital editions, iBooks and other e-reading platforms to test our .epub (to be completed by Oct 5). These tests will provide us with information on whether or not colour pictures will show up in grayscale on e-readers using e-ink or whether they will show up as errors.

All team members will work on sections of HTML, which we will divide into chapters. We have shared these chapters using Slack and once we have updated a chapter, we will post the current chapter on Slack and delete the previous, outdated chapters.

Week One Week Two Week Three Week Four
Install and become familiar with Calibre using .epub of What is Code?
Investigate title page, including both design and file format requirements
Revise title page with fonts used by BBW
Look into implementing the ‘note from Josh’ as front matter
Convert existing footnotes to sidenotes using CSS styling
Create table of contents and investigate creating a .ncx file
Research responsive images
Redo CSS style sheet
Remove interactive elements and animations
Apply styles to images
Test cross platform compatibility
Modify and correct metadata
Rearrange text and image content to better suit epub format

 

 

Project Proposal – E-weavers

Proposal – Draft 1

Written by the e-Weavers
Kathleen, Daryn, Susmita, Josh, Maggie, Alison

The e-Weavers plan to create an ebook for iBooks, which is an application that works on multiple platforms and is more interactive than a Kobo or Kindle reader. Our group-specific reason is that we each have this kind of device so we can test out the ebook ourselves.

Our aim is to maintain the spirit of the original article. The playfulness of the article is its main selling point, and our primary goal is to maintain the integrity of the original article while considering ways of making it better than the original. We value the importance of the design and artwork and are interested in investigating how it relates to, and enhances, the article itself. This means incorporating colour and graphics into the body of our ebook. We hope this would bring out that original playfulness. The overall presentation of the book is important to us, so we plan to spend a considerable amount of time working on the design and format.

Type is important. It needs to be resizable and readable, but preserve the design of the individual page and the piece as a whole. We realize this might be the role of the ebook reader, not a direct function of the ebook, but we want to be sure that our document can be resized by iBooks. We want to explore whether or not it is beneficial for us to make the book reflowable or not; if we do, is this going to make the format too flexible and changeable, or will it increase interactivity? This shouldn’t be the most time-consuming of our projects, but will tie into our design process and our discovery of iBook’s many capabilities.

We plan to include a table of contents because of the article’s many subheadings and the unwieldy length of the article as a book. This way, readers can jump to whichever section they want to read right from the table of contents. The book will be organized by chapters and subheadings, creating an organized structure important for readability. We are also aware that the purpose the article serves is largely educational, and we feel that including clear chapters and subheadings will lend better to an audience that is looking for a clear answer to the question “what is code?”

It is our goal to include the initial pop-up message in the article as an epigraph. We feel this makes a good translation from website to ebook. We are considering how we will treat pop-up footnotes throughout, and plan to spend considerable time on this aspect of the book to further set it apart from traditional forms and, again, maintain the original spirit of the work. These may become static footnotes, or if we can figure out the functionality of the pop-up, we would like to keep them this way.

 

The background on the webpage “What is Code?” is very colourful. We would like to create a title page for our ebook with similar colours and perhaps the pattern as well. This is both to attract readers to our ebook, as well as forge a stronger connection between ebook and website.

For practicality reasons, we will be removing some of the GIFs that won’t function on iBooks, as well as any other little images – like Twitter icons – that no longer have a place in our version. Our hope is to make the graphs and tables throughout the article readable and that they will contribute to the content in an educational way.

We also plan to investigate additional functions like videos and other interactive elements to determine if they will work for the platform we’ve chosen. Is an epub3 going to be a viable option for us? We plan to determine this in the next week, before solidifying our working timeline and planning the finished product.

We have assigned roles for each group member to research and test on our epub file. Our timeline for this research is to come to the table on Friday with specific information as to whether our initial plans are feasible given our project deadline. Once we further investigate our individual roles and responsibilities, we will be better able to come together and create a project that is cohesive and fully-realized.

 

Our initial work will be broken down as follows:

Susmita: Creating a working table of contents

Kathleen: Investigating graphs & footnotes; will these work with our chosen platform?

Alison: Creating the epigraph

Maggie: Work on interactive elements, including the capabilities of InDesign, and the possibility of making an epub3

Josh: Cleaning up logos, GIFs, things we’re removing

Daryn: Planning and conceptualizing our design (including colour usage and visual graphics)

Tech-1 E-Book Proposal

What is Code?

A proposal by Tech-1

Challenge

Tech-1 has been tasked with converting the Bloomberg feature What is Code? into a functioning e-book.

Approach

In considering our approach to the task, we have built a clear picture of who we believe our primary and secondary markets are, and have built our specifications from there.

We envision this text being primarily read and used as reference material by people who are in contact with software developers in a professional setting who wish to build an understanding of the work that is being carried out, as well as the people who are involved with it.  To a lesser extent, we also see this text as an informative overview of code and coding that could be of interest to a more casual observer.  With these two audiences in mind we have chosen the following specifications for the e-book:

Format — Epub

This format is well-established, has broad appeal and opens access to the text across a wide range of devices.  It also allows for colour images (importance discussed below), which we have chosen as more important than the “flashy” features offered by the epub3 format.  We have deliberately chosen to eschew the epub3 as it limits access to a select few devices, which is an important consideration given that our target audiences are not necessarily early-adopters of technology.

File Size — 4MB goal

In researching file sizes for various e-books, we have found varying sources claiming a range of 300KB to 4MB, but Amazon allows file sizes of up to 650MB.  Given the image-heavy nature of the original webpage the raw epub file we will be building on was slow to transfer in our trial run, so we will aim to reduce the file size for convenience.  However, the file currently sits at 5MB and while we intend to delete some of the images, we are interested in keeping many of them so if the trade-off is between file size and a strong visual presence on a reader, we will reassess our goal.

Visual Elements — Strong presence but still-images only and fewer than webpage

Our experience of reading the original text was that the visual elements, whether still, moving or interactive, helped both with comprehension of the concepts being explained and with alleviating some of the work of reading a heavy text.  With this in mind, as well as our chosen file format, we will aim to retain the visual nature of the webpage while removing or altering elements that will not translate directly (either by converting to a still image or removing entirely), as well as some that we do not consider strong supporters of the text.  This choice has also been made in consideration of the time and resource limitations we face.  We will take into account the recommended image sizes for e-book readers, and the original web-destined image files are already small which aids us in achieving our file-size goal.

The changes and deletions of all images will be completed in HTML prior to converting to an epub file format as we have found that the process is simpler and the images are only stored in one location.  The task will be carried out as follows:

  • Create a detailed list of all images present in original webpage
  • Categorise list into ‘delete’, ‘alter’ and ‘keep as is’
  • Remove the ‘delete’ category of images from the HTML document and accompanying folders.
  • Convert the moving images into stills by extracting frames from GIFs or screenshotting where appropriate
  • Insert stills into file in place of their predecessors
  • Convert file as a whole to epub format to assess changes and adapt as necessary

Sidenotes — Transform into endnotes

The group agreed that many of the side-notes throughout the text added texture in both added information and some humour.  With this in mind we would like to retain as many as possible, excluding any corrections, and change them into endnotes linked within the text.  To ensure ease of navigation, we will also include a ‘return button’ to take a reader from an endnote back to the passage of text they were originally reading. This will be carried out as follows:

  • Use regular expressions to differentiate notes from corrections using identifier <a class=“footref correx”>
  • The notes can be similarly identified and moved to an endnotes sections using regular expressions.  

Table of Contents

We are keen to include a functioning table of contents for two reasons; firstly, that the text may be used as reference material, and secondly that it is a long, dense text so we foresee easy navigation as an important tool for a reader. This will be carried out as follows:

  • Use Sigil to create header hierarchy metadata within index file to create TOC using the <h1> designation for chapter and <h2> for subsections.

Short Paragraph Length

Again considering readability, we intend to retain the short paragraph lengths of the original text.  The experience of reading dense text on an e-reader can be unpleasant, so the paragraph breaks are another visual aid that we consider to be important.

  • use a RegEx to find

General Styling

We aim to remain true to the integrity of the original webpage with our style and formatting choices in our e-book. The original webpage feels energetic and informal, clear and to the point. Although the webpage incorporates creative illustrative/multimedia elements, the text itself is simply styled, mirroring the straightforward writing. In our e-book, we’ve chosen to use Helvetica, a clear, no nonsense font with a modern sensibility, for our headings (size 14) and subheadings (size 12). We’re pairing this with 11 pt Palatino for the body of the text–a standard e-book combination. We will align headings and subheadings centre page and set them alongside section and chapter numbers. (Currently, the numbers are set one line above the headings themselves. This leaves a lot of blank space, which looks odd on most e-readers.)

There are a few hyperlinks in the text, mostly linking to sources. We will find these links using RegEx (perhaps by searching for “href” or “http”?) and add the sources to the end along with the other endnotes. We will also use a regular expression to remove the numerous Twitter logos that are currently peppered throughout the ebook (search for: ‘<img src=”images/twitter-blk.png”’ and replace with nothing).

We will centre all images and format their captions as Helvetica-Narrow, 8 point font. To centre the images, we will need to use a regular expression to add a <div align=”middle”> tag to all the images. We’ve tried out a few variations on how to do this most efficiently, and so far, our best RegEx is as follows:

FIND <img src=(.+)>    and     REPLACE WITH <div align=”middle”> <img src=$1> </div>

Unfortunately, this expression centres most, but not all images in the doc. Further finessing of the expression and/or finetuning after doing the find & replace will be required for our final product. But this is a start, at least. Also, we’ve discovered that it’s not possible to use regular expressions when editing in Calibre, because most of the complex expressions aren’t searchable. For editing the bulk of the HTML (including the styling of the images) we’ll need to use Notepad++ (or the Mac equivalent) and then preview it in a browser.

We will make all other style changes using CSS in Calibre, so that we can preview how changes to the stylesheet affect the ebook as a whole. Adjusting the formatting with CSS only (and not HTML) should save time and ensure that formatting is uniform throughout the book. Alice will work independently on the stylesheet while the rest of the team tackles the HTML. After the HTML has been perfected, she will test her styling with the updated book to ensure that her formatting still works after these updates. We’ve allotted time to reconcile any unwanted style changes that occur in the schedule (below).

Delegation of Tasks

Roles:

Erik — Chief Information Officer
  • First pass at text (removal of corrections and other excluded elements)
  • Creation of table of contents
  • Deletion and replacement of images as appropriate
Roshane — Marketing Director
  • Creation of marketing and distribution plan
  • CIO adviser and coding support
Zoe — Creative Director
  • Breakdown of existing visual elements (with support from Ali)
  • Transformation of moving and interactive elements into still images
  • Collaboration with CIO on images in final product
Alice — Style.
  • Creation and monitoring of CSS document
  • Formatting and readability of final product
Ali — COmmunications Director
  • Working document control and distribution
  • Report creation and editing
  • To liaise with Marketing and Creative Directors
Lynn — Designer
  • Visual styling of documents (including report and presentation slides)
  • Creation of book cover
  • Support to Alice

Predicted Challenges

Challenges are likely to arise as we work through each stage.  At this time we foresee the following as potential issues that we will need to negotiate:

  • Limited time
  • Limited experience in some areas
  • Competing priorities for all group members, schedule coordination
  • Social loafing and/or over-work of some members
  • Needing to accept limitations of project and possibility of not achieving our original goals

Existing Resources

Our current resources stand as follows:

  • Existing knowledge of group members in various areas
  • Online pool of coding resources (created by PUB607 class)
  • Other members of PUB607 class
  • Juan
  • Book cover designer (through Lynn)

Timeline

Project will be completed and delivered according the following schedule:

Gantt Chart

 

HTMLadies – EBook Proposal

PUB 607 Proposal (final – Sept. 30, 2015)

What is Code? by Paul Ford – eBook proposal

HTMLadies: Ames, Aniela, Gill, Monica, Natalie

The primary goals of our group are to produce an easy-to-use eBook with high readability, common-sense navigation, and an eye-catching cover design, in a format that is compatible across the most common e-reader platforms. Our group is primarily novice coders, with two members who have some experience with code, so the scope of our project is relatively simple. Regarding the workload, each person will be assigned one aspect of the project and will receive assistance and feedback from the others during group meetings. Our progress will be tracked on a single shared document to simplify the creation of the final project report. As each person completes a task on the eBook schedule, they will add to the documentation, so that all the group members are informed of changes as they occur.

Readability/Legibility

Readability is one of the most important parts of eBooks. We all agreed that readers don’t want it to be taxing on their eyes, or garish to their senses. Good design should be invisible. The minute the reader notices it, it’s not working. We believe good typography is the same way. We want to use two different fonts: one serif for the article body text, and then a monospace typeface (like Courier) when there are direct examples of code.

In terms of readability, we want to ensure we maintain appropriate chapter and section breaks, as well as image quality. The use of rescaleable vector graphics should make the appearance of our eBook more stable across multiple e-readers. Although the reader will be able to adjust the ebook’s typeface, font size, and line spacing (leading), we would like to ensure the default is highly readable. Our ebook should be aesthetically crisp and pleasing to the eye.

Ease of Use/Navigation

Having an ebook that was highly user-friendly and easy to use is a priority for us. As such, we will be focusing a lot on navigation. We decided that because the article is so long and is broken up into different sections, it would be conducive to create a hyperlinked table of contents. Furthermore, we hope to have hyperlinked endnotes, though we recognize that this may be more difficult. One team member watched a video on YouTube on how to code a table of contents, and we believe that this is within our capabilities as novice coders.

Simplifying the Text

With the existing content, we need to remove all elements that do not work in an ePub format: .gifs, and videos. There were some diagrams that were relevant to illustrating concepts that we would like to retain if possible. However, this may mean that we have to consider copyright issues when we outline our distribution plan. While the text is licensed under Creative Commons, the images, artwork, and diagrams are not. We will have to edit the photo/image content to determine which ones are integral to the text. Once we’ve decided which ones we want to keep, we should try to determine if it would be a worthwhile thing to spend time/theoretical money on. We will also have to determine what to do with the various paratextual elements (such as sidebars). Additional research will be required to see if there is a simple way to handle that material in an ePub2, as this is one of the areas in which the increased multi-level functionality of ePub3 would have been an advantage.

Aesthetics/Marketing

Having an appealing cover design will be important, in terms of marketing the eBook. We agreed that the cover needs to be simple but effective at multiple sizes, as ebook covers are frequently displayed as small thumbnails. We would like to use the ‘90s code aesthetic that the online article had, but make sure that the cover does not make the content appear out-of-date or irrelevant. Several draft options will be presented, and then the group will choose one or two to develop further.

Division of Work

We decided that workload would be split as we see necessary. It was agreed that the goal of the project was to learn. As such, we would all support one another to assist in the coding of the ebook. A couple of team members are stronger in regards to this part of the assignment, and they would be the main support system. Furthermore, we identified various portions of the ebook that will need special attention, such as images, title page, table of contents, and footnotes. While it was decided that we would all support one another as necessary, we also agreed that it was important to play into the strengths of the individual team members. As such, work such as design or organization would be divided according to this method of work division. Each team member will be responsible for one element, as assigned below, and then will work in concert with the group to get feedback and assistance.

Format and Tools

From what we can tell, most e-readers will be able to handle an Open ePub file (as opposed to an Adobe ePub file). The new Kindle Fire can handle ePub, but the older Kindle requires a .mobi or .azn. The ePub3 format is currently limited to Apple products, and is not functional on other e-readers, so we have decided to go with a format that is compatible across more platforms. We have decided that we will make an ePub2 file, and will research the possibility of converting it into a Kindle-compatible format at the end. As an ePub2 file, it will be accessible by most eReader devices and could conceivably cover most of the market with a single output. This epub will be reflowable, not fixed layout so that it is responsive and adapts to various devices.

As we will be splitting the work, we will use Calibre or Sigil, based on personal preference. Calibre was the program Juan recommended, but Sigil has a number of tutorials produced that create a very good looking end product. We will also use multiple code validators, such as Flight Deck or http://validator.idpf.org/, at the end of the project to check our final eBook code and to help us identify problems in our code.

Metadata

In considering distribution, we should also be aware that the file’s metadata will need to be generated.

Tentative schedule

 

Dates Assigned person
Documentation This will be completed as we go along. All
Prepare Master file for use Sept 28 – 2 October Monica
Stylize content (tagging text, removing unwanted elements, etc.) Sept 28 – 2 October All
CSS Sept 28 – 2 October Gill
Modify images & diagrams Sept 28 – 2 October All (Specific person TBC)
Footnotes and hyperlinks Sept 28 – 2 October Aniela
Cover Sept 28 – 2 Oct Ames
ToC and Navigation Sept 28 – 2 Oct Natalie
Convert for first iteration review 5 Oct All
Work on fixing coding issues that arise after conversion 6 – 8 Oct All
Review final result 9 Oct All
Prep for presentation 12 – 13 Oct All

© 2018 Monica Miller. Unless otherwise noted, all material on this site is licensed under a Creative Commons Attribution 4.0 License.


Theme by Anders Noren

Up ↑