Dave Thinking Aloud

Google Drive and User Interfaces

2014-08-20T13:42:00.002+12:00

I have explored a few ways of interacting with Google Drive files and folders for a simple document management system. The user-interface needs to present folders and files which represent real world artefacts (eg people , places). Business operations are initiated by the user making a selection on a folder or file name.

The Drive and Google Apps scripting features have developed over time and I have tried using

Google Apps Script UI Service
Google Apps Script HTMLService
Custom App called through the Google Drive interface
Google Drive Filepicker
Google Drive SDK through Javascript

For me, using the Google Drive SDK has proven the simplest to build into a responsive user interface and best performing for the user.

The UI Service approach provided an early introduction to interacting with Google Apps script but it is very limited in function and locks the user interface into the script. It carries all the overheads of generating the user interface at run time as well.

HTMLService does provide the familiarity of HTML/CSS/JS development but has limitations and performance impacts caused by CAJA.

Calling a Google Apps Script from the Google Drive user interface suits users who spend there time interacting with Drive directly but selection of action on folder/file becomes a multiclick operation and subsequent user interface has the limitations of HTMLService .

The filepicker provided for Google Drive is functional and has the advantage of being ready to use with good performance. However the pop-up iframe approach may not suit all design styles and customisation is limited. In particular, presenting the file/folder list initially random order slows down the user interaction.

The direct use of the Google Drive SDK has been simplified recently by improved documentation of the authorisation process. I took the quickstart example and built an html page of links from folder names corresponding to people of interest. It is then simple to incorporate this into a comprehensive user interface for the business user.

Performance and flexibility is the key for this approach. I get a few hundred folder references generate in 3 seconds and can then have a js expert work in there usual toolset to develop responsive bootstrap, jQuery or whatever interface style is required.

Modifed Quickstart example.

<html>

<head>

var CLIENT_ID = '70v406.apps.googleusercontent.com';

var SCOPES = 'https://www.googleapis.com/auth/drive';

