Not so Svbtle

A few weeks ago I got an invitation to Dustin Curtis’ hip new(ish) blogging platform called Svbtle. The original announcement created a bit of a stir around the Intertubes. It was supposed to be both a clean, minimalist writing environment and a fresh new platform for vetted, competent writing. Here’s a relevant excerpt (emphasis mine):

I wrote this engine entirely for myself, without the intention of opening it up to other people. But since realizing that it has improved the way I think and write, I’ve decided to open it up to a small number of vetted bloggers. At least at first. The goal is simple: when you see the Svbtle design, you should know that the content is guaranteed to be great. Network bloggers are encouraged to keep quality high at the expense of everything else.

If it sounds provocative, that’s probably because it was meant to be. The emphasized line in particular, is fighting words, as they say. It’s been about a year and half since that post (at least that’s how long I think it’s been, Svbtle posts don’t seem to have visible timestamps). Now that I have an invite, I thought it would be interesting to see how things have held up. Is Svbtle really all that Mr. Curtis cracks it up to be?

At face value, the original claim seems to have fallen flat. The idea for a minimalist writing platform was copied and open-sourced almost immediately and there’s also a Svbtle-like WordPress theme. Given that Svbtle will let you use your own domain name, it’s hard to tell that you’re reading a Svbtle post unless you care to look. So much for seeing and recognizing the Svbtle design. But what about the rest of the claim? Are we really guaranteed that the content is great?

Svbtle currently positions itself as a “new kind of magazine”. The current About page reads as follows:

We’re a network of great people mixed with a platform that takes the best things from traditional publishing and combines them with the best parts of the web. We want to make it easier for people to share and discover new ideas.

The Svbtle blog announced that they received an undisclosed amount of VC money (good for them). They currently have over 200 writers and hope to build “the future of journalism”. Svbtle is building us up to expect not only good writing, but great writing and journalism. The current state of Svbtle doesn’t give me much confidence. As of this writing, many of the posts on the Svbtle front page would probably only be of interest to a certain section of Silicon Valley resident.s Posts like “The 3 competitive Defenses of Enduring SaaS Companies” and “The Single Best Content Marketing Channel for your Startup” make me think that Svbtle is more a thinly veiled mirror of Hacker News than a magazine devoted to ground-breaking journalism.

To me at least, Svbtle is not so much subtle as confusing. Who are these 200 writers? Why did they get invitations? They claim to span “at least eight disciplines” and journalism doesn’t seem to one of them. If Svbtle is supposed to take the best things from traditional publishing, then where are the editors and expert photographers? If Svbtle is going to be “an important place for the sharing of ideas” then where are the comments and where do I send Letters to the Editor?

Furthermore, this confusion isn’t just on the outward, public face of the endeavor. As a writer, it’s not clear to me what I get from publishing on Svbtle. A group of 200 writers is not exactly exclusive, especially when I have no idea what the invitation criteria are. I don’t see any Terms of Service, or an Export button for that matter. The invitation email claims “One of our main goals is to help members become better writers”, but there’s no mention of how that’s supposed to happen. Is there a peer review or editorial process? If there is, what are the qualifications of the editors and reviewers? I just wrote and published a short post and there doesn’t seem to be any of those things. Can I be kicked out and my posts deleted at a moment’s notice?

I suppose that for people dissatisfied with their current blogging platform Svbtle might be an interesting alternative. But it’s not for me. I’m perfectly content with WordPress when it comes to actual writing and Tumblr when it comes to everything else. I’ve never been distracted from my writing by the various controls and buttons and Svbtle lacks too much of what I’d consider essentials for a modern blogging platform.

Of course, it’s certainly possible that I simply don’t get it and that Mr. Curtis has some grand scheme that I don’t grasp. For the time being, though, it seems like Svbtle is simply just yet another blogging platform. It’s a different flavor than WordPress, Tumblr, or Medium, and some will be drawn to it for that reason. At this point, someone will no doubt point out that I won’t get it unless I try it. While I’m skeptical of that line of reasoning, I would like to give Svbtle a fair chance. Maybe the writing experience really is that much better. If I can think of something that needs publishing and isn’t relevant to The ByteBaker, then my Svbtle blog is where it will go.

