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,. 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 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.