Courses/all-in-one publishing

From Publication Station
Jump to navigation Jump to search

Structure of the course

  • Day 1: intro, overview of our project and a walkthrough of the challenges we encountered. Take a look at the publications that students want to use and see how similar or different their workflow will look. Give motivated students the suggestion to start implementing html structure already at home.
  • Day 2: refreshing Day 1 content, working on student projects focussing on HTML structure and design
  • Day 3: working on student projects focussing on print and e-reader output

In the classes following the intro, we open the output and the code that we created for that medium and start discussing some of the decisions we made and why we made them in the order in which they come up. We may also illustrate the problems by recreating them on the fly. We ask for alternative solutions to some of the problems.


About our process

A short introduction to the process. Structured source file -> structured HTML -> Design in CSS -> convert to different formats with pandoc

Why like this?

  • The source can be updated at any time and exported again in all kinds of formats
  • No separate teams needed to design for the different media
  • Streamlined coöperation between authors, editors and designers. Changes in the content can be made without help from the designer
  • Open standards: cheap, reliable and future-proof

Important factors

  • Recognize and utilize each medium’s unique aesthetics and features
  • The different outputs should complement each other, not compete

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

  • 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!

Output previews

All-in-one Publishing
VISIT File:All-in-one-publishing-pdf.pdf File:Weasybook final.pdf