Almost two weeks ago the W3C launched Community Groups (CG) and they're already receiving a decent amount of uptake.

In a recent interview for a .net magazine article I said the following:

W3C's new Community Groups are a huge step forward for W3C. A few key new things are that all it takes is four people to start a W3C Community Group, and they are also free to adopt additional licenses like Creative Commons CC0 and the Open Web Foundation's OWFa 1.0 agreements. W3C has provided a nice simple interface at their website http://w3.org/community. I think W3C Community Groups provide an excellent opportunity for implementing known best practices for open web standards development.

Related disclosures: I've been a contributor to W3C since 1998 (currently active in the CSS and HTML Working Groups and a few incubator groups), I'm on the board of the Open Web Foundation (OWF), as well as a founder/admin of the microformats.org standards community.

Upon reflection since their launch, I'm still as optimistic, and I'm very glad that W3C launched Community Groups as they did. They've clearly listened to a lot of input from a broad variety of other standards communities, and incorporated many suggestions from over the years.

Opportunities

If you're starting a new web standards effort, consider creating/joining a W3C Community Group to do it. I think W3C has set up a good amount of infrastructure that should empower small teams to get up and running quickly. I myself haven't participated in (or created) a CG yet, but I expect I will in the future.

If you're thinking of creating a new CG:

1. Use OWFa and CC0 in addition. Require that your CG also contribute its work with OWFa and CC0. In particular, require that contributors also agree to the OWFa 1.0 CLA, and contribute their work with CC0. I think using both of these will allow maximum portability of open standards ideas, concepts, features, and that's something we should encourage.
2. Establish a culture of working on the wiki first, irc second, and email third. A wiki can be a much more readable (easily consumable) than an email list (which might have endless delta threads you have to read through to figure something out). Wikis also force contributors to better prepare/gather/edit their thoughts as compared to email, where there is the frequent anti-pattern of contributors writing multiple long rambling emails on a single subject. See Wiki is better than email for more.
3. Prefer IRC to email for coordination. Since most of your contributions will be on the wiki, quickly sharing URLs on IRC, and conducting conversations in real time will help facilitate efficient collaboration (much more so than wading through seemingly never-ending email threads).

Keep in mind that W3C Community Groups are quite new and there will be odd bits here and there to work out. CGs are an excellent "1.0" release and everyone who worked on them, W3C staff, etc. deserve our kudos. I'm glad they didin't wait to perfect CGs and instead shipped it when it got to the level it did.

Suggestions

However, now that CGs 1.0 has shipped, here are few suggested improvements I'd like to see W3C consider:

1. Explicitly permit multi-licensing. E.g. it would be great if W3C added an entry to the Community Groups FAQ about using MIT/CC0 licenses like:

   Q: May I create a community group that licenses its work with another license in addition to W3C's licenses?

   A: Yes, as long as community group materials are made available under W3C license, and the citation requirement (that anything from a W3C CG specification must cite the name and date of the spec at a minimum) is kept, your CG may use additional licenses, e.g. CC0 or MIT.

2. Allow additional "sign-up" agreements when creating a CG. This is the counterpart to explicitly allowing multi-licensing, and that is to implement agreements to such licenses in the sign-up process. It would be great if a creator of a Community Group could list additional agreements, non-asserts, licenses that they want the CG to use via a web form, which would then ask others joining the CG to agree to them e.g. OWFa 1.0 CLA and CC0 contributions.

3. Don't require a W3C username and password. W3C should allow logins using various open/federated systems, and then create accounts tied to the identifiers from those systems, where people can check that they agree to the various agreements etc. Provide support for federated identity systems starting with the most used ones and incrementally adding from there:

   1. OpenID - most used federated identity system today
   2. RelMeAuth - tons of people have personal sites that rel=me link to OAuth providers like Twitter, there's an open source PHP library, etc.
   3. BrowserID - up and coming, implemented in a browser plugin.

   W3C should be setting the example here, using these "web-like" identity systems rather than requiring a centralized W3C identity/password to take part in W3C conversations.

Much of the above is from or related to my previous post on open web standards development, but condensed down to a few essentials for W3C Community Groups in particular.

Challenges

While I'm quite hopeful about W3C Community Groups, there is one big area of challenges they, and you (assuming you participate in or create a CG) will face: negative people (sometimes trolls).