/**

* Called when the client library is loaded to start the auth flow.

function handleClientLoad() {

console.log('handleClientLoad:'+new Date().getTime())

window.setTimeout(checkAuth, 1);

}

/**

* Check if the current user has authorized the application.

function checkAuth() {

console.log('CheckAuth:'+new Date().getTime())

gapi.auth.authorize(

{'client_id': CLIENT_ID, 'scope': SCOPES, 'immediate': true},

handleAuthResult);

}

/**

* Called when authorization server replies.

* @param {Object} authResult Authorization result.

function handleAuthResult(authResult) {

console.log('handleAuthResult:'+new Date().getTime())

var authButton = document.getElementById('authorizeButton');

authButton.style.display = 'none';

if (authResult && !authResult.error) {

// Access token has been successfully retrieved, requests can be sent to the API.

getItems();

} else {

// No access token could be retrieved, show the button to start the authorization flow.

authButton.style.display = 'block';

authButton.onclick = function() {

gapi.auth.authorize(

{'client_id': CLIENT_ID, 'scope': SCOPES, 'immediate': false},

handleAuthResult);

};

}

/* List folders based on a search

* specify the owning folder and mimetype = folder in the search parameter (q)

* set maxResults (can do paged calls if actual results exceed 1000)

function getItems() {

console.log('getItems:'+new Date().getTime())

var start = new Date();

var request = gapi.client.request({

'path': 'drive/v2/files',

'method': 'GET',

'params': {

'q': 'mimeType="application/vnd.google-apps.folder" and "0B90FGJizRd-gX25PTS1CTUF0eHM" in parents and trashed = false',

'maxResults': '400'

}

});

request.execute(listItems);

console.log("elapsed: "+(new Date()-start))

}

/* Sort the result returned from drive api into title order

* insert html paragraph for each title

function listItems(resp) {

console.log('listitems:'+new Date().getTime())

var start = new Date().getTime();

var result = resp.items.sort(function(a, b){

var nameA=a.title.toLowerCase(), nameB=b.title.toLowerCase()

if (nameA < nameB) //sort string ascending

return -1

if (nameA > nameB)

return 1

return 0 //default return value (no sorting)

});

console.log('items: '+result.length)

var i = 0;

var element = document.getElementById("div1"); // insertion point in html

for (i=0;i<result.length;i++) {

var para = document.createElement("p"); // create a link element in a para

var aref = document.createElement("a");

var node = document.createTextNode(result[i].title);

aref.setAttribute('href',result[i].alternateLink); // link to driver folder

aref.appendChild(node);

para.appendChild(aref);

element.appendChild(para);

}

console.log("elapsed: "+(new Date().getTime()-start));

}

</script>

</head>

<body>

</body>

</html>

Sharing Drive Folders with User Groups

2013-12-12T13:02:00.000+13:00

A little issue that has caused a day's worth of pain ...

If you share a folder with a Google Apps user group and, later, add a user to that group the new member will not see the folder or it’s content until that user explicitly follows a link to the folder. This issue (see here for a variant) is not confined to the Google Drive UI, it will occur in scripted access to the folder as well.

It is easy to make this a self-service function by publishing the link to the top level folder that is to be shared in a welcome to user/role page.

Keeping information within the domain

2013-11-17T18:03:00.003+13:00

Google Apps administrators have some useful controls and tools to track where documents are being shared. Often there is a fundamental policy about sharing outside the domain (for example, to limit exposure of privileged or private information).
An administrator can set up the Drive app to prevent sharing beyond the domain.
Note that this does not revoke existing shares! If you are closing off a loophole in your security, then you can discover the documents and files that have been shared publicly (beyond the domain) using a script or custom app like the General Audit Tool.
This also provides a means of enabling sharing of documents and files by exception. Keep the domain normally secured so that users cannot share outside the domain but open the gate briefly to share a document or folder publicly and then close it again. This is handy if you want to use Google Drive Hosting on an otherwise closed domain.

Document Manager on Google Apps

2013-10-15T11:28:00.000+13:00

I have put together some apps scripts , and conventional HTML/JS/jQuery web application to form a document management system for small business/non-profits. Because it uses the underlying access control of Google Apps, users can approach the managed documents either from the Google Drive interface or from the customised business interface.
The application implements organisation-wide business rules to files/documents stored within Google Drive. Essentially, it ensures that documents are named, shared and retained according to the enterprise rules for record and document management.
In the current implementation a particular business information entity type (eg Clients) has its access controlled by administrative divisions (eg Regions).
A nominal user (DocMan) is assigned ownership of all documents and regular users get access to the documents according to their membership of user groups. Effectively, the normal user asks DocMan to undertake administrative actions through the application.
The organisation can specify a fixed structure of folders and the name of the root folder. Access control is handled exclusively by the standard Google Apps Users, User-Groups and Sharing mechanisms.
The diagram below outlines the relationship between folders, documents, users and groups used with the Document Management Application.

Google Apps Script HtmlService Performance

2013-09-10T10:33:00.002+12:00

If you are moving to HtmlService from UiApp, you may encounter some performance issues. First look at the best practices. Hopefully that section will expand over time.
HtmlService introduces Caja to the mix for good or ill and the processing changes quite significantly.
To explore the performance issues around some design decisions, I developed a simple form for an upload to Google Drive. Looking forward to a time when form is as important as function, I chose to style with Twitter Bootstrap and use a bootstrap extension to style the file input component.

Simple input form

This means that, as well as the html, there a few .css and .js files to load.
Note that this example has no submit functionality coded, just the display and upload file selection.

I produced an Apps script that simply loaded the form, using bootstrap and jQuery from CDN and additional css and js from Google Drive hosting. Published as a web app here

function doGet() {
return HtmlService.createHtmlOutputFromFile('bootstrap').setSandboxMode(HtmlService.SandboxMode.NATIVE);
}

To provide a comparison with a hosted web site, I put the same html onto the Google Drive host, using the same .css and .js locations. Available here

The performance difference measured by Chrome at the desktop is quite startling. The Htmlservice script takes around 8seconds to display the form and a further 4seconds to complete loading the javascript files which make the form work. The Google Drive hosted version generally responded fully in 1.4seconds (with occasional outliers around 3.5seconds) which is not bad for a service intended for development rather than high performance service delivery.

A noticable feature of the HtmlService working is that the .js gets are sequential while the hosted version did them all in parallel.

[EDIT The results for the Htmlservice script were so bad that I explored possible workarounds. Putting the css and js files into the project and including them (as described in best practices) did improve the service time to 5-6 seconds. I could not get the jquery.min.js into the project ... the copy crashed in chrome. However, this approach does rather go against the simplicity of including the scripts from a CDN.]

From this, I shall be avoiding Htmlservice wherever possible. I do prefer the separation between presentation and Google Apps function that comes from JSON-P and Javascript.

Your milage may vary of course. I am seeing this in New Zealand at the end of an ADSL link.

Using Google Drive as an Entry Point for Google Script

2013-08-21T12:42:00.000+12:00

Scenario

We have a structured set of folders in Google Drive mapping to the organisation’s business functions. Think of the office filing cabinet.

There is a folder for each client. For control purposes and overall convenience, the clients are assigned to regional groups (folders again).

There are business operations that should be controlled to apply some records management auditability, and for which the user may require a guided path.

The documents on G Drive are essentially the business records (requests for action, review reports, closure etc) and form the usual source of information for staff working with the client. So if a staff member is working with a client, it is reasonable that they would be reviewing the records.

Scripting

There are several business actions that can be broadly visualised as a form entry, validation, response sequence. For example: Setting up a new client will require setting up a folder within the region folder; naming the folder; adding a structure of subfolders.

While we could maintain a database of clients and drive operations from that, the key data is actually in the base documents so we have chosen to script the business operations as functions of Drive itself. Our functions are create or open actions taken at the various folder levels in the structure and activated by a right click.

The Apps Script is built in 3 parts

Integration with G-Drive which handles the initial authorisation; token handling; and calling either the open or create functions. This is based on an introduction that +Arun Nagarajan put together and code samples from his team. A good startpoint is https://www.youtube.com/watch?v=R71oo-5NmPE. I have included my commented source below.
Open and Create. Each of these produce a menu of operation that the user can chose from. These scripts receive the state parameter from G-Drive interface which allows the folder or files selected to be identified.
Detail action scripts. These separate out the individual functions and simplify maintenance.

Source Code

/* Integration of Google Drive with the Actions of CCSLT Document Manager

*The interconnection with Drive is based on Arun's DRIVE SDK + GAS Presentation and code

*Refresh token logic has been added to give continuous use capability

*Handles the installation for the user (execute script with no params and authorise through OAuth2 conversation

// Globals used in api constructs

var AUTHORIZE_URL = 'https://accounts.google.com/o/oauth2/auth';

var TOKEN_URL = 'https://accounts.google.com/o/oauth2/token';

var REDIRECT_URL= ScriptApp.getService().getUrl(); // url of *this* script exec

var TOKENPROPERTYNAME = 'GOOGLE_OAUTH_TOKEN'; // access token valid until time expire or revoke by user

var REFRESHPROPERTYNAME = 'GOOGLE_OAUTH_REFRESH'; //oauth2 refresh token valid until revoked by user

var EXPIRYPROPERTYNAME = 'GOOGLE_OAUTH_EXPIRY' ; // expiry of oauth2 token time to do refresh!

// OAUTH2 data from API project - needs to be replaced if new project is created or project generates new secret/id

var CLIENT_ID = 'ghxcvhxcvhjdfshgjdsfahg';

var CLIENT_SECRET = 'fdsvvdfsh,gvsadhgfsdkj';

var DRIVE_API_URL = 'https://www.googleapis.com/drive/v2';

// maintain scope in step with changing application requirements

var SCOPE = 'https://www.googleapis.com/auth/drive.install https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/drive.metadata.readonly';

/* Main entry point

* functions depend on code and state parameters

* if state present ... app is installed

* createAction called from Google Drive when user selects DOCMAN app from type choice at CREATE menu state=create

* fileAction called from Google Drive when user selects DOCMAN app from type choice at file selection menu state otherwise

* if state not present then it is an installation and authorisation call

function doGet(e) {

var HTMLToOutput;

// business operations of Drive API send state parameter, authentication returns code, initialisation has no parameters

if(e.parameters.state){

var state = JSON.parse(e.parameters.state);

if(state.action === 'create'){

// called as a result of selection from CREATE menu of Google Drive user interface actually creates a UIApp

return createAction(state);

}

else {

// called as a result of selection from right click on file menu of Google Drive user interface

// HTMLToOutput=fileAction(state);

// return HtmlService.createHtmlOutput(HTMLToOutput)

return fileAction(state);

}

else if(e.parameters.code){//if we get "code" as a parameter in, then this is a callback from the install authorisation dance

getAndStoreAccessToken(e.parameters.code); // installer

HTMLToOutput = '<html><h1>App is installed, you can close this window now or navigate to your <a href="https://drive.google.com">Google Drive</a>.</h1></html>';

}

else {//we are starting from scratch or resetting (result of running the /exec of this script)

HTMLToOutput = "<html><h1>Install this App into your Google Drive!</h1><a href='"+getURLForAuthorization()+"'>click here to start</a></html>";

}

return HtmlService.createHtmlOutput(HTMLToOutput);

}

* first step of OAUTH2 dance to get an authorisation code

function getURLForAuthorization(){

return AUTHORIZE_URL + '?' +

'redirect_uri='+REDIRECT_URL +

'&response_type=code' +

'&client_id='+CLIENT_ID +

'&approval_prompt=force'+

'&scope=' + encodeURIComponent(SCOPE) +

'&access_type=offline';

}

* second step of OAUTH2 dance to exchange authorisation code for access key and refresh key

function getAndStoreAccessToken(code){

var payload = "client_id=" + CLIENT_ID

payload = payload + "&redirect_uri="+encodeURIComponent(REDIRECT_URL)

payload = payload + "&client_secret="+CLIENT_SECRET

payload = payload + "&code="+encodeURIComponent(code)

payload = payload + "&scope=&grant_type=authorization_code"

var parameters = {

'method' : 'post',

'contentType' : 'application/x-www-form-urlencoded',

'payload' : payload

};

var response = UrlFetchApp.fetch(TOKEN_URL,parameters).getContentText();

var tokenResponse = JSON.parse(response);

// store the access token for later retrieval

UserProperties.setProperty(TOKENPROPERTYNAME, tokenResponse.access_token);

// store the refresh token for use when access token expires

UserProperties.setProperty(REFRESHPROPERTYNAME, tokenResponse.refresh_token);

// store the expiry time to determine when access token expires (expiry is returned as seconds to go - converted to UTC time in msecs)

UserProperties.setProperty(EXPIRYPROPERTYNAME,tokenResponse.expires_in * 1000 +new Date().getTime());

}

* Handles the token refresh function of OAUTH2 using saved refresh token

function refreshAccessToken(){

var payload = 'client_id=' +CLIENT_ID+

'&client_secret='+CLIENT_SECRET+

'&refresh_token='+UserProperties.getProperty(REFRESHPROPERTYNAME)+

'&grant_type=refresh_token'

var parameters = {

'method' : 'post',

'contentType' : 'application/x-www-form-urlencoded',

'payload' : payload

};

var response = UrlFetchApp.fetch(TOKEN_URL,parameters).getContentText();

var tokenResponse = JSON.parse(response);

// store the token for later retrival - note refresh token does not expire

UserProperties.setProperty(TOKENPROPERTYNAME, tokenResponse.access_token);

UserProperties.setProperty(EXPIRYPROPERTYNAME,tokenResponse.expires_in * 1000 +new Date().getTime());

return tokenResponse.access_token

}

* Construct fetch options

function getUrlFetchOptions() {

return {'contentType' : 'application/json',

'headers' : {'Authorization' : 'Bearer ' + isTokenValid,

'Accept' : 'application/json'}};

}

* CHECK IF STORED token is valid, if not use refresh token to get new one

function isTokenValid() {

var now = new Date().getTime();

var storedToken = UserProperties.getProperty(TOKENPROPERTYNAME);

var storedRefresh = UserProperties.getProperty(REFRESHPROPERTYNAME);

var expiry = UserProperties.getProperty(EXPIRYPROPERTYNAME);

// if expired then refresh storedtoken

if (expiry<= now){

storedToken = refreshAccessToken();

}

return storedToken;

}

Getting Data into your HTML page from Google Apps

2013-07-22T10:09:00.001+12:00

In the scenario where the ‘data’ is in Google Apps (in a spreadsheet, ScriptDB, documents or being integrated from a number of sources in a script) it is worth considering breaking the presentation from the processing work and having a well defined interface between the two.

+Riël Notermans raised a question of how to get tables nicely from Google Apps into a web page. It is tempting to use the HTMLService within an apps script to respond directly to the request from a user with HTML. For me this has some downside factors:

The whole page is constructed server-side before being sent to the browser maximising latency
HTML build will follow “get Data” operations maximising service time
Changes to look and feel HTML have to be made in script increasing risk of introducing error with change
What you can do on the page is limited by HTMLService. So it may be impossible to incorporate an organisation wide look and feel (say using Bootstrap)
Difficult to reuse the ‘data service’ in other ways which either increases the development workload or constrains the end users to the delivered solution.
There is a performance impact from CAJA

Consider a common situation where the data is being presented as a 2-D array or table of information. We tend to incorporate some common behaviours into the display or user interface around this simple table concept. For example:

Paging and scrolling through rows and columns
Sorting by one or more columns
Searching within table (beyond visible elements)

Rather than build your own Google Apps Script to do these things even as a generic library, commercial shops are likely to standardise on existing tools like jQuery. Although jQuery is supported by GAS HTMLService , others, like Twitter Bootstrap, do not play nicely with GAS at present.

Following the best practice recommendation to load data asynchronously, the apparent performance of presenting large tables can be improved by getting the data in two or more passes. To delivery a default format jQuery DataTable, the HTMLService would incorporate a script like this.

/* Ready function */

