The Evolution of Writing on the Web

A non-functional wire sculpture of a toilet.
By CCRI Artdepartment

Why New Styles are Needed

  • Articles should be swifter for the web.
  • People want to read less as they have more to read.
  • Top ten lists and bullet-point articles make it easier to get through.
  • You can skip around between parts, pick up where you left off.

How Did We Write?

  • Old writing was based on a longer attention span.
  • It had deeper stylistic integrity that the form afforded.
  • Structures of sections of paragraphs of sentences of words.

The New Style, Evolved from the Old

  • Headings of bullets of sentences of words.
  • Pictures to anchor each part (not shown here).
  • Barer sentences, with less complexity.
  • Like a powerpoint put through a wringer.

The Old Style Lives On

  • Books and periodicals, along with some traditionalist sites.
  • Nice for articles you want to go deeper into.
  • Side-by-side old and new allows for reader choice.

Benefits of the New Style

  • Students learn outline forms more easily.
  • Reading comprehension goes up for the new form.
  • Discussion is simplified through easily-referenced sentences?
  • Improves collaborative editing and creation.

Downsides of the New Style

  • Students dislike the old style even more than they already did.
  • Comprehension of the old style diminishes further.
  • Discussions are based on less nuance (Fox Newsier discussions prevail).

I Dunno.

  • I’m curious whether this sort of writing style should become more dominant.
  • I think it has some benefits for the way people use the modern web.
    • Easier to read casually.
    • Possibly more accessible to AI.
    • Less opportunity for verbosity.
  • So I wrote this in a version of what the new style may be, to see what it’s like.
  • Oy vey. I’m hoping that there can be some balance. I do think language and writing styles need to evolve to fit the needs of readers, and long-winded writing can be a pain to read (especially as the number of things to read grows), but let’s hope it won’t be a bullet-point-riddled future.
  • One promising alternative is that AI will allow for real-time reorganization/editing of long texts to elicit the parts the reader is most interested in.

What is a Website?

The question comes to mind of real-world places, like the Grand Canyon, libraries, street corners you know, museums. And institutions, great institutions (in the abstract, anyway) like the U.S. Congress and the U.S. Supreme Court and grand institutions of learning like M.I.T. and Harvard University.

We have a certain outlook for real-world places that root abstract concepts. But on the web we still refer to the greats as mere websites.

Wikipedia is a website, yes. But is it not one of several behemoths, great beasts of the modern netscape (err, not the company obviously, though they did loom in their day). Great institutions with all signs of the lasting legacy of the Harvards and M.I.T.s and so on.

There is a certain leveling and democracy in Alice’s Blog being on the same footing with a Wikipedia. But at the same time, it seems we should be looking for new names for great Internet-based institutions. That we should be able to call Wikipedia a website, but also call it something which evokes its importance and lasting nature.

We have another term, web application. It fits certain sites. But when I think of an application, I think of a shell that provides functionality. I don’t associate the data of the application with being what it provides. If Wikipedia is an application that provides encyclopedic articles, well, where’s the competing application that relies on the same data set?

And there can be, don’t get me wrong. You can download Wikipedia’s database and write an application (web-based or platform-based) and pull those articles up (you can also download MediaWiki, the software powering Wikipedia). Others have come up with some innovative ways to, e.g., pull articles over DNS. The main application-like part of Wikipedia is its editing functionality.

So maybe Wikipedia is both a website and a web application. At least in part. But that still doesn’t account for the community behind it. Or that its most essential nature is as a repository of articles.

You could try portal or property or destination after web. Maybe some other term. But I think an important step, one that will eventually happen, is to drop the web. That at some point the articles of Wikipedia will be the headliner, and whatever built-in editing and display they want on the web will be the website. There may be platform-based alternatives (or alternative web applications) to provide the editing and display.

This is already partially true for how Wikipedia and the other Wikimedia Foundation (the organization behind Wikipedia) sites handle things like images. Image files and other media that are embedded in Wikipedia actually live on the Wikimedia site and may be reused across language versions and on other Wikimedia Foundation sites.

But that trend can be extended to other uses, and once enough uses for a system exist, the web frontend is truly a frontend rather than the raison d’être for the backend. It reminds me of the story behind the GNOME Sudoku application; apparently the author wrote a solver for Sudoku puzzles, and it grew an interface up around it. Sometimes that process works in the other direction.

Mozilla’s Advantage in Mobile

One of the major technology spaces still up for grabs is mobile. Apple led out with the i-series of mobile devices (iPhone, iPad), running iOS, while Google came back with third-party manufactured Android and their own Google-designed Nexus devices. Of course, Microsoft has their devices and their mobile operating system, but they are playing catch-up.

