This is a regular text file. People will read it. Maybe.
slopjong.de
slopjong.de
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).
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.
Deviate too much from this and readability suffers.
Edit: adequate whitespace in the margins is important too.
Also, all viewers would have to support it, which somewhat defeats the purpose of using plain text.
8 spaces is fine.
> For example, you need to handle bullet points.
Asterisks are fine.
> Also, all viewers would have to support it, which somewhat defeats the purpose of using plain text.
I think that you're over thinking what plain text is. I don't mean "plain text with some additions". I really do just mean 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 ---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 ---
It looks terrible, and I didn't read it, effectively falsifying the article.
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.
nano -W --fill=65 filename.txt
I like the playfulness of these pages (the original and this parody) and I hope both authors achieve their aims.
That's why I suggested gqip on every paragraph, but I'm sure there are more efficient ways.
Long lines and wrapping within the text viewer is probably your best bet.
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.
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.
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 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.
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).
https://gist.github.com/anonymous/5844581
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.
Might still be worth it though. Thanks.
2: Replace the monospace font with a non-monospace font one
3: Tweak other settings until you have the typesetting you prefer
4: save as bookmarklet specifically for formatting raw text
Done!
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.
Now that's amazing...
> 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.
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!
"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.
Does that work?
Plain text can be readable too: you can keep it to 72 columns like the RFCs.
That's 0.9 KB too large for a 4K demo.
Sometimes, we have a highly up voted UX article that tells us users "can't read" so we should not rely on text.
At other times, we have this highly up voted manifesto that tells us we should focus more on text.
Am I the only one to see a contradiction?
PS: I do think text/plain HTML files are great (in some cases).
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.
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.