CategoryeBook Proposals

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

dot-commas’ ebook proposal

The .epub of What is Code? that our group, the dot-commas, plans to produce will optimally be as cross-platform compatible as possible, removing the interactivity and animation of the online version while maximizing readability and preserving the photography and textual elements (e.g. notes, pop-ups) of the original text. We will aim for a minimal and accessible design, which requires reflowability (as opposed to a fixed-layout design, which does not allow text to be resized) as well as general readability.

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.

In particular, we need to look into whether the inclusion of colour images will be a problem for monochrome e-reader interfaces. Will the images be automatically converted to black-and-white? Will they disappear entirely? Will the result of this conversion still enhance the reader’s experience, or will it be detrimental? We can potentially use the @media CSS rule to address any issues that arise. Our most likely course of action will simply be to test our work-in-progress (and final product) as thoroughly as possible.

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 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 remove. It is important that all our images be formatted correctly; one potential solution is creating “responsive” images using CSS, but this might be a complex solution to a simple problem. Instead, we might simply resize each image using the “width=%” CSS selector.

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 a “float” CSS property, but we will need to investigate further how this property can be applied. Since it is generally inadvisable to include text (i.e. captions) as image files, hopefully this approach can be used to format text as well as images.

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.

Consistency of style is particularly important because of our chosen approach to constructing our .epub. We intend to use Calibre to edit the HTML and CSS of our .epub, working backwards from the original document rather than starting from scratch. Calibre will show a live preview of the .epub document and to check for formatting 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.

Splitting up the document may present a problem when creating our table of contents, but the .ncx document itself can be created simply using Calibre, a final step once most other work is complete. We are undecided as to 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 hide sub-headings unless desired.

Calibre also allows us to insert own cover for the .epub and to identify it specifically as such. The website’s animated header is far too gaudy for our purposes, 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.

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 frontmatter, possibly formatted so as to distinguish it from the body of the text. Having designated frontmatter will require us to investigate the possibility of using page breaks to section our .epub, but might be solved by dividing the text into multiple HTML files.

Design-wise, we are interested in embedding specific fonts (particularly for headers and sidenotes) into the .epub, with the understanding that while these may not show up in all e-readers, they will nevertheless display on some. In addition, we will size fonts proportionally rather than use absolute values, as per this guide, since many e-readers allow the reader to increase or decrease font sizes.

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

Alanna will investigate the matter of the title page, including both design and file format requirements.

Katherine will look into creating the table of contents and how to create an .ncx document, compatibility issues, and how to include such a file in an .epub. She will also embed title fonts, split the main text into separate HTML documents, and research responsive images.

Once the HTML is converted to .epub using pandoc, Zoë will comb through it to remove remnants of interactive elements and animations.

David will look specifically into how to format and size grids for images (with the intention of creating relatively unobtrusive sidenotes). Will also compile list of potentially-useful HTML tags for sizing images and document elements.

Sarah will look into colour compatibility issues as well as different methods of testing the completed (or in-progress) .epub.

All team members will work on sections of HTML.

dot-commas

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


Theme by Anders Noren

Up ↑