For now, just be aware that it is an issue you will have to deal with. Both look out for negative behaviors and do your best to set a positive example. The subject is deserving of its own post.

I have a feeling another challenge will be coordination. What happens when two community groups are created which discuss nearly the same thing? How should community groups coordinate (if at all) with existing working groups in areas of overlap? Is there some way of suggesting that two community groups be merged into one because their efforts seem similar?

I think it's good that W3C is providing the freedom for such groups to exist and communities to form accordingly. I think coordination across or among groups is best done on a case-by-case basis. Thus to some degree this is both a challenge, and a opportunity for community groups to evolve their own processes.

And that's really what I think community groups are about - an opportunity for a more distributed evolution of how different sets of folks approach and develop open web standards. I'm looking forward to seeing what kind of techniques each group uses, and what processes/rules they put in place to make the groups as effective as possible.

While researching a way to describe different parts of a URL for a runtime interface, I was shocked to discover that over the years, different specifications, implementations, and communities had developed an incredible variety of ways to slice and name the pieces of a URL.

I remember seeing XKCD 927 recently, laughing at the familiarity, and what appeared at the time to be quite a bit of exaggeration. 14 competing standards, hah.

I was developing a small single purpose microsite and decided to build it using CASSIS not just for application logic, but for the server-side runtime execution and flow as well. I figured the needs of a simple real world site would work well to drive the design of a simple runtime.

No need to invent anything new, just re-use Apache/CGI environment variables (e.g. as used in PHP, like SERVER_NAME). But they look like old C constants, and CASSIS coders will be more familiar with Javascript.

Window.location's properties seem reasonable, until you get to "search" for the "?" query part of a URL. What about the source, the specs for URL and HTTP? And that's when I started to see the problem.

With a little more research I found a half-dozen different ways to slice and dice URLs. Kevin Marks asked me, what about Python? And that made seven. I published my research publicly on the microformats wiki, which is a good place to document existing formats for something (a key step in the microformats process).

Among all the differences (and overloading of the same terms to mean different things) it did seem that there were some patterns. So I made a diagram of a sample URL, chopped into pieces and named according to seven eight nine ten twelve different conventions over the years, in the hopes that doing so might reveal such patterns.

I hope you find this diagram useful to both understand the many names for different parts of URLs, and what someone might mean when they use one of them.

Also available in image form (as of 2011-08-26, 720x350) image form (as of 2011-09-18, 748x644)

If you publish it, please link it to this blog post: http://tantek.com/b/4DY1

