Here's this post in plain text - https://shkspr.mobi/blog/2025/12/a-small-collection-of-text-only-websites.txt

Obviously a webpage without links is like a fish without a bicycle, but the joy of the web is that there are no gatekeepers. People can try new concepts and, if enough people join in, it becomes normal. I'm not saying the plain-text is the best web experience. But it is an experience. Perfect if you like your browsing fast, simple, and readable. There are no cookie banners, pop-ups, permission prompts, autoplaying videos, or garish colour schemes.

I'm certainly not the first person to do this, so I thought it might be fun to gather a list of websites which you browse in text-only mode. If you know of any more - including your own site - please drop a comment in the box!

• Terence Eden's blog - add .txt to any URl.
• Daring Fireball - add .text to any URl.
• Zach Flowers - replace .html with .txt.
• Fabien Benetou's PIM - add ?action=source to any URl.
• M0YNG - add .txt to any URl.
• Gwern - add .md to any URl or send an HTTP Accept for Markdown.
• Dan Q's textplain.blog - the entire blog is plain text!
• Matt Hobbs - there is a feed of plaintext which allows you to read recent posts.
• Bananas Playground - add index.txt to any post. Also works with index.md.
• Jorvik Systems - change .html to .md for Markdown.
• Max Glenister's blog - add .txt to any post's URl.
• Philipp Dubach's notes - add .txt to any post's URl.
• Derick Rethans' blog - add .txt to any post's URl.
• Ricardson's blog - add .txt to any post's URl.
• elle's blog - text mode only available via curl elle.sh/blog.
• Benji.dog - add .txt to any note's URl.

If you'd like to add a site, please get in touch. The rules are simple - content which has the MIME type of text/plain. No HTML, no multimedia, no RTF, no XML, no ANSI colour escape sequences.

Emoji are fine though; emoji are cool.

1. Are you faster at speaking or typing?
2. Are you faster at reading or listening?

Lots of us now use Siri, Alexa, Bixby, and the like because it is quicker to speak than type. For long-form wordsmithing - it's still probably easier to type-and-edit than it is to speak-then-edit. And the way humans speak is markedly different from how they write.

But the bottleneck has always been that listening to speech is slower than reading text.

The average reading speed is around 238 words per minute. Obviously there are a lot of caveats around the age of the reader, the difficulty of the material, whether one is reading for leisure or work. But it will do as a comparator.

The average speaking speed is around 150 words per minute. Again, that depends on the age of the speaker, urgency of their talk, familiarity with the language, and so on.

Therefore it is faster to read academic papers rather than to listen to academic lectures. Case closed!

Except…

There's a fascinating new paper out - Learning in double time: The effect of lecture video speed on immediate and delayed comprehension.

Here's the quote I found most interesting - with emphasis added:

Collectively, the present experiments indicate that increased video speed (up to 2x) does not negatively impact learning outcomes and watching at faster speeds can be a more efficient use of study time.

Thus, as long as to-be-remembered information can be effectively perceived and encoded, learning outcomes may not be affected by playback speed.

However, previous work has indicated that speech comprehension begins to decline at around 275 words per minute (Foulke & Sticht, 1969; see also Goldhaber, 1970; Pastore & Ritzhaupt, 2015; Vemuri et al., 2004) and the videos in the current study exceeded this threshold when played at 2x speed.

Although the elevated speech rates at 2x speed may initially be less comprehensible to students, researchers have been able to train participants to understand speech at rates up to 475 WPM (Orr et al., 1965).

Therefore, with practice, higher rates of speech may not be completely incomprehensible and since 85% of students reported watching lecture videos at quicker than normal speeds (see Figure 3a), they may be better able to process the material as a result of experience.

I guess this shouldn't come as a surprise to me. I tend to watch my MSc lectures at 1.75x with subtitles - and have been doing the same with podcasts and tutorial videos for years. Looks like I am in the majority.

If the average person speaks at ~150 Words Per Minute, increasing playback speed to 1.5x gives a listening rate of ~225 WPM. That's about the same as reading speed.

Going to 475 WPM means listening at 3x normal speed.

My mate Léonie Watson is blind and has written extensively about the use of text-to-speech technology. Because she listens to a synthetic voice, with predictable and consistent pronunciation, she's able to listen at about 520 WPM! That's 3.5x faster than the speech of a biological human.

I'm not suggesting that you can speed-listen your way through any complicated topic and retain perfect understanding of subject and nuance. But it is becoming clear that synchronous teaching has limitations when it comes to efficiently teaching people. There's no substitute for being able to stop an expert mid-lecture and saying "sorry Prof, I don't get that - could you please help me understand?" But the reality is, most people never stick their hand up in class. So listening to lectures on playback - at double speed - is simply a better "user experience" for the student.

