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.