Mozilla has come in late with the FirefoxOS, and without plans for their own hardware. Yet they have a distinct advantage.

One of the frustrating things about new technologies from the big three (Apple, Google, and Microsoft) is lack of integration. Especially if you don’t standardize your technology choices on one of them, but even then.

For example, you can subscribe to various publications or buy certain media from these technology vendors (and others, like Amazon), but you don’t necessarily get equal access from all your platforms. Indeed, some of your platforms may be wholly excluded.

That’s the most common case for me, as a Linux user. There isn’t a native client for accessing media on Linux, and the web offering is usually inferior (example, with the streaming music services). In some cases the web offers no solution, mostly in the case of video. A few video providers utilize Adobe Flash, but these require an obsolete library, HAL, to support their copy protection schemes (“DRM”).

But that’s why Mozilla has a strong position: the native web. It lacks some features, but it can gain them. As it develops, it will provide the strongest point for integration between platforms.

Google recently announced their “Play News Stand” application for Android. It’s an application to deliver news to you, and some of the content is purchased. But there’s no web version. There is less incentive than ever for users to buy content that’s only accessible on one device.

Consumers don’t want to switch all their device profiles and operating systems to one vendor simply to gain the marginal benefit of equal access. The economics aren’t there. They don’t get cheaper access. All they get right now is access to one shop per device.

Credit card companies would not be the force they are today if their cards only worked at just one vendor, or even a handful of vendors. True market capitalism requires open markets, and that’s what the web represents, what the web (and any viable replacement for the web) must evolve into.

Mozilla’s road may be rocky in establishing FirefoxOS and its benefits. The web as a platform has much growing up to do (especially in things like having a common user interface for applications developed by different vendors), but it has every sign that it will.

Mozilla is playing the long game here.

Against Nonpersistant Web Advertising

I have a lot of complaints against advertisements in general, which I will not be discussing in this post. Instead, this post is dedicated to one of the biggest problems with web advertising: not being able to see the advertisement again.

Take YouTube as an example; if you visit a YouTube video, they apparently invoke some Pseudo-Random Number Generator to determine both whether to show an advertisement, whether it should be video versus popover, and whether it should bear any relation to the video.

Worse, though, is that you can’t replicate the PRNG; they don’t throw you the seed they use or anything. So if you start to watch a video, and decide later you actually want to click that advertisement, you can’t. If you stop watching a video advertisement a few seconds in, closing the window, but then process the snippet you saw and decide you want to watch it, you can’t.

This isn’t unique to YouTube. All over the web there’s different advertisements with each pageload, and you can’t get back to them. Some sites like Reddit are a little better in that they do have persistent addresses for at least some of the advertisements. But you still can’t see the advertisements you’ve seen.

You can’t share these advertisements. They’re like ghosts. They’re black ops. Appearing for a mere moment, just long enough to draw the knife blade across your throat. Okay, maybe that’s too dramatic. They’re more like insects that buzz up by your ear just long enough to make you wiggle a little.

“But!,” I hear the marketadvertbrandologists say, “Advertising is not about selling products, it’s about…” and there they go trying to sell advertising as being the equivalent to your grandmother’s cake or grandfather’s pie. That they want you to feel like a kid in a candystore when you think about your vitamin supplements, carrying around a brown paper sack and scooping the goodies into it.

The main thing is, even that excuse doesn’t work if people want to spread the advertising message. If Smith says, “Jones, did you see the really cool video advertisement for genetically modified hermit crabs?” Jones says, “No, I did not.” Smith says, “Well, that sucks, because I can’t give you a link to it.”

Just one more reason to dislike advertising.

Near-future-diving the Internet

We all know what the browser and web and Internet experience is like today.  There are some great things already happening.  But there are also some lousy things we have to deal with that we hopefully won’t forever.

One example of the bad comes in the form of passwords/the current sign-up user experience (UX).  Along a similar vein of grief ore is the various CAPTCHA systems employed to ask commentators why they aren’t helping the tortoise on its back, baking in the hot sun, in order to evoke an emotional response.

There are three areas I’ll examine today:

  1. Data extraction and manipulation
  2. Resource management
  3. Discussion defragmentation

Data extraction and manipulation

Let’s say you come across a series of dates, like the list of earthquakes at Wikipedia: List of major earthquakes: Largest earthquakes by magnitude. You ponder quietly to yourself, “I wonder what a really napkinny mean of the time between those is?”

I happened to have that very experience, so I:

  1. Opened the python REPL (Read Eval Print Loop, an interactive session for a dynamic language)
  2. imported the datetime module
  3. Hand-created an array of those dates
  4. Sorted the array
  5. Mapped them to an array (size n-1) containing the deltas
  6. Summed that array and divided by n-1
  7. Asked the result what that was in days (a_timedelta.days)