(As an aside, I’ve been thinking of starting a research blog, along the lines of Lindsey Kuper’s Composition.al,. I’d use Svbtle for that, but there seems to be no support for inserting syntax-highlighted code snippets.)

In the meantime, if you’re looking for modern, journalistic writing that covers a variety of topics, I recommend a publication like New Republic.

Moving to org2blog for publishing posts

For most of the last few years I’ve been using the WordPress online editor for writing posts. Part of this was because I moved between computers a lot and wanted to be able to get at my posts and drafts from wherever I was. But since I’m now using one machine for most of my writing (and all of my blogging) I’ve been able to finally move to centralizing all my writing under Emacs. Luckily I found a great Emacs mode that makes posting to WordPress a snap. org2blog is made to be used with org-mode files but by and large you can ignore the org-mode part (if you want to).

Org-mode is a helpful plain text mode for organizing notes, todos, agendas and even writing in general. I use it for taking notes about academic papers and meetings I go to. org2blog mainly uses the plain-text org format for setting up the metadata for the post — title, date, tags etc. But org-mode also makes inserting links easy and I’m much faster writing with all my Emacs editing shortcuts than I am in a text box in a browser. Org2blog then posts the org-file as draft (or published post) with a single command. I personally just save as drafts and then look at the preview before hitting publish. By writing in org-mode on a single I can also keep local backups of all my posts. Currently each post is just saved to a ByteBaker folder as a separate plain text file but I might put it all under version control at some point.

I have been toying with the idea of moving this blog off WordPress to a more home-brewed setup, but I haven’t been able to justify the time and effort it would take. Might be a winter project to get through the upstate New York winters. Personally as long as I have a trustable backup of all my code and add new things easily I’m fairly ambivalent about how the HTML actually gets generated and presented (especially if it’s done by open source software made by people I like). For the time being I’d rather invest in writing the blog than hacking it.

How to blog like a hacker

NB This was supposed to have been published last week, but WordPress ate the original draft I wrote and it took me a while to get the motivation to write it again. But it’s done now. Enjoy

Self-published content on the web has exploded and many of the millions of blogs out there are run on content management systems like WordPress, Blogger, MoveableType and LiveJournal. These are all robust software products that have survived years of rigorous field testing and offer a wide variety of features and customization options. They are good tools which offer a wide variety of customization options and other features. However, to those of us with a more do-it-yourself bend, it can sometimes seem that these systems do a bit too much.

Most of these systems provide dynamically generated content (MoveableType has a static option). The actual content (like posts and comments) is stored in a database and the actual HTML pages are generated on the fly. This makes things like templates and themes simple to use (as you don’t need to regenerate thousands of pages for each change), but it also means that you need to use considerable CPU for every page load. This can be problematic if you have a busy site or traffic spikes. CMS’s also offer a wide variety of features besides just running a blog or website. They allow RSS, comments and a variety of media features. While some people certainly use all these features, it can be overkill for others. Sometimes all you really want is to be able to write some text with an image or two and put it online in a quick simple way.

There are other, perhaps more esoteric reasons for wanting to run your blog without a modern CMS. You might want to have complete local access to your data and web interfaces for writing blogs might not be to your liking. Some people swear by flat files and their favorite text editors and they both have their own advantages. Flat files are simpler to browse about that depending on an interface to a database and certainly easier to move around. Advanced editors like Vim or Emacs can make the job of writing more efficient, especially if you’re already used to them. Popular version control systems like Git can make sure that your data is kept backed up and safe and can be used to keep things synced between a local machine and a server.

A combination of all the above factors has led to the creation of a number of ‘static site generators’: tools that take simple local files (generally plain text with some simple markup) and turn them into full HTML pages after applying some sort of template. You can keep the original source anywhere you want and just transfer the generated, static HTML to a server for the world to see. The original “Blogging like a hacker” post was written as the announcement of a popular static site generator called Jekyll. Jekyll is written in Ruby and is used to power the GitHub Pages online publishing system (it was written by one of the GitHub team). There is a Python clone of it called Hyde (fittingly enough) and a Perl program called Ikiwiki does a similar but integrates a version control system and is meant to be deployed on a server.

