Courses/all-in-one publishing

From Publication Station
Revision as of 07:14, 5 June 2015 by Arjensuijker (talk | contribs)

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.

Intro

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 can complement each other instead of competing

Semantic HTML

All credits for this chapter go to Ben Hunt

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. First order of business is to introduce semantic html and why we need it. HTML tags should indicate structure, not mark-up! The name should really not be HyperText Markup Language, but rather HyperText Structure Language.

The basic advantages of semantic html:

  • Ease of use
  • Accessibility
  • Search Engine Optimisation
  • Repurposing

Ease of use

First of all, semantic HTML is clean HTML. It’s much easier to read and edit markup that’s not littered with extra tags and inline styling. A corollary benefit is that your HTML files are also smaller, so they load quicker.

Accessibility

Unless you’ve had to interact with HTML markup through media other than your web browser, it doesn’t seem obvious to imagine that your web pages have a life outside the browser window, but they very often do. Web pages can be consumed by humans and machines in lots of different ways! When you separate visual aspects (i.e. style) from the actual meaning of a document, you end up with a document that always means the same thing. The way it’s presented or consumed can vary. One common technique web designers use is to apply different style sheets for different media. For example, you can apply a certain stylesheet only when a document is printed to paper, another one when it’s viewed on screen, and yet another when it’s accessed by a text-to-speech aural browser.

Search Engine Optimisation

The pages will be easier to be found in search engines. They are much easier to understand for machines, because machines read structure, not markup. Also, your pages are lighter which makes them easier to digest.

Repurposing

Clearly, it’s easier to grab and re-use content from any source, and apply it to any medium, when it does not contain any hard-coded style information, and also when it does contain semantic markup that can help a computer program understand the meaning and structure of the content.


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 the responsive website

  • 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=Courses/all-in-one_publishing&oldid=1195’