But that was a lot of work, and only for a very simple property of the data. It could have been made easier if I hadn’t hand-created the array of dates. That would’ve been a matter of either copy-pasting the dates into python or into a file and reading them, converting them into dates.

We can say with some certainty that looking at the average gap between a series of dates is a common operation. Can we say that in the near-future of the Internet we would like that kind of operation to become trivial for anyone to execute?

Resource management

Here the resource stands for the R in URI. You are probably dealing with resources all the time. Depending on your use patterns, you may have a hundred tabs open in your browser right now. You may have tons of bookmarks. But even if not, you still have to manage resources.

You also manage them in the more traditional sense, of how many tabs you can have, and how long you’re willing to look for one. How many bookmarks, versus how many of them you’ll ever actually use.

The question for the near-future is how much smarter we can make the tools we use to manage the resources. Tab groups (formerly called tab candy and panorama) in Firefox lets you create groups of tabs. The search feature of Tab groups undoubtedly does more, especially coupled with the Switch to tab feature of the awesomebar.

Part of the difficulty in the explosion of resources is that of finding things. You might take ten tabs to find the one you want, but the other nine may sit idle, requiring attention to be removed.

This difficulty even infects the otherwise superb awesomebar: when you start typing in order to find a resource, it’s often the case that the search items remain higher in the awesomebar results than the resource(s) they led to. That’s plausibly fixable, but does require some kind of recognition of the content of the pages in the history.

That points to a potentially important distinction for the future of the web: a separation between the activity of searching and using resources. Often pages that aren’t directly searches are still part of the search activity rather than the use activity.

Discussion defragmentation

This was prompted by recent discussion on the Mozilla discussion lists regarding how accessible said lists are. Their lists are currently available in three forms: newsgroups, via the Google Groups web interface, and as mailing lists. The lists serve as one of the main discussion formats used for the Mozilla community.

But other discussions of that community (which is much alike the rest of the free software and open source communities in this regard) occur scattered among many blogs across the web. Still others occur on IRC (Internet Relay Chat), which may or may not be logged and made available on the web. And then even more occurs on bugs in a bug tracker.

So we see fragmentation of discussion. But the other half of the story is where discussions will migrate away from their original topic, spawning new discussion. In the case of bug trackers, the commentary may consist of a single thread, but most other forums allow for threaded discussions.

Each of these forms is a tree, so some sort of tree unification would be required to defragment these discussions, and to allow proper splitting off of newly developed topics. It’s harder to envision for subtrees that occur off of the web, but it’s conceivable those parts could be imported to various web-based servings in order to include them.

The challenge to building the full trees are knowing where the upstream discussion is (if any) and where the downstream discussion(s) are (if any). But this is standard tree stuff. The downstream discussions can quite easily point to upstream, and they can also send something like a trackback to upstream so it can collect the downstream locations.

What that might look like (using a pseudodocument for ease of example):

[On foo.example.com]
< !DOCTYPE htmlm>
<htmlm>
  <messages parent="http://bar.example.com/6878c1e8-866f-11e1-a574-001fbc092072">
    <message id="290a4ec0-8672-11e1-a4e2-001fbc092072" time="[TIMESTAMP]">
      Hello, world!
    </message>
    <message id="ca0bfdc8-8672-11e1-b2d3-001fbc092072" time="[TIMESTAMP]">
      !dlrow ,olleH
    </message>
  </messages>
</htmlm>


[On bar.example.com]
< !DOCTYPE htmlm>
<htmlm>
  <messages> <!-- no parent, this is a new root -->
    <message id="6878c1e8-866f-11e1-a574-001fbc092072" time="[TIMESTAMP]">
      Uryyb, jbeyq!
    </message>
  </messages>
</htmlm>

[On baz.example.com]
< !DOCTYPE htmlm>
<htmlm>
  <!-- Treat the parent as a root, even if it has parents -->
  <messages parent="http://foo.example.com/ca0bfdc8-8672-11e1-b2d3-001fbc092072" root="true">
    <message id="fdf0eec2-8673-11e1-b336-001fbc092072" time="[TIMESTAMP]">
      ¡pꞁɹoʍ 'oꞁꞁǝɥ
    </message>
  </messages>
</htmlm>

One thing this example doesn’t explain is how to make a leaf a root of several new discussions. I’m sure there are other cases like that where things get complicated, like wanting to merge discussions (ie, make it into a graph rather than a tree). One case where that could occur is if someone wants to reply to two messages with a single reply that ties everything up with a nice bow.

But it’s worth thinking about, as the current situation is definitely substandard and improving it can result in a better outcome.