I’ve been casually working with my friends at Anomaly Software since early 2012. Back then, they went under a different moniker and were beginning a shift from consulting to a product-based business.
Three years on and they boast a suite of modern products—some proprietary, others free-to-use and more preparing for launch later in the year—backed by a new brand, business model and approach.
I helped name the business, design the logo and the foundations of the website, which will be rolling out in stages throughout the year.
Advocating the Python programming language, Closure Tools, App Engine and other modern web application technologies, Anomaly maintains Prestans, a WSGI-compliant REST framework and is preparing to release Twine, a mouldable task manager for the Web and iOS.
I’m really excited about what we’re working on this year. For more information, visit anomaly.net.au
As part of a recent update, I removed the contact form from this website and replaced it with a simple
mailto link. It started with a quick code review on GitHub. It bothered me that there was a small dirty-blue band at the end of the language graph tagged as ‘PHP’. My first instinct was to go and recreate the whole thing in Ruby, but then it dawned on me that I couldn’t think of a single advantage to using a contact form over a plain old email link.
To confirm I wasn’t alone in my thinking, I tweeted a quick poll. I received half a dozen replies, all voting for plain, old email.
The advantages are huge:
- A copy of the message is stored in the Sent mailbox
- It’s possible to save a draft while working
- People are familiar with their email client interfaces
- Attachments can be included
Essentially, contact forms are a black hole at the mercy of AJAX, your server, the browser and more. Arguably, they may influence the supplied content and reduce incoming junk but spam is a developer’s problem, not a user’s, and there are always ways around those ‘required’ fields you may have defined. Contact forms create user-friction, while email just works.
My wife has been working closely with my friends at Anomaly Software to produce an interactive children’s book for the iPad. It’s called Where’s My Whisper? and is designed for children under the age of about 8.
I had little to do with this project other than watch it from the sideline, but it was great to see creative people working together to produce something special:
Their are a few geeky treats happening behind the scenes; dynamic weather and daytime vs nighttime artwork, alternate pages and the odd Easter egg.
The first version is available for iPad on the App Store with several updates in the pipeline. If you have or know children young enough to enjoy the book, pick up a copy and leave a review!
I know of too many cases where a website has been shipped and then left dormant until it’s time to redesign in two or more years. A website should be a living, breathing thing and this situation is so easily avoided by applying a few well-established software design principles.
I’m an advocate of applying software development protocols to all kinds of problems. I’m obsessive about keeping lists, setting deadlines and monitoring progress—even when it comes to the most basic household chores or errands. There’s no reason not to apply this thinking to websites.
Version Control and Issue Tracking
It doesn’t matter if your site is a single page or a thousand, you should be running it through version control. Beside all of the backup and collaboration advantages, version control is a constant reminder of how much and how often you are (not) committing to your project.
Log bugs for yourself. Tag them. Give them a priority and attach them to milestones with assigned deliverable dates. Not everything has to be fixed immediately, but planning small and major updates in releasable groups is a very good idea.
Public Release Notes with Semantic Versioning
Many software vendors keep a public list of what and when things are changed. Doing so for your website will force you to remember that people can actually see how long it’s been since you released any work and is a nice incentive to keep shipping. You should label each release with a semantic version number. Not everyone uses this standard, but having some order to the way you release and document updates is great for consistently shipping.
The most important thing is to keep organised and remember that good software is regularly maintained and constantly refined with small bite-sized updates rather than long periods of dormancy followed by major overhauls. Most of us understand this already, so we should apply the same thinking to websites and other digital goods.
I just deployed a small update to the site which features new navigation, a redesigned archive and the early stages of some better content organisation via tags. I went through several iterations and couldn’t settle on any that I liked just yet, so this is just the first part of that update. As part of the process, I discarded a lot of near-polished icons which I’ve now put up on Dribbble.
I’ve also wiped about a dozen articles from the site; old, outdated and no longer relevant content has been dropped in favour of some new pieces I have on the way.
Lastly, as a bit of an experiment and part of a new approach to maintaining my site and other projects, I’m making my release notes public. More on this soon.