I’m not going to pretend that static site generators are the best fit for all or even most bloggers and web writers. In fact, I would suggest that static site generators are you’ most useful for those people who value simplicity and control more than anything else. Using a static site generator well requires at least working knowledge of HTML and CSS and a good text editor. Using a version control isn’t a necessity, but it seems to be that being able to use a VCS is one of the big attractions of static site generators: you don’t have to rely on whatever draft system your CMS provide, but rather you can use industry standard version control tools to keep your work safe.

I’m a fan of practicing what I preach, so I’ve been using a static site generator as well. I’ve personally be using Jekyll to manage a personal site for the last week or so. I think it’s the simplest such tool to set up and has sufficient features to create some pretty good looking websites. That being said, I don’ t think I’ll be moving this blog off WordPress any time soon. WordPress suits my needs well enough and converting almost 250 posts from WordPress to plain text is not something I want to spend my time on at the moment. I export the blog weekly and keep the resulting XML file under version control to be safe. I think of it as a sort of middle ground between having everything hosted in a remote server database and having a locally secure version of everything.

As I continue writing and using software, I’m coming to realize that the best tools are the ones that can be molded to your needs. Static site generators attract users who aren’t afraid (and might even be eager) to get under the hood. It’s the same sort of mentality that attracts people to open source software and systems like Linux: the ability to tinker to your heart’s content until you have something that is just right for you. If you are someone who gets can spend hours setting up your computing environment to be just the way you like it, then you’ll probably like working with static site generators. On the other hand if you couldn’t care less about what goes on when you hit the ‘Publish’ button, thats fine too. Use WordPress or something similar and just focus on writing great content.

Is WordPress professional enough?

My college has recently started rolling out WordPress MU to students in a small scale experiments. From what I hear, it seems like IT expects WordPress to gradually replace the existing static web pages that most college groups now have (most of which are never updated I might add). I think it’s an interesting idea and I’m all for it. I hope this will make it much easier for college groups and students to maintain a stable web presence.

But there is a particular little question that I’m currently trying to answer. The foreign languages center has a program for students to make ePortfolios: basically small websites where students can show off all the language experience they’ve gathered over their years here. It’s a good idea with a decent amount of support from the faculty, but the uptake has been rather slow. Till now we’ve been using a standard Dreamweaver template where students just fill in the blanks with their own text, images and video. However this approach doesn’t seem to have gelled well with the students. There are a number of different reasons. Despite how easy Dreamweaver makes a lot of things, there is still a considerable learning curve. People who aren’t naturally inclined to such things need a reason to learn and use them and I don’t think making an ePortfolio is a strong enough motivation. Also students actually need to have Dreamweaver in order to do something, which means they need to go use a library computer. I’ve made some templates for the portfolio but due to the slow update, we haven’t really been able to get students past the basic one. I’ll eventually put the templates up for download once I clean them up a bit.

At this point in our story enters a brash young outsider: WordPress. In a static scenario like the college ePortfolio, WordPress is a total game-changer. It makes things a lot easier for people who are not used to making their own sites. It’s a great tool for anyone who wants to quickly put their information out on the web. I run this site on WordPress with a custom template and widgets. However, if you want to set up a professional web site which will mostly stand as evidence of you work and not a rapidly changing blog, I’m not sure if WordPress is the way to go.

My college is rolling out the Multi-User version of WordPress to students, which makes perfect sense for a college setup. But for the end user, MU does have some serious constraints. Most importantly you can’t install your own plugins or themes and so if you want something that the native installation doesn’t provide, it may not be very easy to get it. This in turn leads to the problem of sameness. Because you have only a small number of themes and other options to choose from, your site is bound to look very similar to someone else’s. I personally think this is a big problem if you seriously want your site to be a reflection of yourself on the web. This was the main reason I decided to take the plunge and move to paid hosting.

