Nice, I like text files.
Paragraph width is a little too wide for me, however.
I assume you made the line breaks manually,
but it IMHO looks better if you let a decent
algorithm do it.
Most Unix systems should have fmt, but par is
better. If you are a vim user, just hit gqip
inside of every paragraph.
The manual of par [1] has an example that shows the superiority of a dynamic programming algorithm (par, TeX) over a greedy algorithm (fmt, aprox. format manually).
> Nice, I like text files. Paragraph width is a little too wide for me, however.
This is why we need markup languages like HTML. Inevitably people will want different widths paragraphs due to different devices, preferences, etc. Just because some people use HTML badly doesn't mean we need to go back to text.
Ideal paragraph width is not a function of device display size. A line of text should contain about 12 words, give or take. Long enough to not feel choppy but short enough to not feel like a "wall of text."
Deviate too much from this and readability suffers.
Edit: adequate whitespace in the margins is important too.
But it wouldn't handle indentation properly, unless you define a standard formatting convention similar to Markdown. For example, you need to handle bullet points. But what if a plain, non-indented text just happens to contain a star at the start of a line? This means headaches for text writers to avoid these edge cases, and wrong indentation when viewing legacy texts.
Also, all viewers would have to support it, which somewhat defeats the purpose of using plain text.
I'm not talking tab characters, I'm talking indentation of whole paragraphs with plain spaces, as seen in the article. Most existing viewers just wrap long lines so that the wrapped content is unindented: this makes any indentation hard to notice and mostly useless. For your proposition to be viable, viewing software has to detect indentation and keep that indentation in wrapped lines.
> Asterisks are fine.
Ok, but usually you want to indent the wrapped contents by 2 columns otherwise asterisks become hard to notice. This is only possible with special magic in the viewer.
--- BEGIN MESSAGE ---
--- BEGIN BLOCK QUOTE ---
--- BEGIN BLOCK QUOTE ---
I'm not talking tab characters, I'm talking indentation of whole paragraphs
with plain spaces, as seen in the article.
--- END BLOCK QUOTE ---
Ah, okay. You're right, indenting an entire paragraph is hard.
--- BEGIN BLOCK QUOTE ---
This is the kind of thing they'd do on Usenet.
--- END BLOCK QUOTE ---
--- END BLOCK QUOTE ---
All you get is a very verbose markup language :-)
--- END MESSAGE ---
This is the best solution, because you never know how large the text will be when rendered by the user's software. For example, this is how it rendered on my iPad:
You Europeans have things too easy with your metric paper sizes and sales tax included in displayed prices and standardized road signage and drinkable beer and functional healthcare systems. We'll stick with PDFs, and fluid ounces, and trying to calculate 18% of pretax dinner tabs thanks. Excuse me while I go fight with my health insurance company over my last doctor bill.
I'd say it's more than fine. I just spent three weeks in Europe and I was underwhelmed by the beer everywhere except Munich, Berlin, and Copenhagen (Mikeller was great). Foreigners seem to think of American beer as PBR, Bud Light, Miller, etc... and they have a good reason to--it's what most Americans drink.
But the strong microbrew renaissance going on right now is producing some of my favorite beers. Beers with the same depth and complexity as the finest of wines--he said, opinionatedly.
Now, I've learned that this experimental attitude towards beer is highly American. I don't think I've seen anywhere else in the world, except maybe Belgium, that is quite as crazy and experimental with what they put in their beers. After all, who in their right minds would like sour beers?
If you think the beer situation in the US is poor try out some Russian River, Boulevard, or Elysian brews and come back to me.
gqG also does violence to some plain-text formatting, such as numbered lists or other short sections in which a specified line length or presentation is preferred.
Long lines and wrapping within the text viewer is probably your best bet.
This made me laugh harder than it should have. Or maybe it was just really good, I am not sure yet. Either way, thanks. I had a slightly cranky response to that other thread I never typed, and enjoying this instead is much better.
And yes, some people read that stuff. Though I would rather read something silly that is honest, than something that ultimately tries to sell me something. Which reminds me of this! http://textfiles.com/directory.html <-- Anyone remember spending hours being fascinated by that as a teenager? Text files are the best files.
Does anyone know of an easy way to improve the readability of raw text files in the browser? I'm writing a novel using github and the raw text file output looks very ugly in the browser, even using things like readability [1].
It's easy to convert a static text file into something more readable, but I can't seem to find a solution for a dynamic text file at a static address.
Make sure your text files are readable in the first place (line length, paragraph length, etc.).
Chose a readable font. Text files are shown with the browser default monospace font, but you change it to whatever you like best.
I think there is not much else you can do with raw text files in the browser. The next level would be to write in something like markdown and view the processed text, I think.
I've been trying to avoid adding manual line breaks to the text file because in prose, unlike code or poetry, line breaks are presentation, not content.
I suppose I could try to write something that scrapes the text file, adds <p> tags around paragraphs and presents it with some really basic CSS. I don't know how to code, but I might try cobbling something together.
You could alternatively use an online markdown editor (such as http://markdown.pioul.fr/). It'll wrap your paragraphs in <p> tags.
Additionally, since it uses the Markdown syntax, it might give you more than paragraphs if you use more than line breaks. (Have a look at the quick reference for more about the syntax.)
Edit: Didn't see your answer to @kybernetikos. I still think this could help you out. Also note that in HTML (what you'll get by adding <p> tags to your text), whitespace is collapsed (except inside <pre> tags)
Instead of writing a converter yourself you could try to use Markdown on your files without modification and see how well it does. The design goal of Markdown is:
Markdown allows you to write using an easy-to-read,
easy-to-write plain text format, then convert it to
structurally valid XHTML (or HTML).
The styling applied there really clashes with the explicit breaks in the story text. Anyway, that gets you down to one click each time you want to review the text file, which is maybe still more than you want.
Now write your novel in markdown in an index.md file. Every time you check in github will render a nice html file for you that's easy to read, but your source remains easy to write and diff since it's just markdown.
I had exactly that problem, although use of text-indent in the css meant that every paragraph starts indented, so you just make each line of dialogue a new paragraph and it works out ok. So yes, it's not ideal, but it's still pretty good.
I think this is a bridge too far. Justin Jackson made a good point about approaching your content first etc, but stripping back to just plain text just makes this harder to read. In fact, if you've read the first post http://justinjackson.ca/words.html, I'd argue that this almost impossible to read through to the end without skipping. Which sort of dilutes the whole point...
Perhaps the post should read:
This is a regular text file.
Nothing advanced and not much to see here but some words.
And you're pretty sure you've read this already, quite recently in fact...
AND THAT'S ANNOYING!
You're probably not even reading this bit, as most of you will have elected to skip to the end only to find I'm plugging something.
The whole point is that it /is/ hard to read. That it isn't just about content, but how that content is presented.
> All these people didn't manage to get the driver compiled and installed, one cause surely was that the readme author didn't care about how to present the content at all. He just cared about functionality.
> If a client wants to get something done, I'd like to challenge you to think about user expierence (UX). If you want to sell products you will have more success with some good designs and layouts.
By taking it to an exteme of just a text file they're demonstrating that to communicate the content you need to present it effectively, and nice fancy layouts help with that.
I think I was conflicted over the idea of making a point by making said point hard to read. But to be fair, since I last read the text file, the width has been fixed up, which has... made it much easier to read (the original was full width lines). If it had originally been presented in it's current format, I would have never made my comment.
> In fact, if you've read the first post http://justinjackson.ca/words.html, I'd argue that this almost impossible to read through to the end without skipping.
That's interesting: I saw the plaintext version first, which I had no problem reading. But in the HTML version, the fact that all bold sentences are pretty mundane and the excessive use of italic and bold just made me want to skip the whole page. In fact I didn't even notice it was the same content until I went back to your post!
My instant thought is that the bold headings draw the eye away from the bit you are currently reading.
"You" read the first heading, and decide to read the plain text below. As you are reading that, your eyes notice another heading below what you are reading, and if the paragraph you are currently reading is not holding your attention enough, the next heading gets your attention. Your eyes then leave the paragraph you are currently reading because the heading below it now has your attention. So, you start on the next paragraph and the whole thing loops as you go down the page.
So, I would suggest that one should use headings and attention grabbers as little as possible, make the paragraphs worth reading, and try to get the message of the paragraph across in the first sentence or two.
The plain text file has been fixed up since I made my comment. I agree, the plain text file is now quite easy to read, making my snarky comment look quite silly... :)
I don't think not using a CMS was Justin Jackson's point: his core point was that content is king - design can come later, it's a distraction before your content is written. You can easily use a CMS with a very lightweight template.
Plain text can be readable too: you can keep it to 72 columns like the RFCs.
When referring to the post that inspired it, it would have been useful to take advantage ad some kind of technology that, let's say, allowed me to click with my mouse on that link you wrote and be magically transported there.
If you look carefully, this dilemma exists in all forms of creative work.
Say I'm creating a piece of electronic music, do I start working on the bare melody on a piano first or do I start with picking voice textures that blend well together? Both can be exciting to work on and both can lead to great songs. Just two different points of entry. Two different layers of abstraction.
This is extensible to almost any type of creative work that I know of, and I think people who regularly create things have tried at least a few of these points of entry in their creation process.
For me, if I want to narrow down my focus, I go with the piano, the pen, the text editor – black and white, minimum degree of freedom. Otherwise, I start by finding two or more voices/tones/shapes/colors that go/interact well together and focus on the overall experience instead.
Looks awful on an iPhone due to the manual line breaks. If your goal was to let your words speak for themselves, you failed -- I was so distracted by the jagged text I couldn't make it to the end.
It's time for someone to step up and write an article that says the conscious choice of tools (or medium) most adequate for the particular problem is what really matters.
Someone should make .jpg file with nice typography saying:"This is an image. Not much to see, but you are starring at it anyway..." - Instant first page of HN :)
I assume you made the line breaks manually, but it IMHO looks better if you let a decent algorithm do it.
Most Unix systems should have fmt, but par is better. If you are a vim user, just hit gqip inside of every paragraph.
The manual of par [1] has an example that shows the superiority of a dynamic programming algorithm (par, TeX) over a greedy algorithm (fmt, aprox. format manually).
[1] http://www.nicemice.net/par/par-doc.var