$(document).ready(function(){

var runner = google.script.run.withFailureHandler(onFailure);

var runner2 = google.script.run.withFailureHandler(onFailure);

runner.withSuccessHandler(onSuccess).getData();

runner2.withSuccessHandler(onSuccess2).getData2();

});

/* function done when getData is successful */

var onSuccess = function(data){

var aDataSet = data.slice(1); // all except header

var head = []; // headers

data[0].forEach(function(e){

head.push({'sTitle': e});

});

/* jQuery DataTable insertion happens after data load*/

$('#demo').html( '<table cellpadding="0" cellspacing="0" border="0" class="display" id="example"></table>' );

$('#example').dataTable( {

"aaData": aDataSet,

"aoColumns": head

});

}

var onSuccess2 = function(data){

var aDataSet = data.slice(1); // all except header

/* jQuery DataTable refresh happens after 2nd (longer) data load*/

$('#example').dataTable().fnClearTable(); // clear existing

$('#example').dataTable().fnAddData(aDataSet); // reload full table

$('#example').dataTable().fnDraw();

}

/* function done if error in getdata */

var onFailure = function(err){

alert(err.message);

}

</script>

The GAS script has two callbacks, the first presents a useful amount of data (say the first page) so the user gets something to work with quickly and the second returns the whole table data. The table is built when the first call is successful and refreshed when the second is successful.

You can standardise on the datamodel used by the jQuery DataTables extension as the interface between presentation and web service layers or develop a generic table model (perhaps incorporating paging through a 3rd dimension of data) that can be mapped to the jQuery DataTable on the client-side script.

