Wednesday, 18 July 2012

York Council Spending Above £500


So. Jon happened to tweet a link to York Councils spending on items over £500. I couldn't believe it when they were a collection of PDFs. What the actual...

Having found the CSVs here,  I tried to import them into one single Google spreadsheet, but the import seemed to fail ( or run very, very slowly ) pulling in extra data.

So, I created a Google Fusion Table and that quickly whipped in the 6 files for this year. Then I could aggregate the sum of moneys spent and group them by supplier name. You can see the company data here... it looks like the picture below.



Interesting reading? Well, each item might need more explaining. The top two spends this year so far are the people organising new offices for the Council ( York Investors LLP £6,704,386) and Yorwaste Ltd £2,383,920 ( are these the people that empty our bins? ).


Next on the list is REDACTED - PERSONAL DATA £1,682,939 which I can only assume is spent REDACTED REDACTED etc HSBC REDACTED.


At number 11 is Streamline Taxis with a spend of £957,571.... this year! .... so far! Just imagine the size of that tip.


You can also view the data by expense category here. Did you know that "Other Agencies" get about £2 million of the Council's money? It just sounds sinister doesn't it? Other Agencies. 


I did want to visualize this data into a Treemap, but my Fusion Table knowledge is lacking, so if anyone can point me in the right direction I'd be grateful.



















Tuesday, 10 July 2012

Can You Use a Collaborative Inbox for an Enquiries Email Address?

Google Groups have added a few new flavours of group recently. As well as a regular Email List, you can now make a Web Forum, a Q&A Forum and a Collaborative Inbox - all slightly different takes on the same thing.

As part of the move to Google, one of the biggest challenges are  what we call "non personal email accounts", for those accounts like chemistry-enquiries@york.ac.uk. Traditionally the handling of these accounts was done by a number of people, all sharing the log in details. In a Google-ized world, having accounts that can't be audited is "not the done thing".

Our first trawl for non personal accounts found thousands of them. This included accounts for projects, conferences, departments, etc. With many of them, nobody knew who was replying ( or not ) to any enquiries.

Gmail has the ability to delegate access to your account to someone else, but this still doesn't solve the chemistry-enquiries@york.ac.uk problem. Essentially we need some accounts that nobody really owns ( maybe the department), that named administrators can administrate.

Collaborative Inboxes To The Rescue?

So, our initial look at the new Google Groups features suggested that the Collaborative Inbox feature was EXACTLY what we wanted for creating a chemistry-enquiries@york.ac.uk email address.



 

At this point it's worth pointing out that although there are four different types of Google Group you can create ( Email List, Web Forum,  Q&A Forum, Collaborative Inbox) that they are essentially ALL THE SAME THING but with a collection of settings and options tweaked in different ways. For example, I think the Web Forum defaults to have Tagging switched on and email delivery set to off. There is NO SUCH THING as a Web Forum in Google Groups really, it is just a collection of attributes that makes it more Web Forum-y than Email List-y.


This is a big problem. Given that there's no such thing as a Web Forum in Google Groups really, it'd be good to know what the difference is exactly between a Web Forum and a Q&A Forum. What get's switched on, what gets switched off? Is there anything you can't do in the other? Do they look the same?

I think the answer is that very little changes, with a Q&A Forum you get a "Mark This Post as Best Answer" button. That may be it as far as I can tell. But we could do with a matrix of features / Forum type so we know exactly what the differences are without having to create a group, get 5 people to populate it with discussion BEFORE we realise that feature X changes in Forum Type Y.


There are so many permissions, for membership, email delivery, moderation, posting that you'd think anything was possible. We certainly did.


And so, on to the need for chemistry-enquiries@york.ac.uk, an email address that prospective students, visiting lecturers, other departments might send any type of question that someone in the department might deal with. So we created a test Collaborative Inbox called Silly Questions, and hoped that people could post their silly question and receive a response from a team of members giving silly answers.

This sort of thing.




So Mike posted silly questions and I ( being one of the silly answerers ) posted answers. I marked questions I felt I'd answered with suitable silliness as "Completed". It was all working beautifully. I could even choose to respond as the group, rather than as me.


But here's the thing. Because of the way settings are organised. You can "allow posting by email" and make that available to all members of your organisation ( or even "Anyone") . Brilliant! That means you can publish the address and everybody can post to it.


BUT. Even though I replied to Mike's question, Mike doesn't receive my reply BECAUSE HE ISN'T A MEMBER OF THE GROUP.


The settings are wired so that if you are a member, you can both SEE and POST on other people's messages. This is exactly what a collaborative inbox isn't. I wouldn't expect my questions to be visible by everyone else... and definitely I wouldn't expect a reply from someone else who was only there because they, like me, were asking a question too. That'd be like getting a prescription from the person coughing next to you in the doctor's waiting room. 


It would seem that Collaborative Inbox is a mis noma. But then, all the nomas are mis... None of the Group Types really are the thing they say they are, they are just a bit more like the thing they say they are.


This isn't a pure technology failure, it's a failure of Google to communicate what their technology is and does. It's bad usability in that system understanding and affordance and expectation are all left dangling in a suck-it-and-see world. I'm not even sure I'm 100% right about all of this. And that's the problem.


Anyway, I don't think a Collaborative Inbox does what we need it to do. 


















Monday, 2 July 2012

When Is Just Enough is Too Much?

Recently I've been working on trying to create a Booking System using Google Spreadsheets, Apps Script and Google Calendars. And today, a request for a system stunningly similar came in, except this time, instead of being for booking hot desks, the bookable items are tape measures, cameras, radars, computers and exotic mystery items such as a "FM36 B". Lots of them.

The thing that strikes me about the similarity of the needs, is that already with the booking system, the relationship has more of the developer/client than I'd like. You could say I'm failing in managing expectations slightly. I'll get it back on track. Not that there's any problem, but there is this...

At what point is something software and no longer just a cool spreadsheet?

One of the really great things about spreadsheets is that they're almost agnostic about what you put in them. As soon as you start hanging interfaces off them, then the notion that perhaps you shouldn't be able to book a desk if someone else has already booked it ( sensible enough ) arises. 

Except that an administrator might want to quickly and easily unbook a desk if someone phones in sick, freeing the desk up for other users.

An administrator might simply want to block out a number of desks, which might be done by setting the background to grey. Simple.

These sorts of things are easy when "it's just a spreadsheet" but they quickly become another feature to get bugs / slow down /need an interface / need maintaining when what you are looking at is software ( rather than "just a spreadsheet" ). 

Finding the balance between the two is essential. What we need is a collection of people getting on doing great things with great tools, not the creation of another bottleneck of slightly less professional software development.

As our collective experience with AppsScript grows, we'll learn and develop approaches that we can share that people will be able add to their projects.