For most students this doesn’t matter. Their blog is mostly something personal and so it doesn’t really matter much if it stands out visually. An ePortfolio is different however. By definition, it’s meant to be be professional and needs to stand out. It’s meant to be something that you can send to potential employers and will reflect favorably on you as a professional. I think is very hard to do with a stock WordPress MU blog. Even if you stick to a clear format with well thought-out pages (which is how we’re trying to proceed), you are still completely at the mercy of the original design which might not be anywhere near what you want. What’s worse is that you might start trying to bend your content to fit the design. This might work out for good designs, but if you do it too much you’ll completely loose your own style. Loosing your personal style when putting together something that you want a lot of people to see is self-defeating.

The current Dreamweaver is very reminiscent of old-school web design with lots of tables and fixed-width elements, both of which are falling out of favor with current generation of web design. WordPress has some very good modern themes, and anyone moving to WordPress needs to utilize this instead of trying to pull their old designs along with them. The definition of what is professionally acceptable changes every so often and at this point in time, fluidity and flexibility are definitely the way to go.

For myself, a considerable amount of effort went into selecting this theme that I’m using. From the start I wanted something clean and sharp which would encourage readers to look at the content and not get distracted. Hence the choice of a mostly monochrome template which places emphasis on the categories and the main post body, while the sidebar makes search and RSS prominent.

I’m still uncertain as to whether or not using WordPress for a professional ePortfolio is a good idea. If it was a standard WordPress install where students could change the look and feel of their Portfolio to suit their style, I’d be all for it. But with MU, I’m not quite so sure. I would really appreciate feedback from my users on this matter and any experiences they could share would be appreciated. I’m going to keep thinking about this matter and I think I’ll have a part to play in whatever direction we go. I think it is very important for everyone to have a strong web presence, students especially. Tools like WordPress make that much easier to accomplish, but sometimes you just have to take a step back to make things the way you want them.

Simplicity and clarity as design tools

For the past week or so I’ve been customizing my WordPress install by adding a number of plugins. I plan on writing an article soon about what plugins I’m using, but first I’d like to talk about something that I’ve noticed about WordPress plugins. Installing plugins is easy. There’s plugin directory in every WordPress installation, generally under wp-content and you just drop a plugin folder in this directory and WordPress will detect it. If you’re using a recent version of WordPress, you can actually search the plugin repository and install a plugin from inside WordPress itself. This is really useful feature and makes using plugins much easier. However, the one gripe I have is that the settings to control the plugin get spread all over the WordPress interface.

Here’s a screenshot of my WordPress Dashboard. Along the left side you can see buttons for various drop down menus:

My WordPress Dashboard
My WordPress Dashboard

I’m currently using 8 plugins, each of which have various settings and interfaces to change those settings. One of those plugins (StatPress) has it’s very own sidebar menu. Two of them are under the Plugin menu, one is under the Tools menu and the rest are under the Settings menu. That means that if I have to find the settings for a particular plugin, I potentially have to look in 3 different places to find them. For me this is a clear design and organization mistake. Things that do the same thing should be in the same place. I’ve picked WordPress as the example because it’s what’s been striking me most recently, but it’s not the only one. Office 2008 for the Mac allows users to change the default saving format to the old formats. This option is in the same place for Word and Powerpoint, but is different from Excel.

Simplicity favors regularity. User interfaces need to be both simple and regular. Google’s interface is probably the simplest you can get. WordPress’ interface in general is pretty regular and simple, but the organization of the plugins is not regular at all and so there’s an extra level of complexity added in which users really shouldn’t have to deal with. It’s not just user interfaces. Indenting your code properly is also recommended for the same reason. All code that gets executed as part of the same operation should have the same indent level. It’s a visual clue that’s much easier to follow if done right than keeping track of curly braces. One of the criticisms of Perl is how it uses contexts: variables and operations can mean different things depending on what’s surrounding them. That isn’t always a bad thing, but it does mean that you have to consciously keep track of the context your code is in.

