The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

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.

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):

< !DOCTYPE htmlm>
  <messages parent="">
    <message id="290a4ec0-8672-11e1-a4e2-001fbc092072" time="[TIMESTAMP]">
      Hello, world!
    <message id="ca0bfdc8-8672-11e1-b2d3-001fbc092072" time="[TIMESTAMP]">
      !dlrow ,olleH

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

< !DOCTYPE htmlm>
  <!-- Treat the parent as a root, even if it has parents -->
  <messages parent="" root="true">
    <message id="fdf0eec2-8673-11e1-b336-001fbc092072" time="[TIMESTAMP]">
      ¡pꞁɹoʍ 'oꞁꞁǝɥ

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.

Incivil Disobedience

The participants must disobey the prompt that incivility poses. They must respond with care and defuse the situation rather than buying into the false story that the misbehavior is merely due to that person being an asshole or a troll.

One of the problems that seems to get brought up quite often is the incivil behavior that happens when strangers interact on the Internet.

There are a variety of motivations for that behavior, and I will examine them in turn.  But here’s the general list to let you stop and think about ones I might have missed if you wish:

  1. Impress others
  2. Share a bad mood
  3. Genuinely angry at the situation
  4. Pyschopathy

After looking at each of them, I will argue that (with the possible exception of psychopathy) they all stem from a single problem.

Impress others

This antecedent is rather specialized.  It occurs when there is an existing social structure in place, and a person wants to improve their standing in that structure.  It’s one that’s sometimes seen around FLOSS communities, because they create a natural social structure.

They also offer help or discussion of their projects, which leads new users to their doors at which they may be mistreated because some other participant feels that their relationship in the community isn’t as strong as they would like and believes that tearing into the user could improve their standing.

This behavior is especially prevalent in communities where it’s become a cultural attribute.  There are online communities that fit this bill, but so does the political and media establishment at times.

But that’s not the only reason that behavior occurs in relation to project-based structures.

Share a bad mood

This is another reason that it happens, and also applies to project communities.  If someone in the community is having a bad day and didn’t manage to extricate themselves from the community for the day to cool their heels, they may lay into another user, even a peer or a superior in the structure.

This one is hard, because the person is simply on tilt, and if it’s recognized as such the situation doesn’t have to become a burden to the participants and community.  But it’s too easy to overlook, and the natural reaction is to feed back into the community and make things worse.

Genuinely angry at the situation

Again one that is seen in project cultures.  Most commonly this is a matter of either RTFM (Read The Fucking Manual) or LMGTFY (Let Me Google That For You), but it could be something else, such as a peer pulling the rug out on a change the user worked on, or a user that feels like a change made increases the suck of the project.

They have a valid position, but they handle that poorly.


Psychopathy is a relatively rare psychological disorder.  It’s almost definitely not this, but it could be.  Maybe one in a hundred.

You will need to inspect the microstructure of their uncinate fasciculus for signs of underdevelopment, damage, or other abnormality, but be aware that could be a sign of other various disorders too.

Memory and emotion exercises may help over time, though at present the condition is largely considered untreatable.


Aside from psychopathy, the other three stem in part from insecurity, but there are other forms where insecurity plays a role.

In the instance of impressing others, the insecurity is with regard to the individual’s place in the community.  If they feel like they will be included and their opinion matters, they will not see the need to try to dig in further.

In the instance of a bad mood, the insecurity is of their own emotional state.  They have taken an emotional hit, and it is causing their brain to fixate.  They need to understand that the other community members have bad moods and they can avail themselves of the community for support for their problems.  They also need to find a way to normalize the firing of their brain.

And, in the instance of genuine anger they are insecure about their time and the presence of people that may not be as conscientious as they wish they were.  The best result for this case would be to take a moment to suggest the manual or search options, but to explain that they are willing to help. In this case it’s also notable that they are trying to ensure the community does respond to those that need help, so there’s also a measure of insecurity with regard to the community’s role and ability in providing that assistance.

Pulling it all together, a few things are apparent.  The main thing is that people have motivation behind their behavior, and while their motivation may be based on bad information, that doesn’t make it go away.  In order to get past the incivility on the Internet, the participants must not let the behavior of others push them to continue the bad behaviors or make them worse.

The participants must disobey the prompt that incivility poses.  They must respond with care and defuse the situation rather than buying into the false story that the misbehavior is merely due to that person being an asshole or a troll.

In the case of genuine trolls?  It’s still an insecurity.  If it’s a Foo user going in to troll the Bar project, they aren’t secure with their choice to use Foo over Bar.  Note you can replace Foo and Bar with just about any sort of rivalry or difference of choice.  It could be Cat and Dog, Allah and Yahweh, Coffee and Tea, etc.  Or Vim and Emacs.