Tag: Software

    SuccessWhale.com Discontinued as of Today

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    As far as I know, SuccessWhale is not being actively used by anyone any more, so I have chosen not to renew the domain name successwhale.com when it expires today. Like most of my past web-based projects, it will continue to live on at an onlydreaming.net subdomain, in this case sw.onlydreaming.net, but will not be actively maintained there.  As well as its graphical web interface, SuccessWhale also has a back-end API that used to run on a SuccessWhale subdomain. This has now moved to https://successwhale-api.herokuapp.com/. The OnoSendai Android client already uses this address for the API as of update 479, so you may need to update.

    Thank you to all the SuccessWhale users over the years!

    Automating the Roast Dinner Timing Chart

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Against all my expectations, the most popular page on this website (at least, the most visited) turns out to be “The Great Roast Dinner Timing Chart”, which was my attempt to help newbies at the revered British art of the Roast Dinner get their timings right. I first posted it over eight years ago—in the intervening time I have cooked a lot of roasts and tweaked my timings a bit, so it was in need of an update.

    I’ve also cooked roast dinners to serve at all sorts of different times, with variations on the ingredients, so I thought the old list to cook certain things for a fixed 7pm dishing-up time could use some improvements too. To that end, I’ve converted it from a static list to an automatically generated one that users can play with. Visitors to the page can now choose their meat and its weight, the accompaniments and the serving time, and the page will do some JavaScript magic to generate a chart just for them.

    If you’re interested, you can check out the source code on GitHub. It’s not much and not very complicated, but free for anyone to use and modify.

    For anyone who prefers the original non-automated version of the Roast Dinner Timing Chart, or anyone without JavaScript capability, you can still get to the old version here.

    Hopefully it will help someone on the way to cooking their best roast dinner yet!

    A Sea Battle Update?!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    “Sea Battle” was a casual 2D real-time strategy game that I put together in a few days back in 2010, and documented in a series of blog posts at the time. It’s lain dormant ever since, but I picked it up again today while bored and made a couple of tweaks.

    Six years on, it’s obvious how much my coding style has changed—not only is the formatting dubious and commenting sparse, there’s also a lot of inefficient loops and abuse of global variables. I may change all that in a big refactor at a later date, but for now all I’ve done is a few minimal changes on top of the existing code.

    If you played Sea Battle ages ago and fancy trying it again, here’s what to expect:

    Annotated screenshot showing what's new

    1) Islands! You now get some randomly-generated islands to break up the wide expanse of blue sea. They’ll be different each time you run the game. Collision detection is based on the old code for detecting collisions with other ships, which is not great, but your ships shouldn’t get stuck behind islands too much. Islands only affect movement, not the firing arcs of weapons.

    2) Death list! I originally wanted to give ships randomly-generated names in this update, so you could see something like “Bismarck sank HMS Hood”. However, I couldn’t find a nice way to display them on the play field without adding loads of clutter—maybe one to save for the full-screen 3D version 2. 🙂 The implemented list instead shows which equipment the ships had, e.g. “1.2.3.4” = 1st hull, 2nd weapon, 3rd engine, 4th radar, to give you an idea what your enemy’s current tech level is and what’s working well against what.

    3) Equipment changes! I’ve simplified some of the abbreviations for different equipment types so they’re less confusing. Submarine types (SSK and SSN hulls) have been dropped, as it never really made sense to have submarines with 15-inch cannons anyway.

    HMS M1

    HMS M1, a submarine with a 12-inch cannon. It could only fire one shot before being reloaded, which required it to stay surfaced. Needless to say, it did not see operational service. (Image: Wikimedia)

    4) Removed dodgy monotype fonts! Not sure what I was thinking with these really. All fonts have been removed from the source package, the whole UI now just uses your system sans-serif font.

    5) Build time rebalancing! Build times used to be dependent on hull size alone. This made it (spoilers!) preferable to research only weapons and radar, and flood the field with quick-to-build ships that did high damage and outranged the enemy so they could get a couple of shots off before dying. (The AI prefers this approach on higher levels too.) Now, although hull still dominates, the other equipment affects the build time too. For example, Hull 1 Weapon 10 Engine 1 Radar 10 used to take 4 seconds to build, it now takes 13.

    6) An extra bug fix—playing a new game after a win or loss now resets the world properly.

    If you fancy a go, head to the game’s page where you’ll find instructions and download links. As always, the source is on Github.

    Have fun!

    Exploiting Conde Nast Magazine Subscriptions (for fun and profit)

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    I have a pile of unopened subscription copies of Wired UK piling up in the hallway, so this evening I decided to try cancelling my subscription. It looks like you can only do that by email or over the phone, but for other subscription changes, such as change of address, the Condé Nast parent company offer a very helpful website. Rather too helpful.

    The login page usefully notes that “you can find your customer number on the wrapper your magazine comes in.” And indeed it does — strip the letters off the beginning of that long number (as it helpfully doesn’t tell you to) and that’s the customer number.

    The signup form asks for the customer number “(if known)”, leading me to suspect that even that may not be necessary, and all you actually need to know to manage someone’s magazine subscription is their name and address.

    I tested this with my own details. Signing up sent me an email in which high-quality HTML character code skills are demonstrated.

    After fixing the URL and pasting it into a browser, then logging in with my new details, I was given full control of my subscription account. This allows me to see my subscriptions, and to change the address to which they are sent.

    So there you have it — non-intrusively viewing the outside of any Condé Nast magazine subscription packet (possibly UK-only) gives you the ability to view all the recipient’s subscriptions, and redirect them to the address of your choice!

    Migrating to Octopress 3

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Those of you who follow me on Twitter may have seen me dither about whether to re-style my website after the very appealing (to me) Tufte CSS. The sidenotes with their wide bar didn’t work particularly well with my blog format, but I’ve taken on some of the major style elements, and unless you’re reading this via RSS, you can see the results in front of you right now.

    In doing so, I decided to update the old Octopress code on which many of my websites are based. This is a long, complicated process of “merge hell” where I try to keep my own customisations to core files, theme mods, new themes, and odd plugins, while making sure nothing conflicts with the changes that have taken place within Octopress itself. With eight different Octopress sites, each with their own oddities, this was a daunting task.

    While looking for the latest minor version of Octopress 2, I discovered that Octopress 3 was released months ago… and it changes everything.

    All the problems I’ve had with Octopress over the years—updating and merging using git, managing multiple sites as branches, pulling in themes as submodules—I’d always put down to me just “not getting it”. Lots of people use this, so my problems are due to my inadequacies as a programmer, surely?

    But no, all along the developer has had the exact same problems with it. Octopress 3 reworks the whole thing, to do less rather than more, and it makes so much more sense. It’s now a gem that helps you set up a Jekyll site in a certain way, with some extra tools to help manage posts and deploy the site. Your source is no longer mashed together with Octopress’ source in the same repository, and it’s sufficiently out of the way that Jekyll’s “collections” now work properly.

    I’ve had to faff with a few links here and there to manage the eight different sites as collections under the same site (so apologies if you find any dead links), but the whole thing should be a lot more manageable!

    Preparing to Leave Heroku

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    An email today announced a beta test of some new features that Heroku are “excited” to introduce. New service levels are available that include a “hobby” tier that does… exactly what the old “free” tier used to do. For $7 per month per app!

    The free tier has now been downgraded so that it must “sleep” — i.e. be unavailable — for at least six hours a day.

    As a long-term abuser of Heroku’s free tier, I’ve enjoyed continuous uptime for all my sites courtesy of Heroku. A lot of sites.

    Heroku Apps

    All of which I now have to slowly migrate off Heroku as freeloaders like me are no longer welcome!

    The sites that are static HTML (including the Octopress sites) and PHP have in the main already been migrated back to my own web server over the last few hours, and I’ll continue to monitor usage statistics over the next few days to ensure it can cope with the extra load.

    Some sites using Ruby, and others that depend on HTTPS will be a little more difficult to move. Certain sites such as the SuccessWhale API that require high bandwidth and good uptime may stay on Heroku and move up to a paid tier if required.

    Hopefully none of this should impact users of the sites, but please let me know if you find a site or application is inaccessible or suffering from poor performance.

    "Archive by Year" Aside for Octopress

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    (Note: This code is designed for Octopress 2. My website now uses Octopress 3— the Jekyll plugin works just the same, but Octopress 3 sites can use the jekyll-archives gem to generate proper archive-by-year pages so should not need the bookmark ‘hack’ shown in the first code block.)

    One thing that’s annoyed me since migrating my website from WordPress to Octopress years ago has been the lack of an “archive by year” widget for the sidebar. The WordPress widget that fulfills this function lists each month and year, with the number of posts in that month, and each one is a link to a page that shows all the posts from that month.

    As you may notice on the left-hand side of each page, I decided to recreate something similar in Octopress.

    There are a couple of differences between the WordPress implementation and my Octopress implementation:

    1. Octopress doesn’t generate pages that show all posts from a particular month (or year). It does generate an “archive” page with links to all posts in order, which is what I’ve used as a destination for each link.
    2. Partly as a result of this (and partly because I’ve been blogging far too long), I decided to stick with one link per year rather than one link per month.

    My first modification was to the “archives” page. To this I simply added a named a tag to each year title (see line 12 below). This allows each year title to be used as a bookmark and linked to appropriately.

    source/blog/archives/index.html

    ---
    layout: page
    title: Blog Archive
    footer: false
    ---
    
    <div id="blog-archives">
    {% for post in site.posts reverse %}
    {% capture this_year %}{{ post.date | date: "%Y" }}{% endcapture %}
    {% unless year == this_year %}
      {% assign year = this_year %}
      <h2><a name="{{ year }}"></a>{{ year }}</h2>
    {% endunless %}
    <article>
      {% include archive_post.html %}
    </article>
    {% endfor %}
    </div>
    

    The code that generates the widget (or “aside”, in Octopress parlance) can’t be written in a single .html file using Liquid tags as it is too complex. Thus I implemented it by defining a new Liquid tag called archive, as follows.

    plugins/archive_tag.rb

    module Jekyll
      class ArchiveTag < Liquid::Tag
        def render(context)
          html = ""
          yearData = Hash.new
    
          # Get range of years for which there are posts
          posts = context.registers[:site].posts
          firstYear = posts[0].date.year
          lastYear = posts[posts.size-1].date.year
    
          # Build up a map of {year => number of posts that year}
          for year in firstYear..lastYear
            yearData[year] = posts.select{ |post| post.date.year == year }.size
          end
    
          # Build the html items
          yearData.sort.reverse_each { |year, numPosts|
            if numPosts > 0
              html << "<li class='post'><a href='/blog/archives##{year}'>#{year} (#{numPosts})</a></li>"
            end
          }
    
          # Write out the html
          html
        end
      end
    end
    
    Liquid::Template.register_tag('archive', Jekyll::ArchiveTag)
    

    The final piece of the puzzle is to create an aside to display the new tag, which is done simply as follows:

    source/_includes/asides/archive.html

    <section>
      <h1>Archive</h1>
      <ul id="archive">
        {% archive %}
      </ul>
    </section>
    

    Adding asides/archive.html to the default_asides section in Octopress’ _config.yml adds the new aside to each page.

    The end result is just like the one you can see in the sidebar of every page on this blog: a list of each year for which there are posts, in descending order, suffixed by the number of posts made that year. Each item in the list is a link to the main “archive” page, jumping straight to the bookmark for that year.

    This code is in the public domain so feel free to use it on your own blog and modify it however you like!

    The End of the Road for SuccessWhale’s Facebook Support?

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    My SuccessWhale application has long supported both Twitter and Facebook social networks, despite both networks’ relatively developer-hostile stances. The worst offender by far was Twitter, with it’s 100,000 user limit that has deliberately crippled many third-party clients in order to drive users to the official website and app, which make money for Twitter through adverts. While I was never under any delusion that SuccessWhale would be popular enough to reach 100,000 users, it’s not a nice thing to have hanging over your head as a developer.

    Facebook’s permissions policy, as I have ranted about before, also makes it difficult for third-party clients to deliver a useful service for their users. With the new requirement that apps migrate to API v2, they are adding the extra hassle of requiring all apps be reviewed by Facebook staff. This isn’t a problem itself — SuccessWhale has been through the somewhat scary process of manual review before when it was added to the Firefox Marketplace.

    But Facebook has now snuck something extra into the notes for some of its permissions, each of which must now be manually approved as part of the review process. Into pretty much all the permissions that are fundamental for SuccessWhale, such as read_stream:

    Facebook dialog for read_stream permission

    Yep, this permission will be denied, as a matter of policy, to apps running on Android, iOS, web, desktop, and more.

    So predictably, SuccessWhale failed its manual review and has been denied approval to use Facebook API v2.0 or above. As far as I can tell at this point, that means on May 1st all Facebook features of SuccessWhale will cease to function. Facebook, ever the proponent of the walled garden path down which Twitter has ventured as well, has struck another blow for increasing their profits and user lock-in at the expense of the open web that SuccessWhale depends on.

    It’s a sad time for the web; the “web 2.0” of mashups and free access to data is slipping away with it. And though Facebook’s change does not kill off SuccessWhale and its kin outright, the future does not look rosy for us developers that believe users should be free to access a service in a way they prefer.

    Fun with Playbulb

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Playbulbs are colour LED lights sold by a company called Mipow. They come with an iOS and Android app that can set their colour and various patterns via Bluetooth. There’s no security on them whatsoever, so any nearby device can connect and change their colour. That seems pretty bad — especially when you consider that as well as the small “candle” style lights we have, they also sell room lighting versions that play music and can probably flash fast enough to trigger photosensitive epilepsy. Controlled by your neighbours!

    Playbulb Candle

    Despite the security problem, this does have one advantage: it’s easy to get any other device controlling the Playbulb, not just a phone with their official app. Anything with a Bluetooth 4.0 Low Energy transceiver can easily control the Playbulb using tools like those provided by BlueZ under Linux, and the protocol is somewhat understood. This means it’s pretty easy to control a Playbulb programatically using the language of your choice.

    Here’s a demonstration I knocked up this morning: mailcheck. This python script checks an IMAP mailbox at a defined interval, and will set the Playbulb colour to red if there are no unread messages, or green (with a brief flash) when you have unread mail. It was inspired by similar “ambient electronic devices” such as Nabaztag. Here it is in action:

    It’s BSD-licenced open source, so if you have a Playbulb you want to have some fun with, please take my code and use it for your own ends!

    All-Terrain Raspberry Pi!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Another year, another childrens’ toy with a Raspberry Pi needlessly attached to it.

    Over the past few weeks, I’ve been taking one of my son’s old broken RC toys and turning it into something a bit more fun — by strapping a computer to it, naturally.

    The result is the “All-Terrain Pi”, a robot which can be controlled by smartphone as if it were a racing game, or by using the kid-friendly Scratch programming language.

    Here’s a video of the smartphone interface. It all runs in the web browser, with no need to install an app on the phone. Full-screen (ish) video streams from the robot’s on-board camera, while speed and turning are controlled using touch and tilt controls implemented in Javascript.

    Programming in Scratch is possible too, recreating the 80s/90s Logo “Turtle” experience for a new generation. As with the smartphone interface there’s a Python program behind the scenes controlling the motor driver board, but this time it receives commands via Scratch’s “Remote Sensors Protocol”.

    It didn’t take long for my son to get into controlling the robot, both with the game-like smartphone interface and using Scratch, which he has some experience with from school. (They start programming young now!) We took it to last weekend’s Constructorium hackerspace event at the library, where it was a big hit — by the end of the afternoon, he was teaching the grown-ups!

    Programming the All-Terrain Pi in Scratch

    “Proud” is an understatement.

    I’ve finished all the things I set out to achieve with this robot, in a total of only 20 hours or so. Thanks to a pre-made motor driver board and a Raspberry Pi camera fork of mjpg-streamer, some of the hardest bits of the project turned out to be very easy, so I’m very grateful to everyone whose work I’ve built upon to create this robot.

    I’m hoping we might be allowed to take the robot into school and maybe hold a competition for the kids to write a program to steer it around an obstacle course; or something similar — to make programming more exciting by taking it off the computer screen and into the real world. If the teachers don’t let us do that, we might hook it up to the internet and have it controlled using redstone circuits on my son’s Minecraft server.

    You can find a step-by-step guide to how I built the robot on the All-Terrain Pi page and all the code is open source!

    Adventures in Emoji

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Yesterday, a friend of mine started me on a quest that was to be filled with despair. It started innocently enough.

    I gleefully replied with my 140 character attempt at making that come to life (each Emoji counting, as I would later discover, as two normal characters).

    Well, that didn’t look like a bad start. There were some alignment issues there, probably because Twitter uses a proportional font. Nothing that a couple of <pre> tags couldn’t solve!

    Oh, how wrong I was.

    Twenty-four hours later, this is what I have to show for my efforts:

    Well, it’s a whole screen of Rogue-like, which is not bad. But despite wrapping the whole thing up in <pre> tags, there are still alignment issues.

    Lesson 1. Not all Emoji are a fixed width.

    Lesson 2. No Emoji are the same width as a half-width or full-width Unicode space.

    This will become important.

    You may also notice that the picture above isn’t a nice <pre> block full of text that you can copy and paste. That’s because, after hours of tweaking to get something looking vaguely presentable, I decided to see what it looked like in a different browser.

    And even in the same browser, with a different monospace font:

    Lesson 3. The width of an Emoji — and even one of the Unicode spaces — varies from font to font.

    Before I even got to that point, though, I was nearly thwarted by an even more frustrating issue — actually laying out the Emoji in a text editor.

    I assumed that in the world of monospace text that editors inhabit, these problems of layout would be avoidable. Any modern text editor should allow me to edit a bunch of Unicode characters in a regular grid, right?

    Of course not.

    My first attempt was using gedit, my GUI editor of choice. It happily allowed me to mix standard ASCII and Unicode characters. When I inserted a space between ASCII characters, it was about 20px wide — so far, so good. But when I inserted a space, even a Unicode full-width space, between two Emoji, the result was only 10px wide. The browser renders the spaces correctly, so to look right in the browser, all spaces had to be half as wide in gedit — useless for drawing a dungeon layout.

    I resorted to vi, my console editor of choice. My console font happily supports Unicode, so this should be no problem!

    Of course not. For a start, keypresses in vi insert one byte at a time, meaning that every other keypress misaligns every subsequent two-byte Unicode character on that line. And then there’s the quite bizarre way in which it decides to write characters on top of each other.

    My third and almost bearable choice was an odd one. I figured that if I wanted the same look in my editor as in the browser, I should use an editor that runs in the browser. I chose the Chrome extension Caret.

    At last I had something almost usable, although the misalignment of characters rears its ugly head here too. There’s the infuriating bug that this only applies to characters on the screen, not the cursor position. 70 characters into a line of Emoji, the cursor position can show up almost two characters away from the text it actually sits at.

    Lesson 4. There’s not a single program in the world that renders Emoji the same as any other.

    Last but not least, there’s the matter of Emoji fonts.

    On my Linux machine, my browser and my text editor at least use the same set of monochrome Emoji symbols. But view the same page on an iOS, Android or Windows Phone device, and you’ll discover they have their own platform-specific Emoji fonts which are specifically designed to look great while ruining your attempt at cross-platform compatability. Here’s what our Rogue-like looks like on Android, showing off the inevitable inconsistent widths:

    If you’d like to post your hard work to social media sites, you may also discover that Twitter has its own set of unpredictably-sized Emoji. Facebook will at least use your system font when you post Emoji, although trying to edit a post with Emoji quickly results in a field of “your encoding is broken” rectangles.

    Lesson 5. Despite Emoji having existed for over a decade, and having been incorporated into Unicode for half that time, Unicode fonts and particularly Emoji in them are a complete mess of incompatible typesetting and platform-specific weirdness. They are not yet suitable for use in layouts — and thus, sadly, for making Roguelike games.

    For the curious, here’s how my Emoji Rogue-like would render in your browser. If you use the Cousine font in Chrome on Linux, this might look alright! If you’re using anything else, this is probably a horrible mess.

                                                                                        
        🔳🔳🔳🔳🔳🔳🔳🔳🔳                                                              
        🔳🐍             🔳                        🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳      
        🔳      🐂       🔳                        🔳        🍖                  🔳      
        🔳               🔳                        🔳          🍖                🔳      
        🔳🔳🔳🔳🔳🔳🔳🚪🔳                        🔳                            🔳      
                     🔳  🔳                        🔳🔳🔳🔳🔳🔳🔳🔳🚪🔳🔳🔳🔳🚪🔳     
                     🔳  🔳                                       🔳  🔳    🔳  🔳      
      🔳🔳🔳🔳🔳🔳🔳🔳🚪🔳🔳🔳                                  🔳  🔳     🔳  🔳     
      🔳        🐀           🔳                                  🔳  🔳   🔳🔳🚪🔳🔳🔳  
      🔳  🔳                 🔳                   🔳🔳🔳🔳🔳🔳🔳🔳  🔳   🔳     🐉  🔳  
      🔳  🔳          🐀     🔳🔳🔳🔳🔳           🔳                 🔳  🔳  💍     🔳  
      🔳  🔳                 🚪      🔳           🔳  🔳🔳🔳🔳🔳🔳   🔳  🔳🔳🔳🔳🔳🔳    
      🔳  🔳  🎫             🔳🔳🔳  🔳           🔳  🔳         🔳  🔳                  
      🔳🔪🔳                 🔳  🔳  🔳           🔳  🔳         🔳  🔳                  
      🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳  🔳  🔳           🔳  🔳         🔳  🔳                  
              🔳         🔳      🔳  🔳       🔳🔳🔳🚪🔳🔳🔳🔳🔳🔳🚪🔳🔳🔳              
              🔳  🐍     🔳🔳🔳🔳🔳  🔳🔳🔳🔳🔳          🐍              🔳              
              🔳    🐍   🚪                   🚪      🐍  🐍🐍💥🚹        🔳              
              🔳         🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳        🐍        🍖      🔳              
              🔳🍗       🔳                   🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳              
              🔳🔳🔳🔳🔳🔳                                                              
                                                                                        
    Level:1     Hits:14(14)   Str:15(15)   Gold:34    Armor:1   Exp:20/23
    

    The limited set of Emoji currently available also causes a number of other issues with creating a Rogue-like using the characters. For example, the character set currently does not contain glyphs for:

    • Stairs
    • Treasure chests
    • Corridors
    • Kobolds
    • The Amulet of Yendor

    I’m sure the Unicode committee will be working on these soon.

    State of the Whale Address

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    It’s no secret that the current state of my SuccessWhale social network client is not a good one. It currently exists in three forms:

    • The main server runs SuccessWhale version 2.0.3. It’s not been updated in nearly a year, and the only changes within the last three years have been playing catch-up with the changing Twitter and Facebook APIs. It probably has some broken features by now, because I don’t regularly test it out.
    • The test server runs SuccessWhale version 2.1.2 with debug flags enabled. The 2.1 branch includes things like mixed feeds and LinkedIn support, and is “beta-ish”. Some people use it anyway. LinkedIn support is broken and will never be fixed.
    • The dev server runs SuccessWhale version 3.0.0-dev, a complete rewrite of the whole thing that has stalled in a half-finished state. It’s just about usable provided you’re willing to drop back to the test server to fiddle with any settings (they use the same database). It’s buggy, and as far as I know used only by me.

    SuccessWhale 3 interface

    SuccessWhale v3.0 web interface

    Very occasionally, I get the motivation to do something about SuccessWhale. It feels bad to leave it in its current “limbo” state where there isn’t really a version that works and is properly maintained. I use SuccessWhale every day, so at least there’s the dogfooding aspect, but “it works well enough for me” is far from “it’s something other people would want to use”. And my friend Fae produces the excellent OnoSendai Android client that uses SuccessWhale, so I have some sort of responsibility to him to keep SuccessWhale going.

    But there’s a hell of a lot of reasons why I would rather not.

    • Free time is nice. I started SuccessWhale five years ago, when I still had the energy to keep big projects going. Now, with less free time in the evenings and more responsibilities in my day job, I’m much more keen on grabbing a few minutes of that blissful feeling that comes from having nothing to do.
    • We created a monster. SuccessWhale (or FailWhale as it was then called) was first and foremost a simple Twitter client. I explicitly declared that it would never be a client for other social networks such as Facebook. Nowadays, SuccessWhale has its own API that wraps both Twitter and Facebook, along with several front-ends.
    • Rewrites are no fun. Version 2.0 was badly coded and had to go. Version 3 is nice and designed properly from the start! But it requires hundreds of hours of work just to let it do all the things that version 2 could already do.
    • The APIs are crap. In fairness to Twitter, its API is well-documented and makes a lot of sense. But, like all APIs it is regularly updated, meaning that all application developers need to work just to keep up — we put hours in not to add new features, but just to make sure the existing stuff doesn’t break.
      Facebook’s API is much the same, except that it makes much less sense and the documentation is largely non-existent. It’s quite telling that I asked a simple question on StackOverflow, and a Facebook dev replied with “here’s how to do it. I guess I’d better add that to the docs, huh?”
    • The services are hostile. Twitter, once the darling of those that believed in a strong 3rd-party client ecosystem, are now if their friends have configured their privacy settings badly.
    • The services are crap. Twitter is the playground of celebrities, companies seeking “engagement” and people who want to have a pleas to return to more honest times fall on deaf ears. But I don’t want to use them, and that makes developing a client for them a distinctly unfulfilling experience.

    For now, SuccessWhale stays alive. Twitter and Facebook are what I’m stuck with as the only sensible way of communicating with many of my friends and family, and SuccessWhale helps me avoid the worst features of their interfaces — their cryptically-curated feeds, in-line adverts and one-feed-at-a-time pages. That, plus a vague sense of responsibility to my users, are what keeps it around.

    When the day comes that I can jetission Twitter and Facebook from my life without missing them, it will be SuccessWhale whose loss I mourn. Like many projects before it, its user count will fall to zero and it will slowly start to fade from the internet.

    One day, I’ll be sad that I made a thing that is no more. But right now, all I feel for the thing is the frustration that developing it is fighting a losing battle that has no end in sight.

    Raspberry Jammin’

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Last Saturday was the Linux User & Developer Raspberry Jam event at Poole RNLI college. I took the tank, of course, and Joseph too — worrying all the while that he’d be the youngest kid there by about ten years, and he’d get bored within half an hour.

    How wrong I was.

    We eventually escaped almost an hour after the scheduled end of the event, once Joseph and the other kids — many his age — had had their fill of Minecraft and the Raspberry Tank.

    Along the way we’d met the awesome people from PiBorg with their much more impressive RPi tank, along with robot arm-wielding BigTraks and 3D LED matrices. We’d done a show-and-tell session, drunk a lot of coffee, and most importantly been part of a room of 20+ kids all learning to code for the first time using Python and Minecraft.

    It was really an amazing thing to see and be part of, and my heartfelt thanks go out to the organisers from Linux User for hosting a fantastic day!

    Here’s the kids playing with our tank:

    NaNoGenMo: A 50,000 Word Target I can Meet

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    One of the ways in which a number of my friends spend November is participating in National Novel Writing Month, or “NaNoWriMo”. This is its 15th year, in which some 300,000 amateur novelists signed up to write their hearts out over the course of 30 days.

    It’s ten years since I first came across the idea, and in all ten of those years I have professed myself too busy to dedicate that much time to churning out my sub-standard fiction.

    This year, though, I discovered a similar project I couldn’t help but have a go at—NaNoGenMo, National Novel Generation Month. The idea is simple—instead of spending November writing a novel, spend November writing a script that can write novels for you.

    A lot of NaNoWriMo novels are fanfiction of highly variable quality, so in homage to that, my NaNoGenMo script uses exactly that as its source material: specifically, a user-selected category or search on FanFiction.net. It will scrape the stories it finds for sentences, store them all locally, then set to work mashing them together in various gramatically-reasonable ways until the 50,000-word goal has been reached.

    Thumbnail of example NaNoGenMo output

    During the course of writing the script I tested it mostly with Doctor Who fanfiction, some of which is not particularly bad. But then I discovered that FanFiction.net has categories for cross-overs, where authors borrow characters from two of their favourite ‘universes’. These are generally, shall we say, less well written.

    So, if you’d like a glimpse into a world where Bayesian poisoning spammers hawk not Viagra but My Little Pony / Sonic the Hedgehog fanfiction written by 12-year-olds, look no further than the example output that my NaNoGenMo script generates.

    If you’re up for some more bizarre fiction written by haiku-spouting drunken Markov chains, check out the list of NaNoGenMo competitors, quite a few of whom seem to have taken my code to new and stranger heights!

    Whatever Happened to the Generic PC?

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    It doesn’t seem that long ago, perhaps only five or ten years, that you could buy or build your own computer and do whatever you liked with it. If you bought it, it would probably come with an operating system, but if you didn’t like it you could download another one and use that instead.

    Nowadays… not so much.

    My main computer is a Late 2007, 13-inch Macbook. You can install another operating system on it—so long as you keep the original OS to apply firmware updates. And you repartition the hard disk using Apple’s tools. And you install a custom boot loader. Oh, and even the custom boot loader can’t boot from USB.

    My other computer is a Samsung Series 3 Chromebook. You can install another operating system on it—in a chroot, because you have to use Google’s kernel to get proper hardware support. You can try your luck with a proper dedicated install of another OS, but your hardware will be badly supported. Your choice of other OS is a two-year-old version of Ubuntu, or a current version of Arch Linux for which no-one knows how to build Firefox. It boots from USB when it feels like it. The rest of the time, it beeps and restarts with no error messages.

    Linux on a Chromebook (image from muycomputer.com)

    And these days our phones are computers too. The more capable they become, the more like a real computer, the more we resent their limitations.

    I have a Droid Razr Maxx. You can install another operating system on it—so long as it’s pretty similar to the one it started with. And it’s compatible with the built-in kernel, which you can’t replace because it has to be signed. So you have to kexec your own kernel on top.

    All I really want from a computer is a bunch of POSIX utilities, a tiling window manager, a copy of Firefox and a package manager, preferably APT-based. Ten years ago that didn’t seem too tall an order. But with the computers we have today, I can and have struggled for days to achieve that—before giving up.

    Whatever happened to the generic PCs of years gone by? Computers were always supposed to get smaller and cheaper, but why did they also get less useful; less free?

    The End of Westminster Hubble

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Three years ago, after a two-month secret development period working with my old school friend Chris, we announced Westminster Hubble.

    The name was a pun on the “Westminster Bubble” in which MPs are sometimes unkindly said to live — implying a lack of awareness of the rest of the country — and “Hubble” alluding to the Hubble Space Telescope, which has allowed us to see distant objects in more detail than ever before.

    Westminster Hubble was a website that aimed to bring MPs and their constituents closer online by providing a single location to find contact details for an MP, in real life and on social networks. It also provided customised feeds of MPs’ activity from a variety of sources, from YouTube videos to speeches made in the House of Commons. At its core was a RSS-parsing engine powered by SimplePie that pulled in content from all the sources it knew about as quickly as it could, stashing the results in one giant database table. The contents of this would then be served to users as HTML, or as an RSS “meta” feed to users who preferred to get the data that way.

    Westminster Hubble MP Feed

    Westminster Hubble’s main “feed” page for an MP, in this case tech-savvy MP Tom Watson.

    Amongst my favourite features were the Google Maps / They Work For You mashup that allowed users to find their local MP in an intuitive way, and the “badges” awarded to MPs for particular dedication (or just a lot of tweeting).

    Find Your MP map

    Westminster Hubble’s “find your MP” map

    We launched just after similar service Tweetminster really took off, and although we never achieved their relevance or their Wired UK features I still feel that we were offering separate complimentary services — Tweetminster curated tweets around particular subjects for use by those in and around Westminster, while we pulled together tweets and other items from particular people inside Westminster and provided them to those on the outside.

    In many ways, Tweetminster provided a destination, somewhere people would go to get information, whilst Westminster Hubble was designed to fade into the background and become part of the plumbing of the internet — RSS feeds went in, RSS feeds came out in a more structured form as chosen by the users. In many ways, then, it shouldn’t be surprising that this week I am closing Westminster Hubble due to a lack of use. Without the user appeal of being a “destination”, the users didn’t come — didn’t spread the word.

    Westminster Hubble "badges"

    Westminster Hubble “badges”

    In recent months, the web itself seems to have turned a corner from the heady days of the early 2000s; the Web we lost. Twitter’s discontinued API v1 takes with it the availability of RSS feeds for a user — parsing Twitter feeds now requires a “proper” Twitter client that must authenticate and use the JSON API. Facebook pages no longer advertise their RSS feeds; third-party tools must often be relied upon instead.

    It seems the days of mashups, of open services that exposed their data in freely-usable machine-readable formats, are fading. Facebook, and to a lesser extent Twitter, are realising that to maximise their profits, they need to keep users on their sites rather than accessing their data from elsewhere. They are becoming walled gardens in the tradition of AOL, a transition that is fundamentally bad for the free and open web that most of us enjoy today.

    If I were more of an activist, I would keep Westminster Hubble alive and fix its links to Twitter and Facebook precisely for the reason that this trend needs to be fought — that the British public should have the right to see what MPs post on “walled garden” websites without the members of the public themselves needing to enter that garden. But the fact of the matter is that Westminster Hubble has failed to become a popular service. In the past month there have been exactly six unique visitors, and that includes consumers of the RSS feeds.

    It is tempting to leave the service running somewhere in some capacity — its database currently contains nearly a million items posted by MPs over the course of 16 years. (Westminster Hubble has only been running for three years; it retrieves old posts from feeds when it can.) However, there seems little point in maintaining the domain name, the Twitter account and the Facebook page for a service that now sees so few users.

    For anyone wanting one last play with the site, on the understanding that many social network integration features no longer work, can do so on the Westminster Hubble temporary server. On request I am also happy to host the complete (~420MB) database dump, in case anyone wants a large data set of MP activity on which to run some analysis.

    To everyone else who has used Westminster Hubble over the years, thank you. I hope it proved useful, and I like to hope that maybe even one of you was inspired by it to support an open government, to campaign for it, or to follow in the footsteps of Chris and I and build your own tools to make it happen.

    After many MPs have held Hubble’s “badges” over the years, I’d like to award one special, final badge of honour. The Westminster Hubble award for Social Network Mastery could go to nobody else: ladies and gentlemen, Ed Balls.

    So long, and thanks for all the fish.

    The Last of Last.fm: Seven Years in Pretty Graphs

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    I started using coming to the conclusion that I should stop back in 2011. Although the social media narcissism of “everyone must know what I’m listening to!” is no longer appealing in these days of over-sharing, I kept my Last.fm account around for its free “recommendations” streaming services until deciding earlier this year that a Spotify subscription was a worthwhile investment.

    I was reluctant to delete my account, though, as seven years of listening to over 30,000 songs is a lot of data — so much that it feels wrong to click a single button and pretend it never happened.

    Luckily, I’m far from the first person to want to turn their years of recorded listening habits into some kind of accessible permanent record. The most famous such service, LastGraph shut down earlier this month — annoyingly on the very day that I intended to use it — but there are many other ways to get interesting data from a Last.fm history.

    Last.fm Playground

    Last.fm offers their own visualisation tools in their “Playground” site. Many are for subscribers only, but even free users get access to some interesting graphs.

    For example, the Gender Plot uses your history to guess your gender and age. As you can see below, Last.fm pegs me as 24 (I’ll take that as a compliment) and it’s pretty indecisive on my gender — a largely manly playlist conflicts with my fondness for Tokio Hotel, apparently only listened to by 18-year-old girls.

    Last.fm Gender Plot

    Last.fm Graph

    Last.fm Graph is a third-party Java app that takes your favourite artists and displays them as a network graph, showing the interlinking between them. The result is interactive and designed to be played with, which unfortunately makes for a pretty poor screenshot.

    According to my output, my main genres of metal and EBM don’t intersect anywhere — perhaps they would have if more industrial acts had made the “top 50 artists” cut-off that I used for the data set. My 2006-2007 J-Pop phase is sitting on its own separate from everything else (and deservedly so).

    Last.fm Graph

    Last.fm Extra Stats

    Last.fm Extra Stats (Windows only, .NET 2.0) generates much the same graphs that LastGraph did, more configurably but perhaps a little less pretty. Everyone’s favourite is the “Wave chart” view, showing trends in listening to your most popular bands over time.

    Here, the amount of music I listened to — or at least, the number of tracks I scrobbled to Last.fm — dominates the chart causing a very bumpy output, but it’s all there. The sheer volume of Kotoko and Scooter tracks I’ve listened to are now laid bare for the world to see and silently judge me on.

    Last.fm Graph

    LastHistory

    My favourite of the bunch has to be LastHistory (OSX only). It’s not the prettiest visualisation, but what it does do is not just plot your listening over time on a day-by-day basis, but minute-by-minute. The resulting visualisation displays information about your life, while others simply display your music.

    In this history I can see my varying sleep patterns as I changed from student to office worker to father. I can see the all-nighters I pulled and what music I chose to accompany me. The days when I listened to music only on my commute, and the rarer interludes where I managed a whole day of listening.

    Last.fm Graph

    Reminiscence rears its head in strange places, few stranger than a 30,000 point data set began one day with a 20-year-old thinking people on the internet would be interested in his music.

    Today I delete my Last.fm account, thankful for the opportunity to look back over seven years of my life summarised in scrobbles. I hope this page proves useful for anyone else in a similar situation, looking to extract pretty graphs — or even memories — from their Last.fm history.

    Announcing: "Can I Call It…?"

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    There are a whole host of decisions involved with starting a new software project. What’s my target audience? What language shall I write it in? Which libraries shall I use? And of course, “What shall I call it?”

    For anyone looking to give their new project a unique name, there’s an annoying process to go through of searching for each idea to see if something already exists by that name. Linux packages need to have unique names, as do SourceForge projects, Ruby Gems and projects on many other distribution systems.

    As of 4pm yesterday, there was no simple way of querying all these repositories and package management systems together, to see if your chosen name was already taken by someone else.

    So at 8pm I sat down to code. And by 11pm, there was a way to do exactly that.

    Meet CICI, or “Can I Call it…?”

    CICI is a simple website. You give it a name you would like to use for your project, it checks against a bunch of services, and tells you if your name is unique – i.e., you can call it that – or not.

    CICI Results Page

    Currently, CICI looks up information on packages and projects using Github, SourceForge, Ruby Gems, PyPI, Maven, Debian and Fedora, but it’s easy to add more. CICI itself is a simple Ruby script (full of ugly hacks, as is befitting for a program that I knocked together in a few hours), which you can download and contribute to on GitHub. It’s all BSD-licenced.

    Of course, you can play with CICI on the web right here:

    Can I Call It…?

    As we have also discovered, typing random words into the search box to see what it finds is surprisingly addictive… See what odd (or even useful) things you can find on CICI, and good luck with your new projects – whatever name you end up giving them!

    Fuck it, Let’s Remake TweetDeck. Only Better.

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    It’s no secret that, since the launch of version 2.0 back in July of 2011, my SuccessWhale social network client has stagnated somewhat. It had reached that point at which it did everything that I needed it to do, and so my enthusiasm for updating it kind of disappeared.

    SuccessWhale 2.0

    Well, no longer. Twitter discontinued TweetDeck, the only Android client that merged Twitter notifications and Facebook feeds without sucking. At the same time it discontinued TweetDeck’s desktop client, and removed Facebook support from the web-based client.

    That really sucks.

    And that’s where SuccessWhale comes in.

    I’m no longer content with the ways in which I interact with Twitter and Facebook, particularly on mobile devices, so we’re going to fix it.

    SuccessWhale began as a “my first PHP application” kind of affair, and right now it still is. The code behind it is an ugly mash of model, view and controller without a decent structure. SuccessWhale version 3 will be rebuilt from the ground up with proper design principles behind it.

    It begins with a proper API, which I’m coding up right now using the Sinatra framework in Ruby. Once complete, the web-based front end will be rewritten too, as a strict user of the API using client-side templating in JavaScript. It will be a responsive design, displaying the user’s preferred number of feed columns in landscape mode and reverting to a single swipe-able column in portrait mode for mobile phones.

    Even better, haku is making an Android client called OnoSendai which will feature the combined feed columns that are SuccessWhale’s major feature. We will bring TweetDeck’s feature set back to Android with a lot more besides, offering the users the ability to mix together the feeds in their social network client like never before.

    And to prevent our software going the way of TweetDeck – being bought up and eventually scrapped – SuccessWhale and OnoSendai are open source software. A version of SuccessWhale’s API, operating on the main database at sw.onlydreaming.net, will be open for anyone to use and build clients for. SuccessWhale is released under the BSD 2-clause licence and OnoSendai under the Apache 2.0 licence, meaning that even if we were to be bought out, anyone on the web could simply grab our source code and run their own SuccessWhale.

    We’re bringing TweetDeck’s features back to Android and to the web. We’re making SuccessWhale an application to be proud of. We’re free, we’re open, and we’re Twitter-proof.

    Alas, Poor TweetDeck

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    It should have been obvious when TweetDeck was acquired by Twitter back in 2011 that it wasn’t long for this world. Even more so when the only significant update in the intervening period was to remove a feature (handling tweets over 140 characters).

    Although Twitter started out by enthusiastically embracing 3rd-party app developers, its quest to find a way to monetise its service has led the company to grab more and more control over how its users interact with the platform. Users who use Twitter’s website and mobile apps can be served ads, or “promoted tweets”, much more easily than those using 3rd-party clients. The transition was an obvious one, but not a pleasant one – many developers turned on Twitter, accusing it of being actively hostile to developers.

    I would be hard pushed to disagree. Westminster Hubble relied on Twitter’s RSS feeds to let people follow their MPs more easily – a feature broken by Twitter’s API changes. SuccessWhale survives, but hardly with Twitter’s blessing – if it were to ever have 100,000 users, it would be banned.

    TweetDeck's Merged "Mentions" and "Notifications" Column

    TweetDeck’s Merged “Mentions” and “Notifications” Column

    And today we lose the TweetDeck app on desktop and mobile platforms.

    I am an avid user of TweetDeck for Android (actually, its fork “TweakDeck”, though they are very similar). This is for the simple reason that it is the only Android app that can combine “mentions” from multiple Twitter accounts and “notifications” from a Facebook account in a single column view. Surely this is a feature that plenty of people would like in an app. But check out the competition. This is a list of all the Android apps that are both Twitter and Facebook clients:

    • TweetDeck is dying – service outages are forecast before it is killed off completely in May.
    • TweakDeck is an old fork of TweakDeck, not under Twitter’s control – but the API changes that kill TweetDeck will take TweakDeck with them.
    • Seesmic offers combined Twitter and Facebook feeds in its paid version – I don’t object to paying £1.89 for an app, but Seesmic has been acquired by HootSuite and will be phased out.
    • HootSuite itself does support multiple Twitter and Facebook accounts, but its user interface offers no way to merge feeds together or even swipe between columns from different accounts.
    • Scope offers a merged mentions/notifications feed, but only supports one Twitter account, has performance issues (on my devices at least) and has odd defaults (all retweets are also posted to Facebook, Tumblr etc unless manually turned off every time).
    • UberSocial (formerly Twidroid) supports only one Twitter account, and adds Facebook as an afterthought with no merging of feeds.
    • Plume (formerly Touiteur) supports multiple Twitter and Facebook accounts, but only supports Facebook’s posts feed, not notifications.
    • StreamLife is intentionally low on functionality, and only shows “home” timelines, not mentions/notifications.

    The functionality that Twitter is removing by retiring TweetDeck is simply not found anywhere else in the Android ecosystem. Until some other application steps in to fill the gap, a function that I and many other users love is simply and infuriatingly impossible to achieve on Android.

    Just like with Facebook, it is the network effect that keeps me – and countless other developers – using Twitter despite its increasingly developer-hostile control over the ways in which we interact with it.

    One day, perhaps the “next big thing” in social networking will be a platform that starts open and stays open.

    Lament for Web 0.1

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    With every passing day, my Facebook feed is spending more and more time informing me that old school friends “like Amazon”. (No shit, really?) In the background, it’s fiddling our feeds, showing and hiding entries according to what it thinks is relevancy, and also what it thinks is profit for itself. Game spam is constant. On the other side of the fence, Twitter is trying to force out the third-party clients that made it great, so that it can monetise its users more easily.

    Facebook Pages You May Like

    Should we be surprised? Feel betrayed? Not at all. Facebook and Twitter are in it to make money, yet we use them for free. It’s pretty clear that if you aren’t paying for the product, you are the product. We should only expect free-to-use websites to change in favour of their profits, never in favour of us as users.

    But I’m growing tired of it. My use of these sites is intensely personal – they are my default, or only, way of contacting many of my friends – but yet this personal process is controlled by a company that is willing and able to affect the process to make money. If it’s more profitable to show me “Bob likes Product X” than to show me Bob’s deep and meaningful status update, you can bet I’ll be shown the “like”.

    I miss everyone being equal. I miss services that were honestly free. I miss being close to the infrastructure I use to communicate, rather than having it abstracted. I miss Web 1.0.

    Hell, I miss Web 0.1.

    irssi

    There was a time, not so very long ago, when IRC was our Twitter. It was just as full of funny links and pithy comments, but it was communication between friends, not 140 character witticisms broadcast into the ether in the constant, vain hope of affirmation delivered by the retweets of strangers.

    There was a time when blogs were our Facebook, our innermost thoughts put out there for our friends and no-one else; when our friends would think of something to say and say it, rather than simply dishing out an iota of affirmation with the “like” button.

    There was a time when mailing lists were our forums, just simple e-mails back and forth without the need for moderators, or advertising, or CAPTCHAs.

    There was a time when USENET was our Reddit, a place to while away hours without karma whores and downvotes.

    Those times are never coming back. No friends of mine are willing to leave Facebook and talk to each other on a mailing list. The monetising services of Web 2.0 are simply much better, easier to use, nicer to look at, more functional. But they’re lagging behind the tools and services of the old internet in other ways. Honesty – what you put into IRC is what you got out, no server inserted “promoted tweets” into your channel. Thoughtfulness – we had to say things to each other, no likes, no retweets, no upvotes.

    At this point it would be appropriate for me to announce some kind of online “back to the land” movement, ending with a rhetorical “who’s with me?”. But rhetorical it would be, because nobody’s with me. I am, at the age of 27, simply old and curmudgeonly before my time; sitting typing in monospaced text to an audience that already sold themselves to play FarmVille.

    The Need for Mobile General Computation (aka, why I’m stuck with Android)

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    My mobile phone contract has well and truly hit the “18-month itch” stage – although I still have six months until an upgrade is due, I can’t help but look at adverts and scan gadget blogs and think “ooh, I want one of those”.

    I could go for an iPhone, and have a vast library of apps to choose from – far more than Android has ever offered.  I could go for a Windows Phone device and enjoy a user interface that is genuinely refreshing compared to the rest of the mobile OS options.

    But much as it annoys me with its weird bugs, poor battery life, fragmentation, weird manufacturer-specific skins and inconsistent interface, there’s one important advantage to Android that sways my decision back to it every time I consider the alternatives. It is simply this:

    I want to be in charge of my device.

    The seeds of the war on general-purpose computation are already taking root in the mobile OS space. Phones and tablets are quickly gaining ground as the primary means of getting things done in our online worlds, and implicit in that is that users of these devices are putting the manufacturers and the mobile networks in charge of what they can and cannot do with them.

    I reject this trend. I want root.

    I want to be able to uninstall the apps HTC and Vodafone think I should use. I want to firewall apps off from “phoning home”. I want to back up a complete partition image of my phone. I want to run any script I can think of. I want to tunnel my network access over SSH.

    By and large, mobile software and hardware manufacturers are hostile to this kind of activity. It’s impossible on a Windows Phone device. iPhones can be jailbroken but OS updates – including important security updates – undo the jailbreaking until some enterprising hacker can find another exploit.  Of the current crowd of mobile operating systems, only Android, with its open-source releases of the core OS, allows said enterprising hackers to create their own distributions of the operating system and maintain “root” whilst applying Google’s own OS updates.

    So although I am bored of Android, though I crave a new and interesting user interface to play with, I crave freedom more. If I can’t make a device mine; if I can’t choose to be master of all that goes into it, out of it and through it, it’s not a general purpose computer – and I refuse to base a good proportion of my future computing needs on it.

    On Very Small PCs

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    With my recent acquisition of a Bluetooth keyboard added to the PowerSkin, my phone has completed its transition from thin, attractive polycarbonate slate to the monstrous assault on product design you see before you.

    Desire HD + PowerSkin + Bluetooth Keyboard

    Or so I would have said in the dim and technologically distant days of 2010.

    But really, I don’t have a giant ugly phone – because the other day, an incoming call interrupted my SSH session and I was briefly confused as to why someone was calling me on my computer.

    I don’t have a giant phone – I have a really tiny laptop, with a battery that lasts two days.

    Did the future happen while I wasn’t looking again?

    App Idea: CatchUp

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Here’s some initial design ideas for a location-aware chat app that, as far as I am aware, has significant new features over and above existing mobile chat apps (iMessage, WhatsApp, BBM etc.) and existing location-based functionality in apps (FourSquare, Facebook check-ins, Google Places).

    Background

    Pictochat

    The inspiration for this idea came, more or less, from the Nintendo DS “Pictochat”application.  PictoChat allows up to 16 users to link their DS consoles over a peer-to-peer WiFi connection, and share doodled messages with each other in real time. Between a couple of DS-using friends, PictoChat is an interesting gimmick, but I first encountered it coming into its own at an anime (Japanese animation) convention called MinamiCon. Here, the concentration of DS users was so high that multiple 16-person PictoChat rooms came into existence, full of people chatting away with other convention-goers.

    This was in 2005, before the now ever-present smartphone really came into its own. What about today? Achieving a critical density of DS users to make PictoChat useful is no longer an issue – a critical density of smartphone users exists at every event and every non-event in the Western world. What if we reimagined PictoChat for the smartphone?

    Concept

    There is one big change to the PictoChat concept that we need to make to have a viable idea – and one big addition.

    Attempting to write using DrawSomething

    • Text, not pictures. The DS’ stylus and resistive touchscreen were ideal for doodles, but not so much for text – though a keyboard was available. Modern smartphones have thumb-friendly capacitative screens, and anyone who’s tried to give textual clues in DrawSomething will tell you that writing text PictoChat-style is a non-starter. This new app needs to be text-based, with optional picture and video sharing, much like MMS.
    • Catching up. The idea of “catching up” provided the app’s working title, and forms a secondary mode for the app. As well as real-time chat between people in close proximity, the app also attempts to solve the problem of “how do I keep in touch with people I did [activity x] with?”. Say, for example, that you are at a concert. Over the course of the event the app detects 20 people in your vicinity. You could chat with them live (though hopefully you paid to watch the band not stare at your phone…), but the app remembers who was there so you can also chat to them afterwards.

    Technical Issues

    There are a number of technical issues that the app would have to address.

    • Privacy. It must be easy for users to indicate that they don’t want to be interrupted by messages, and that they don’t want people to detect your presence and “catch up” with you later.
    • Identification. Integration with Facebook would be desirable to allow users to find their friends on the service. However, the app is providing a semi-public mapping of people to locations, so CatchUp users should not be identifiable to people who are not their friends. Foursquare has struck a reasonable balance here.
    • Connection technology. PictoChat used device-to-device WiFi. This is not ideal for CatchUp as it would prevent users from using their WiFi for other things. A low-power Bluetooth connection is a possibility which would also enforce the “chats must be local” idea. However, if we are going to enable “catch up” chats later, we need a server-side chat backend anyway, so it may be best to route everything through the server and determine user proximity for local chat groups on the server.

    CatchUp Architecture

    CatchUp Architecture

    • Integration to other services. Integration with the Facebook, FourSquare or Google Places API could give users the ability to “check in” and use the chat facility together, increasing uptake. Integration with services like Last.fm could incorporate knowledge of event times and places, meaning that the “catch up” chats can have sensible names like “Justin Bieber Concert, Wembley Stadium, 1/1/2012” rather than “with 312 users at Wembley Stadium, 1/1/2012”.

    Last.fm's Events List

    Last.fm’s Events List

    • Blocking. It must be easy for users to block and report abusive users, prevent them from finding out where the reporter is in future, etc.

    Mockups

    I have produced a couple of user interface mockups for the potential design:

    CatchUp Main Menu

    CatchUp Main Menu

    The main menu of CatchUp presents a simple list of chat opportunities, in reverse chronological order.

    At the top is the “Chat now” area. Pressing there takes you to the live chat for your location, as determined and managed by the CatchUp server. The tile shows where CatchUp thinks you are, and how many people you will be placed in a chat room with.

    Below this is a list of all your “catch up” opportunities. If configured to do so, CatchUp monitors your location in the background. If you stay in a location with enough people for long enough (possibly without having to explicitly open a chat), a “catch up” for that event will be placed in the list. The user can press one of these to be taken to a chat room for everyone who was there. Users can remove the Catch Up from the app (and thus prevent being chatted with by other event attendees) with a swipe.

    Settings will have fine-grained privacy options, for example to prevent the user appearing in others’ Catch Ups without explicit permission, to mark certain locations that Catch Up will automatically deactivate itself in, and so on.

    CatchUp Chat Interface

    CatchUp Chat Interface

    Chatting in CatchUp is a simple affair. As locations may have many people chatting, iPhone-style bubbles are replaced with a more basic appearance – though images and videos can still be embedded.

    Potential Flaws

    No application is without its flaws. Here are some that CatchUp would have to address:

    • User Critical Mass. Any social app is only as good as the number of people using it, particularly if the main use case is live chatting. Facebook integration could help a lot here, as could venue sponsorship such as posters with instructions / QR codes to download the app.
    • Balancing default privacy options. Many (most?) users will never change their privacy options. The default must be restrictive enough that the app does not raise Facebook/Buzz-style security concerns, but permissive enough that Catch Ups are still useful.
    • Web interface? Can Catch Up do without a web interface and run mobile-only like Instagram? Or would a web-based interface be useful so that post-event Catch Ups can be done with a proper keyboard?
    • Permanence. Catch Up needs to strike a balance between permanence (everything is kept forever – but UI becomes more complex and permissions more fine-grained) and impermanence (Catch Ups expire and are deleted – but we may need to allow users to get their data out).

    Naming Ideas

    Aside from “CatchUp”, a number of other names have been suggested:

    • Ketchup (a pun on Catch Up)
    • ReCollect (based on the idea that you can “collect” people at events then chat to them later)
    • LiveChat

    Next Steps

    What’s next for CatchUp is largely down to you.

    I am a UX guy and a Java/Python/PHP developer with zero experience of mobile app development – I can do a mean usability study, but I can’t make this app myself in a sensible amount of time.

    If you want to help make this app, get in touch. I can’t do it without help.

    If you want this app to exist but can’t help, share this post! Eventually it’ll get to someone with the time, skill and inclination to help out.

    And if you have any comments whatsoever, keep on scrolling. I’d love to hear any thoughts or (constructive) criticisms you may have!

    Towards a Simpler Desktop

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    In one of my previous blog posts, “Designing for Granddad”, I examined some of the user interface features that cause my grandfather issues when using his computer, and left a few hanging questions as to how we software designers can make our apps less confusing to the novice computer user.

    As is my unfortunate habit, I spent some of today checking out how work had progressed on the GNOME-shell and Ubuntu Unity desktop environments.  (I enjoyed the eye candy for around three hours before reverting to the UI of least resistance.)  Various complexities in their interfaces irritate me and seem to have provoked the wrath of a community of largely experienced computer users.  This got me thinking about how I would go back the other way, and design a desktop environment for absolute novice computer users – one without many of the frustrations of modern software.

    Gnome-Shell Screenshot

    The Gnome-Shell Interface

    My ideas, roughly distilled into a sort of ‘design manifesto’, are:

    1. One activity at a time.  Here I actually agree with Gnome-shell and Unity’s focus on  full-screen applications, avoiding unrelated yet overlapping windows.

    2. Never hide the means to change activities.  Both Gnome-shell and Unity hide their application switcher during normal use, requiring at least a mouse movement or a click to get it back.

    3. Don’t change state with mouse position.  Novice computer users often have trouble controlling the mouse.  Unity’s auto-hiding dock and Gnome-shell’s “hot corner” could prove frustrating, particularly the latter which completely changes the display when hit.

    4. No system trays.  The distinction between the taskbar and system tray is not well-defined and can be confusing.  Gnome-shell is a particularly bad offender here, with not one but two tray-like areas.

    5. No notifications (unless they help).  Pop-ups confuse and scare novice users.  If at all possible, the app should use a sane default rather than asking a question, and do nothing rather than displaying information.  If a pop-up does appear, it should be helpful and clearly worded.

    6. Stateless apps and background services.  The user wants to get their e-mail. Reading e-mail is a legitimate activity, but leaving a mail client open so that they are notified of new mail is not.  Use background services so that it doesn’t matter which apps are running.

    7. Zero tolerance on UI clutter.  While UX people like me may sometimes deplore clutter and idolise minimalism on aesthetic grounds, for the novice user, every bit of clutter is something that they feel like they should know how to use.

    8. Explain things clearly.  Keep words to a minimum, but ensure that the user always feels confident that they know what clicking a given element will do.

    9. Undo everywhere.  Offer an “undo” option wherever possible.  If you’re dealing with small but important items (such as e-mail), consider offering a non-destructive way of getting e-mail out of the user’s face – “archive” instead of “delete”.

    10. Use icons and words together.  Novice computer users may be young or old, and users of any age may have poor vision or may not speak the language in which the interface was written.  These may result in users finding either icons or words easier to understand on a control.  Providing both, by using clear iconography and simple text together, helps to alleviate this problem.

    I’ve mocked up a couple of interfaces to show a desktop environment that adheres to these principles.  The first shows the “desktop”, taskbar and an example notification:

    Simple Desktop Environment - Taskbar & Notifications

    The second shows the mail app with example messages:

    Simple Desktop Environment - E-mail App

    Is there anything you particularly like or hate about the mockups or the design principles behind them?  Bear in mind that if you consider yourself tech-savvy or a software designer yourself, you’re probably not the target audience for this desktop environment – pretend to be your mother or grandfather for a minute and see how you feel about the suggestions I’ve made.

    I’m happy to go further with these designs if you think it’s useful, and of course your own ideas and suggestions are more than welcome.  The comments section is yours!

    For anyone wondering, the mockups in this post were generated with Mockingbird, an excellent UI mocking web-app.

    Designing for Granddad

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Slate’s recent article, “2011 Was a Terrible Year for Tech”, coins the term “mom-bomb” for the moment that technology journalists declare a gadget so easy-to-use that it is actually useful to people who aren’t technology journalists:

    He begins by praising the gadget’s intuitive interface and its easy setup process, but eventually he finds that mere description doesn’t adequately convey the product’s momentous simplicity. That’s when he drops the mom bomb: This thing is so easy that even my mom could use it.

    I’m blessed with parents that, by and large, ‘get’ technology.  Their VCR never flashed 12:00 (and now they have a DVD recorder); they both have Android phones that they can happily e-mail from.  My grandparents are a different story, of course.  Two of them have almost never used a computer, but my Granddad has a nice new shiny one and uses it regularly.  But as the article points out, what tech journalists and we tech-savvy users think is simple and ‘user-friendly’ often falls far short of the ‘mom (or granddad) test’.

    A few observations spring to mind:

    • Moving photos from a digital camera to a computer is one of the simplest tasks non-‘tech-savvy’ users often want to do.  But when you plug in a digital camera, Windows 7 helpfully pops up this dialog:

    Windows 7 Camera AutoPlay Dialog

    Do I want to “Import Pictures and Videos” using Windows, or using Windows Live Photo Gallery?  What’s the difference?  Do I want to “Copy pictures to [my] computer”?  Do I want to “Download images”? Where will the photos go?  Will they still be on the camera?  I just want to see my photos, so I click “Open device to view files”, but what the heck is “DCIM”?

    • I set Google as his browser homepage, and since then, he has been getting his news not from the BBC News bookmark I created, but using the ‘News’ link on Google’s own menu that appears at the top of its pages:

    Google Menu Bar

    …which is great, except that Google can change that menu at any time.  And of course they are doing exactly that:

    New-Look Google Menu

    To my granddad, and many other novice internet users, the distinction between bookmarks – which only change if you want them to – and web page navigation menus – which can change at the webmaster’s whim – is not necessarily clear.

    • Even simple mouse commands can be unclear and difficult.  In the example above, Google’s instruction to find the new menu is to ‘roll over’ the logo.  When the novice user figures out that means ‘hover the cursor over’, they’re greeted with a JavaScript popup which will disappear again if their cursor accidentally wanders too far from the popup.

    It’s my family duty to be tech support, and occasionally I am called upon to fix things that have actually gone wrong.  But more often than not, I am called upon to try to rationalise a simple task that is unexpectedly complex to perform.  This complexity has usually arisen because the software’s developers and most vocal users are so immersed in common UI paradigms that they just don’t notice that the complexity exists.  For the novice user, on the other hand, even your software’s installation wizard is complexity they’d rather not deal with.

    The Slate article is right to cite Facebook’s user interface as a particularly onerous example of software complexity.  Feeds, live updates, inboxes, hidden inboxes, walls, profiles, Timeline, comments, likes, tags – some users need and revel in that level of complexity, but a significant number just want to, say, see what their kids are up to.  I’m nervous that one day soon, my granddad will ask me to set him up with a Facebook account.  I’ll dutifully comply, log him in, and give him this:

    Facebook User Interface

    Where does one even begin?  There are multiple feeds, multiple menus, pop-up and pop-down boxes.  How do you add one of these “status” things?  How do you add a friend?  How do I send a message to someone?  What’s public and what’s private?  Why is there so much stuff?

    In the world of User Experience (UX) design, we spend so much time thinking about how software will be used and by whom – personas, use cases, red routes and all the rest.  But in the majority of software I see when working with novice users, it seems that either the novice user has not been considered, or their persona is paid lip service while the latest excitingly complicated new features are bolted onto the software.

    As creators of software and of user experiences, I know we can do better than this.

    Do you have any thoughts on how we can design better for the novice user?  Just want to vent about an app with a particularly poor UI, or about a relative with a particularly poor grasp of computing?  Fire away in the comments below!

    SuccessWhale is Terrifying: VPS Edition

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Just under two years ago, my noticed with alarm, was about to blow through my then-limited bandwidth allowance.

    I’ve since relocated all my web stuff to Dreamhost, taking advantage of their unlimited bandwidth offering to plow through 10 GB and more a month. But now I’m coming up against the last remaining limit of my shared hosting – memory usage.

    Both Westminster Hubble, which constantly crawls MPs’ social networks and RSS feeds, and an increasingly complex SuccessWhale, churn through a ton of memory. I don’t have a nice scary graph for this one, but at peak times, I’d estimate that my web server kills over half my PHP processes due to excess memory use. That means Only Dreaming basically goes down, while SuccessWhale throws errors around if it even loads at all.

    It looks like I’m left taking the expensive plunge of moving my hosting to a VPS rather than a shared solution, which is a jump I’m nervous to make, especially since none of my web properties make me any money. Most worrying of all is that VPS prices tend to vary by available memory, and I don’t actually know how much memory all my stuff would take up if it were allowed free rein. And nor do I have any way of finding out, bar jumping ship to a VPS and taking advantage of free trial weeks.

    So, dear lazyweb, do you have any experience with this sort of thing? And can anyone reccommend a good (cheap!) VPS host that fulfils the following criteria:

    • LAMP stack with “P” being both PHP and Python (or *BSD instead of Linux)

    • Full shell access

    • Unlimited (or at least 100 GB) bandwidth

    • Unlimited (or at least 10 GB) disk space

    • At least 20 MySQL databases

    • IMAP mailboxes & mail forwarding

    I’ve been recommended linode by a friend which seems great for tinkering, though the price scales up rapidly with RAM use and I’m not sure I want to deal with the hassle of setting up Apache, MySQL etc. by myself. And there’s Dreamhost’s own offering, which would be virtually zero-hassle to switch to, but probably isn’t the cheapest around.

    So, citizens of the interweb, I seek your advice!

    Announcing: SuccessWhale version 2.0!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Ladies and Gentlemen of the Internet, I am pleased to announce that SuccessWhale version 2.0 has just been released and is now live on sw.onlydreaming.net.

    SuccessWhale is a web-based client for Twitter and Facebook, written in PHP, JavaScript and MySQL. It offers a multi-column view that allows users to merge together information from all their connected accounts and view it at a glance from any web browser.

    The big changes between version 1.1.2 and 2.0 are:

    • Facebook support
    • Support for multiple Twitter (and Facebook) accounts
    • As many columns as you want
    • Columns that combine multiple feeds
    • Lightboxed images from Twitpic and yFrog
    • New themes
    • Numerous bug fixes!

    You can see a screenshot of it in action below:

    SuccessWhale Screenshot

    I would particularly like to thank Alex Hutter, Hugo Day, Erica Renton and Rg Enzon, whose help in finding bugs and suggesting new features has been instrumental in bringing SuccessWhale up to version 2.0 today.

    SuccessWhale is an open source project, and the source code is licenced under the GPL v3.

    Announcing: Daily Promise!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    After a couple of weeks of development – documented here, here and here – I think I’m ready to call Daily Promise version 1.0.

    It’s a site that helps you keep track of your promises day-to-day, giving you a pretty display of which promises you’ve kept when, and letting you compete against your Twitter-using friends to be the best at keeping your daily promises!

    For now, you can find Daily Promise at http://dp.onlydreaming.net.

    I’ll make the same deal as I made with Dynamic Democracy, but doubling the number so that I can be more sure of it taking off, and that’s the following:

    At the moment the site does everything I want it to do, and it’s hosted on a subdomain of my main website, which I have no problem with. What I would like to do is give it its own domain, and start implementing feature requests that people send in. So that I don’t end up spending money on something that’s going to die off quickly, the deal is this: When it gets 20 active users, it gets a domain and some TLC. If it doesn’t make it to that point, it stays like it is.

    So if you’d like to help me make something of this site, please start using it, and show it to any of your Twitter-using friends who might need a little help getting healthy, keeping fit or any other goal that Daily Promise can help them with!

    Daily Promise: Avatars Everywhere!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    After a couple of days and one frantic family-free morning, Daily Promise is getting near completion. Here’s what’s new since last time.

    (This is post number 3 in my series on the development of _Daily Promise. The others are here: Design Sketches, Coming Together.)_

    Friends Page

    Daily Promise: FriendsHere’s the Friends page – again, almost no deviation from the original design sketch. The friends page pulls in the list of people that you follow on Twitter, matches it up against Daily Promise’s user list, and if any match, they’re your Daily Promise friends! They’re simply displayed in alphabetical order, along with a summary of their performance. Invisible users (see later) don’t appear, even to their friends.

    Nicer User Pages

    Daily Promise: User PageClicking on one of your friends takes you through to their ‘view’ page (minus any editing functionality). It also shows you their Twitter bio, and how long they’ve been using Daily Promise.

    Top Users Widget

    Daily Promise: Top Users WidgetThere’s now a “top users this week” widget on the home page, showing the performance of the top 5 users. This resets at midnight on Monday morning.

    Spam your Friends!

    Daily Promise: Tweet BoxTwitter integration now includes boxes suggesting Tweets you might like to make after each significant activity. Just as promised in the “How does it work” graphic, Daily Promise never posts to your Twitter account without you deliberately clicking a “Tweet” button each and every time. Do no evil™!

    Behind the Scenes

    A lot of other stuff has changed in the last few days that isn’t immediately obvious to users:

    • Authentication fixed – users using the alternative login weren’t able to do Twitter things. That’s sorted.

    • Account visibility – your account can now be set to invisible, meaning it won’t appear anywhere – top users, friends lists, etc. New accounts are given a prompt to set their visibility before starting to add promises.

    • Account deletion simplified – you now only have one, nuclear, option for account deletion. It erases all traces of you having used the site. Do no evil™! 🙂

    • Removed promises no longer shown in the history table – ‘cos no-one likes to be reminded.

    • Fill in data for yesterday – when creating a promise, users can opt to enter data for yesterday, giving them something to fill in straight away.

    • History table scrolls – narrow displays can’t fit the whole history table in, so now it scrolls (in reasonably modern browsers).

    • Time zones implemented – we pull the timezone you have set in Twitter, so Daily Promise will roll over to a new day at your local midnight.

    • Crontastic! – we now update stats and things from an hourly timed cron, to avoid extra loading on user-requested pages.

    Next Steps

    This all brings me to the slightly worrying conclusion that Daily Promise is damn near finished. So, where do we go from here? I’ll have a few more days of bug-fixing and implementing features that people request, and then it’s difficult decision time:

    This has been a fun project for the last week or so – does it deserve a domain and advertising, or shall I let it quietly die?

    Daily Promise: Coming Together

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Despite the lack of response to my earlier post, in which I floated my design concepts for “Daily Promise”, boredom won out in the end and I started coding anyway.

    It’s now coming together, and all bar the Twitter-integrated social aspects are largely complete. Here’s how it’s developed:

    Home Page

    Daily Promise: HomeThe social side – top users, etc. – still isn’t implemented, but there’s a reasonable-looking homepage in there. The main body is taken up with a short description and a big graphic explaining how the site works. Side-bar widgets provide the Twitter login and alternative login (bypassing twitter.com). The site now has a proper name, Daily Promise, and with it a logo and style that is reflected throughout.

    Set Up Goals (“Manage”)

    Daily Promise: ManageThe “Manage” page has remained almost exactly faithful to the design. New promises can be created, old ones deactivated and deactivated ones can be activated again. A Tweet box appears for the user to announce their new promise, if desired.

    Daily Performance (“Enter”)

    Daily Promise: EnterAgain, there’s not a lot of difference here between the design and the reality. Each promise has a yes/no choice, and after completing a day’s entries, Tweet boxes appear for the user to let their friends know about their successes and failures. “Winning streaks” aren’t yet implemented.

    Performance Log (“View”)

    Daily Promise: ViewThere’s no ability to scroll through your history yet, but the default display shows 4 weeks (which scroll if necessary). Just as in the design drawings, the history table is followed by a text summary of how the user is doing.

    The “View” page also, with a few additions, becomes a user’s profile page, which is accessible to other users.

    Configuration

    Here you can set your password for the alternative login, and delete your account. It’s exactly as dull as it sounds.

    Friends

    That’s my big job for the next few days! It doesn’t exist yet, but it’s now my top priority.

    Daily Promise: Design Sketches

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Current flavour of the month of some of the geek crowd, “Health Month”, is a social network of sorts on which users compete to achieve certain health-related goals. Each month, each member sets a number of goals for themselves to achieve. Its core mechanic is health points – you start with 10, lose one every time you fail to meet a goal, and players who perform well can heal you.

    I’m enjoying my use of the site with three goals this month, but I’d like to step it up and set lots. Unfortunately, having more than three goals costs money. (Not that I think the site’s owners don’t have a right to charge, but it can be a deterrent to users such as myself.) It also currently only allows two “custom” rules per month – beyond that, you have to stick with the pre-defined ones.

    Another social health site is Tweet What You Eat, on which users tweet their food intake and have the site, or the community, calculate statistics such as their calorie intake.

    Over my lunch hour, I’ve come up with some sketches for a site that sits somewhere between the two. It takes Health Month’s goals mechanic, opens it up and removes some of the social aspects that in my opinion Health Month doesn’t implement all that well. It also drifts closer to Tweet What You Eat, in that rather than being its own service it piggybacks of Twitter for its social side.

    At the moment this is just a fun concept I’m toying with – I don’t really have the time to make it at the moment, I doubt the space between Health Month and Tweet What You Eat is wide enough to make a new site popular, and I feel a little guilty about thanking Health Month for the enjoyment I’ve had by becoming its competitor.

    In the notes below it’s dubbed healthi.ly, though as that domain is parked, it’s come to be known as “Daily Promise” instead.

    Home Page

    Daily Promise Home PageThe home page would largely be a “log in / register” affair, possibly also showcasing successful and popular users in a side-bar (not shown). Big banner text explains the rough concept, with a “read more” link to a full “About” page. On the registration side, we make it clear exactly what Daily Promise does and doesn’t do with access to your Twitter account.

    Set Up Goals

    Daily Promise Goals PageThe main setup page is where you set your goals. Users can set any (reasonable) number of goals, they can drop and resurrect old ones, and add new ones, at any time. Performance against all the goals is tracked and visible on this page. Adding new goals and dropping old ones can be tweeted, but as with every tweet opportunity, the user is presented with an @Anywhere box that they can freely edit and can choose not to tweet as easily as they can choose to tweet. The tweet links to the list of goals on their profile.

    Daily Performance

    Daily Promise Daily Performance PageOnce goals are set, the user logs in each day (and can fill in past gaps) with whether or not they have met each goal. Each day’s entry presents some brief statistics, and you get more stats on the week after filling in Sunday’s performance. Very good or very bad performance suggests a Tweet that a user might like to make. The tweet links to their performance log on their profile.

    Performance Log

    Daily Promise Performance LogThis is a user’s main screen. It displays a chart of passes and fails for the last month or so as green (pass), red (fail) or grey (goal not active) squares. Below the chart, more detailed stats are presented, as well as an encouraging text summary of how the user is doing.

    Settings

    Most of the core settings such as username, display name, avatar and bio are handled by Twitter. Daily Promise’s settings probably boil down to privacy (stop me being searchable, delete my account, etc.) and removing annoyances (always tweet on condition x, never tweet on condition y, etc. – all of which have an “ask me” setting by default).

    Friends

    Daily Promise Friends PageThe user’s “following” list from Twitter is used to generate their list of Daily Promise friends. Avatars, usernames and Daily Promise performance summaries are displayed here. Clicking through to a user’s profile shows the “performance log” page, topped with name / avatar / bio / etc.

    So, and interesting idea, or an appalling one? Would you use this? Should I get off my arse and code? Should I have finished the last six things I started before prototyping something new? Your thoughts are, as always, appreciated.

    Sea Battle: Of Ships and Submarines

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    The distinction between surface ships and submarines in Sea Battle has turned out to be a more thorny issue than I originally imagined.

    The original plan was to have two classes of vessel, based on their hull types – ship or submarine – and weapons that could hit ships, submarines, or both. A future update could also have included aircraft “hulls”. However, the more I think about the game balance issues, the less I’m convinced that this is a good decision with the tech tree and playing field size that Sea Battle currently has.

    Sea Battle’s tech tree, as it currently exists, has four straight “trees” with 10 items in each. By and large, each component that you research is better than its predecessor. (Later hulls are heavier and take longer to build, so small hulls are still useful. However, you would rarely want to choose anything other than the best weapon, engine and radar that is available to you.) Combined with the small playing field, this makes for a fast-paced game of a few minutes, with each player researching and churning out ships constantly to gain the upper hand.

    There are a number of reasons why the current tech tree is inappropriate for submarines. Firstly, the weapons that a submarine could have: there’s only two. The Sting Ray torpedo (weapon 8) and Tomahawk missile (weapon 9) are the only weapons appropriate to be fired from a submarine. This would make rushing down the hull tree to submarines pointless unless you’d already reached near the end of the weapons tree – and in most games, you don’t even get that far.

    It also creates a UI complication, in that currently, any combination of hull and weapon is permissible. Submarine-appropriate weapons would break that behaviour.

    There’s an issue with anti-submarine weapons too. Again, only two (Depth Charge (6) and Sting Ray (8)) are appropriate for use against submarines. But since a viable submarine build wouldn’t exist until Hull 6 + Weapon 8, they would only exist in the late game, at which point Depth Charges just can’t hold their own against other weapons – so why have them at all?

    To abuse game theory, the logical choice is for players to build Depth Charge ships when they become available, then hold them in reserve as insurance against their opponent building submarines. But if you see your opponent stocking up on Depth Charge ships, you might as well not bother building subs and just go for better weapons and radar instead. Whoever commits to a strategy first ends up on the losing end.

    To cure these problems, perhaps we need to take another lesson from Warzone 2100’s book and have separate tech trees for different weapon types. So rather than one tree of 10 weapons, we have two trees for anti-ship and anti-sub. (And potentially anti-air later.) If we’re going down this route we ought to have different hull trees for ships and subs too. But at this point it’s turning into a rather different game – a slower, more traditional rock-paper-scissors RTS. But these games benefit from larger playing fields, varied terrain and squad-based combat – none of which Sea Battle is particularly well suited to in its current form.

    So the question stands: Do I expand Sea Battle significantly to include this extra complexity, on the understanding that I would probably need to rewrite it in something other than Processing and that may consign it to the pile of “projects I lost interest in”, or do I just ignore the issue and for the sake of simplicity not treat submarine hulls as any different from ships?

    Sea Battle: Here Comes the Science Bit

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Another day down, and somehow Sea Battle is remarkably close to the finish line. (No idea what I’m talking about? See previous blog entries 1, 2 & 3.)

    First things first, my failings: CPU use and mouse sensitivity are still not fixed. I’m now having to re-render more of the window on each refresh than before, so if anything they might be slightly worse.

    On the Facebook thread, Scott and Mark mentioned an AI issue in that a suitably scary player ship, when parked close to but slightly off to one side of the enemy base, will be ignored by enemy ships in favour of attacking the player base instead – even when they have no hope of destroying the player’s base before their own is destroyed. As far as I know that issue is still there, though improved enemy research and build AI should mean the enemy is pumping out ships just as scary as yours.

    On to the new features:

    • All 10 hulls, weapons, engines and radars are now implemented

    • You can now choose between them when setting build orders, so you can build in whatever configuration you like

    • Research is now implemented – click on an unresearched component to start researching it

    • You start the game with only basic components, and must research more to survive

    • Colours: Grey – not researched yet, Green – researching now, White – available, Yellow – selected (clicking Build will build this)

    • Enemy AI now handles its own research

    • Enemy AI now builds intelligently rather than randomly

    • You can now drag a box to select multiple ships

    And bug fixes / tweaks:

    • Base health significantly increased

    • Building a second ship without moving the first no longer places them on top of one another

    • Pathfinding code tweaked to cope with much faster/slower ships now all the hulls and engines are available

    • Fixed an issue whereby the blue radar circles were drawn at half the ships’ actual radar range

    Still to come:

    • Ship / submarine hull and vs ship / submarine weapon distinction

    • Tweaks to enemy AI

    • CPU use / mouse responsiveness fixes

    • Menu system and difficulty picker

    If you’d like a good strategy for beating the game at this point, I recommend you begin by keeping your build queue about 3-4 ships full, building the best thing you can at any point. Research-wise, rush down the weapons tree as far as Harpoon missiles, throwing in a couple of hulls and radars. Avoid engines for now. As soon as you have Frigates with Harpoons and Radar Mk 4, keep building them until you’ve fended off all the enemies near your base and you have a fleet of 15-20 of them, then move them all right up to the enemy base. With that fleet you should be able to destroy the base before the ships they build wear yours down too much.

    Sea Battle: That’s what Guns are for!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Another day – or three, in this case – brings another ton of functionality for Sea Battle. (Previous posts: 1, 2)

    Today’s release reduces the target frame rate from 60 to 30 frames per second, in an attempt to alleviate the CPU hogging reported by aefaradien in the previous post’s comments section. As I said in the comments, it’s not an issue I see on every machine, so I’d be grateful if any testers could tell me what PC setup they have, and how much CPU power the game takes up.

    Today’s version also fixes the spinning ships bug that just about everyone reported. What it doesn’t do is make mouse clicks any more responsive, which is annoying me too. Please bear with it for today, I’ll see if I can work out how to deal with that soon.

    Mostly this release is about new features. Sea Battle now has:

    • Ships are now implemented as having separate Hulls, Weapons, Engines and Radars

    • Ships can shoot at each other (finally!)

    • Ships have health (and health bars), and can be destroyed

    • Bases have health (and health bars), and can be destroyed

    • That means there’s now a win and a lose condition

    • Enemy ship AI now considers your ships’ scariness – a factor of firepower and remaining health – to pick targets it thinks it can defeat

    • You can now build, with appropriate build delays and an 11-slot build queue

    • The enemy can now build too

    • Colours have been tweaked to make ships’ allegiances more obvious

    The only real bit of functionality that’s still missing is the research / build options. Currently, clicking the Build button produces a ship of a predefined configuration – you can’t change that config or research better ones. The AI builds random ships up to and including as powerful as your default one, and has a reasonable amount of ‘thought delay’ to its actions, meaning that you can achieve victory fairly easily. (Just fill up the build queue and send every ship North as soon as it’s built – you’ll lose a few, but enough should survive to destroy the enemy base.)

    Note: this blog post is old, and the game now has more functionality than is described here. The next blog post in the sequence is here.

    Sea Battle, now with more Processing

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Nearly a month ago now, I blogged some sketches and ideas for a game I felt like writing. comment, and having heard people mention it in the past, I figured I should check it out.

    I’m very, very glad I did.

    It neatly deals with the issue of what I should develop for. The comments were leading me down the Java path anyway, but Processing’s two-click export to Applet and bundles for Windows, Linux and Mac OS sealed the deal. And it’s easy to program in too – it’s clear that it’s beginner-oriented, but it’s also ideal for simple games like this as it simply removes all the starting faff, like sorting out JPanels and TimerTasks and all the rest. Time will tell if Processing over-simplifies things and stops me doing something I want to do, but for now it is excelling at the main task of high-level programming languages – reducing the amount of brain overhead I need to allocate in order to talk to the computer.

    One lunchtime has produced 270 lines of code – which already includes the game area of the GUI, controllable player ships, and the beginnings of AI for the enemy ships.

    Note: this blog post is old, and the game now has more functionality than is described here. The next blog post in the sequence is here.

    Currently there’s no real gameplay – you can’t build, and ships can’t shoot or be damaged. You can move your ships (starting at the bottom of the screen) around, and the AI ship will hunt yours. Click on a ship to select it (blue circle), then click elsewhere to set its destination. Red lines, when they appear, show when ships would be shooting.

    The next block of code will give the ships customised gear, health points, and the ability to attack and sink others. With that will probably come attack animations, which with my lack of skill in that department, will take a while. After that, damageable bases and win/lose conditions, then the build/research system. Finally, graphics tweaks, AI improvements and game balancing will finish it off.

    More bloggery will appear once more coding occurs!

    For the Discerning Lady or Gentleman, SuccessWhale version 1.1

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    The sudden proliferation of peoples’ syndicated tweets from sources such as Foursquare and Fallen London annoys me far more than it should. Any more sensible old grouch would pick up his pipe, don slippers and write a strongly-worded letter to the local newspaper about how this ‘checking in’ business is corrupting society.

    Instead, I made my Twitter client block them. Also, you can now do it too!

    SuccessWhale users will now see a link at the top-right of the interface called ‘Manage Banned Phrases’. Clicking it will take you to a page where you can specify a semicolon-separated list of things you don’t want to see, such as “4sq.com;fallenlondon.com;bieber”. Once confirmed, any tweets in any timeline that are sucky enough to contain one of these phrases will be hidden from your view.

    Twitter: now 12% less full of shite!

    An extra feature has been rolled into this release, which is the ‘Reply All’ button. It only appears where two or more people are having a conversation (three or more if you’re included too). Clicking on it starts a reply to everyone mentioned, not just the tweet’s originator. So if @Alice is talking to @Bob, and you click ‘Reply All’ on one of her tweets, your entry box will then read “@Alice @Bob”.

    So that’s version 1.1. Share and enjoy!

    SuccessWhale is a free, open, multi-platform web-based Twitter client. It’s hosted at sw.onlydreaming.net, and you can find out more about SuccessWhale here. It’s GPL-licenced, so you can download yourself a copy too if you want one.

    a thousand words: Finishing Touches

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    The vast majority of user-reported bugs and requested features on “a thousand words” have now been sorted out. As requested by my co-conspirator Eric, we now have an ‘adult content’ filter based on a date of birth field in users’ profiles, and a ‘report’ button to bring problematic stories and pictures to the attention of the moderators. There’s also a DeviantArt-style “request critique” option to let users know what kind of comments you’re looking for.

    Timestamps have been fixed, “no stars yet” ratings introduced, and text field policies such as “mustn’t be empty” have been added across the site. A few rendering issues in IE have been sorted out, so it now looks much the same across all platforms.

    The biggest change is unfortunately something most of you will never see – the moderator console. Picture submissions and reported stories/pictures now sit in queues that can be dealt with by moderators. An item entering a queue triggers an e-mail to all mods, who are invited to review it and make changes as appropriate. Once changes are made, the affected users are then e-mailed to let them know what happened (and in the case of reported items, to give them a chance to challenge it).

    There’s one major feature request that’s not yet been implemented: file uploads. Once in the system this would allow users to submit pictures from their hard drives rather than from the web by URL, and would allow moderators to copy URL-linked pictures to the site to avoid hotlinking. (At present we don’t hotlink, but we do therefore have to copy pictures to the site manually using FTP.) It could also allow users to use a non-Gravatar picture for their profile.

    Depending on how things go, that may or may not be ready by tomorrow night. On Saturday morning I jet off to sunny Saudi Arabia, so any changes not made by then are going to remain unmade for a while. From that point it’s in Eric’s capable hands as to whether she wants to release the site or not. Even if the site does advance to release status, I’m still taking bug reports (they’ll sit in my inbox until I get back), so keep on letting me know what’s broken and what you’d like to see added!

    a thousand words: Alpha, Beta

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    “a thousand words” has now reached a stage where every feature that I give a damn about is implemented. Thus, we’re opening it up to a limited beta test to iron out the wrinkles and get a list of any features potential users would like to see us launch with. If you’re bored or simply have a love of breaking other people’s shit, head along to http://athousandwords.org.uk and see what hell you can raise. As the Big Red Box Text warns you, really don’t submit any work of fiction you care about, just in case some kind soul finds an SQL injection vulnerability and trashes the database.

    Since last time I bored the hell out of you all, voting and commenting has been implemented, registration has been fixed, filtering HTML tags from submissions has been added, as has a word count and the picture selector on story submission. There’s been a bunch of behind-the-scenes tweaks to improve security too.

    The one feature that Eric definitely wants is a way to mark stories according to their content. We could do this in several ways – I would prefer, if anything, to just have a “not for kids” option on each post and a Date of Birth field associated with user accounts, so we can hide stories as required. Other options include a range of ratings (U, PG, 12, 15, 18…) or tags for certain content (violence, sex, language) so people can avoid whatever they’re picky about.

    This probably ought to come with a Report button so that users can report incorrectly rated stories, and I would add a similar feature to report pictures. (Picture submissions are moderated, so Goatse isn’t going to make it through anyway, but the mod team might miss subtler things like licencing terms and copyright infringement.)

    At that point, all that’s left on my list is the admin interface and anything that users suggest during this beta. Hopefully we’ll be ready to launch by the time I depart for sandier shores at the end of the week!

    a thousand words: Hot Profilin’ Action

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    A few days’ laziness (by which I mean a few days’ Starcraft) have passed with not much work being done on “a thousand words”. That came to an end tonight, with a productive evening resulting in a working profile system so that users can now add and display personal information, change their registered e-mail address and password, etc.

    There’s now a database backend for the voting and commenting systems, which will be complemented by their GUI pages tomorrow night.

    Once that’s done, that’s the last of the main functions out of the way and we’re basically down to tweaks. I think we ought to, in no particular order:

    • Decide on what formatting users can add to stories, and filter for it

    • Add a word count, and possibly limit submissions to e.g. 600-1400 words

    • Add a means of reporting stories and pictures for e.g. copyright issues

    • Add a means of rating stories, so users can mark them as containing sex, violence etc.

    • Create an admin interface, so we don’t just have to run the site with raw SQL queries

    • Add ranks, etc. (incentives for achieving high Total Stars)

    • jQuery up some of the main bits to improve user experience

    • Implement the scrolling list of pictures for users to select when creating a new story

    At that point, I think it should be ready for open beta. Hopefully we can get it all done within a week, before I depart for internet-less shores!

    a thousand words: GETting and POSTing

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Another day, another bunch of functionality added to a thousand words. With the main public-facing interfaces largely complete, I have moved on to the guts of the site’s user interaction. The site now has working, but ugly, implementations of:

    • E-mail address / password authentication, with cookie support based on a secret phrase generated at registration.

    • Registration itself, including the setting of a display name (users authenticate with their e-mail address, so we need something friendlier to display in the UI). Accounts are created in an unactivated state, and an e-mail is sent allowing the user to use their secret phrase to activate the account (GETted via a “click here to activate!” URL).

    • Picture submission, which adds the submission to a ‘queue’ table. In time there will be an admin interface for moving items from the queue to the real pictures table, i.e. promoting a suggested picture to “picture of the week” status.

    • Story submission, which adds the story to the live site and takes you there after submission. There’s currently no edit capability, and the picture that the story is based on must be manually specified by ID number. (The latter will become a scrollable jQuery list of all pictures.)

    A story edit/delete interface is my next task, and once that’s done, the core functionality (excluding any user profile-related code) will be largely finished. After that there’ll be a period of testing and improving the interfaces of the new functions, before I put a call out for a couple of willing guinea pigs to try and break the site for me! If anyone out there is expecting to be really bored sometime this week, let me know!

    a thousand words: First Sketches

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    With the main browsing UI for a thousand words up and running, it’s time to bore the world with more pointless trivia before moving on. Today: design sketches!

    Pretty much every software project I undertake these days begins with a sketch of the user interface and an initial structure for the database. Labouring under the cruel ‘no whiteboard’ conditions at home (maybe I should get one?), I drew these out on paper. Passing the UI sketch over to Eric after about 5 minutes’ work, she described it as “awesome”. I think that’s the first time that’s ever happened; the general response at work is along the lines of “but where are you going to put giant-ugly-element-X that I’ve just thought of and wasn’t in the spec?”. So that was that, and I’ve coded it up pretty much as it was on paper.

    The database hasn’t changed much from the original design yet, but it will have to soon – as designed, the vote (‘stars’) system doesn’t record each user’s vote on each story, so it can’t support users changing their vote. Sometime during development I’ll have to devote a few hours to figure out the best way of handling it, though that probably comes down to a few minutes as someone on Stack Overflow has inevitably asked about it already.

    a thousand words UI Sketch
    a thousand words Database Design

    Next up on a thousand words is coding the first few forms that will allow users to register and log in, submit photos and submit stories. That should be done within the next few days, and will allow me to play with actually changing the contents of the database, rather than just showing views of it.

    a thousand words: A New Timesink has Arrived!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Somehow unable to cope with actually having free time of an evening, I have taken on yet another project which will doubtless push me deeper into the dark, untamed wilds of the internet, the land stalked only by the mysterious beast known as the “web developer”.

    Eric has come up with the idea for a fiction-writing community known as “A Thousand Words”. The concept is simple:

    • Users submit photos or other images that they find interesting
    • Every week (or other suitable period of time), one of these is chosen by the site staff
    • Users then write short stories, of around 1000 words, inspired by the picture
    • Users rate, comment etc. on each other’s stories

    I’ll be coding up this site in my spare time over the next few weeks, and you can check out my current progress on the live site at a thousand words.  Currently, the database design is done and I’m partway through the UI of what will be the main page.  My todo list is roughly:

    1. Finish the main page and story page UIs.
    2. Add bare-bones pages for all the GET/POST functions, e.g. registering accounts, submitting stories, submitting pictures.
    3. Test all the functions.
    4. Work on their UIs.
    5. Start closed beta testing for anyone interested.
    6. Liberally apply jQuery to improve user experience.
    7. Add commenting, possibly via DISQUS.
    8. Add proper user profiles, gravatar support etc.
    9. Get everyone I can find to try and break it.
    10. Release!  Open the flood-gates, and despair at the dribble I receive.

    As I go I’ll be posting updates and hopefully-interesting insights here, and you can always check the site at athousandwords.org.uk to see how I’m getting on.

    Farewell, Dynamic Democracy

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Back in April, the Digital Economy Bill was rushed through the wash-up procedure of the outgoing government without the due debate and consideration that I and others believe such a far-reaching bill deserved. My disillusionment with the government decision-making process over the following week led me to set up and announce a new site, called “Dynamic Democracy”. It was an experiment to see what would be discussed if everyone was involved – on an anonymous basis – rather than just our elected representatives that often do not do a good job of representing us anyway.

    The site allowed all users to create and comment on ‘Bills’, encapsulated ideas or laws that they would be pushing for if they were in power. Registering gave users the ability to vote bills (and comments) up and down, leading to a list of highest-ranked bills that represented the users’ favourite potential policies.

    Dynamic Democracy saw little success, possibly because writing a full, well-thought-out bill represented significant effort that a casual browser would be unlikely to commit. ‘Karma’, the point system that aimed to encourage users to submit bills and comments, did not prove to be a good enough incentive as there were so few users to compete with and no direct reward was ever implemented for reaching high karma levels.

    What the site did bring, however, was a number of enquiries from like-minded individuals all over the world, keen to discuss the ideas behind the site and whether or not something like Dynamic Democracy could ever be implemented as a real government policy-making tool. One of the more notable contacts, Denny de la Haye, stood as a candidate for Hackney South and Shoreditch in the general election and promised to implement a crowd-sourced voting system similar to Dynamic Democracy for his constituents to voice their opinions in Parliament through him. (Denny, who sadly did not win his seat, now represents the UK arm of political party DemoEx.)

    I have decided that today is the day to close the Dynamic Democracy experiment, because today the UK government announced their “Your Freedom” website. While largely focussed on repealing or changing laws rather than the complete freedom to suggest anything you like, Your Freedom is certainly in the same vein as Dynamic Democracy, with the crucial extra feature that is endorsed and used by our government and thus ideas proposed there stand at least some chance of making it into official government policy.

    Time will tell whether that really happens, or if like the No. 10 Petitions site, suggestions will be responded to with an e-mail from the Prime Minister’s office explaining why thousands of users are all wrong. But I do still hold out hope.

    Did Dynamic Democracy influence the government in their decision to create Your Freedom? Almost certainly not. As my discussions with visitors to the site have shown, I am far from the only person to have come up with this idea, and neither am I the only one to have coded up a website around it. No – this is simply an idea whose time has come. A vast gulf exists between Westminster and the world outside, just as it always has, but these days the public are coming to question why that is and if we can do something to correct it. And nowhere is the desire to bridge that gulf stronger than among the tech-savvy youth that have the drive and the ability to use the internet to that end. Sites like these will come and go a hundred times over the coming years and decades, and slowly but surely we’ll reshape our government into what we want it to be.

    So to everyone who contributed to Dynamic Democracy: thank you, and goodbye.

    If you’d like to contact me about Dynamic Democracy (or anything else), you can still do that via email. If you’d like to help get the Digital Economy Act repealed, please vote up and comment on one of these ideas on Your Freedom. If anyone would like use of dynamicdemocracy.org.uk until my ownership expires in 2012, let me know. Stay tuned for the announcement of another project that bridges politics and the internet in the next few weeks.

    An Experiment in Dynamic Democracy

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Dynamic Democracy

    I’ve been an advocate of opening up our democracy and involving the public in government decision-making for some time, without doing anything particularly concrete about it besides placing my vote. The Digital Economy Bill fiasco showed us that, really, we’re not involved with the day-to-day workings of government at all, and born of that is this experiment.

    I’d like to know what we, the people, think our government should be talking about. I’d like us ordinary people to submit our ideas, vote on other people’s ideas, and come up with some idea of what we really care about. And so here we are:

    Dynamic Democracy

    This is all very experimental at the moment – please sign up, post ideas, vote on other people’s ideas, and if it proves popular I’ll take it on as a permanent project. Let’s do this!

    So Farewell, Psion 3a

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    No idea why the hell I bought a Psion 3a a lottery ticket? Check out my previous blog post, “Coming of Age”.

    Pictured: Progress.

    It wasn’t a good sign, I suppose, when I switched the old Psion on this evening and discovered naught but vertical black bands on the display. It took a good few power cycles, lid closes and a strenuous massage of its hinges before it finally spluttered back into 16-bit (Multi Tasking!) life. But it made it in the end, just in time to discover what fate had in store for it.

    Now, there are a few ways of finding out what the night’s lottery numbers were. First, one can tune into the live draw on television. However, the TV guide indicated that the show was presented by Scott Mills, so that option was immediately discounted. No blog stunt is worth 10 minutes’ exposure to Scott Mills. The next method is going to the lottery website, but this was discounted just as quickly – I didn’t want to shock the poor old girl by showing her what BBSes had become.

    Keepin' it Old Skool.

    Ah, but there is of course a third option more befitting of the Psion’s age. I speak, of course… of Teletext. Trust me, I am as shocked as you that this thing still exists. Hell, I was pretty surprised that my TV still had an analogue receiver. So, to page 555 on BBC CEEFAX we went, the Psion checked her numbers, and… Yeah, we didn’t win. A paltry single number, in fact, only a third of the way to the £10 lowest prize.

    And that, I suppose, is the end of the road for the old Psion 3a.

    ':(', yeah, that's the kind of emoticon we rolled with back in '93.

    I remember virtually idolising these things when I was a kid – I’d been though innumerable personal organisers and proto-PDAs, but to have a Psion 3, with their high-resolution screens and the little touch-sensitive app buttons, the voice recorder, the programming environment… This thing was an object of desire as far as I was concerned. And it was certainly an improvement over its predecessor, the Psion 2, which I somehow also had despite it being nearly as old as I was.

    Yet now the 3a headed for the great landfill in the sky, an anachronism in today’s world. It takes expansion cards that nobody sells, communicates with a PC through a cable that nobody has and software that no-one can run. My cellphone has a processor 70 times faster, with 200 times more RAM. In my pocket I carry 10,000 times more storage than this thing has. In a world soon to be rolling its way into the year 2010, it is less than useless.

    And yet, despite that, I will be sorry to see it go.

    Coming of Age

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Yes, she's legal.

    The other day, while excavating the depths of our airing cupboard-turned-junk pile, I discovered possibly the oldest gadget I own: a Psion Series 3a… thingy. Time has obscured from my memory what we actually called these things when they were new. It certainly wasn’t ‘netbook’ – was it ‘palmtop’? After some new batteries and a non-trivial number of blunt impacts against the table to reseat the display connector, it spluttered into life. The back of the unit declares it to have been made in 1993, so this thing is sixteen years old.

    Now where I am, at sixteen, one can do the following:

    • Drive a scooter

    • Have heterosexual sex

    • Marry (heterosexually) with your parents’ consent

    • Enter full-time employment

    • Play the lottery.

    The Psion 3a, having the decency to look embarrassed next to my cellphone.

    There are a few issues with most of these. Driving a scooter is clearly beyond the poor thing’s capabilities. It appears to have expansion slots, so I’m going to go ahead and consider it female. Now that by default makes all other Psion 3as female, so marriage (within its own species at least) is presumably out. I have no expansion cards to put in it, and now I’ve mentally pidgeonholed that as “having sex” I’m not sure I even want to. Full-time employment is out as I’m not sure it does anything that peoples’ cellphones don’t these days. And that just leaves playing the lottery. Well, then.

    These things can be programmed in a language called OPL, which appears to be so antiquated that even the internet has largely forgotten it. I’m immensely grateful to Gareth and Jane Saunders, who seem to be the only people left with an OPL-related webpage that hosts the programmers’ manual.

    In the UK, one picks six numbers between 1 and 49 for each draw. Six numbers and a bonus are chosen by the lottery machine, and matching all of the main six is a jackpot (odds about 14 million to one). Matching three is the lowest prize, £10 at odds of about 56 to one. So, not really confident we’ll be winning anything here. Still, onwards!

    Making sure all six numbers it picks are different would take more than the three minutes I’m prepared to spend in contact with OPL – damn thing doesn’t even have FOR loops. I’ll just run the program again if it picks two the same. So here’s possibly the shortest program I’ve ever written:

    Eat your heart out, Visual Studio 2008.

    PROC lottery:
      LOCAL count%, n%
      RANDOMIZE(MINUTE+SECOND)
      PRINT "Lottery Numbers:  ";
      DO
        n% = (RND*48+1)
        PRINT n%;
        PRINT "  ";
        count% = count% + 1
      UNTIL (count% = 6)
      GET
    ENDP
    

    The Die is Cast.

    And when translated (translated? really?) and run, it does indeed produce lottery numbers. So – to the newsagents! And back, lottery ticket – and granulated sugar – in hand.

    Having foolishly switched the thing off in the meantime, it took a few seconds of mashing the On button and opening and closing the lid to coax it back into life. But back to life it came, long enough to pick its six numbers. And now, we wait to see what fate befalls this aged device.

    Will it quietly be replaced by gadgets a decade and a half its junior? Or become a palmtop millionaire, and, er… and I’ll have to work out what the heck a Psion 3a would do with a million quid. Tune in on Saturday night to find out!

    The lottery results are in! You can find out what happened in my next blog post, here. Spoilers: I am still not a millionaire.

    Announcing: SuccessWhale!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    For the last few days I’ve been working on a simple web-based Twitter client, to fill the void between the simplicity of Twitter’s own web interface and the broken-in-IE6 complexity of BeTwittered and Seesmic Desktop’s web interface.

    It’s still under heavy development, and there are probably a ton of bugs and missing useful features. Please give it a try and let me know what you think. Bug reports are more than welcome!

    The source code is licenced under the GNU GPL v3.

    Update: Due to a move to the proper OAuth API, the software could no longer continue to be called FailWhale, as someone’s already written a Twitter app with that name! Thus, until I or someone else comes up with a good idea, it’s called SuccessWhale.