A better approach is to use the content service to return JSON-P which I explored here.

jQuery supports AJAX operations for getting data, (and sorting, paging etc. when server side processing is more appropriate - large tables, mobile devices)

GAS REST Server as calling user

2013-05-01T10:07:00.000+12:00

In this post Peter Bauer provides a proof of concept showing the use of Google Apps Script as a rest server where the ultimate work is done as originating user rather than the script owner as in my example.
Interesting test, but there is a risk that Google will decide this is not how things should be and stamp on it.

Trees in Google Apps Script II

2013-04-27T14:11:00.001+12:00

More learnings this week!

Don't try to work around deficiencies in Google products until you are desperate. After hacking a way through uncharted and untracked bush, you may find that Google has built a highway to your destination.
Technical documentation is really clear in hindsight - but then you do not need it.

In this post, I described a work around for the defective Tree widget in the Google Apps Script UI. I learnt a lot then. I am really pleased that the long outstanding issue 307 from 2010 has been fixed.

I have spent a lot of time trying to get OAUTH2 to work for me to enable the use of Google Drive as an entry point for my Google Apps Script based applications. Reviewing the documentation now, it is obvious - why did it seem so much greek even with the benefit of +Arun Nagarajan 's video and code?

I will provide some details of the Google Drive + Google Apps Script implementation and purpose in a future post. Basically, folders and files are business records of the core business operation and it is natural for a significant class of users to use an open or create operation on a folder to initiate a business operation. It also allows business rules to be applied to the records (which may be scanned letters) before they become part of the stored information base.

JSONP and Google Apps Script (Part2)

2013-04-13T15:58:00.001+12:00

In an earlier post, I explored the use of the Google Apps Script Content Service supplying data to a web page in an effort to provide a reasonable degree of separation between a service view of Google Apps and a presentation layer. There were also considerable side-benefits in performance and freeing up of the way the web page can be built.

HTML Service in GAS in comparatively slow delivering even a simple page.
Adding large libraries like JQUERY and DataTables introduces further delays server-side
In my simple use of DataTables, simply painting the screen first time was very slow

Following the documentation for the content service, I got to this dramatic warning.
Warning: Be very careful when using this JSONP technique in your scripts. Because it's possible for anyone to embed the script tag in their web page, you may be "tricked" into executing the script when you visit a malicious website, which can then capture the data returned. It's a best practice to make sure that your JSONP scripts are read-only and only return non-sensitive information.

The issue with JSONP is the exposure of script which can then be captured by a third party who may then induce an authorised user to load another page which includes the script and provides the third party with access to restricted data and controls. Note this does require an active attacker (information cannot accidentally leak).

With any information storage, you do have to consider the value and sensitivity of the information and the effort that a third party will go through to get it and match your response accordingly.

A simple method of providing assurance that the server is sending its data response to the right page (not some other party copy) involves a number of steps.

The request from the browser should contain a 'hard to guess' additional factor - a 'session key' used by the server script to verify the validity of the request in concert with the Google Account.
The session key is stored in a cookie on the local machine. The browser operation will prevent a page from a foreign site from obtaining cookies associated with your site.
Session key is generated by apps script and stored in a User Property.
The new session key is returned to the user by an alternate path (email, SMS, UIApp) and entered into the original web page to be stored in cookie.

This strategy should be sufficient to negate the exposure of the script that initiates the JSONP exchange. Of course, it does not protect against all other attacks.

Example apps script code

HTML Code

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" /><title>JQUERY DataTables Page Hosted in Google Drive with cookie for added security</title>
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="stylesheet" type="text/css" href="//ajax.aspnetcdn.com/ajax/jquery.dataTables/1.9.4/css/jquery.dataTables.css">
<script type="text/javascript" charset="utf8" src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.8.0.min.js"></script>
<script type="text/javascript" charset="utf8" src="//ajax.aspnetcdn.com/ajax/jquery.dataTables/1.9.4/jquery.dataTables.min.js"></script>
<script type="text/javascript" charset="utf8">$(document).ready(function() {
$('#demo').html( '<table cellpadding="0" cellspacing="0" border="0" class="display" id="example"></table>' );
var proxyJsonp = "https://script.google.com/a/macros/example.com/s/AKfylkjghffdvN2tXR6fo_c/exec";
var sessionparam = "session="+Cookies['ppkcookie1'];
$.getJSON(proxyJsonp + "?" +sessionparam + "&prefix=?", null, function(data) {$('#example').dataTable( {
"aaData": data.aaData ,
"aoColumns": data.aoColumns
} );
document.getElementById("user").innerHTML=data.user;});
} );</script>
<script type="text/javascript" src="cookies.js"></script>
<script type="text/javascript">function saveIt(name) {
var x = document.forms['cookieform'].cookievalue.value;
if (!x)
alert('Please fill in a value in the input box.');
else {
Cookies.create(name,x,7);
alert('Cookie created');
}
}</script>
</head>
<body>
<h1>JQUERY DataTables Page Hosted in Google Drive with cookie for added security</h1>
<div id="header">
</div>
<div id="content">
<h3>
<form name="cookieform" action="#"><p>
Session Code <input name="cookievalue" />
</p></form><p><a href="javascript:saveIt('ppkcookie1')" class="page">Save Session Code</a><br />
</h3>
</div>
<p>Session cookie contains a hard to guess value to be passed in request and validated at server</p>
<p>Data returns from Google Apps Script JSONP</p>
<p>Includes sorting, paging and filtering by default.</p>
<p id="user">User ???????</p>
<p>User must be logged on to Google Apps Account for this data table to appear (by design!) </p>
<p>Entire data table loaded in one hit.</p>
<div id="demo">This iss where the table goes</div></body>
</html>

Cookies usage was based on http://www.quirksmode.org/js/cookies.html

Making Use of Google Apps Data

2013-03-20T11:14:00.004+13:00

Google Apps provides a number of office productivity components - eg Drive , Document, Spreadsheet, Drawing and Calendar which are often seen as single purpose personal tools. Underlying these components are some useful data structures that can be used to assist the broader business processes.

For example, Calendar can be used not only to provide a personal reminder service but as the core of a job management system.

For Karen at the centre of busy removals business in Sydney, the calendar has become the tool of choice for keeping the team aware of what jobs are coming up, where they should be and when the trucks are earning money. A potential job comes in from a web site contact, phone call, mail or a chat in the street and can be pencilled in as an event for a date/time that does not conflict with other commitments of team resources. A document is created in the Google Drive “Jobs” folder. Geoff, as director of operations, can glance at the month ahead and see the committed and potential jobs. Since he is often out driving or finalising details with customer, it is handy that the calendar is just as visible on his I-Phone as in the office. Karen is also out and about with customers and needs to be able to see the resources available as she commits to a new job (perhaps moving the ‘pencilled-in’ time to a committed one that will allow the customer to meet completion schedule on a purchase).