Similarly the development of the RISC processor architecture was motivated in part by the fact that most processor instruction sets are highly irregular with lots of instructions that seem very similar but actually operate quite differently (or have some seemingly arbitrary limitations). The book Computer Organization and Design which was co-authored by one of the creators of the RISC architecture, states 4 design principles, one of which is that Simplicity Favors Regularity. I must say I have to agree

While designers should try to contain functionality within regular components, it’s also possible to go overboard. Typical electrical installations in buildings are controlled by rows of identical switches. Very regular, but also perfectly impossible to tell which switch does what. Things that do different things should look different. Clarity is key. In the Design of Everyday Things, the author talks about how employees in power plants distinguish switches on their consoles by attaching different handles to them. One of the reasons that Lisp looks scary to a lot of programmers is that it can easily look all the same, as opposed to C-like languages where a for-loop looks very different from a function call or object creation. To be more specific, the external design of an object (or interface) should suggest it’s possible function. Admittedly this is harder for on-screen software than it is for physical object.

But these two principles seem contradictory. How do we reconcile regularity with easy differentiation. Part of the answer is that there is an underlying concept which is pretty powerful: ambiguity is bad. On Reddit today I saw an article criticizing Xfce’s settings interface. The author couldn’t figure out how to increase his text size. There is some comparison with the Windows 3.1 interface, but the central reason is that the Xfce settings interface is ambiguous: should text size be under Window Manager Settings, Display or User Interface Settings, all of which seem equally probable to the casual user. It’s the exact same case for my WordPress plugins. I think plugin settings should be under Plugins, but it does make sense to put them under Settings or Tools.

xfce-settings
Xfce settings manager

So the question then is: how does one avoid ambiguity and achieve clarity, especially when there really are a number of logical alternatives (like WordPress)? In some cases it’s possible to use clear labels to distinguish what operation will be performed. Taking another example out of design of everyday things: a flat bar across a door makes it clear that the door is to be pushed, not pulled. When it comes to designing software interfaces like WordPress or XFCE, it’s not quite so simple because there can be a lot of debate over which design is correct. After all, plugin settings can go under Plugins or Settings. I feel that the key here is to just make a choice and then make that decision known. In the case of WordPress, plugin settings could go in either Plugins or Settings, though I would personally prefer Plugins so that there is one place for all plugin-related activities. But equally importantly, plugins should not be given a choice as to where in the UI to go. The case for XFCE is made more complicated by the fact that the text size for the window title bars can be changed independently of the rest of the UI and hence text size control is spread over two places. I would still argue that the two should be pulled into a single interface, but this is a case where the interface is heavily influenced by the functionality. The thing to remember in this case is that even if something might seem clear and logical for the developer or engineer, it might not seem that way for a casual user. Users don’t want to spend any time actively learning where things are, they just want to use it and they want it to work. Beta testing products with users is a great tool and it’s also essential that design decisions be well documented in easy to read manuals.

In conclusion: ambiguity is the enemy. Fighting ambiguity requires a two-pronged approached. Interfaces must be simple and regular so that the user is not overwhelmed with choices. But at the same time, there must be sufficient cues to let the user know that different objects have different functions and how required functionality can be accessed. This can be done by using labels (different text and images) and by offering easily accessible documentation. However, good design requires many decisions and compromises and the best way to figure out which ones are best is by watching actual users and adjusting accordingly.

It’s time for web 1.0 to die

Yes, this is going to be a controversial topic to write on and yes, I have a history of terribly messing up controversial topics. But I’m going to make an effort to keep my thoughts clear and justifiable. Without sounding too academic, let me first present my thesis:

The original internet and World Wide Web was one of the greatest technological innovations of human history. It has an interesting history fundamentally linked to many other developments in the past few decades. Any self-respecting computer geek should take a few hours and read about the start and growth of the net. However, in the 21st century, the old web is no longer enough. It is time for us to accept that the old days of plain HTML and static links are just that: old days. I’m going to show that important developments have made it necessary for us to look at the web in a new light and we must actively embrace these changes so that we can have a hope of shaping them into something as monumental as the original web.