Learning, of course, isn't just listening to people drone on in front of a blackboard. The student still needs to do the exercises, write their essays, consolidate their knowledge, reflect on what they've learned, and so on.

But the ability to "speed" your way through a (well edited and professionally recorded) lecture is something to be welcomed. It gives students more time to spend on their studies with, apparently, no ill effects.

"You are in a maze of twisty little passages, all alike"
>Go East
"You have been eaten by a Grue. A dwarf starts singing about gold"

Smashing! Just like the pictures are better on the radio, so the graphics are immeasurably superior when they're in your head. Don't get me wrong, I love the 5.1 surround sound snarl of a rabid beast rendered in 1080p - but nothing is quite as good as using your imagination.

Text Adventures - or, more properly, Interactive Fiction - is enjoying a mini-renaissance at the moment. There are emulators for smart phones, computers, and consoles.

But for SMS? None that I could find. Think about it; SMS is close to the perfect medium for Interactive Fiction. Your commands are concise enough to fit into a single message, you don't have to worry about the speed of your response, everything is text based.

So, I present to you, Zork via SMS (with a little help from Twilio).

Brilliant!

HOWTO

Although superficially a simple project, there are a few gotchas along the way. This documentation is mostly for me - but may be of use to you :-)

Let's start at the end.... Using Twilio you can send an SMS to a phone number, that is then POSTed to a webserver of your choice.

Twilio will send an SMS back if it receives a response such as

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <sms>You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
</sms>
</response>

Easy enough. (NB the free account prepends your messages with a trial message. Once you pay, that goes away.)

So, how do we get a text adventure like Zork running server side? There are plenty of client side emulators out there - but I only found one which was purely server side.

THCnet have a PHP interpreter for Zork. It's slightly cludgy - but it works. I'm checking to see if I can distribute it on GitHub.

The game library "dtextc.dat" must be installed in "/usr/games/lib/". The source code is available if you want to recompile it and place it somewhere more accessible.

A MySQL database needs to be created to keep track of users and sessions.

A temporary directory (which must be readable and writeable) will also be needed to store the state of play for each session. I've used "tmp/404/" but you can alter config.php to point wherever is convenient. You will also need to adjust index.php and functions.php with the new location.

Finally, the executable "zork" must be runable.

That's pretty much it.

When a user (or, in this case, Twilio) first makes a request to the URL, we check to see if they already have a session cookie. If they don't, create one, and start the game by returning the opening text.

For every subsequent connection, we check the state of the game based on their cookie, then apply the body of their SMS to the game engine. Whatever Zork spits out, we return as an SMS.

By default, Twilio kills unused sessions after 4 hours, and all cookies will be lost.

Where Next?

It strikes me that the various forms of text adventures are excellent as a sort of mini-IVR. A nice little finite-state-machine which can quite happily run for years. Services like Frontline SMS are great for information sharing, but they're really not designed for this sort of work.

Could we use interactive fiction in places where SMS is cheap but other forms of entertainment are expensive? Could IF be used to augment existing media events? SMS is lowest common denominator - even iPhones can use it.

But, for now, all I have to worry about is someone texting me "Go west'); DROP TABLE ..." ;-)

I also get friend requests from people I've never met, including from Ahmed al-Najjar (احمد النجار). I've never met Ahmed and I've no wish to taint him as a spammer - I'm sure he's just misclicked in his friend request - but because Arabic is written right-to-left (RTL) it shows up some interesting design and usability imitations of FourSquare.

On the Android app, there's a curious problem.

In layman's terms, I'm expecting to see "[name] [action]". What the computer is seeing as its instruction is "Place [name] at the start - then place [action]" - in this case, the [name] is placed and, because it is RTL, the [action] is placed after it - which means on space to the left.

Incidentally, their website doesn't suffer from this problem:

In an average design environment, we may only encounter one text layout. In the west, that's usually Left To Right (LTR). If we're feeling exotic, we might internationalise all our assets and strings so that they support a fully RTL experience. (Of course, internationalisation and localisation is slightly more complex than that.)

So, the experience becomes: "أحمد النجار يريد أن يكون صديقك."

That's fine, but what happens when we want to mix the scripts? Should we say "أحمد النجار wants to be your friend."

Somehow that feels wrong. It's the lexical equivalent of writing "nedE ecnereT wants to be your friend". Yuck!

