Collaborative Tools Project

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 pers...

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 a...

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 Goog...