And if you know of other standards, implementations, or even cultural conventions that split up URLs and name the pieces differently than the above, please let me know. Note: username & password were omitted for simplification (and you shouldn't be using http-auth anyway); params omitted because it's obsolete.

A few conclusions:

• scheme is more prevalent than protocol. Yet anecdotally developers use protocol more, and in practice most schemes are protocols.
• hostname is used consistently (to mean the same thing) as are port and query.
• path has been used consistently for the past 10+ years and in a way consistent with its operating system roots.
• fragment(id) is used inconsistently as to whether or not it includes the leading "#" hash/pound symbol. However, notably absent from any specification or platform was the alternative phrase named anchor.

The highlighted subset of terms should work just fine for a new CASSIS web app runtime convention, thus inevitably fulfilling the expectations as documented and foretold by XKCD 927.

Thanks to Erin Jo Richey, Ian Fung, Kevin Marks, Ben Metcalfe, and Violet Blue for feedback and reviewing drafts of the diagram.

Update 2011-08-31: Thanks also to Jeremy Leader for IMing me the info about Perl, including a sample Perl script that slices up the example URL, as well as its output, and 1998 reference to URI library 0.01 readme.

Update 2011-09-01: Thanks to Wladimir Palant for reminding me about the Mozilla XPCOM interfaces nsIURI and nsIURL and their respective IDL files, used by Firefox extension developers.

Update 2011-09-02: I've added Node.js's URL class, originally documented in 2010 because of the debate on github, as well as jQuery Mobile's path.parseUrl thanks to Scott Jehl sending me the results of parsing the example URL into the various properties.

Comments

• 2011-08-26 Hacker News commentary thread
  • Funny that the first comment is not the post itself but about Falcon post UI (arrowkey navigation between items as numerous content hosting sites do, e.g. Facebook, Flickr, etc.). The "/* " problem noted was due to a very old stylesheet rule which has been fixed. t
• 2011-09-08 Saveen: A Great Diagram: URL Slicing by Tantek Çelik
  • Thanks for the kind words Saveen! t

In short, if you keep an inbox (in the Getting Things Done (GTD) sense), consider collecting into both sides of it as follows:

1. things you come up with - add them to the top
2. things the world sends you - add them to the bottom

and then always process your inbox(es) into your next-actions etc. from top to bottom.

This works for both physical inboxes (trays) and digital inboxes (e.g. text files).

The source of this insight for me was threefold:

• GTD collection order is unspecified. GTD does not specify an order for collecting things, just that you do collect them first (rather than reactively doing them), into as few inboxes (ideally just one) as possible, and batch process them later.
• GTD processing order is unspecified. GTD also leaves unspecified the order of processing items in an inbox - top to bottom, reverse, pseudo-random - it doesn't matter, or so it says.
• Freedom is a measure of how you spend your time. Similar thoughts have pre-occupied me for a while (per The Acceleration of Addictiveness vs Willpower, Productivity, and Flow). Free will is fundamentally about the conscious prioritization and time you spend on what you want to do vs what anyone else, or anything else, demands of you.

This isn't just about your self: this is about your thoughts, your will, and what you care about. For example, you might think, my parents (insert other loved ones) matter to me, I should give them a call, but maybe it's not a convenient time to do so, or you're in the middle of doing something else. So collect that thought, right into the top of your inbox.

Contrast: anything you get in the mail (someone else sent it and is demanding your attention). Or some object of yours breaks or needs maintenance (you have spares or backup plans/devices right?). These are good examples of things to collect into the bottom of your inbox. And what about email? Well, email is not your inbox, and if anything you should "process" it (if you can call it that) after you've processed your explicit inbox.

And with that, I'm going to call my parents, as that now happens to be at the top of my inbox.

Afterword: I was about 2/3 done writing this when I saw the news on Twitter about Steve Jobs stepping down as CEO of Apple. Even though he's remaining as chairman of the board, the message is clear: Steve is done taking an active role in driving product design at Apple, and will (hopefully) be taking time to take care of himself now first and foremost.

It's far too easy to fall into the habit of fitting into a system with all of its pressures, assignments, duties, and roles. Steve was in the rare situation of being able to do both, fit into a system and drive it / make it implement his will.

Few of us will ever have such an opportunity. That is, for the rest of us, we have to constantly choose what and who to pay attention to, our own thoughts, desires, and will, or that which the world thrusts upon us?

I think it is possible to prioritize, process (and follow-up on) your own thoughts first, and still keep up with interacting with the people and things that matter to you.

As usual, this is a productivity improvement work in progress. Your results may vary, and I'd like to know how they do. I encourage you to iterate upon anything you've learned here, and publish your findings and improvements publicly.

Every once in a while, design and development practices emerge on the web that enable a leap forward in our understanding of its potential. Developers' asynchronous use of JavaScript (JS) led to AJAX and breakthrough interactive web applications. Designers' semantic use of class names led to microformats and widespread portability of contacts, events, and more.

In the past few years we've seen the rapid proliferation of buttons on web pages that allow the user to do something with the current page or site over on another site or application. You've all seen them: Blog this, Digg, Read later, Follow, Like, Share, Tweet, +1. There's something more interesting going on here than mere social media self-promotion. We're witnessing the emergence of a whole new building block for the web: web actions.

Defining Web Actions

A web action is the interface and user experience of taking a specific discrete action, across the web, from one site to another site or application. They're not a specific technology but use a variety of technologies. Typical web actions consist of:

1. a visible hyperlink, button, iframe or other element (typically with a semantic class name) presented as an affordance to take a specific action
2. ideally, initial declarative markup (linking or form submission) to perform the action
3. JS (that uses AJAX techniques) to unobtrusively enhance said visible element to provide an inline and more responsive interaction
4. often an interstitial or simulated pop-up window for confirmation, choosing an option, or providing additional information
5. the execution of an action at another site or in another application

The most well designed web actions consist of all the items listed above. Ideally an interstitial should only be presented when necessary for specific reasons, e.g. authentication or a user choice or other additional input like a comment.

Web actions are not "just" hyperlinks. Hyperlinks are nouns and they reference destinations (sometimes with an explicit relation) with an implied action of navigation. In contrast, web actions are verbs and are first and foremost about a specific action that often but not always does something with the current page or site.

Web actions are also not "just" AJAX. AJAX typically refers to interactively responsive features (yes, often actions) on a site itself. While web actions often make use of AJAX techniques for responsiveness, they are distinguished by the fact that they work across sites. It is this cross-site interactivity that makes web actions explicitly web-like and thus named accordingly.

Twitter's "Web Intents" are perhaps the most exemplary of web action APIs created to date: they use well formed fairly minimal semantic markup (hyperlinks with class names) that work declaratively as-is on desktop and mobile browsers alike. They efficiently require only a single <script src="..."> to progressively enhance all Tweet actions and other Twitter buttons on the page.

If you're designing and building web actions for others to deploy, you'd do well to mimic Twitter's design. Twitter's documentation is also quite good with one minor-nit: they've appear to have used the phrase "web intents" confusingly to mean two different things. Twitter calls the overall feature "Web Intents", as well as referring to implying that the interstitial dialog windows asare "web intents" (From their documentation as of 2011-08-11: Web Intents don't require Javascript, but it makes it easier to pop them up ... recommend rendering each Web Intent at 550px by 420px - the emphasis added phrases seem to imply that the web intents are pop-up windows that are popped-up, and rendered at specific dimensions, though this implication is apparently unintended.). They do explicitly use the phrases "Tweet action" and "Follow button" though to refer to the buttons themselves, some form of which I think they should use for the overall feature as well.