When the job is committed, Karen completes a summary of the move in the calendar title and description. The detail documents (inventory, quote, property access etc) becomes part of the ever growing set of job information linked by the common event.

Geoff will be assigning people to the job (in calendar, simply by adding them as ‘guests’). Team members then relate to the jobs as for any calendar invitations (accept, decline, etc) and see their own workload in their calendars.

A jobs list provides a handy customised summary of the current working period by combining information from the calendar and the jobs folder. Visibility of detailed information is limited by the standard sharing protocols of Google Apps (for example, the quote may only be seen by the team leader, but the inventory might be available to all).

This works simply by a bit of office discipline:

Giving jobs an identifier and using that identifier when creating document file names and calendar events

Adding assigning people to jobs as guests in the calendar event

… and a bit of Google Apps Script to create a custom list from data in the calendar and data in the file names

If you want to leverage your standard office tools to enhance business processes in your organisation or project, drop me a line.

JSONP and Google Apps Script

2013-03-14T09:23:00.001+13:00

This follows my baby steps towards a web page populated with data from a table. See also part 2.

Having worked with the standard user interface of Google Apps Script, I felt that I was approaching a sensible limit of what could be delivered through it. Even a simple table view was going to require significant coding and ultimately maintenance. The close-coupling of application with presentation was also a concern for future changes to data, user interface and application logic.
Exploring the implications of moving to a conventional HTML page for the user interface, I chose to work with jQuery. There are other candidates like Angular JS.
A common issue is a table or grid of data (often sourced from a spreadsheet). Presenting this as part of the user interface was a suitable example of the interface issues.
jQuery has a DataTables plugin which would save a heap of styling, structuring and client handler coding that is needed when you write your own user interface. I also chose to make use of the Google Drive Hosting facility as an easy path to get a working set of web pages available without engaging with hosting services.
First I used a demo from DataTables to see the default table functionality from delivered from a web page on Google Drive Host. This is just a script executing in the browser on ready. The data is embedded in the script. The page is available here.

<script type="text/javascript" charset="utf8">
   $(document).ready(function() {
   $('#demo').html( '<table cellpadding="0" cellspacing="0" border="0" class="display" id="example"></table>' );
$('#example').dataTable( {
   "aaData": [
       /* Reduced data set */
       [ "Trident", "Internet Explorer 4.0", "Win 95+", 4, "X" ],
       [ "Trident", "Internet Explorer 5.0", "Win 95+", 5, "C" ],
       [ "Trident", "Internet Explorer 5.5", "Win 95+", 5.5, "A" ],
       [ "Trident", "Internet Explorer 6.0", "Win 98+", 6, "A" ],
       [ "Trident", "Internet Explorer 7.0", "Win XP SP2+", 7, "A" ],
       [ "Gecko", "Firefox 1.5", "Win 98+ / OSX.2+", 1.8, "A" ],
       [ "Gecko", "Firefox 2", "Win 98+ / OSX.2+", 1.8, "A" ],
       [ "Gecko", "Firefox 3", "Win 2k+ / OSX.3+", 1.9, "A" ],
       [ "Webkit", "Safari 1.2", "OSX.3", 125.5, "A" ],
       [ "Webkit", "Safari 1.3", "OSX.3", 312.8, "A" ],
       [ "Webkit", "Safari 2.0", "OSX.4+", 419.3, "A" ],
       [ "Webkit", "Safari 3.0", "OSX.4+", 522.1, "A" ]
   ] ,
   "aoColumns": [
       { "sTitle": "Engine" },
       { "sTitle": "Browser" },
       { "sTitle": "Platform" },
       { "sTitle": "Version", "sClass": "center" },
       {
               "sTitle": "Grade",
               "sClass": "center",
               "fnRender": function(obj) {
                       var sReturn = obj.aData[ obj.iDataColumn ];
                       if ( sReturn == "A" ) {
                               sReturn = "<b>A</b>";
                       }
                       return sReturn;
               }
       }
   ]
   } );
   } );
   </script>

The default table looked good enough to work with so I proceeded to linking the page to some application data. Since the DataTables feature can map to a 2D table like a spreadsheet, it seemed reasonable to use the object defining the table as the interface between application and presentation. A layout designer can simply think of the table in the UI as a box, filled on ready. The apps designer can add columns, sort specifications etc as appropriate.

The script was then required to get the data using a jQuery getJSON call. JSONP is required in the interface because of the cross domain.

<script type="text/javascript" charset="utf8">

  $(document).ready(function() {
  $('#demo').html( '<table cellpadding="0" cellspacing="0" border="0" class="display" id="example"></table>' );
  var proxyJsonp = "https://script.google.com/macros/s/AKfycbxqfgshdfgd2WmRQ4/exec";
  $.getJSON(proxyJsonp + "?prefix=?", null, function(data) {

   $('#example').dataTable( {
   "aaData": data.aaData ,
   "aoColumns": data.aoColumns
   } );
});
} );
</script>

The application side of the interface was supplied by an apps script using the content service.

function doGet(request) {
var result ={
   "aaData": [
    /* Reduced data set */
    [ "Trident", "Internet Explorer 4.0", "Win 95+", 4, "X" ],
    [ "Trident", "Internet Explorer 5.0", "Win 95+", 5, "C" ],

    [ "Webkit", "Safari 2.0", "OSX.4+", 419.3, "A" ],
    [ "Webkit", "Safari 3.0", "OSX.4+", 522.1, "A" ]
   ] ,
   "aoColumns": [
    { "sTitle": "Engine" },
    { "sTitle": "Browser" },
    { "sTitle": "Platform" },
    { "sTitle": "Version", "sClass": "center" },
    {
    "sTitle": "Grade",
    "sClass": "center",
    "fnRender": function(obj) {
    var sReturn = obj.aData[ obj.iDataColumn ];
    if ( sReturn == "A" ) {
    sReturn = "<b>A</b>";
    }
    return sReturn;
    }
    }
   ], "user":user
   };

return ContentService.createTextOutput(request.parameters.prefix + '(' + JSON.stringify(result) + ')')
   .setMimeType(ContentService.MimeType.JSON);
}