Clarification: I’ve received my comments that made me realize that I should clarify what I mean by web 1.0. For the rest of this post I’ll take it to mean the web in terms of mostly human-generated, static pages with mostly static content. By contrast web 2.0 can be defined to be mostly auto-generated, constantly changing content where the main human role is to create the content, not manage its organization or delivery.

Trip down memory lane

In many ways the start of the internet can be traced back to Douglas Engelbart’s famous Mother of All Demos in 1968. This demo showed of the revolutionary NLS (oNLine System) which was years ahead of its time and presented important concepts such as voice and video conferencing, complex document formats and hyperlinks.

Fast forward a few decades and the internet was slightly more mainstream by the early 1990’s. Though the internet had implemented Engelbart’s vision to some extent, it was actually quite primitive by the standards of the demo. Hyperlinks were simple one-way roads instead of the ubiquitous and powerful cross-linking system that was part of the demo. Rich media communication was still years away. However, the key parts were in place. The early web was a rather simple place to live in. Mostly text, followed later by simple graphics. Pages were static and more often than not crafted by hand. For much of the 1990s the web bore the signs of the academic and somewhat austere and information dense culture that had spawned it.

That web is not the web of today. With low bandwidth, information density needs to be maximized, presentation is often an afterthought. While there are a small number of producers and a large number of viewers, it’s fairly simple to do things by hand. The drastic change of the internet in the past few years can be attributed to two main causes:

  1. The growth of scripting languages and applications built on them have allowed a massive explosion in the number of content producers. It’s possible to build a fairly high quality website without writing a single line of code.
  2. Bandwidth, storage and processing prices have fallen, opening the door for rich media applications, which can be distributed across the Internet.

Dynamism’s Day

The game of web development has changed at a fundamental level. You can no longer ship a website to a customer and expect it to stay the same way for months at a time. Dynamic content is the order of the day. Blogs are no longer creations of random individuals with too much time on their hands. Instead, if you want to have a viable web presence, you’d better have a blog and you’d better update it regularly. This goes for individuals as well as corporations (especially those whose business is the web). This in turns means that hand-rolling a website is impractical at best and downright stupid at worst. A recent article proclaimed that Dreamweaver is Dying, and I have to grudgingly agree. Over the past two years, I tried maintaining an old style website by hand with mostly static content, but it’s simply not worth it. I would rather spend 5 minutes working on a new post than fiddling around with HTML and CSS to get things to look right. And don’t even get me started with keeping links and navbars up to date. Dreamweaver and similar tools help. A lot. But they’re not enough.

Web 2.0 is showing us an important fact that we must not ignore: content creators do not need to be programmers as well. What that means for you and me is that if you want to create a content-focused site (and that’s what most of us want really) then an automated content management system like WordPress or Drupal combined with good themes and widgets should be our first pick. Only if the need for customization becomes overbearing (ie. you need to forge a brand image with a custom logo and theme) should you consider diving into the code.

For web developers, this means that you should pick a content platform or two and learn it back to front and inside out. Try porting some previous designs and suggest that customers take a more active role in creating their web presence. The web’s hallmark is that it is by definition a bidirectional medium. If anyone wants to be successful on the web, that bidirectionalim must be respected and utilized.

To generate the best content, you want to have good tools. Unfortunately HTML and CSS simply aren’t good tools for writers, journalists or artists. They want, no, they need WYSIWYG editors where they can see what their content will look like without worrying about the layers beneath. Cheap bandwidth means you can now use heavier technologies like Flash to build better looking tools. Cheap storage and processing power means that you can generate the webpages on the fly while keeping the actual content neatly stored in a backend database. HTML and CSS aren’t the core technologies of the web anymore; they’re a thin veneer that hides the raw power underneath and gives everyone a simpler, focused view of what they need to see.