From the user's perspective, the buttons and the actions they take are the feature. The interstitial dialog windows deserve their own term or phrase, perhaps something like "web action interstitialpop-up window".

To be fair, Twitter's documentation is for developers (it's on dev.twitter.com after all), and thus they're seemingly re-using the existing developer-centric phrase "Web Intents" to refer to the suite of API endpoints for performing actions on Twitter rather than the buttons and web actions as a whole.

This confusion/iteration has made me realize that it would be a good idea to diagram/write-up an "anatomy of a web action" that describes all the pieces (i.e. the five items listed above in Defining Web Actions) and how they interrelate.

Nonetheless, if you're considering adding web actions to your site, Twitter's Buttons and Tweet actions are a good place to start.

Two Tweet actions in particular made immediate sense to me personally, each in a specific context:

• "Follow" - a logical upgrade to simply linking to my Twitter profile in the sidebar of my home page
• "Tweet" - a quick way to share a specific post, a logical addition to the shortlink, permalink, and citation hypertext copy/paste fields in the sidebar of my blog posts

I've wanted to add reply, fave, retweet buttons to my self-hosted tweets for some time, however, it wasn't clear to me how to best present them, nor what the right "IndieWeb" interaction should be. At IndieWebCamp this past June, I led a hack session on "web intents user experience".