This produced a fairly responsive web page so I added real data from a spreadsheet by replacing the apps script.
function doGet(request) {
var sourceSpreadSheet = SpreadsheetApp.openById("0AthfgyjkfyzRQd00xRUE"); // ourPeople
var dataArray = sourceSpreadSheet.getDataRange().getValues();
var aadata = [];
var aoColumns = [];
var col = {};
var headers = dataArray[0];
// all except header
for ( var i=1;i<dataArray.length;i++) {
   aadata.push(dataArray[i]);
}
// headers
for (i=0;i<headers.length;i++) {
   col = { "sTitle": headers[i]};
   aoColumns.push(col);
}
var result ={
   "aaData": aadata,
   "aoColumns": aoColumns, "user":user
   };

return ContentService.createTextOutput(request.parameters.prefix + '(' + JSON.stringify(result) + ')')
   .setMimeType(ContentService.MimeType.JSON);
}

This code made the whole thing insensitive to number of columns. I published as available to users in my domain and it required users to be logged on their Google Apps account before returning table. As written, the web page just did not build the table if user not logged on.

So that was fairly painless thanks to the giants that had gone along similar paths (+Riël Notermans +keisuke oohashi). I didn’t have to worry about OAuth2, signon etc because it all happens under the covers.
However, I am now at this Warning!

Warning: Be very careful when using this JSONP technique in your scripts. Because it's possible for anyone to embed the script tag in their web page, you may be "tricked" into executing the script when you visit a malicious website, which can then capture the data returned. It's a best practice to make sure that your JSONP scripts are read-only and only return non-sensitive information.

Part 2 outlines a possible solution to this.

Break your own Google Apps security

2013-03-10T11:17:00.000+13:00

2-step verification for Google Apps is a must for those serious about protecting their account and all it contains.

MightyText is handy for getting SMS messages to and from your desk.

Doing

both

is not so smart. The 2-step verification sends an sms message to your registered phone number and MightyText will route that to your desktop browser where it pops up, conveniently for the opportunist with access to your machine.

Trees in Google Apps Script UI

2013-03-03T10:10:00.001+13:00

Trees in Google Apps Script

The tree widget in the Apps Script user interface presented me with a few issues. I persevered to get a solution that worked for me.

What did I want?
Tree element can be selected
Selection reflected by a change of style attributes (eg bold, red etc)
Selection of one element turns selection of previous element off
Take an action based on the selection made (a handler)
Tree Widget
Apps Script UI does provide a Tree widget and Google helpfully tells you it is based on GWT. I suspect that if you are an expert in GWT and its documentation you would not be using Apps Script.
Initially, I just set the tree branches to text with no widget (code below). This provided a standard indication that I had clicked (selected) the tree branch - a blue highlight. Unfortunately the selection handler that is fired, currently only tells you that the tree has been selected and not which branch or leaf. There is a long outstanding issue for this. EDIT 25/4/13. Now Fixed

function doGet() {
var start = new Date();
var app = UiApp.createApplication();
var target = app.createLabel().setId("target");
var panel = app.createAbsolutePanel();
// create tree
var selhandler = app.createServerHandler("selector").addCallbackElement(panel);
var tree = app.createTree().setAnimationEnabled(false).setId('FullTree').setTag("").addSelectionHandler(selhandler);
var handler = app.createServerHandler("selector").addCallbackElement(tree);
// build a tree
for (i=0;i<100;i++){
   var str = "label"+(i+1);
   var str1 = "item"+(i+1);
   // create level 1 branch
   var item1 = app.createTreeItem(”TEXT”).setId(str1).setState(true,true);
   // add level 2 branches to level 1
   addsub(app,item1,tree);
   // add level 1 branch to tree
   tree.addItem(item1);
}
panel.add(tree);
panel.add(target);
app.add(panel);
Logger.log("Elapsed:"+(new Date() - start));
return app;

}

Putting a label widget in the branches instead of the plain text allowed a click handler to be used. In the handler, parameter.source provides an indicator of the item clicked. But branch is no longer highlighted when selected so the user does not get feedback of what is selected.
At this point, I thought of setting the styling for selected/ not-selected myself. What was I thinking! You can use a client handler on click to set the attributes of the label widget when you click it. Unfortunately, client handlers do things to the source widget or statically named target widgets so you can’t remember the currently selected item and set its styling in a toggle action.
Back to the server handler then. Yes, if you have remembered the previous state, you can use the server handler to set the style accordingly. BUT, the only way that you can know the state in the server handler is to pass it via the parameters. This led me to the final problem, which was that the users would be able to click more than one widget faster than the server handler can deal with it. Multiple parallel server handlers are fired and the “previous state” is dependent on timing … instead of a toggle operation, the user interface can get multiple widgets marked as selected. The only way around this is to restyle all the widgets to the unselected state and then style the selected widget. To say this makes for an unresponsive interface is an understatement.

Solution
We need a widget that has built in “selected” behaviour and to put that in the tree. So use a radio button for each of the tree elements.

Highlighted (and filled button) when selected - fast, in browser, change
Exclusive selection built-in
Fires click handler for server action
Developer can change base style
  var label1 = app.createRadioButton("XOX",str).setId(str).setName("SameGroup").addClickHandler(handler).setTag(str).
   setStyleAttributes({'fontWeight':'bold','fontSize':'14pt', "color" : "black","fontFamily":"arial,sans-serif"});
Note that the name of each radio button has to be the same to put them into a common group for the toggle action to work.

Mixing User Information and Private Information in Google Apps Script

2013-02-13T12:57:00.000+13:00

Going back to real coding. Well Google Apps Script anyway:)
Google Apps Script presents a few hurdles to an application designer if you want to work in the users' context with information derived from your private documents or domain.I needed to work with

some information derived from a document within my protected Google Apps document store (document private to me, within a domain where sharing documents outside domain is forbidden)
the identity of user (may be outside domain but with a Google Account)

The identity of a user is available from Session.getActiveUser().getEmail() but this will fail in interesting ways unless the script is published to run under the user id of the user running the script.

The private document cannot be shared outside the domain, and in this particular case, access to the full document is restricted to one user within the domain. Scripted access to the information on the document must be done by a script published to run as that privileged user.

So we need two scripts that talk to each other. One doing the conversation with the user and one operating as me in the background. UrlFetchApp.fetch() provides the means for one script to call another with parameters. ContentService.createTextOutput() provides the means to set the response to a regular format like JSON or XML.

The following scripts demonstrate the mechanics.

1. The front end UI interaction with the users