Let’s face it, HTML is ugly. It’s angle-bracket hell and you know it!! No human should have to write that sort of thing by hand. CSS is better, but not by much. A lot of people complain that autogenerators create really bad, really redundant HTML and CSS. That’s true and I thought that was a bad thing and I hand crafted my code until not too long ago. But the fact is: no one cares!! No one is ever going to really read your generated code except browsers and they’re mostly pretty tolerant of what they’re fed as long as it’s not downright wrong. The massive boost in productiveness far outweighs any aesthetic qualms you may have. Sure you still need to do some amount of tweaking to get things just right, but it’s very easy to get good enough without doing any tweaking at all.

On another note, the database + dynamic code creates far better presentation/data separation than HTML/CSS ever could. You had to be really disciplined to not mix presentation consideration into your supposedly semantically structured HTML and you never got it quite right. Admit it, you know you bent the rules. But with web 2.0, such separation is natural. Theming is at the heart of almost every major CMS out there and the web is a better place thanks to it.

But wait, there’s more…

CMS’s are just the tip of the iceberg. Web 2.0 is becoming an application platform, much closer to Engelbart’s vision than to Web 1.0’s “information highway”. It’s not just content creation and delivery, it’s active interaction that is getting the spotlight. And HTML/CSS utterly fails at this. Text and graphics are ok, sound and video are good, but active interaction is even better. Web apps may not be as feature-rich as their desktop equivalents, but they’re not far behind either. I use Google Docs almost as much as I use Word and web-based IDEs are starting to become a reality. Take a look at the SproutCore and Cappuccino web frameworks for some examples of what’s on the horizon.

The limitations of Web 1.0 have spawned the developments of multiple ways around them. The web is a now a mix of different document formats and PDFs are gradually becoming the document interchange format of choice for many organizations and companies. Streaming media has proved to be a much more popular alternative than simply offering up files for download. The dynamic web is a much faster and more interesting place than 1.0 could ever be.

We’re only starting to explore the web as a core component of personal computing. Cloud computing is still a very nascent technology, but one that looks like will it progress by leaps and bounds in the years to come. Amazon S3 lets you store practically unlimited amounts of data for really cheap making it possible for any technologically savvy individual or group to roll their own webapp without investing in massive computing resources first. Why buy a external hard drive when you can pay a small monthly free for crash-proof, access-anywhere storage? (If you trust them with your data that is, but that’s for another post…

Web 1.0 is simple and for the past two decades it has served the needs of human society admirably. But we need more now. There is a massive amount of computing power in the world today, but we can’t use it properly if we stick to old fashioned HTML. The internet is no longer a web of statically linked pages. It’s a complex network of rapidly changing web applications interfacing with each other on a number of levels. It’s more like a growing, vibrant ecosystem than it is a spider-web. Web 2.0 is alive.

In the near future…

We must learn to start treating the web like a vast collection of interacting programs and not just as a simple file hierarchy. The author of the Dreamweaver is dying article says (quite rightly):

In the relatively near future every website will be a dynamically-generated web application and all of today’s sites built on multiple static pages will be ripped out and replaced.

I think that is pretty close to the truth. Sure there will be still be some holdovers, but any serious website will have no choice but to become a distributed webapp: part of it running on a server (or server farm) and part of it running as a scripted application in your browser. Sure you’ll still need a grasp of HTML/CSS and their descendants (for a while at least), but you’ll use them in much the same you people do baking nowadays: you make special treats now and then, but you’d hardly ever bake your own bread.

Web 1.0 is dying. It’s passing can be painful, but it doesn’t have to be. Start using content management systems. I would recommend open source systems like Drupal, WordPress and Joomla. If you’re a developer, learn PHP and JavaScript while keeping your HTML/CSS knowledge in fair shape. If you’re building a web application or framework, make it easier for non-browser clients like other webapps to access data and functionality. The easier it is to use your servive, the more people will use it. Twitter and Google Maps seem to do this quite well. Don’t worry about supporting every version or every browser ever built. Pick 2 or 3 modern browsers and make sure versions released in the last year or two work well. Above all, don’t do anything to turn away the early adopters.

It’s time for web 1.0 to die an honorable death. It’s time for the rest of us to move on.