2013 update Automating online activities without IT intervention - using web tools to make jobs easier

There's often lots of small - and not so small - activities that communications teams want to carry out online that would make their jobs easier, but aren't really tasks to give to IT teams.

For example, you may wish to update your agency's Facebook and Twitter profile pictures when your logo changes, automatically post your blog posts to LinkedIn and Facebook, be sent an email whenever someone tweets at you or receive an alert whenever your Minister is mentioned in a breaking news story.

This is where it is useful to get familiar with services like IFTTT and Yahoo Pipes.

IFTTT, or "IF This Then That" is a simple logic engine that allow you to string together a trigger  and an action to create a 'recipe' using the format IF [trigger] then [action].

For example, below is a recipe used to automatically tweet new posts on this blog:

A recipe in IFTTT

This sounds very simple, but it can be a very powerful labour saving tool. Each trigger and action can be from different online services, or even physical devices.

A recipe in IFTTT (click to enlarge)

Recipes can be more complex, with various parameters and settings you can configure (for example the recipe above has been configured to append #gov2au to the tweets).

For example, at right is the full page for a recipe that archives your Tweets to a text file in your Dropbox.

Besides connecting the trigger (a new tweet from you) with the action (posting your tweet in Dropbox),  you can choose whether to include retweets and @replies.

You can set the file name where your tweets will be stored and the file path in Dropbox, plus you can set the content that is saved and how it will be formated.

In this case the recipe is set to keep the text of the tweet (the 'Text' in a blue box), followed on a new line by the date it was tweeted ('CreatedAt') and then, on another new line, a permanent link to the tweet ('LinkToTweet'), followed by a line break to separate it from following tweets.

You can add additional 'ingredients' such as Tweet name and User Name - essentially whatever information that Twitter shares for each tweet.

Rather than having to invent and test your own recipes, IFTTT allows people to share their recipes with others, meaning you can often find a useful recipe, rather than having to create one from scratch.

In fact I didn't create either of the recipes I've illustrated, they were already listed.

There's currently over 36,000 recipes to choose from, for the 47 services supported - from calendars, to RSS feeds, to email, to social networks, to blogs and video services, from SMS to physical devices.

All the online services that can be 'triggers' for IFTTT

It is even possible to string together recipes in sequence.

For example, if I wanted to update my profile image in Facebook, Twitter, Blogger and LinkedIn, I can set up a series of recipes such as,

• If [My Facebook profile picture updates] Then [Update my Twitter profile picture to match]
• If [My Twitter profile picture updates] Then [Update my Blogger profile picture to match]
• If [My Blogger profile picture updates] Then [Update my LinkedIn profile picture to match]
• If [My LinkedIn profile picture updates] Then [Update my Facebook profile picture to match]

Using these four recipes, whenever I update one profile picture, they will all update.

Also it's easy to turn recipes on and off - meaning that you can stop them working when necessary (such as if you want to use different profile pictures).

However there's limits to an IF THEN system, which is where a tool like Yahoo Pipes gets interesting.

Yahoo Pipes is a service used to take inputs, such as an RSS or data feed, webpage, spreadsheet or data from a database, manipulate, filter and combine them with other data and then provide an output with no programming knowledge.

This sounds a bit vague, so here's a basic example - say you wanted to aggregate all news related to Victoria released by Australian Government agencies in media releases.

To do this in Yahoo Pipes you'd fetch RSS feeds from the agencies you were interested in, 'sploosh' them together as a single file, filter out any releases that don't mention 'Victoria', then output what is left as an RSS feed.

Building a Yahoo Pipe (click to enlarge)

But that's getting ahead of ourselves a little... To the right is an image depicting how I did this with Yahoo Pipes.

Here's how it works...

First you'll need to go to pipes.yahoo.com and log in with a Yahoo account.

First I created a set of tools to fetch RSS from Australian Government agencies. These are the top five blue boxes. To create each I simply dragged the Fetch feed from the 'sources' section of the left-hand menu onto the main part of the screen and then pasted in each RSS feed URL into the text fields provided (drawing from the RSS list in Australia.gov.au).

Next, to combine these feeds, I used one of the 'operator' function from the left menu named Union. What this does is it allows you to combine separate functions into a single output file. To combine the Fetch feed RSS feeds all I needed to do was click on the bottom circle under each (their output circle) and drag the blue line to a top circle on the Union box (the input circle).

Then I created a Filter, also an 'operator' function and defined the three conditions I wanted to include in my final output - news items with 'Victoria', 'Victorian' or 'Melbourne'. All others get filtered out.  I linked the Filter's input circle to the Union's output circle, then linked the output from the Filter to the Pipe Output.

Then I tested the system worked by clicking on the blue header for each box and viewing their output in the Debugger window at bottom.

When satisfied it worked (and I did have to remove the filter condition 'Vic' as it picked up parts of words such as "service"), I saved my pipe using the top right save button, giving it the name 'Victoria RSS', then ran the pipe and published it at http://pipes.yahoo.com/pipes/pipe.info?_id=0392f5ec8f7450abbf650056c22f1e5d.

You can also see the output RSS feed at: http://pipes.yahoo.com/pipes/pipe.run?_id=0392f5ec8f7450abbf650056c22f1e5d&_render=rss

Note that pipes don't have to be published, you can keep them private. You can also publish their outputs as RSS feeds or as a web service (using JSON) for input into a different system. You can even get the results as a web badge for your site, by email, phone or as PHP for websites.

An IFTTT recipe built from the Yahoo Pipe above
(click to enlarge)

Alternatively you can even combine them with IFTTT - for example creating a recipe that sends you an email every time an Australian Government agency mentions Victoria in an media release.

In fact I created this recipe (in about 30 seconds) to demonstrate how easy it was. You can see it to the right, or go and access it at IFTTT at the recipe link: http://ifttt.com/recipes/43242

So that's how easy it now is to automate actions, or activities, online - with no IT skills, in a short time.

There's lots of simple, and complex, tasks that can be automated easily and quickly with a little creativity and imagination.

You can also go back and modify or turn your recipes and pipes on and off when needed, you can share them with others in your team or across agencies quickly and easily.

Have you a task you'd like to automate? 

• Finding mentions of your Department on Twitter or Facebok
• Tracking mentions of your program in the media releases of other agencies
• Archiving all your Tweets and Facebook statuses
• Receiving an SMS alert when the weather forecast is for rain (so you take your umbrella)
• Posting your Facebook updates, Blog posts and media releases automatically on Twitter spread throughout the day (using Buffer)

The sky's the limit!

2013 Free our data - a great presentation from Pia Waugh

Open Data advocate Pia Waugh spoke recently on the topic of freeing government data at Ignite Sydney 9 (an event where speakers get five minutes and 20 slides to say their piece).

It provides a strong view as to why governments need to open up data to the community and is definitely worth viewing and sharing.

2012 Why do agencies struggle with FOI and open data so much?

The linked email conversation (in a blog post), Freedom of Information Request for Classification Data, provides an interesting insight into the struggles government agencies are having with FOI and open data and with the difficulties applicants are having accessing data which should be available in reusable formats.

In this case information which is publicly available and searchable has been made less accessible by an agency in their site (breaking a site scraper). Then after the developer asks the agency for access to the data under FOI the agency (after several delays) offers to make it available for $4,000.

As far as can be determined from the information provided, the process for releasing the data - which is already in a database - simply requires a single SQL command.

The appearance is that the agency is being badly let down by its IT systems or staff - or that it is unwilling to provide the data.

Either situation is a sad reflection on the agency and on the commitment of the government to openness.

I'll keep tracking this request - as are also a number of people in the open data space - to see how it is resolved, and how long it takes to do so.

2012 OpenAustralia Hack(s)fest on FOI - for hackers, media, activists & FOI gurus

The OpenAustralia Foundation will be holding the first Australian Hack(s)fest as part of the countdown to the launch of their new FOI assistance site, designed to make it easier for ordinary Australians to put in FOI requests to Commonwealth agencies.

The event, being held in Sydney at Google's office, will be held on the weekend of 17-18 November.

For more details and to register, visit: www.openaustraliafoundation.org.au/2012/11/05/youre-invited-to-our-freedom-of-information-hacksfest/

Making APIs for government data - should agencies do this or leave it to third parties?

APIs (Application Programming Interfaces) are a technique for interacting with data (usually on the web) which liberates users from relying on particular applications or having to do complex programming to reuse the data in interesting ways.

Unfortunately few government agencies go the extra distance to release their data with an API, instead using specific data formats which require specific applications to access them.

This is a real shame, as APIs essentially makes data application free - great for accessibility and both easier and faster for any web user or website to reuse the data effectively.

It is often relatively easy for to create APIs from an agency's released data, as demonstrated by the Farmer Market API example from Code for America, which took less than an hour to convert from a spreadsheet into a map visualisation.

Agencies can certainly take the position that they don't want to do the extra work (however little it may be) to provide APIs for their public data and leave it up to third parties to do this - wherever and whenever they wish.

This is a choice, however, that comes with risks.

Where an agency simply 'dumps' data - in a PDF, CSV, Shapefile or other format online, whether via their site or via a central open data site - they are giving up control and introducing risk.

If a third party decides to create an API to make a dataset easier to access, reuse or mash-up, they could easily do so by downloading the dataset, doing various conversions and clean-ups and uploading it to an appropriate service to provide an API (per the Family Market API example).

Through this process the agency loses control over the data. The API and the data it draws on is not held on the agency's servers, or a place they can easily update. It may contain introduced (even inadvertent) errors. 

The agency cannot control the data's currency (through updates), which means that people using the third party API might be accessing (and relying on) old and out-dated data.

The agency even loses the ability to track how many people download or use the data, so they can't tell how popular it may be.

These risks can lead to all kinds of issues for agencies, from journalists publishing stories to people making financial decisions relying on out-dated government data. 

Agencies might see a particular dataset as not popular due to low traffic to it from users of their site, and thereby decide to cease publication of it - when in reality it is one of the most popular data sets they hold, hence a third party designed an API for it which is where all the users go to access it.

As a result of these risks agencies need to consider carefully whether they should - or should not - provide APIs themselves for the data they release.

Open data doesn't have to mean an agency loses control of the datasets it releases, but to retain control they need to actively consider the API question.

Do they make it easy for people to access and reuse their data directly, retaining more control over accuracy and currency, or do they allow a third party with an unknown agenda or capability to maintain it to do so?

Agency management should consider this choice carefully when releasing data, rather than automatically jumping to just releasing that CSV, PDF or Shapefile, or some other file type.

Victorian Government launches consultation on draft 'digital by design' ICT strategy

The Victorian Government has announced it is seeking public feedback on a proposed ICT strategy, Digital by design developed by the Victorian Information and Communications Advisory Committee (VICTAC).

The draft provides advice on the future management and use of ICT by government and how the Victorian Government can design and use information and technology to deliver better services.

The public consultation is for just over two weeks, finishing on 17 October.

The strategy sets out objectives and actions focused in three key areas and proposes eight principles to guide ICT decision making (per the chart below).

While not focused on Government 2.0, the draft strategy takes into account the increasing digitalisation of communications, expectations of citizens and the need to increasingly co-design and co-produce policy and service deliver programs and to design code for reuse, as well as the need to embed innovation within ICT and release more public data.

To learn more and to leave comments, visit www.vic.gov.au/ictstrategy/

Mapping open data site generations

Over the last three years we've seen an increasing level of sophistication and capabilities in successive generations of open data sites.

To aid governments in their open data journey, I've mapped five generations for the progressive development of open data sites, detailed in the document below.

Please feel free to reuse the information within the bounds of the embedded Creative Commons license.

My next task is to release a view of open data sites around the world mapped against these generations to provide a view as to who is leading and who is lagging in the open data stakes.

Standardising content across government (or why does every agency have a different privacy policy?)

Every government website serves a different purpose and a different audience, however there are also standard content every site must have and legislation and standardised policies they must follow.

This includes content such as a privacy policy, legal disclaimer,  terms of use, accessibility statement, copyright, social media channels, contact page, information publication (FOI) pages and so on. It also includes the navigational structure and internal ordering of pages and the web addresses to access this content (such as for 'about us' pages).

So is there a case to standardise the templates and/or content of these pages and where to find them in websites across government?

I think so.

From an audience perspective, there is a strong case to do so. Citizens often use multiple government websites and it makes their experience more streamlined and efficient if they can find what they need in a consistent place (such as www.agency.gov.au/privacy), written in a consistent format and, where possible, using identical or near identical language.

It would also save money and time. Rather than having to write and seek legal approval for the full page content (such as for privacy information), only agency-specific parts would need writing or approval. Websites could be established more rapidly using the standard content pages and lawyers could focus on higher value tasks.

To put a number on the current cost of individually creating standard, if you assume it cost, in time and effort, around $500 to develop a privacy policy and that there are around 941 government websites (according to Government's online info offensive a flop), it would have cost up to $470,500 for individual privacy policies for all sites. Multiple this by the number of potentially standardisable pages and the millions begin adding up.

Standardisation could even minimise legal risks. It removes a potential point of failure from agencies who are not resourced or have the expertise to create appropriate policies and expose themselves to greater risks - such as over poorly written legal disclaimers which leave them open to being sued by citizens.

In some cases it may be possible to use the same standard text, with a few optional inclusions or agency-specific variations - such as for privacy policies, disclaimers, accessibility statements, terms of use, and similar standard pages.

In other cases it won't be possible to use the same content (such as for 'about us' pages), however the location and structure of the page can be similar - still providing public benefits.

Let's take privacy policies specifically for a moment.There's incredible diversity of privacy policies across Australian Government websites, although they are all subject to the same legislation (the Privacy Act 1988) and largely cover the same topics (with some variation in detail).

While this is good for lawyers, who get to write or review these policies, it may not be as good for citizens - who need to contend with different policies when they seek to register for updates or services.

Many government privacy policies are reviewed rarely, due to time and resource constraints, which may place agencies at risk where the use of new tools (such as Youtube, Slideshare and Scribd) to embed or manipulate content within agency sites can expose users unknowingly to the privacy conditions of third party sites (see how we handled these in myregion's privacy policy with an extendable third party section).

So, how would government go about standardisation? Although effectively a single entity, the government functions as a group of agencies who set their own policies and manage their own risks.

With the existence and role of AGIMO, and the WebGuide, there is a central forum for providing model content to reflect the minimum standard agencies must meet. There are mandatory guidelines for agencies, such as for privacy, however limited guidance on how to meet it. A standard privacy policy could be included and promoted as a base for other agencies to work from, or even provided as an inclusion for sites who wanted to have a policy which was centrally maintained and auto-updated.

Alternatively web managers across government could work together, through a service such as GovDex, to create and maintain standard pages using a wiki-based approach. This would allow for a consistently improving standard and garner grassroots buy-in, plus leverage the skills of the most experienced web masters.

There's undoubtably other ways to move towards standardised pages, even simply within an agency, which itself can be a struggle for those with many websites and decentralised web management.


Regardless of the method selected, the case should receive consideration. Does government really need hundreds of versions of what is standard content, or only a few?


Examples of government privacy policies (spot the similarities and differences):

• http://health.gov.au/internet/main/publishing.nsf/Content/privacy_security.htm
• http://www.immi.gov.au/functional/privacy.htm
• http://www.ag.gov.au/Pages/Disclaimers/Privacystatement.aspx
• http://www.dpmc.gov.au/privacy.cfm
• http://daff.gov.au/about/privacy
• http://www.deewr.gov.au/Pages/Privacy.aspx
• http://www.centrelink.gov.au/internet/internet.nsf/legal/privacy.htm?OpenDocument&nav=footer

Participate in Melbourne Knowledge Week 2012

The City of Melbourne was recognised in 2012 as ‘Most Admired Knowledge City’ in an award from the World Capital Institute and Teleos, an independent management research firm.

The city is building on this with the annual Melbourne Knowledge Week, designed to engage both the knowledge community and the wider public in a range of events and opportunities that help promote Melbourne's identity as global knowledge city.

I reckon there has to be a place for Gov 2.0 in this mix and wanted to flag to all my Victorian readers that an expression of interest is now open to businesses, organisations, educational institutions, networking groups, community groups and individuals who wish to showcase knowledge-related projects, thinkers and capabilities as part of this year's event.

Melbourne Knowledge Week runs from 26 November to 1 December. More details on the event, and the expression of interest, are at http://www.melbourne.vic.gov.au/enterprisemelbourne/events/KnowledgeWeek/Pages/KnowledgeWeek.aspx

Patient Opinion launches in Australia

One of the UK's social media success stories, Patient Opinion, has now launched an Australian website at www.patientopinion.org.au.

Patient Opinion, which has been live since 2005, allows patients to rate and comment on their experience with health providers. It has been an amazing (if sometimes painful) success in the UK, leading to a number of care improvements across the health system and at individual providers.

Having worked in the area in government in Australia, I recognise the sensitivities that get raised around the idea of rating health providers, or allowing public comment on individual experiences, particularly from hospitals and health professionals.

However decisions are made every day by people based on their views and experiences - which product to buy or shop to visit. They are even made about health services in private conversations that health providers can neither see or address.

Patient Opinion makes patient views and experiences visible in a central and public way, allowing health providers with the ability to access and review - even respond - to comments. The site also provides a level of governance and safety through monitoring stories and comments to ensure they are not defamatory.

The approach allows health providers to view and address operational concerns and provides valuable insights for policy makers into the Australian health system which, after all, is supposed to maximise the outcomes for patients.

While fears of negativity are common amongst organisations and individuals when social media channels open, the Patient Opinion experience in the UK has been that there is a high level of positive feedback provided - people do have faith in many health providers.

A brief video about the site is below, and you can learn more about Patient Opinion in Australia at www.patientopinion.org.au/info/about