Thursday, November 1st, 2012
Something extraordinary happened a few weeks ago and I felt like I should mark the occasion: The government launched a website that didn’t suck.
No, not only didn’t it suck, this website has a wonderful user experience. Really. Not only that, but it came in without falling foul of the cost creep endemic in government digital projects. It replaced and rationalised content. It made things clearer and used plain English. It focused on what users wanted to find, not what government departments wanted to say. The team shared their code on github and accept pull requests. They set metrics for pages and continually revised and improved. They ran detailed user and accessibility tests.
I can’t quite remember when I first heard of the then alpha.gov.uk project. Possibly from one of the many folks on the web scene who seemed to get sucked into the project. This in itself was the first sign that those behind the new government website knew what they were doing, they got professionals with industry respect to work on the prototype. Over the last year or so I’ve watched it move from alpha to beta and slowly iterate and optimise. They’ve done this in public, often sharing their detailed research and testing experiences on their blog (with some interesting results, see their notes on auto-completing search). The web community in the UK has been cheering from the sidelines the whole way, because it’s really made a nice change to be enthusiastic about a government website. It’s weird when the hotest startup in the UK is a government website…
If you ever wanted a case study for a large scale user-centric redesign, this is it.
This is truly a watershed moment, and one whose lessons I hope will cascade down from central government to regional (please pay attention Birmingham City Council) and other public sector areas. The Government Digital Service is a model for how this kind of project should be delivered. They put the web it its own category and built something amazing.
Given I have pretty much hated the major policies of the current coalition, it seems very strange to be congratulating it, but for their support of this one project they really deserve it. They’ve given us a UK website to be proud of.
Friday, July 29th, 2011
So we’re doing some mobile/responsive design work and I wanted to check what they might look like on various devices before we actually got to full testing.
Fortunately having a Mac means the iPhone emulator is a mere 3GB download away in the iPhone SDK… And great, it picks up the systems /etc/hosts so all the nice modifications I’ve made for testing our app locally get picked up. Easy win.
Android proves more of a problem, so I thought I’d document it here as I had to hunt round developer docs, read a couple of blog posts and cobble together with string.
First get the Android SDK. Switch into the SDK directory and run:
to bring up the SDK and AVD (Emulator) manager. Oh, you should probably install the updates first.
Go to virtual devices and click new to create a new virtual device, call it TestDevice, pick a target version and use those defaults. OK this. You could run the emulator here, but not pass in a hosts file… Quit out. Then run:
tools/emulator -avd TestDevice -partition-size 256 &
This runs the emulator directly and gives it some space so you can actually modify the devices hosts file.
To see what the emulator thinks it’s called. Probably emulator-5554 or something memorable. So now run:
./platform-tools/adb -s emulator-5554 remount
To remount the filesystem so its not read only and you’ll be able to change the hosts file. Then run:
./platform-tools/adb -s emulator-5554 pull /etc/hosts
This gets the current hosts file from the device. Edit it in whatever text editor, it’s been pulled to the current working dir. Finally run:
./platform-tools/adb -s emulator-5554 push hosts /etc/hosts
To push it back to the device with the changes.
Now test your webpage.
PS. For added fun, this isn’t saved when you save the emulator state. Any ideas why?
Edited: Updated memory allocation based on comments below. I’ve wrapped this into a script and posted it on Forrst.
Sunday, July 17th, 2011
Way back in February, I did a quick talk at the Show & Tell event on a new side project of mine (slides over here) and forgot to publish this related blog post, hey ho! Here it is in reduced form:
Finder is simple web app to help parents discover and catalogue local child-friendly businesses, something I’ve built from personal need. It currently residing at finder.newdadsite.com and is in need of some content/contributions love (you can sign in via Twitter!). It makes use of some funky browser geo-location to make it extra useful, with fallback to plain old search.
Finder is a simple enough little app, and it gave me a great opportunity to use Python in anger; Previously I’d only really played about with it. I arrived at using Pylons for a number of reasons. Like most people who want to do some Python web-appery, I’d initially looked at Django, which seems to be the most talked of framework. Something about Django didn’t really mesh with me, it’s got its own way of doing things, and that wasn’t an exact fit somehow – personal taste maybe.
Pylons felt, well, much more toolboxy. You could pull stuff in from all over, pick the modules you liked best. Particularly I like the SqlAlchemy/FormAlchemy combo, I’ve always felt that it should be easy to build a form from an existing model if you’ve used sensible naming conventions. Stuff like this:
FieldSet.__init__(self, Location, session=Session)
is a really neat way to just turn a model into a form for editing that model’s data. Not part of Pylons, but I can chose to use it cos I like it (and I’m a fan of easy).
One thing I forgot to mention in my talk (well, I only had ten minutes!) was that Pylons in now merging with Repoze to become Pylons Project with a new framework called Pyramid… It’ll be interesting to see what the future holds for it.