At the risk of becoming a link blog, anyone thinking about social software should go and read Dare Obasanjo’s latest post: Participation as Social Capital: The Fundamental Flaw of Social News Sites. I think the most telling part for me was:

Although turning participation in your online community into a game complete with points and a high score table is a good tactic to gain an initial set of active users, it does not lead to a healthy or diverse community in the long run. Digg and Slashdot both eventually learned this and have attempted to fix it in their own ways. The trouble with starting a new social site is always in bootstrapping. How do you get enough people using the site to start making the social aspects actually pay off? Ranking users is basically the default answer because it works so well with even a few users – it’s easy to get to the top and you feel just as special about getting there so you hang around and try and stay there so it helps to build the initial users of the site.

I’ve had this article by Seth Gottlieb open for a while now but quite frankly don’t have much I could add except to say go read it. The idea that content is more than just data because of how real people perceive and work with it leads to a huge difference in how you design user interfaces for content management systems. A content management system should be more than just a web interface to some great big database, it shouldn’t make users think the way the database is laid out, it should let them focus on the content and the true messages that it conveys.

For the first few years that I worked at Ephox there was a regularly recurring problem: how to let our clients know exactly what’s changed between versions. We were good at showing off the new features but never had an accurate list of which bugs were fixed and every so often a client would ask for that. It seems simple enough – just keep a changelog – but there were some challenges.

Around the time of the iPhone’s initial release, I wrote:

It’s this popularity of Java in the mobile phone world that makes the lack of Java on the iPhone seem so odd to me. I can understand Apple wanting to have complete control over the iPhone interface, and I’ll concede that most of the existing games for mobile phones probably wouldn’t translate very well to the keypadless iPhone, but it will be interesting to see if Apple can satisfy the great desire for cool little mobile games that today’s teenagers, a key market segment for the iPhone, without leveraging the existing knowledge mobile games developers have in Java. Turns out I was completely wrong. Teenagers don’t give a damn about those gimmicky little games on their mobile phones, they just use them because they’re there. The iPhone’s coolness factor and the built in iPod is all that matters. Even wandering around Australia (where iPhone’s aren’t yet available) with my iPhone, lots of people asked about browsing the web, the iPod etc but not a single person asked about games (and yes, I do know quite a few teenagers who were doing the asking but still nothing about games).

Doug’s discovered a way to improve the effectiveness of simian to avoid adding more duplication to a code base:

The solution is very simple. The simian-report is a an xml file, so I wrote a SAX2 DefaultHandler that was able to parse the number of duplications at the different threshold levels. Putting this into a trivial ant task then gave us a task to help make things no worse even at levels below what the simian-check was doing! Within the first week, the new legacy-check was breaking the build (where the simian-check would never have) and focusing the teams attention on how to make things better. The solution is simple and really cool. I have no doubt that it will have a big impact on the amount of duplication and the overall quality of our code. The trouble is, Simian’s normal reporting is really, really lousy and Doug’s extra check highlights just how useless Simian is at telling you where the duplication is instead of just detecting that there is duplication.

There are a lot of articles around the place giving generally good advice on how to be a better blogger and get noticed. Alastair Rankine highlights one of the key problems with slavishly following this advice – you become boring:

I was initially attracted to Atwood’s blog for its relatively simple premise and smart delivery. With startling regularity over an extended time he managed to deliver bite-sized morsels relating to the stated domain of programming and human factors. He writes well and generally illustrates his point in a clear and easy to digest style. It’s quite engaging.

Back as far as Raskin’s The Humane Interface, and quite possibly before, modes in user interfaces have been frowned upon. Despite that, huge amounts of software ships with a simple mode and an advanced mode. The theory being that when users get started they use the simple mode which makes the simple tasks they want to do really straight forward. Later when they want to do more than the basics, they’ll be more familiar with the software and thus be able to handle the advanced mode.

David Welton described a frustration he had with FireFox’s spell checker which piqued my interest:

I write most of my email (in gmail) and submit most web site content in English, however, a significant portion is also done in Italian. I leave the spell checker in English, because Italian is, in general, quite easy to spell, so that even as a native speaker, a helping hand is occasionally welcome. However, it isn’t as if I write Italian perfectly either, so the help there would be nice as well. I find it quite annoying to go change the language in the spell checker option each time, especially when, as an example, I’m responding to email and do 2 in English, one in Italian, another in English, and so on. On the face of it, identifying what language an author is using looks a lot like a natural language processing problem and thus requires a PhD and many years of research to tackle. Looking a little closer though, you begin to realize that the problem domain is dramatically reduced in this case:

Kevin Gamble pointed me towards the Sun Wiki Publisher for publishing documents to MediaWiki servers straight from OpenOffice/StarOffice. The key problem with these types of integrations is that wiki markup simply can’t handle anywhere near the same level of expressiveness as even HTML, let alone a word processor document. Hence the description mentions:

All important text attributes such as headings, hyperlinks, lists and simple tables are supported. Even images are supported as long as they have already been uploaded to the wiki site. An automatic upload of images is currently not supported.

Jeff Atwood:

Some of the largest sites on the internet — sites you probably interact with on a daily basis — are written in PHP. If PHP sucks so profoundly, why is it powering so much of the internet?

The only conclusion I can draw is that building a compelling application is far more important than choice of language. While PHP wouldn’t be my choice, and if pressed, I might argue that it should never be the choice for any rational human being sitting in front of a computer, I can’t argue with the results.

Nick Bradbury:

Those of us who believe that desktop software is still relevant in a browser-based world should be up in arms about how hard it is to install software (on Windows, at least – it’s easier on the Mac). Multiple security warnings, required OS updates, and tech-heavy language make downloading and installing software too scary a prospect for non-technical users.

Desktop software on all platforms can and should be really easy to install. All it requires is for the user to click a link, click “Run” and the application should be up and running. In future they should be able to access it directly from their hard drive (start menu, Applications folder, command line, whatever is appropriate for the platform). Anything more complex is purely because the developer chose to make it more complex.

Jeff Atwood chimes in on the age old question of HTML vs Markdown/Textile/Custom Markup/etc. Unfortunately he rules out using a WYSIWYG editor with the one line statement:

Nothing’s decided at this point, but we definitely won’t be giving users one of those friendly-but-irritating HTML GUI browser layout controls. Well sure, you wouldn’t give them a friendly-but-irritating HTML GUI browser control, but why not give them a good one? These days it takes a fair bit of effort to find a HTML editor that doesn’t handle the very basics fairly well and Jeff doesn’t seem to be looking at anything more complex than bold, italic and some hyperlinks. I think a lot of people get stuck in a real geek ego thing or remember the really early days of HTML editors and don’t actually evaluate modern editors properly and it’s a real shame.