What’s new with PlanningAlerts, part 2

In part one, we covered some of the new features that we’ve added in the last couple of months. Next, we’ll cover the myriad of improvements, some small, some large, that we’ve made to existing features.

Most of these, as a normal person using the site, individually you might never notice the difference. Small aesthetic tweaks, usability improvements, but on mass they represent some huge improvements overall.

Most of the changes have been focused on the application detail page. This is where you get the map and streetview of the application and links off to nearby applications and stats about the application itself. This is actually the page where over 70% of new people arrive at PlanningAlerts, most of the time by searching for a specific address on Google that they’re interested in.

A big part of what we’ve been trying to achieve with these changes is to take all those people that come to PlanningAlerts for the first time and firstly make PlanningAlerts really useful for them right then but more importantly try to get them to come back. The best way to keep in touch with planning applications in your area is by signing up to email alerts. You can totally forget about things until something of interest comes along and arrives in your email inbox.

So, we really want to get people signing up to those email alerts, especially new people that arrive on those application detail pages.

Here’s the requisite before and after screenshot.

Before

After

Improvements

Improvements to the application detail page, including:

  • Visual tweaks on application detail page – see those before and after screenshots
  • Make maps zoomable and draggeable
  • Removed display of tweets on application detail page – few people were using it
  • Remove clutter of nearby applications. Just replaced with a link
  • Made map and streetview work without javascript – accessibility is important to us. Not everyone has javascript enabled. So, we’ve made the map and streetview on the application detail page work even if you don’t have javascript enabled.
  • Added some simple hover effects to comments and some simple visual tweaks to visually separate different comments
  • We ran a bunch of A/B experiments:
    • Remove RSS feed
    • Put sign up form directly on the application detail page
    • Moving sign up form to the sidebar
    • Sign up form with email address on home page
    • Telling people how many people signed up to alerts on form
    • Test variation of button wording

Improvements to the backend, including:

  • Added Google analytics to mobile site – embarrassingly we managed to not have analytics for our mobile enabled site. Well that’s fixed now!
  • Began testing against Ruby 1.9.3 as well as Ruby 1.8.7 – in preparation for moving the whole site to using Ruby 1.9 which is faster and has better support for different text encoding.
  • Bring gems up to date (heaps of changes) – we were depending on a lot of very out-of-date libraries. We’ve brought most of them up to date.
  • Replaced administration backend with ActiveAdmin.
  • Added new relic monitoring – helps us understand the real performance of the site so that we could improve things for you.
  • Added bounding box optimisation to distance queries – we used to have this. When we upgraded to Rails 3, we lost this optimisation as we changed libraries for geo database lookups. We added this optimisation into the new library and contributed the change back to the community.
  • Various database speedups

Improvements related to scraping, including:

  • The PlanningAlerts application now grabs data directly from ScraperWiki rather than going through the scraper
  • Adding a new ScraperWiki scraper can now be done completely from the admin interface. Doesn’t require a code deploy.
  • Optimise scraping by collecting date range in one go – speeds things up considerably and lightens the load on ScraperWiki.
  • Show broken scrapers on coverage page – this is part of our strategy of exposing a little more of the underlying workings of PlanningAlerts in an attempt to make it easier for people with some programming skills to contribute to the site.
  • Improve integration of ScraperWiki and PlanningAlerts.
  • We also consolidated all the SPEAR authorities from Victoria into a single planning authority. This makes the difference between SPEAR and the local council clearer.

A bunch of improvements related to the API, including:

  • Added logging of API calls – we weren’t keeping tabs on the usage. We are now.
  • Made documentation of usage of API clearer on high volume & commercial use – nothing has actually changed about our policy here we just made it explicit. It used to be that we would discuss this stuff when people would get in touch with us.
  • Added throttling to API (configurable by source IP address) – to ensure that a single API user can’t bring the whole site down accidentally for everybody.

Some other improvements

  • Add vanity for A/B testing – rather than making small tweaks, hoping that it affects the change you want, we’re now using A/B testing using a gem called vanity where we show different variants of a page to different users and see which variant is more effective.
  • Open out the visual layout (get rid of margins at the side)
  • Rejig of volunteers list including adding new people (Added Kat, Andrew Perry, Maxious, and Justin Wells). Laying them out in a little grid and sorting them randomly.
  • Added new footer with direct links to other projects and contact info (twitter / email, etc..)
  • Improve menu with hover effect and larger selection area – this makes it easier to click around.
  • Only show the first ten applications in an email alert if there are more than 10 – this helps when we add a new planning authority with a large amount of historical data
  • Removed beta badge – A small but significant change. We removed the beta badge because we’re now coming up to 3 years old (in December) and hundreds of thousands of people have used the service.

Fixes

  • The following 20 scrapers were fixed which means that people in those areas can now use PlanningAlerts once again:
    • Penrith
    • Lane Cove
    • City of Greater Geelong
    • NSW Major Projects
    • Clarence City Council
    • City of Melbourne
    • Gosford
    • Parramatta
    • Kingston City Council
    • Knox City Council
    • Bankstown City Council
    • Sunshine Coast Regional Council
    • City of Yarra
    • Muswellbrook Shire Council
    • Fairfield City Council
    • City of Onkaparringa
    • Rockdale City Conucil
    • The Hills Council
    • Woollahra Municipal Council
    • City of Burnside
  • Site problem notifications
  • Fixed comment abuse report
  • Fixed problem with people on mobiles not being able to confirm registering for email alerts
  • Security update to Rails
  • Fix bounding box API call
  • Make XML sitemaps persistent between application deploys
  • Fixed a caching bug
  • Fixed distance unit bug
  • Fixed custom 404 page

As always let us know what you would like to see happen next!

This entry was posted in Development, PlanningAlerts.org.au. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*
*

Subscribe without commenting