Erin Richey and I spent the better part of that day at IndieWebCamp iterating on how to best construct a UX with such buttons, made some progress, but found the terminology stifling and confusing (despite participating in Chris Messina's earlier "Standardizing Web Intents" session). Soon thereafter I decided to try referring to the buttons and experience as "web actions" which seemed to resonate with others and apparently had not been previously considered. In particular it was clear from discussions with Erin that such a more user-centric term really helped understand and explore the overall concept.

What was also clear from Erin and my analysis of the UX of these buttons was that current usage was all over the map. From sites that discretely used a few buttons here and there to outright "button sluts" which plastered their articles with a veritable NASCAR of social media logos. Their designs appeared to be driven more by fashion and brand fetishes than anything sensible or user-centric. There didn't seem to be any analysis of user motivations, nor emotional design: attempting to understand a user's reactions and motivations that might drive them to want to use any particular web action button. Erin has written more about this in her post Button Sluts and Web Actions.

Web Action Motivations and Clusters

Based on my research I've found that existing popular web actions can be placed into one of a few categories based on user motivations:

• later: "I don't have time or this is too long!" - AKA tldr or more positively put: I want to read this later. Readability and Instapaper are examples.
• save: "This is interesting and I want to save it!" - similar to "later", but primarily a collection impulse. Some use saving as a read later function, but this is more about collecting, categorizing, and knowing it's somewhere you might find it again since it might be useful some day. Bookmarking is a form of saving.
• props - "This is cool, I like this, I want to praise it." - This item is worthy and deserves recognition. Digg, Like, Favorite, +1 are all examples. Sometimes favoriting is used as a method of saving, but it's special in that it indicates a positive evaluation.
• share - "This is so good that I feel compelled to share it, my friends will want to see this, or sharing it will make me look smart, in-the-know etc." - This item is worth passing on to friends, perhaps with commentary. Tweet, Blog This, and Tumblr are all examples.
• follow - "I want to hear more from this author/site!" - I like this site/author, perhaps based on this post, and want to see more from them in the future. While Twitter's Follow button is the obvious example, the earliest occurrences of this web action date back to the late 1990s and the emergence of "subscribe to my feed / RSS" buttons. This may be the oldest web action.

There are more categories; these are just the common ones.

By studying and classifying existing web actions from a user motivation perspective, we can better design user experiences that place the web actions such that a user will more likely see them when they are motivated to use them.

Intuitively a few thoughts come to mind, like perhaps place:

• "later, save, props" actions near the top of a post
• "save, props, share" actions near the bottom of a post
• "follow" actions somewhere global to the site, like a sidebar

There's an opportunity to document existing research, do more research on different variations and approaches, and document their relative effectiveness.

The next step would be to try some of these out. In the coming weeks I'll be experimenting with them on my own site and encourage you to do so as well.

Once we have a better understanding of which simple web actions work best where, and which motivational scenarios drive users to use them, then I think we'll be able to better design standards for web actions and respective APIs. There's a lot of potential for web actions, but for that potential to be realized, it must lead with a good user experience first, and standardization second.

Web actions have the potential to change our very notions of what a web application is from a single site to loosely coupled interactions across multiple, distributed sites. In that regard, web actions have the potential to become a building block for distributed web applications.

Focus on the user and publish your work

I encourage everyone working on web actions to focus on user motivations and their experience on your site first and foremost.

If you're an implementer of web actions, follow something like Twitter's designs. If you're embedding web actions on your pages, choose actions and place them on your pages by matching them up with users' state of mind and motivations to act.

In both cases, share your work.

As an implementer of web actions, provide good documentation (as Twitter does, except consider describing your web actions feature primarily from a user-centric point of view, even to developers. A user-centric description will make your feature easier to understand for everyone, and will hopefully help your developers provide user-friendly documentation as well.). As a content/site publisher, share your visual design iterations and reasons why you chose to place specific web actions where you did/do.

I'll be sharing my work in progress on my blog and on IndieWebCamp.com. I encourage you to do the same.

Want to chat about it? Since the IndieWeb perspective is a good practical approach to using and developing web actions, let's chat in the #indiewebcamp channel on Freenode.

Update 2011-08-12: This article has been updated to correct the references to and descriptions of Twitter's Web Intents feature, in particular: Tweet action is lowercased (rather than "Tweet Action"), Tweet actions refer only to actions taken on a tweet (rather than all Twitter buttons), Twitter Web Intents are specifically the suite of endpoints for performing actions on Twitter, and the author's confusion regarding web intents referring to pop-ups has been documented via implying quotes from Twitter's documentation, as well as acknowledgment that such implication was unintended. Thanks to Ben Ward for feedback and corrections.

In OSX Lion both DVD Player and Safari fail to respect/use the monitor of the window that you're full-screening, and only use your primary (e.g. small laptop) display for full screen. Solution: use Firefox/Chrome instead of Safari, and use VLC instead of DVD Player (hat-tip: Daniel Glazman).

It appears either all the built-in OSX apps (e.g. DVD Player, Safari), or some system API they're all using for entering full screen mode broke in OSX Lion, hence a regression from OSX Snow Leopard. This bug was reported over a month and a half ago by OS X Daily, but apparently not fixed in the shipping version of Lion (OSX 10.7).

The problem is, if you use an external monitor with your laptop, and want to display a web page or DVD in full screen view on your second monitor - you can't. Even if you first move the window you want to full screen to your second monitor, when you choose "Enter Full Screen" in DVD Player or Safari, OSX Lion swoops (yes, cheesy effect) the window back to your laptop's smaller screen and expands it there, leaving an odd grey linen background on your external monitor.

There are two workarounds.

First, for full screen web browsing on a second monitor, download and install Firefox and Chrome. Both of these browsers properly expand a window to fill up the entire screen it's on when you use their full screen modes.

Second, for full screen DVD playback on a second monitor, download VLC, a donate-ware "free and open source cross-platform multimedia player". Thanks to Daniel Glazman for the tip.

After installing VLC:

• Select a DVD (or ripped DVD Player Media Document) in the Finder
• Choose "Get Info" from the "File" menu
• Where it says "Open with:", click on the pop-up menu which reads "DVD Player (default)" and choose "Other..."
• Choose "VLC". If you don't see it browse to where you installed it.
• Check the "[x] Always Open With" checkbox
• Click the "Add" button to dismiss the dialog
• You should now see "VLC" selected in the pop-up menu.
• Close the "... Info" window

IMPORTANT: In the "... Info" window, DO NOT click the "Change All..." button and "change all similar documents to open with the application VLC" - even though it sounds like a good idea. The problem is, it will turn your DVD Player Media Documents into folders which will open in the Finder and you won't be able to open/run in VLC or DVD Player. If you do make this mistake, you'll have to fix it with a command line like:

SetFile -a B /mirror/dvd/Inception.dvdmedia

which of course needs the "SetFile" command which requires that you first install XCode for OSX Lion, and add /Developer/usr/bin to the end of your /etc/path (which you shouldn't mess with unless you're comfortable with unix command lines and configuration files, and need to get something like cvs working again, ahem). Thanks to Daniel Craig Jallits for the clue that led me to figuring out the path problem with cvs in OSX Lion. Yes, this is a regression in XCode for OSX Lion.

Get Info on the rest of your DVD Player Media Documents one by one, and choose "VLC" from the "Open With:" pop-up menu. I don't know how to make this work automatically for any new DVDs or DVD Player Media Documents you might load/open. Using the "Change All..." option screws them up as noted above (possibly another OSX Lion regression). If someone finds a fix to the problem with "Change All..." (errantly changing DVD files into folders), please let me know!

Referencing Articles

• 2013-02-26 TUAW / TJ Luoma: Play .dvdmedia files with VLC (Internet Archive link. Original redirected to Engadget mid 2015, subsequently TUAW domain shutdown, re-emerged as a zombie in 2024)

A year ago Paul Graham posted The Acceleration of Addictiveness, and I just re-read it thoroughly. It is a wonderful insightful post. I agree with the whole thing and if you haven't seen it yet go read it first.

---

There's only one thing wrong with the essay: it's framed in terms of a problem rather than a self-reinforcing solution.

We are living in a world of accelerating addictiveness and increasingly I think the only way (likely lonely, squirming, and eccentric as Paul alludes) we'll get things done is the continuous directed practice and improvement of willpower, productivity, flow, and exercising thereof.

In All Fairness

To be fair 1: Paul does suggest by example taking long hikes and running, both of which I concur with, though I tend to substitute long bouldering sessions for long hikes. I find bouldering much more whole mind-body engaging: simultaneous problem solving, physical challenge, and confrontation of fears.

To be fair 2: The essay is the sounding of an alarm bell, with good reason. The problems he describes and predicts are real, are affecting us greatly, getting worse (from passively Amusing Ourselves to Death to actively texting ourselves to death), and (he stops short of saying this) our industry (technology, internet, web) is making them worse: how many people do you know who are working on designing and building ever more addictive and absorbing interfaces of constant interruption, and see nothing wrong with doing so?

A Metacognitive Hypothesis

Wording and describing (framing) something in terms of a positive, in terms of what it is or what you should do, is far more empowering, effective, and self-sustaining than wording or describing something in terms of what it is not, or in terms of what you should avoid.

A few examples you might be familiar with:

• Build on existing work vs. don't reinvent the wheel
• "Humans first, machines second" vs. "Don't boil the ocean"
• BarCamp (participant driven conference) vs. "unconference"
• Eat "mostly plants" vs. avoid carbs.
• Exercise and eat properly vs. lose weight.

Hypothesis: positive framing is more effective than negative framing because thinking and acting on negative framing unnecessarily burdens you with thoughts of the thing you're trying to avoid, and thus requires greater use of willpower (which is limited) to deliberately reject it.

In short: positive framing is cheaper to implement than negative framing for a more self-sustaining and scaling outcome.

Here are a few illustrative thought experiments relating to the essay topic:

The Stress of Denial

If I say, "Don't think of Twitter!", what are you thinking, and how much mental energy do you have to spend to not just go check Twitter right now? (How many of you did just that? Were you acting on your free will or an addictive impulse?)

If I say, "Don't think of Facebook!", are you able to avoid immediately checking it? Or did you spend the necessary executive control to resist doing so?

And if those didn't distract you, how about if I say:

Don't check your email, feed reader, IRC, Convore, iPhone, or Blackberry?

Either I just lost you (sorry to miss you!) or you just spent some executive control resisting the urge to check one or more of those, and that resistance probably stressed you out a bit. Take a note of that specific feeling of stress. As a shorthand, let's call this the stress of denial.

It's also the feeling of deliberately exercising free will over impulse.

The Stress of Focus

Now if I ask instead:

"What's the most important project, to you, that you're working on right now?" (related: Paul Graham touched on this in his essay: The Top Idea in Your Mind)

Or:

"What's the next action you can do to make progress on that project towards a successful outcome?"

How do those make you feel?

Both of those also induce some stress (unless you're already exceptionally organized, prioritized, focused, and/or your name is David Allen or Merlin Mann).

Notice how this specific feeling of stress is different.

Unlike the previous set of examples, you're not denying yourself something, you're instead making yourself figure out what matters the most to you, what matters now, and what can you do towards that. You're forcing yourself to focus. So as a shorthand, let's call this the stress of focus.

Aside from shifting from the stress of denial to the stress of focus, What else can we do?

Filtering Instead Of Denying

Paul concludes his essay with We'll increasingly be defined by what we say no to. He's right, we will and are.

The problem is, "saying no" is expensive. It costs you willpower to do so. Explicitly saying no doesn't scale. We need automatic or default ways to "say no". The best word we have for that is "filters".

We need filters against two sources of things to say no to:

1. Environment
2. People

We're far from figuring out how to do this (in fact the other side's techniques, commonly known as advertising, marketing, and sales, are way ahead of us). However, here are some things that I've found work for me, and they may work for you.

A few simple environmental filters:

1. Minimize your exposure to brands* and ads.
   • Cancel your cable/satellite subscription.
   • Replace your TV with a monitor (or projector).
   • Listen to your iPod (#brandirony) not broadcast radio.
   • Disable Flash in your browser (use plugins like ClicktoFlash for Safari and Flashblock for Firefox).
2. Choose paths through parks and neighborhoods, instead of malls and along storefronts.

People filters are much more difficult, as it's much harder to clearly determine who you want input from and about what.

I've been deliberately working on this for a few years and have seen what I feel like is only partial success. I've written up some of my specific techniques:

• Communication Protocols
• Communication Filters

Perhaps we can better solve this collectively, I encourage each and every one of you to create your own personal wiki, write up your preferred communication protocols, how you do and don't want to be contacted, and about what. Share your ideas for how you filter your social activity streams.

Lonely Fate?

Second to last Paul mentions: ... this kind of lonely squirming to avoid it [addictiveness] will increasingly be the fate of anyone who wants to get things done. (emphasis mine)

That's the thing about willpower, it's not a collective thing. It's a personal thing. No one is going to give it to you. You have to create it yourself. It's just you.

Willpower is a lonely thing. Exercising it can often mean deliberately deciding to do something different than everyone else.

Addictions are memetically viral (per Paul's example of how the use of cigarettes originally spread the way an infectious disease spreads through a previously isolated population). Fighting and avoiding such addictions requires exercising willpower and thus at times choosing to be a lone eccentric. The person that didn't smoke. Or doesn't drink (more challenging: limits their drinking). It might also mean you have to look harder for similar peers, who are also deliberately choosing paths that minimize and avoid addictions.

Harmless Addictions and Opportunity Cost

Cigarrettes and alcohol have well documented physical harms, but what about supposedly physically harmless addictions (like various internet distractions and interruptions)?

Their harm is opportunity cost.

This is your life and it's ending one minute at a time.

The time you spend giving into your urges and supporting your addictions is time you could have spent being creative and productive.

How you choose to spend your time defines you and your life.

Consumer or Creator?

Are you primarily a consumer, driven by appetite (inevitably, addictions), or are you a creator, driven by directed willpower to be productive and prolific?

Do you identify yourself primarily by your tastes, where you eat or shop, what brands you wear or gadgets you own, what bands you listen to or shows you watch, what websites you browse or feeds you read, or which apps you download and select for your home screen?

Or do you identify yourself by your creative output, what you cook or build, what writing, photographs, music, videos, websites, art or apps you make and publish?

If you identify as the latter and want to continue to do so, due to accelerating addictiveness, you will have to deliberately fight the former, and you'll increasingly need more willpower to do so.

Improving Willpower and Productivity

Being productive and creative comes down to one core skill: willpower, the ability to direct your attention, your focus, deliberately at what matters the most to your conscious rational mind (also known as volition, in contrast to your appetite).

With willpower, you can create the necessary environment and probabilities for inspiration that creativity requires.

Willpower is depleted over time. It's possible to restore it.

More importantly, it's possible to strengthen and grow your willpower, have more of it to "spend", and thus spend a greater proportion of every day being productive.

I'm collecting the techniques I've learned so far on wiki pages:

• Willpower Improvement
• Productivity Improvement

To be clear, they're far from complete, and I would not by any measure consider myself a master of willpower or productivity.

I have found these works-in-progress techniques incrementally helpful and share them in the hopes that maybe some of you may find some of them helpful as well, and better yet, have suggestions for improvement.

Finding Flow

While increased willpower and focus can help avoid internet distractions, the closest to the opposite of being distracted is a state of flow: ... in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.

I've only read part-way through the seminal book on the subject but enough to highly recommend it, and to recognize the state of flow when I've managed to experience it.

My personal experiences of flow have occurred during a few different types of activities, like writing code and standards specifications, or the aforementioned bouldering. In each case I observed a few things:

1. The absence of distraction by others. This is usually best achieved by signing off IRC/IM, closing email/Twitter, and putting away all communication devices (phone, iPod touch). Interestingly enough, the presence of others in the climbing gym isn't usually distracting.
2. A dramatic drop in the energy required to maintain directed willpower, that is, at some point I get so absorbed in the task itself that the need to expend energy to concentrate disappears replaced by a self-sustaining state of focus.
3. Feeling restored. Perhaps related to the previous item, after I've been in a state of flow for some time and complete whatever it was I was focused on, I often emerge not tired, but rejuvenated, as if I have more energy than when I started.

The point is, in addition to working on improving willpower and focus, there's even more to be gained if you can block out time to disconnect and direct those abilities to focus on a specific creative act and achieve a state of flow.

Focus on the Positive

If I could summarize the points of this article in a single statement, it would be:

• Focus on the positive

It's good to be aware of problems we're dealing with now and expect more of in the future, however, it's even more important to stay focused on solutions.

Regarding accelerating addictiveness in particular, I don't have all the answers, but I've been documenting various techniques which may help address various aspects, all listed here together for your convenience:

• Communication Protocols
• Communication Filters
• Willpower Improvement
• Productivity Improvement

Try them out and see what works for you. Have additional studies, data, or techniques to suggest? Write up your own respective wiki pages and perhaps both independently, and together, collectively, we can not only avoid addictions, but get more things done, and live more directed, focused, productive, and meaningful lives.

Have a good weekend.

Further reading

Wikipedia

• appetition (classical definition of appetite)
• executive functions
• flow (psychology)
• metacognition
• volition

Articles

• New York Times (NYT): Technology: Driven to Distraction - Series
• 2011-07-18 NYT: Still Counting Calories? Your Weight-Loss Plan May Be Outdated
• 2011-01-03 NYT: The Claim: Taking a Walk Can Help Reduce Cravings
• 2008-04-02 NYT: Tighten Your Belt, Strengthen Your Mind
• 2007-12-08 NYT: How to Boost Your Willpower

Books

• Getting Things Done by David Allen
• Flow: The Psychology of Optimal Experience by Csíkszentmihályi Mihály
• Don't Think of an Elephant!: Know Your Values and Frame the Debate by George Lakoff
• Fight Club by Chuck Palahniuk
• In Defense of Food: An Eater's Manifesto by Michael Pollan
• Amusing Ourselves to Death by Neil Postman

Thanks to Erin Jo Richey, Theresa O'Connor, and Matthew Levine for reading drafts of this.

Update 2012-131: L'Accélération de la Dépendance vs Volonté, Productivité et Flow, French translation by Christophe G. Ducamp.