function doGet() {

var app = UiApp.createApplication();

var email = Session.getActiveUser().getEmail();

var label = app.createLabel('Your email address is '+email);

app.add(label);

// get the private data object

var obj = callUserWithPermission(email);

Logger.log(JSON.stringify(obj));

// put out data originating from private world and data round tripped from user world to private world and back

var label2 = app.createLabel('App effective user was '+obj.available + " Originating user was " + obj.actual);

app.add(label2);

// Proceed with business on user side .... initial UI here

return app;

}

function callUserWithPermission(email) {

try {

// use the run as privileged user script

var response = UrlFetchApp.fetch("https://script.google.com/macros/s/AKfgfgfgmlxQXUP1OLr-BEs014S7b6gVxdhfdhfshdhfdVzM/exec?who="+encodeURIComponent(email));

var parsedResponse = JSON.parse(response.getContentText());

return parsedResponse;

}

catch(e) {

Logger.log("error "+JSON.stringify(e))

}

This script must be deployed so that it is run as the script user and available to anyone. It will insist on a Google Account login and acceptance by user of exposure of the email id.

2. The back end interaction with private domain documents

function doGet(e) {

// see content service simple example

// receive the info from "run as user" script as parameter "who"

try {

var app = UiApp.createApplication();

var effective = Session.getEffectiveUser().getEmail();

var result = {

available: effective,

actual: e.parameter.who

};

// DO the business function and add info to result

return ContentService.createTextOutput(JSON.stringify(result))

.setMimeType(ContentService.MimeType.JSON);

}

catch(ex) {

throw new Error("In testgetprivate doGet()"+ex.message)

}

This script must be deployed so that it is run as the script owner and available to anyone including anonymous users. This certainly should give you something to think about … this script can be run by anyone, from anywhere who knows the, admittedly difficult to guess, URI. Is the information returned very sensitive (not in my case)? Is the risk of exposure (very slight unless the developer leaves the source code lying around) balanced by the ease of implementation. Alternatives requires a whole authentication mechanism built into your app.

You may find that you cannot deploy a standalone script like this because of the "no sharing of documents beyond domain" restriction set up by administrator. In that case, put the script into a public site and deploy it from there.

Innovation Blackout

2012-06-27T12:55:00.001+12:00

In the Harvard Business Review Blog Evade an Innovation Blackout, Jordan Cohen points out the difficulty of engaging effort for new ideas when the people with the ability to develop those ideas are up to their asses in aligators.
In a financial downturn, the razor-gangs that decend on the organisation are a big inhibitor of necessary change at just the wrong time. Any innovation is seen as something to be avoided or delayed rather than embraced as a means of getting out of a failing operation.

Backup Google Apps II

2012-06-25T08:56:00.000+12:00

Continuing from Backup Google Apps , I have been taking a look at Backupify.
This product meets a key component of my disaster recovery scenario. I am assuming that the worst that can happen to a Google Account is that users and the administrator lose access to it and, perhaps through the action of a 'bad person', Google cannot be persuaded to restore the account access.
Backupify can be accessed through a login independently of Google Apps which provides an alternative route to the backups if the 'bad person' has locked users out of the primary google apps files. Documents and Mail can be downloaded from Backupify as an alternative to restoring to the apps account so there is a measure of comfort that if the worst happens there will be a recovery path.
However there are some fish-hooks...

Because Backupify is accessible from Google Apps single sign-on, this convenience would be available to the bad person who could then lock the legitimate user out of Backupify*.
To support the download capability, Backupify transforms the Google Apps documents (creating xls files for Google Apps spreadsheets for example). This has unfortunate side effects, as there is not a one-one relationship between Google documents and the MSOffice equivalent so the round trip will lose

any scripts developed in google apps spreadsheets
the effect of google functions in spreadsheets
charts in spreadsheets
external references to shared or published documents

So there still does not appear to be an equivalent in Google Apps of the conventional off-site backup that will allow a recovery of all information in a disaster situation.
Is losing access to the Google Account a scenario that should be considered? I can think of a few possible events. In no particular order of likelihood or Machiavellian complexity:

Side effect of law enforcement action in US (eg Megaupload)
Destructive action by a Google Apps super administrator
A 'bug' in Google Apps

[Update] * Backupify recognised the issue and responded (sensibly in my opinion)

Currently, we are looking to improve security with an extended identity verification that would allow you to regain access to your account faster in the case that this happened. We do not have this in the product now, but in the meantime if you want to send us a photo of your picture ID then we can store that internally and securely with your account. That way in the future is someone did gain unauthorized access to your Backupify account via Google Apps login and they changed the Backupify password that you set then we could work with you and use the photo ID that you sent to verify your true identity and get you access to your account again.

so we can expect there to be a process that could circumvent the issue of losing access to the backify account.

Backup of Google Apps

2012-06-13T16:26:00.001+12:00

I am looking at the need for backup and recovery capability for organisations that manage their information and operations through Google Apps.

Classically, backup for the unforeseen event comprises a resource remote from the primary information that can be used to support the business operations in the event of the non-availability of the primary source. Analysis of risk and impact of losses can be used to determine how long that you are able to do without the primary source and how much you should be prepared to pay for recovery within that time. Generally, only broad classifications of risk to the primary information is considered (destruction of data centre; denial of service etc).
In “cloud” services, we are buying a measure of protection of our information assets from the provider whether that is Google, Microsoft or Waikikamukau Data Services. The trust we can place in these organisations is related to their competence and also the size of the pain that the organisation will feel when your primary information is unavailable. For example, if Google reported that it could not recover from a failure of just one of its data centres, there would be a massive loss of confidence affecting the viability of the multibillion dollar company.
So we might safely assume that Google will be able to restore your account in event of a catastrophe in their domain, but user mishandling of information is another matter and firmly in the user’s court. For this the user needs a strategy to suit their needs for information assurance.

Implementing some form of backup for Google Apps will require one or more of

Maintaining an inhouse backup storage server to backup cloud based documents to local hard disk or another storage supplier like Amazon.
Use a 3rd party service like Backupify or Spanning to copy and restore Google Apps documents/files.
Something to confirm that your backup policy is adhered to

In the case of Spanning Backup there are a few issues to be aware of.

When a document is recovered it is a new Google Apps document. Any references to the original will not be replaced by the restore operation. This will affect Sites that link to Apps documents, shares of the original, and published documents.

When a shared document is recovered, the new document is retains the shares of the original but the ownership changes to the user that performed the restore.

When a restore is performed, a folder is created to contain the restored documents. This folder is treated like any other, including taking part in subsequent backup cycles. There are opportunities for confusion about which version of a document is which.

The backup can only be used to recover to Google Apps and not as a path to another service

There will be good reasons for these issues and the design fits well with organisations where the individual user is responsible for their own environment (like with a personal computer). However, those familiar with IT-managed filestore could be surprised, unpleasantly.

Privacy Watchdog with Teeth?

2012-06-04T19:37:00.002+12:00

Lets take computer privacy breaches seriously here in New Zealand. Give the Privacy Commission some teeth and send appropriate messages to the likes of ACC.
A recent case in the UK resulted in a significant fine being levied on a National Health Trust which failed to destroy sensitive data on 1000 hard disks before releasing them. More worrying was that they thought that they could contract out of the responsibility by using a 3rd party to facilitate the disposal.
Here in New Zealand, we get investigations but no sense that responsibility for the protection of sensitive data is sheeted home to senior management. The pressure on organisations that mishandle sensitive data is reduced by the requirement that the “complainant can show that they have suffered harm” rather than that there was a breach. Only “if the harm is significant, a complainant might be able to claim that they are entitled to compensation”. Note that there is no actual entitlement to compensation nor a means of making orders like that made in the UK case. The best we can hope for is a sound drubbing of the Minister by the the capital’s press but even that has been lacklustre.

Smart Meter Privacy

2012-05-16T09:29:00.000+12:00

John Udel has raised Smart Meters up the conciousness ladder in a timely post.

Smart meters are new. But we can’t afford to think that every new technology rewrites all the rules, requiring new legislation which, as we know, can never keep pace with innovation. Here’s a powerful simplifying rule: It’s your data. That’s the default. And you shouldn’t need to be a do-it-yourselfer to assert ownership. Even if you use a utility-supplied meter, as most people will, it’s still your data.

It's your data??? I am not sure that it is so simple. It is 'their' accounting record. The meter certainly reveals something about the occupier, which is not necessarily the other party to the power company contract, and there are certainly undesirable uses for the information - for example knowing that the house has a pattern of occupation.
There needs to be an auditable protocol for dealing with the handling of the broad swathe of surveillance data from smart power meters to smart parking and cctv but I don't think it starts with "It's my data"!
I am looking forward to the views of the NZ Privacy Commisioner on this. I would hope that some clear direction is given so that surveillance data which can be associated with individuals is treated in the same way as Personal Information and therefore covered by the privacy principles. Attaching some teeth to the principles would be good too, but one step at a time.

ICT Benchmarking NZ

2012-03-26T19:53:00.001+13:00

The Administrative & Support Services Benchmarking Report for the Financial Year 2010/11 is probably not going to make it into the best seller list and if you have to download it from the treasury web site you may experience for yourself what the prime minister was describing when he was quoted as “shocked” by the state of many government IT systems, which he says will need to be upgraded to improve public sector efficiency.
However, it is hard to see whether we should be appalled , content, or apathetic about the current spend of $980 million on ICT which represents nearly 57% of total government administration and support services costs.
We might expect a benchmark report to indicate some standard to be achieved but I searched in vain. $980m seems low when compared with the total expenditure of the NZ Government. The NZ Govt Treasury Web Site was down as I wrote this so I am relying on the 2011 budget forecast figure of $78,944.4 million. Actual spend was 70,450 million. So the ICT spend is about 1.3% of total spend. You can compare that with the profligate Brits who reported that the “average for the percentage of total revenue expenditure spent on ICT in central government departments is at least 5%”. They were not very happy about that but did note in a report of Public Administration Select Committee that “It is widely accepted that 3% is a benchmark of good practice in the private sector service industries for ICT spend as a percentage of total revenue expenditure. Socitm benchmarking in recent years has demonstrated that local government organisations spend consistently less than 3%”. The US federal govt spends about 2% of its 3.8 trillion expenditure on ICT.
So in benchmark terms are we spending too much or too little?
The emphasis on ICT being 57% of total government administration and support raises the same question. With pressure to cut public service numbers (the other main component of administration and support) we should be looking at increasing the proportion of the A&S cost that is taken up by ICT. But really is it a sensible benchmark factor?

Added actual NZ govt expenditure 9:24pm

Simulation not in the BPMS please

2011-05-12T10:28:00.002+12:00

The efforts of BPMS vendors to deliver simulation of processes have not been impressive ... even the best is more like a visualisation of the assumptions made in the process design rather than a model that can usefully explore the real world factors that may influence future process design.
Bruce Silver has been able to consider this from the perspective of the process designer and concludes , among other things, that "Simulation should not be embedded in a BPMS".
I agree and have argued before that the simulation should be handled by a dedicated simulation tool (after all these have been around longer than BPMS). see this post.
Fortunately we now have a formalised model of the business process in BPMN 2 that can be transformed into elements useful for a simulation engine. Similarly, the control blocks and flows that characterise a simulation model could be transformed into the starting point of a BPMN. The relationship between the simulation and the process model is 2-way.
Choose your BPMS toolset on its ability to delivery process design and implementation. Choose your simulation tool for its ability to support the analysis of the real world process under investigation.
Although I sympathise with Bruce's view that "Simulation should not require programming", there will be occasions when the complexity and value of the model will merit more effort and experience. I suggest that the ideal simulation tool should have full logic development capability (programming) in addition to a simple wiring diagram approach.

User Interface to BPM

2011-04-04T16:02:00.000+12:00

In Tips for the Business Process Developer - Human Interfaces to Business Processes, John Reynolds points out where the real work is in delivering a managed business process.... getting the appropriate attention of real people. Making it harder are the BPM suite providers who, in an attempt to grab the lion's share of the market claim to be providing a complete solution with hastily nailed on use transactions that take no account of how real people work - only what is needed by the BPM engine to get to its next bit of well-defined (read as simple) execution. What is needed is a well-defined interface - and John identifies the important stuff. For example ...

"To Do List" interfaces have three goals:

Make sure the participant knows what tasks they are responsible for

Make sure the participant knows when each task is due

Help the participant prioritize which task to work on next

That last bullet is (of course) the hard one to implement. ...

One trouble is that the implementation keeps getting left to the BPM guys. Equally bad is the suggestion that everything the important people in the business have to do is some mysterious "knowledge work" and knowing where you are in the production of business value is trivia. The big snags for everyone in the BPM implementation are

not everything, that people have to do, is controlled by the documented and managed business processes.
real people have different ways of visualising their 'to-dos' and delivering a one-size fits all mechanism is likely to be counter-productive

If we are to reduce the implementation cost of BPM we need a formal interface defined at the UI boundary and look at how the vast number of personal productivity tools can be used to but a familiar face to the interface. There are probably as many people who would react favorably to IM and Twitter-like presentation as those happy to log on a refresh a screen of activities awaiting action.