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

From Publication Station
 
(14 intermediate revisions by 2 users not shown)
Line 16: Line 16:
=== Why like this? ===
=== Why like this? ===


The source can be updated at any time and exported again in all kinds of formats
* 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
* 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
* 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
* Open standards: cheap, reliable and future-proof


=== Important factors ===
=== Important factors ===


* Recognize and utilize each medium’s unique aesthetics and features
* Recognize and utilize each medium’s unique aesthetics and features
* The different outputs can complement each other instead of competing
* The different outputs should complement each other, not compete


== Semantic HTML ==
== 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. 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.
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: ===
=== The basic advantages of semantic html ===


* Ease of use
* It looks cleaner, which makes working with it easier (especially as a team).
* Accessibility
* It works much better for screen readers and similar devices for people with disabilities
* Search Engine Optimisation
* It ranks higher in search engines
* Repurposing
* It makes your content much easier to restyle or use for different purposes
 
==== 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 ==
== Suggestions for the ‘regular’ website ==
Line 65: Line 49:
* Add interactive elements like tooltip footnotes <- be creative!
* Add interactive elements like tooltip footnotes <- be creative!


== Suggestions for the responsive website ==
== Suggestions for making it responsive ==


* Set the default viewport (<meta name="viewport" content="width=device-width, initial-scale=1.0" />
* 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.
* Add media queries for several widths, test at what width your design breaks.
* Use a browser with device emulation for testing (Chrome for example)
* Use a browser with device emulation for testing (Chrome for example)
Line 76: Line 60:
* 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.
* 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!
* 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 == 
{| class="wikitable"
|+ All-in-one Publishing
|-
|WEBSITE
|EPUB
|PRINCE pdf
|WEASYPRINT pdf
|-
|[http://headroom.pzwart.wdka.hro.nl/~ldossin/all-in-one-publishing/ VISIT]
|[[file:all-in-one-publishing-epub.zip]]
|[[file:all-in-one-publishing-pdf.pdf]]
|[[File:Weasybook_final.pdf]]
|}

Latest revision as of 12:34, 24 June 2015

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 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
WEBSITE EPUB PRINCE pdf WEASYPRINT pdf
VISIT File:All-in-one-publishing-epub.zip All-in-one-publishing-pdf.pdf Weasybook final.pdf
Retrieved from ‘https://ps.wdka.nl/wiki/index.php?title=Courses/all-in-one_publishing&oldid=1430’