Difference between revisions of "Research/all-in-one publishing"

From Publication Station
(Created page with "== Introduction == The core of our research is developing a workflow in which HTML and CSS is used as the source for a publication. This publication is than available for pri...")
 
Line 12: Line 12:
For this research, we have chosen to take an existing publication and explore how it could be rebuilt from scratch using our newly developed workflow. The original publication was only designed for print. Our goals was to replicate this design as closely as possible with our new print version, and adapt the design to also fit the other media.   
For this research, we have chosen to take an existing publication and explore how it could be rebuilt from scratch using our newly developed workflow. The original publication was only designed for print. Our goals was to replicate this design as closely as possible with our new print version, and adapt the design to also fit the other media.   


The global process was as follows:
The global process consisted of the following steps:


1. The original Word documents with the contents of the publication were converted to html files using pandoc conversion software.
1. The original Word documents with the contents of the publication were converted to html files using pandoc conversion software.
Line 20: Line 20:
5. The outputs were created using Pandoc (for epub), Prince (for pdf), Chrome (for reposponsive web) and Firefox (for direct browser print) and checked for consistency.
5. The outputs were created using Pandoc (for epub), Prince (for pdf), Chrome (for reposponsive web) and Firefox (for direct browser print) and checked for consistency.


Of course the process wasn't as lineair as it appears here. The process can be better described as being iterative, looping through the steps continuously.
Of course the process wasn't as lineair as it appears here. The process can be better described as being iterative, looping through the steps continuously.  


== Challenges ==


=== Important factors ===
Because we are off the beaten tracks for the duration of this research, we encountered many challenges that didn't have readily available solutions. We will discuss the challenges for every step of our process:


* Recognize and utilize each medium’s unique aesthetics and features
=== From Word to HTML ===
* The different outputs should complement each other, not compete
In word, there are basically two methods to style a document: using styles or by manually changing the font properties for every heading and paragraph. The first method results in html files with a great structure, because the styles can directly translated to HTML tags. The second method creates very messy HTML files that require lots of cleaning, becuse the HTML is littered with styling information.   
 
== Semantic HTML ==
 
After the intro we take a look at what we made, just to show what can be done. After this, the focus is on semantic HTML. Our first order of business is to introduce semantic html and why we need it. HTML tags should indicate structure, not mark-up! We could even say that the name shouldn't be HyperText Markup Language, but rather HyperText Structure Language.
 
=== The basic advantages of semantic html ===
 
* It looks cleaner, which makes working with it easier (especially as a team).   
* It works much better for screen readers and similar devices for people with disabilities
* It ranks higher in search engines
* It makes your content much easier to restyle or use for different purposes


== Suggestions for the ‘regular’ website ==
== Suggestions for the ‘regular’ website ==

Revision as of 09:31, 18 June 2015

Introduction

The core of our research is developing a workflow in which HTML and CSS is used as the source for a publication. This publication is than available for print, epub and for a responsive website. This approach was chosen because it could potentially improve the publication workflow for the following reasons:

  • Both the design and the content can be updated at any time, fully independently of each other.
  • Every update in content or design is automatically exported to every available publication medium.
  • HTML and CSS are very widespread transparent file formats that have been used for decades without much change, and will remain this way for years to come. This makes them much more suitable for digital archiving than most proprietary formats.
  • For larely the same reasons, the resulting publication is very suitable for (collaborative) reuse and redesign.

About the process

For this research, we have chosen to take an existing publication and explore how it could be rebuilt from scratch using our newly developed workflow. The original publication was only designed for print. Our goals was to replicate this design as closely as possible with our new print version, and adapt the design to also fit the other media.

The global process consisted of the following steps:

1. The original Word documents with the contents of the publication were converted to html files using pandoc conversion software. 2. These html files were 'cleaned up', deleting everything design-related and only leaving structural information. 3. Additional HTML was added to improve semantic value and facilitate CSS styling. 4. CSS stylesheets were created for every output format. 5. The outputs were created using Pandoc (for epub), Prince (for pdf), Chrome (for reposponsive web) and Firefox (for direct browser print) and checked for consistency.

Of course the process wasn't as lineair as it appears here. The process can be better described as being iterative, looping through the steps continuously.

Challenges

Because we are off the beaten tracks for the duration of this research, we encountered many challenges that didn't have readily available solutions. We will discuss the challenges for every step of our process:

From Word to HTML

In word, there are basically two methods to style a document: using styles or by manually changing the font properties for every heading and paragraph. The first method results in html files with a great structure, because the styles can directly translated to HTML tags. The second method creates very messy HTML files that require lots of cleaning, becuse the HTML is littered with styling information.

Suggestions for the ‘regular’ website

  • Keep the html structure as logical and semantic as possible
  • Use relative positioning and measurements (% and em)
  • There are no pages! How do you deal with this? What do you do with the cover?
  • It doesn’t have to be linear anymore
  • Use a ‘reset.css’
  • Limit text-width (60-120 characters)
  • Create a menu from the index using anchor tags
  • Select fonts with proper online license and readability
  • Add interactive elements like tooltip footnotes <- be creative!

Suggestions for making it responsive

  • Set the default viewport (<meta name="viewport" content="width=device-width, initial-scale=1.0" />
  • Add media queries for several widths, test at what width your design breaks.
  • Use a browser with device emulation for testing (Chrome for example)
  • In most cases, the width of your content should be 100% on smaller screens
  • Make buttons for thumbs, not cursors. Hovers work differently!
  • Don’t imitate apple or android specific interfaces, but do use apps as inspiration. If the interaction with your site feels as ‘snappy’ on smartphones as a well-made native app, you did a good job.
  • Optimise screen space, hide what is not essential
  • If it is possible ask authors to write short abstracts for every chapter, so that users can choose when they want to read more or not.
  • Test on several real devices! Browsers may be able to imitate the looks of mobile devices, but how it actually ‘feels’ may be very different!

A preview of the website can be found here: [1]

A preview of the epub can be found here: File:All-in-one-publishing-epub.zip

A preview of the pdf can be found here: All-in-one-publishing-pdf.pdf

Retrieved from ‘https://ps.wdka.nl/wiki/index.php?title=Research/all-in-one_publishing&oldid=1309’