I.e. thanks to using a PDF we can give authors full flexibility on how to lay out their article, which allows folks to be really really creative (as you can see in this issue). The obvious problem with that (apart from countless hours foxtrot_charlie - our DTP/PDF programmer - has to spent on fighting with PDF weirdness) is that reading an A4 PDF isn't great for phones, computers screens, or tables. It's even worse if you're using a screen reader, since getting PDFs in the way we get them and making them screen reader compatible is... complicated, to say the least (that's why it's not yet there). On the flip side, everyone has a PDF reader nowadays, articles look everywhere the same (this wouldn't be true for other formats), and it's also printable almost out of the box.
So, pros and cons. At the end of the day I don't think there's an easy out for us without breaking any of the things which make Paged Out! what folks like about it. The things I want to improve is getting printed versions more accessible, and some day finally getting solid screen reader support. But other than that I do believe the scrolling problem with remain with the zine.
ETA: Actually I also want "readings" of articles to become a thing. From the get go we put the in the author's license (note: not all articles use it, but most do) the ability for folks to agree to have their articles be recorded in an audio form. I think that would be cool for folks who like consuming things like audiobooks or podcasts. And it would save us from scrolling (for the cost of having illustrations described instead of seeing them).
I'd still keep in mind that this format severily limits reach in times where short (kudos for one page thing!) and accessible form is an expectation.
Nevertheless - I will keep reading and spreading the word.
Tangenatially. How would audio reading work for posts with code samples and diagrams in it? Do you have an example of that?
Most illustrations are a bit simpler to handle than code and the way is pretty much paved by HTML img alt texts (the well written ones, that actually can substitute for the illustration by conveying the same information). Ideally we should receive the ALT texts from article authors, but effectively (for now) it would be up to the person reading to come up with a solid substitution text.
Code is a different can of worms. My favorite idea so far is to basically explain what the code does as close as possible, without actually reading it, and then having a separate audio track with the code being read (likely just by a text-to-speech algorithm, though possibly augmented a bit to include things like "next line" or "this line has a 2-level indent" for Python code).
I don't have an example yet, but let me get back to you on that next week, since I was thinking of doing recordings for my two articles in this issue.
1. HTML is the primary format for articles. Authors can do whatever tricks they like in CSS, but are encouraged to make their layouts reasonably responsive. JS should be limited to things that actually benefit the article (such as LaTeX rendering or simple live examples).
2. The article must fit on one page when printed to PDF using a mainstream Web browser.
3. The author should provide a PDF file. It could just be the output of printing the HTML to PDF from a browser, or it could be something fancier, as long as it fits on a page and has the same text as the HTML version.
Looking at the most recent issue, most articles could be faithfully reproduced with a typical modern Markdown implementation (one that supports tables and code highlighting, and maybe LaTeX math) and some simple CSS.
The final goal is to do mass prints of Paged Out! to give out at events. We've already done that once, and we're chatting with sponsors and events about doing more of this. And actually "how can I get a printed issue" is THE most common question we get from readers. So there's interest in a printed version from both sides (readers + our team).
With regards to the HTML idea – it was something I considered as well (and an idea I come back to from time to time). The issues that made me decide against it are:
- Not everyone knows HTML/CSS on a level that would allow them to express what they want. This would downgrade the "creativeness" of layouts. While some typical text processors or WYSIWYG editors can output decent HTML, that's not true across the board.
- Asking authors to do more work (especially to fight with making sure HTML behaves correctly when printing to PDF), would have a negative effect – I a significant chunk of authors would pull out.
- It does solve readability issues for typical text layouts. It doesn't solve them for more creative layouts, especially on mobile phones.
- For better or worse almost every newsletter, blog, news website, etc on the internet uses HTML format. I think I prefer PO! to stay in the magazine category.
Anyway, I'm going to be revisiting this idea from time to time, especially if PO! happens to get more funding for whatever reason.
All that said, I'd encourage you to NOT switch to HTML and leave it as PDF. There's something about it.
I suppose it's not the literal file format, although I do see value in a format that is closer to "everyone gets the same experience" (c.f. recent blogpost about grammarly extension borking CSS)
I miss when you got one edition of your favourite mag, once a month, and could read it beginning to end, or on any order you fancy, but you got _an amount_ of content and could complete it.
Web properties of any scale now do not really have a "size" that you can experience. You can't "complete" them.
And this breaks up a communal experience. I'm on HN, and so are you: but we're not on the same HN. Whereas if I see you picking up Total Guitar, I could ask you if you got anywhere with the Satch tab in October's edition.
Is that what you were driving at?
a single column on a4 simply is too wide anyhow...
https://en.wikipedia.org/wiki/Column_(typography)#:~:text=Fo...
Art is almost always inaccessible to someone because that's part of what constitutes "art". Music is inaccessible to the deaf. Paintings are inaccessible to the blind. Food is inaccessible to those unable to smell.
If the purpose of the thing that you're creating is art, then it is necessarily inaccessible along the dimensions of your artistic freedom. (obviously, intentionally making it inaccessible along other dimensions, such as requiring a verbal test in order to view a painting, is silly, but we're not considering that) That's just what art is. That doesn't mean that you can't strive to make it a bit more accessible (e.g. with readings of content that a screen reader would have a hard time parsing), but merely that you have to acknowledge that (1) there's some parts of your art that certain people will never be able to experience (which is not your fault) and (2) that some things will be economically (in the spiritual sense, e.g. including volunteer time) infeasible to make accessible.
Conversely, if what you're making is meant to be a purely functional resource, then you should probably strive to make it accessible - but the only reason you can do this in the first place is because you've made a value decision to sacrifice aesthetics/art in the name of function.
That's a very long way of saying that I think you're taking a very reasonable position on this.