Thursday, 25 October 2012

Collaborative Inboxes Now Work!

Google Groups' different types of groups ( Web Forum, Email List and Collaborative Inbox and the other one ) do more to muddy the waters of understanding Google Groups than actually describe what it is they actually do. Anyway...

 I previously have blogged here that Collaborative Inboxes didn't work because in order to receive a reply to an enquiry - it meant that you had to be a member of a group - and therefore able to see everyone else's enquiries. This is the equivalent of group therapy for a clap clinic, in that as a question asker, you get to see everyone else's questions.

I was only now, just showing someone interested in using Collaborative Inboxes, that particular quirk when I discovered a "cc The original sender" checkbox which is by default checked. Yay!

This means you could now use Collaborative Inboxes for private issues, that get responses from the experts who are members in that group. AND fellow experts can see your response. AND the person who replies doesn't have to remember to make sure the person who asked the question in the first place gets a reply.

This is great and means that Collaborative Inboxes can be used for generic enquiry email addresses and responded to by a team of people - which is what they were supposed to be in the place.

Monday, 15 October 2012

Platform Dilemma ( UI Builder vs HTML application )

I'm currently working with the Chemistry dept. to help use Google Docs for recording students lab experiment marks.

It sounds simple enough until you find there are over 170 students in a year and there are at least 20 tests to be done, and the students get broken down into groups and rotated, and different people need to log different bits of information (that the student attended, their mark, that their mark has been agreed etc ). That's well over 2000 marks a year.... which in the scale of numbers isn't the biggest, I know, but that's not where the dilemma is.

Part of the problem is the different ways different people need to access creating the students marks but I'll come to that another day.

The dilemma is that, I have the need for a really simple to use interface for entering students' marks. I could either use the UI Builder built into AppsScript OR I could create an HTML application in AppsScript.

With an HTML application, it's a breeze to add jQuery ( a Javascript library ) which means I can lovely widgets such a calendar drop-downs or type-ahead scrolling ( where you start typing the students' name and it makes suggestions ) etc. jQuery really helps to make an interface user-friendly... and if you imagine that the lecturer may have to enter 30 at a time, you can see why it needs to be easy and quick.

With a UI Builder interface, there are fewer widgets available, but the Chemistry dept. themselves will ultimately be able to continue hacking anything I build as I work with them. It's very easy to just open up a UI Builder window and start adding things or moving them around whereas working with jQuery and HTML may be too big a leap into the geeky unknown.




Friday, 5 October 2012

The Day I Dropped Round The Security Guy's

After discovering that my direction of work for the Booking System was from a security perspective, deeply flawed, I thought that I could perhaps work around giving people access to the code by embedding a web application within a Google site. I thought this would be a big structural change, but it only took a few minutes. It looks like this.


There's a slightly different approach. Firstly the spreadsheet is embedded as view only. The spreadsheet is only used a visualisation of availability now - there's no direct manipulation of any data. 

Because, almost without thinking, I made the published web app a HTML based one, it meant that I could easily add jQuery and interface niceties like the date choosing dropdown (shown above).

Because all the code runs as me, and I've already authorized the code, the end user isn't presented with any awful dialogs. I make adding the booking something that the end user does, by hand themselves. You can pre-populate a Google Calendar new event form by hacking the url variables easily. Like this...



Conclusions?

Well, it's good to know that I have something that we can happily share around the university securely.

The disappointing aspects are that...

Google Spreadsheets don't seem to allow you separate the concepts of a "data editor" and a "code editor" in any useful way. That means, if you allow someone to add data, they can change the way that data gets added. The only way to "share" collaborative data is to cludge an awkward and ugly interface in the front of it. This means that, AppsScript is best used within a spreadsheet for individual ( or selected ) users... not in a collaborative scenario.

Whilst "jumping ship" into a HTML based web app, rather that using widgets in a Spreadsheet does add more complexity but also brings more control. I may end up not using the spreadsheet viewing gadget and build a table of bookings by scratch, one that can take direct manipulation to book multiple hot-desks across multiple days. I had wanted to leverage many of the spreadsheet's abilities, I now have to think of the spreadsheet as backend-data storage. I also have to grapple with jQuery to build a table as complex as a the spreadsheet shown above (with some cells coloured in). 

When working with the UI Builder, it isn't possible to have copy-and-pasteable UIs or share them amongst different spreadsheets. This makes for unmaintainable code, with each spreadsheet containing its own hand-crafted UI. Were UIs standalone objects, like AppsScripts are becoming, then they could at least be duplicated, or loaded and copied-n-pasted. 

Google's whole "Publish Your Apps Script" concept is flawed. Who would be daft enough to click the dialog that says, give this unknown author complete access to all my docs and emails? 

What All Of This Means

Over the last few months we've seen a lot of new developments from Google, many of them very welcome, but new developments are often very easy self-contained concepts... I would like to see a bit more depth and sophistication from Google in how the bits fit together, where the gaps are and where things could be smoother.

For example, the UI Builder components could include a date-picker surely? And what about type-ahead scrolling perhaps. And how about different classes for working with data, instead of SpreadsheetApp how about CodeAuthorSpreadsheetApp ( which can't read all the user's data  )? 

The feeling that I'm getting is that AppsScript ( and UI Builder widgets ) when used with spreadsheets is only useful for data that you own... and isn't appropriate for shared data... a web app front-end to working with shared data seems much more sensible ( but a fair bit more work ). It means that only the hot-desk admin team get to do the more complex things, but hey... it sort of makes sense.

Google really could do to take a look at HyperCard and make it work in AppsScript. It would solve a million problems ( yes, they're mostly all mine, but ... ).

My next challenge is to help develop a better way of storing students marks than the system that is currently used. This seems already to be breaking down into a spreadsheet with UI Builder widgets to do certain admin tasks and a web app for exam markers to record results. 

I'll let you know how I get on and share the code/files from the Booking System when I've got it running smoothly.