Do we accept that - whether one can or cannot read the script - a block of foreign text is read as a separate unit?

Bidirectional text support is present in most computers. Even if it does lead to some complex problems.

Combining the text into one layout is a solved problem - but it doesn't address the usability of mixing and matching. What is it that the user expects to happen? I think we can agree that their must be consistency between all UIs - in this case Web and Mobile.

As I see it, there are five approaches

1. Keep original UI ordering - place the name where the user expects it to be.
2. Take the ordering from the first element of the sentence.
3. Whenever the text direction changes, start a new line.
4. Translate the foreign text into the user's native language.
5. Rotate or reverse the foreign text.

The common consensus is the first option. Take the overall direction of the text and place the reversed text in place.

However, of the above items, I think that starting a new line is the most satisfactory.

أحمد
wants to be your friend.

But, of course, that leads to

أحمد
is now friends with
تيرينس

Both of which could lead to vertical layout problems, as well as introducing alignment confusion.

أحمد
is now friends with
تيرينس

Gah!

But then, adjacency also provides problems. The W3C maintain some excellent guidelines for mixing bidirectional text. In this adjacency example, can you quickly determine which item should be checked to select "English"?

( Incidentally, number 5 isn't as strange as it sounds. In languages which are written Top-To-Bottom sometimes foreign characters are inserted in place but rotated!)

A Conclusion - of sorts

I think it's obvious that in this example, the FourSquare mobile app is wrong from my point of view. As the user, I expect the starting element to be at the left. From Ahmed's point-of-view, he as a user expects the starting element to be on the right.

Yet, for both of us, it's an unsatisfactory and inconsistent experience.

Bidirectional support in Unicode solves the layout problem. Yet I'm not sure if it solves the semantic problem. Indeed, I wonder if that can be solved at all.

I had a suggestion from digital journalist Kevin Anderson

Terence Eden is on Mastodon

@edent

Gah! The #leveson witness statements are photocopied & scanned in levesoninquiry.org.uk/evidence/?witn…
Disastrous for open justice - shkspr.mobi/blog/index.php…

---

Mr Anderson

@kevglobal

@edent Put the Leveson docs up on Google Docs. I'd be curious how their OCR could handle them. Then click 'make public'

---

Google Docs has an annoying 2MB limit for uploaded PDFs. However, I've taken the first half of Rebekah Brooks' witness statement and run them through the OCR process.

This is how Google recognises the text in the document

Leveson Inquiry into the culture, practices and ethics of the press

1 I dlT| necessarily inhibited to some extent about what I can say in reiation to some of the issues that the Inquiry has raised with me. My background

3. ijoined News International in 1989. I began my career on the News of the Worlcfs coiour supplement, Sunday magazine, whiie simultaneousiy attending ajournalism course at the London College of Printing.

4. Since then i have been either a joumeiist or an executive on both The News of the World and The Sun. For afrnc-st a decade Iwas a nationai newspaper editor. In May 2000 I became the editor of The News of the Worid and in January 2003 I became the editor of The Sun.

5. In September 2009, I was appointed Chief Executive of News lnternationaf. My responsibilities embraced ail the newspapers and digital products of the 1.... -. -

That's based on this text:

Why Is This Important

The journalist Heather Brooke has been ranting for some time about the closed nature of the British Courts. It's close to impossible to get verbatim or accurate information about course cases. This means as citizens, journalists, or archivists, we can't accurately search documents. We need access to the original digital documents.

Poor OCR is also a huge problem. As above, OCR gives us a misleading impression that documents are searchable.

Should we wish to search, say KRM-18, to see whether the MP Tom Watson is mentioned; a search for "Watson" turns up zero results. Yet he is mentioned.

The page shows: But the scanned text reads:

Had ~ debrief with 5f[ ~nd his team tm~.igl~t ttt 77~ betbre he [o~ t.o his constituency:

l-]~e is veo’ h.,qlopY~ith d~ ~va~, today" wellt mid ~s~cci~iiJ~’ ~,it[i tae ~bsoiutely’idiotie. del)&t~s led by Wtttson.urtd

Prescott.

So, it's totally impossible to rapidly search through these documents. It would be necessary to laboriously read each document manually.

How To Accomplish This

There are two ways to get this done - in the case of the Leveson Inquiry.

1. Petition the Inquiry to release the original documents.
2. Crowdsource the OCR. Taking the Google OCR as a starting point and "Wikifying" it to let anyone correct the text. A bit like Distributed Proofreaders

I will, of course, send an email to the Leveson Inquiry - but would people be interested in being part of a crowdsourcing effort to opening up these documents?