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:

Data extraction and manipulation
Resource management
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:

Opened the python REPL (Read Eval Print Loop, an interactive session for a dynamic language)
imported the datetime module
Hand-created an array of those dates
Sorted the array
Mapped them to an array (size n-1) containing the deltas
Summed that array and divided by n-1
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.

As any system grows, the cost of maintaining it as a single system grows. When a system becomes a certain size, maintenance of it is too high, and fragmentation is required.

This can be seen in pizza. Very few people refuse to slice a large pizza and eat it as a single unit. Even the few that do (you monsters) would cut up a pizza that was twice the size. Another way it happens with pizza is when the parties to the pizza could not agree on a single set of toppings, so different portions of the pizza have different toppings.

But it can also be seen in a few non-pizza places, which I will examine below.

Government

There’s a reason why a world government has been opposed by many people for a long time. The size of such a government would be so big, with so much bureaucracy, that we would all die trying to figure out which floor we needed to visit to requisition a pencil to fill out a form to submit that would let us take our street-crossing test so that we might return home.

At some point, government at one level may grow too large, and it should fragment. We have in the USA a national government, with state, county, and local governments. At some point we will need to rework the layers so that we have regional governments (some of which might overlap), or specialized governments (eg, the Mississippi River Government that would manage collective interests for states and regions directly related to that river).

When we learn to manage the layers of government, we will be able to institute world governance that is not a threat to individual liberty.

This type of fragmentation might be called stratification, since it deals most particularly with layering the governments.

Transportation

The transportation in America, of humans, anyway, is primarily by autonomous transport (ie, cars). There is some use of buses, trains, planes, and boats, but these are fairly limited in scope and, therefore, use. In certain areas, the road-based system has grown too large, and it should be fragmented to help reduce that burden.

You can only build so many roads before it does no good. It makes far more sense to add alternative transportation to augment the system. This means that fewer people are reliant on the original form, and more of the traffic does not overlap. It’s equivalent to adding multiple traffic channels in other systems. Instead of getting cross talk on a radio, you can simply move some traffic to another channel, and continue with multiple sets of conversations independently.

This type of fragmentation is also a form of stratification.

Browsers

At some point it may make sense to fragment the browser. When it happens, the OS gets new services to handle different parts of what’s currently in the browser. That includes HTTP, bookmarks, cookies, authentication, signup, and rendering.

Some of these are already partially fragmented in the form of libraries, and some browsers like Uzbl already try to move toward a browser that is reliant on outside components.

While the functions could permanently remain in the browser, with other applications relying on the browser as a service, the benefits of moving them outside will reach a tipping point for most systems and users.

This type of fragmentation isn’t about the layers as much as about specialization, which it could be called.

Mobile Devices

One day the mobile device will likely fragment. You will still have a dedicated component with a CCD for a camera, one with broadband wireless IO, one with a screen, but you won’t have a separate screen on your camera and phone.

In that world, you could use your computer screen as the head for your mobile device, for example, and you could use the power from the train to power your phone or mobile computer, saving your battery for later.

This is also a form of specialization, and some aspects are already there. Many smart phones use WIFI when available instead of the wireless broadband. There are also a few smart phones with the ability to plug in to a netbook-style dock.

Online Services

The final fragmentation for thought today is of online services like Facebook, but also things like Google and Wikipedia, and even the DNS itself may fragment. There’s an ongoing push for someone to come up with distributed social networking. Diaspora is the most prominent attempt, but others are working in the same direction. This type of fragmentation might be called democratization, because its primary goal is to restore the control over the service to the users.

But it also has other benefits, including the possibility of improved utility.

Stratification, Specialization, Democratization

The three types of fragmentation today were in layering the functions, in breaking up by activity, and in distributing the control of systems. They all have their places, and some systems will require a combination of them, or even something different entirely.

But we should be aware of the systems we interact with, and we should consider whether the problems we see are caused by other factors, or if they are due to the system outgrowing its britches.

The examples are numerous. I could go on. Economic systems, little league sports organizations, insect colonies, large-scale computing, military, etc. The abstraction of fragmentation is quite useful, and even more so when intelligently put into practice.

Tag: browser

Near-future-diving the Internet