Majelika

Last month, we announced several new ways to customize Google Forms. As of this week, three of those options are also available in forms created from Apps Script — embedding YouTube videos, displaying a progress bar, and showing a custom message if a form isn’t accepting responses.

Adding a YouTube video is as simple as any other Google Forms operation in Apps Script — from the Form object, just call addVideoItem(), then setVideoUrl(youtubeUrl). Naturally, you can also control the video’s size, alignment, and so forth.

To show a progress bar, call setProgressBar(enabled). Don’t even need a second sentence to explain that one. The custom message for a form that isn’t accepting responses is similarly easy: setCustomClosedFormMessage(message), and you’re done.

Want to give it a try yourself? Copy and paste the sample code below into the script editor at script.google.com, then hit Run. When the script finishes, click View > Logs to grab the URL for your new form, or look for it in Google Drive.

function showNewFormsFeatures() {
  var form = FormApp.create(New Features in Google Forms);
  var url = form.getPublishedUrl();
  
  form.addVideoItem()
    .setVideoUrl(http://www.youtube.com/watch?v=38H7WpsTD0M);
  
  form.addMultipleChoiceItem()
    .setTitle(Look, a YouTube video! Is that cool, or what?)
    .setChoiceValues([Cool, What]);

  form.addPageBreakItem();
  
  form.addCheckboxItem()
    .setTitle(Progress bars are silly on one-page forms.)
    .setChoiceValues([Ah, that explains why the form has two pages.]);
  
  form.setProgressBar(true);

  form.setCustomClosedFormMessage(Too late — this form is closed. Sorry!);
  // form.setAcceptingResponses(false); // Uncomment to see custom message.

  Logger.log(Open this URL to see the form: %s, url);
}

Dan Lazin   profile | twitter Dan is a technical writer on the Developer Relations team for Google Apps Script. Before joining Google, he worked as video-game designer and newspaper reporter. He has bicycled through 17 countries.

Editor’s Note: This blog post is authored by Peldi Guilizzoni, from Balsamiq. As a user of Balsamiq myself, it was great to see them join as one of the first Drive apps! -- Steven Bazyl

Hi there! My name is Peldi and I am the founder of Balsamiq, a small group of passionate individuals who believe work should be fun and that lifes too short for bad software.

We make Balsamiq Mockups, a rapid wireframing tool that reproduces the experience of sketching interfaces on a whiteboard, but using your computer, so they’re easier to share, modify, and get honest feedback on. Mockups look like sketches, so stakeholders won’t get distracted by little details, and can focus on what’s important instead.

We sell Mockups as a Desktop application, a web application and as a plugin to a few different platforms. An iPad version is also in the works.

We believe that tools should adapt to the way people like to work, not the other way around. Thats why when Google Drive came out, we jumped at the chance to integrate Mockups with it. This is the story of how the integration happened.

First of all, a little disclaimer. Although my job these days is to be CEO and all that, I come from a programming background. I started coding at 12, worked at Macromedia/Adobe for 6 years as a programmer. Id say Im a pretty good programmer…just a bit rusty, ok? I realize that the decision to write the code for Mockups for Google Drive myself instead of asking one of Balsamiqs better programmers to do it might have been a bit foolish, but we really wanted to be a launch partner and the programmers were already busy with lots of other stuff, plus I didnt want to pass up on the chance to work on something cool after dinner for a while. ;) OK so now you know the background, lets get started.

Once I got access to the Google Drive API documentation and looked around a bit, I started by following the detailed "sample application" tutorial.

The sample was written in python, used OAuth, the Google API Console, and ran on Google App Engine, all technologies I hadnt been exposed to before.

Following along brought me back to my childhood days of copying programs line by line from PC Magazine, not really understanding what I was doing but loving it nonetheless. :)

The trickiest part was figuring out how OAuth worked: its a bit of a mess, but after you play with it a little and read a few docs, it starts making sense, stick with it, its the future! ;) Plus the downloadable sample app had hidden all that stuff in a neat little library, so you dont have to worry about it so much.

Setting up the sample application took around 2-3 hours, easy peasy. Once that was done, I just had to convert it to become Balsamiq Mockups for Google Drive. Because I had done this before for other platforms, this was finally something I was comfortable with doing. The bulk of our code is encapsulated into our Flash-based Mockups editor, so all I had to do was to write a few functions to show the editor to the user and set it up using our internal APIs. Then I had to repurpose the "open with" and "edit" APIs from the sample app to work with the Mockups editor. All and all, this took maybe a day of work. Yay!

Opening a Balsamiq Mockup file in Google Drive

Once the proof of concept was up, I started turning the code into a real app. I cleaned up the code, added some comments, created a code repository for it in our bazaar server, set up a staging environment (a parallel Google App Engine application and unpublished Chrome Web Store listing) and integrated the build and deployment into our Jenkins server.

One tricky bit worth mentioning about integrating with Jenkins: the Google App Engine deployment script appcfg.py asks for a password interactively, which is a problem if you want to deploy automatically. The solution was to use the echo pwd | appcfg.py trick found here.

After some more testing and refinements, shipping day came, Balsamiq Mockups for Google Drive was live.

Balsamiq Mockups on the Chrome Web Store

It was a very exciting day. Getting mentioned in the official Google blog was quite awesome. The only stressful moment came because for some reason my Google App Engine account was not set up for payments (I could have sworn I had done it in advance), so our app went over our bandwidth quota an hour after launch, resulting in people receiving a white blank screen instead of the app. Two people even gave us bad reviews because of it. Boo! :(

In the days that followed, things went pretty well. People started trying it out, and only a few bug reports came. One very useful Google App Engine feature is the "errors per second" chart in the dashboard, which gives you an insight on how your app is doing.

I noticed that we had a few errors, but couldnt figure out why. With the help of the docs and our main Developer Relations contact at Google, we narrowed them down to a couple of OAuth issues: one was that the library I was using didnt save the refresh_token properly, and another that had to do with sessions timing out when people use the editor for over an hour and then go to save their work.

Fixing these bugs took way longer than what I wanted, mostly due to the fact that Im a total OAuth and Python n00b.

After a few particularly frustrating bug hunting sessions, I decided to rewrite the backend to Java. The benefits of this approach are that a) we get static type checking and b) I can get help from some of our programmers since Java is a language were all already familiar with here.

Since by now the Java section of the Google Drive SDK website had been beefed up, the rewrite only took a day, and it felt awesome. Sorry python, I guess Im too old for you.

The hardest part of the java rewrite was the Jenkins integration, since the echo pwd trick doesnt work with the java version of appcfg. To get around that, I had to write an Expect script, based on this Fábio Uechi blog post. By the way, I would recommend reading the Expect README, it has an awesome 1995 retro feel to it.

Overall, integrating Balsamiq Mockups with Google Drive was a breeze. Google is a technology company employing some of the brightest people in our industry, and it shows. The APIs are clean and extremely well tested. The people at Google are very responsive whenever I have an issue and have been instrumental in making us successful.

While the application is still pretty young - we are working on adding support for Drive images, linking, symbols… - we are very happy with the results were getting already. The Drive application netted around $2,500 in its first full month of operation, and sales are growing fast.

Alright, back to coding for me, yay! :)

Peldi

Peldi Guilizzoni Giacomo Peldi Guilizzoni is the founder and CEO of Balsamiq, makers of Balsamiq Mockups. Balsamiq is a tiny, ten-person multi-million dollar company with offices in 4 cities around the World. A programmer turned entrepreneur, Peldi loves to learn and to share what he learns, be it via his blog, giving talks or mentoring other software startups. Follow him on Twitter @balsamiq.

Editor’s Note: Guest author David Fothergill works at QueryClick, a search-engine marketing company based in the UK. — Eric Koleda

Working in Paid Search account management, Ive often found tremendous wins from making reports more useful and efficient. Refining your analytics allows you to streamline your workflow, allowing more time for strategic and proactive thinking — and thats what were paid for, not endless number-crunching.

The integration between Google Analytics and Apps Script has opened up lots of opportunities for me to make life easier through automation. In a recent blog post on my agencys website, I outlined how an automated report can quickly “heatmap” conversion rate by time and day. The aim of the report is to provide actionable analysis to inform decisions on day-part bidding and budget strategies.

In that post, I introduce the concepts and provide the scripts, sheet, and instructions to allow anyone to generate the reports by hooking the scripts up to their own account. Once the initial sheet has been created, the script only requires the user to provide a Google Analytics profile number and a goal for which they want to generate heatmaps. In this post, we’ll break down the code a bit.

Querying the API

This is a slight amendment to the code that queries the Core Reporting API. Apart from customising the optArgs dimensions to use day and hour stats, I have modified it to use goal data from the active spreadsheet, because not all users will want to measure the same goals:

function getReportDataForProfile(ProfileId, goalNumber) {
  //take goal chosen on spreadsheet and select correct metric
  var tableId = ga: + ProfileId;
  if (goalNumber === eCommerce Trans.) {
    var goalId = ga:Transactions ;
  } else {
    var goalId = ga:goal + goalNumber + Completions;
  }
  // Continue as per example in google documentation ...
}

Pivoting the Data

Once we’ve brought the Google Analytics data into the spreadsheet in raw form, we use a pivot table to plot the hour of the day against the day of the week.

For this type of report, Id like to use conditional formatting to heatmap the data — but conditional formatting in Google Sheets is based on fixed values, whereas we want the thresholds to change based on cell values. However, thanks to the flexibility of scripts, I was able to achieve dynamic conditional formatting.

Conditional Formatting Using Scripts

The script needs to know the boundaries of our data, so I’ve set up several cells that display the maximums, minimums, and so forth. Once these were in place, the next step was to create a function that loops through the data and calculates the desired background color for each cell:

function formatting() {
  var sheet = SpreadsheetApp.getActiveSpreadsheet().
      getSheetByName(Heatmap);
  
  var range = sheet.getRange(B2:H25);
  range.setBackgroundColor(white);
  var values = range.getValues()
      
  //get boundaries values for conditional formatting
  var boundaries = sheet.getRange(B30:B35).getValues();

  //get range to heatmap
  var backgroundColours = range.getBackgroundColors();

  for (var i = 0; i < values.length; i++) {
    for (var j = 0; j < values[i].length; j++) {
      // Over 90%
      if (values[i][j] > boundaries[1][0]) {
        backgroundColours[i][j] = #f8696b;
      }
      // Between 80% and 90%
      if (values[i][j] < boundaries[1][0] 
          && values[i][j] >= boundaries[2][0])  {
        backgroundColours[i][j] = #fa9a9c;
      }
      // Between 60% and 80%
      if (values[i][j] < boundaries[2][0] 
          && values[i][j] >= boundaries[3][0])  {
        backgroundColours[i][j] = #fbbec1;
      }
      // Between 40% and 60%
      if (values[i][j] < boundaries[3][0] 
          && values[i][j] >= boundaries[4][0])  {
        backgroundColours[i][j] = #fcdde0;
      }
      // Between 20% and 40%
      if (values[i][j] < boundaries[4][0] 
          && values[i][j] >= boundaries[5][0])  {
        backgroundColours[i][j] = #ebf0f9;
      }
      // Less than 20%
      if (values[i][j] < boundaries[5][0])  {
        backgroundColours[i][j] = #dce5f3;
      }
    }
  }
  // set background colors as arranged above
  range.setBackgroundColors(backgroundColours);
}

Calling the functions based on the profile ID and goal number specified in the main sheet gives us a quick, actionable report that can easily be adapted for use across multiple accounts.

function generateHeatmap() {
  try {
    var profileId = SpreadsheetApp.getActiveSpreadsheet()
        .getSheetByName(Heatmap).getRange(4,10).getValue();
    var goalNumber = SpreadsheetApp.getActiveSpreadsheet()
        .getSheetByName(Heatmap).getRange(7,10).getValue();
    if (profileId === ) {
      Browser.msgBox(Please enter a valid Profile ID);
    } else {     
      var results = getReportDataForProfile(profileId, goalNumber);
      outputToSpreadsheet(results);
      formatting();
    }
  } catch(error) {
    Browser.msgBox(error.message);
  }
}

This was my first foray into the slick integration between the Core Reporting API and spreadsheets, but has proven a valuable test case for how effective it will be to roll this method of reporting into our daily process of managing accounts.

We have now started the next steps, which involves building out “client dashboards” that will allow account managers access to useful reports at the press of a button. This moves us toward the goal of minimizing the time gathering and collating data, freeing it up to add further value to client projects.

Editors Note: If youre interested in further scripting your AdWords accounts, take a look at AdWords Scripts, a version of Apps Script thats embedded right into the AdWords interface.

David Fothergill   profile | twitter | LinkedIn Guest author David Fothergill is a Project Director at the search marketing agency QueryClick, focusing on Paid Search and Conversion Optimisation. He has been working in the field for around 8 years and currently handles a range of clients for the company, in verticals ranging from fashion and retail through to industrial services.

Hey Tel Aviv developers!

We are organizing a hackathon focusing on Google Drive next week. If you’d like to learn more about the Google Drive SDK and have fun developing your first Google Drive application, join us there!

The event will take place at the Afeka Tel Aviv Academic College of Engineering. We’ll start with an introduction to the Google Drive SDK at 17:30 on Tuesday September 4th 2012 and the hackathon will run through the whole of the next day. We’ll also have some of the Android team to talk a bit about Android, so be sure to check that out. See the detailed agenda of this 2-day event.

Don’t forget to register and have a look at this document to help you prepare.

See you there!

Nicolas Garnier profile | twitter | events Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

Editor’s Note: Guest author Romain Vialard works at Revevol, an international service provider dedicated to Google Apps and other Cloud solutions. -- Arun Nagarajan

There are many tools available to help you manage a task list and Google Apps comes with its own simple Tasks app. But sometimes it is more convenient and collaborative to simply manage your task list in a shared spreadsheet. This spreadsheet can be a simple personal task list or a project-management interface that requires team-wide coordination.

Google Spreadsheets come with a set of notification rules that might come in handy. For example, you can be notified each time someone adds a new task to the list or each time the status of a task is updated. Furthermore, it is very easy add to add basic reminders through Apps Script with just a few lines of code:

function remindMe() {
  var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheets()[0];
  var data = sheet.getDataRange().getValues();
  for(var i = 1; i < data.length; i++){
    if(data[i][2] > new Date()){
      MailApp.sendEmail(message);
    }
  }
}

The simple remindMe function performs a standard JavaScript-based date comparison on every row and sends an email for tasks that are due. You can then schedule the remindMe function via a programmable trigger based on the settings.

This script is already available in the Script Gallery today. Try it out for yourself!

Once you have installed the script, you get a new menu option in the spreadsheet that opens a simple user interface to set the options you want. As a developer, you can extend this interface further to provide more options and capabilities.

Romain Vialard   profile | YouTube Romain Vialard is a Google Apps Change Management consultant at Revevol. Romain writes scripts to automate everyday tasks, add functionality and facilitate rapid adoption of cutting edge web infrastructures. As a Google Apps Script Top Contributor, he has also built many of the top scripts in the Apps Script Gallery, including the very popular Gmail Meter.

If your app needs to keep up with changes in Drive, whether to sync files, initiate workflows, or just keep users up to date with the latest info, you’re likely familiar with Drive’s changes feed. But periodic polling for changes has always required a delicate balance between resources and timeliness.

Now there’s a better way. With push notifications for the Drive API, periodic polling is no longer necessary. Your app can subscribe for changes to a user’s drive and get notified whenever changes occur.

Suppose your app is hosted on a server with my-host.com domain and push notifications should be delivered to an HTTPS web-hook https://my-host.com/notification:

  String subscriptionId = UUID.randomUUID().toString();
  Channel request = new Channel()
    .setId(subscriptionId)
    .setType("web_hook")
    .setAddress("https://my-host.com/notification");
  drive.changes().watch(request).execute();
 

As long as the subscription is active, Google Drive will trigger a web-hook callback at https://my-host.com/notification. The app can then query the change feed to catch up from the last synchronization point:

  changes = service.changes().list()
    .setStartChangeId(lastChangeId).execute();
 

If your app only needs to be notified about changes to a particular file or folder your app can watch just those files rather than the entire change feed.

If you are interested in using this new feature, please refer to the documentation at developers.google.com. You can see push notifications in action with the Push Notifications Playground and view the source at Github.

Steven Bazyl   profile | twitter Steve is a Developer Advocate for Google Drive and enjoys helping developers build better apps.

• Start the software testing process by analyzing requirements long before development. I object to the word “long” here. It implies that we do big requirements up front. It also more than implies a process smell - the long gap between anaylsis and implementation. Rather, let’s take a look at a story together as a team right before development begins on that story to analyze the requirements and create our tests before we start coding. Then, repeat for the next story.

• Integration testing (performed by IT) performed by the team.
• System testing (performed by professional testers) performed by the team.
• Acceptance testing (performed by business users) performed by the team.

• First let me state this: Automated testing can be extremely useful and can be a real time saver. But it can also turn out to be a very expensive and an invalid solution. I tried to find more some information from Ray on what he means by automated testing but couldn’t find any additional info despite the fact that he has written a few blog posts about automated testing. This statement is usually delivered by someone who has attempted and struggled with automated UI testing. Automated UI testing can be more difficult and more expensive, but Im not sure how it is an "invalid solution". However, automated service testing is comparably simple, not expensive, not invalid, and a consistent time saver. Automated UI testing can still be valuable, but the ratio of service to UI tests should be heavily weighted toward service testing IMO.

• If you like to be instantly popular, don’t become a software tester! You’ll find out that you are going to meet a great deal of resistance. It is very likely that you will end up being the sole defender of quality at a certain point. Other participants in the project will be tempted to go for the deadline, whatever the quality of the application is. This is one of the reasons the agile testing community preaches a whole team approach to quality. Being the sole defender of anything on a project is a problem. We want our teams to own the budget and schedule, not just the PM. We want our teams to own quality, not just the tester, etc.

Our newest set of APIs - Tasks, Calendar v3, Google+ to name a few - are supported by the Google APIs Discovery Service. The Google APIs Discovery service offers an interface that allows developers to programmatically get API metadata such as:

• A directory of supported APIs.
• A list of API resource schemas based on JSON Schema.
• A list of API methods and parameters for each method and their inline documentation.
• A list of available OAuth 2.0 scopes.

The APIs Discovery Service is especially useful when building developer tools, as you can use it to automatically generate certain features. For instance we are using the APIs Discovery Service in our client libraries and in our APIs Explorer but also to generate some of our online API reference.

Because the APIs Discovery Service is itself an API, you can use features such as partial response which is a way to get only the information you need. Let’s look at some of the useful information that is available using the APIs Discovery Service and the partial response feature.

List the supported APIs

You can get the list of all the APIs that are supported by the discovery service by sending a GET request to the following endpoint:

https://www.googleapis.com/discovery/v1/apis?fields=items(title,discoveryLink)

Which will return a JSON feed that looks like this:

{
    "items": [
        …
        {
            "title": "Google+ API",
            "discoveryLink": "./apis/plus/v1/rest"
        },
        {
            "title": "Tasks API",
            "discoveryLink": "./apis/tasks/v1/rest"
        },
        {
            "title": "Calendar API",
            "discoveryLink": "./apis/calendar/v3/rest"
        },
        …
    ]
}

Using the discoveryLink attribute in the resources part of the feed above you can access the discovery document of each API. This is where a lot of useful information about the API can be accessed.

Get the OAuth 2.0 scopes of an API

Using the API-specific endpoint you can easily get the OAuth 2.0 scopes available for that API. For example, here is how to get the scopes of the Google Tasks API:

https://www.googleapis.com/discovery/v1/apis/tasks/v1/rest?fields=auth(oauth2(scopes))

This method returns the JSON output shown below, which indicates that https://www.googleapis.com/auth/tasks and https://www.googleapis.com/auth/tasks.readonly are the two scopes associated with the Tasks API.

{
    "auth": {
        "oauth2": {
            "scopes": {
                "https://www.googleapis.com/auth/tasks": {
                    "description": "Manage your tasks"
                },
                "https://www.googleapis.com/auth/tasks.readonly": {
                    "description": "View your tasks"
                }
            }
        }
    }
}

Using requests of this type you could detect which APIs do not support OAuth 2.0. For example, the Translate API does not support OAuth 2.0, as it does not provide access to OAuth protected resources such as user data. Because of this, a GET request to the following endpoint:

https://www.googleapis.com/discovery/v1/apis/translate/v2/rest?fields=auth(oauth2(scopes))

Returns:

{}

Getting scopes required for an API’s endpoints and methods

Using the API-specific endpoints again, you can get the lists of operations and API endpoints, along with the scopes required to perform those operations. Here is an example querying that information for the Google Tasks API:

https://www.googleapis.com/discovery/v1/apis/tasks/v1/rest?fields=resources/*/methods(*(path,scopes,httpMethod))

Which returns:

{
    "resources": {
        "tasklists": {
            "methods": {
                "get": {
                    "path": "users/@me/lists/{tasklist}",                         
                    "httpMethod": "GET",
                    "scopes": [
                        "https://www.googleapis.com/auth/tasks",
                        "https://www.googleapis.com/auth/tasks.readonly"
                    ]
                },
                "insert": {
                    "path": "users/@me/lists",
                    "httpMethod": "POST",
                    "scopes": [
                        "https://www.googleapis.com/auth/tasks"
                    ]
                },
                …
            }
        },
        "tasks": {
            …
        }
    }
}

This tells you that to perform a POST request to the users/@me/lists endpoint (to insert a new task) you need to have been authorized with the scope https://www.googleapis.com/auth/tasks and that to be able to do a GET request to the users/@me/lists/{tasklist} endpoint you need to have been authorized with either of the two Google Tasks scopes.

You could use this to do some automatic discovery of the scopes you need to authorize to perform all the operations that your applications does.

You could also use this information to detect which operations and which endpoints you can access given a specific authorization token ( OAuth 2.0, OAuth 1.0 or Authsub token). First, use either the Authsub Token Info service or the OAuth 2.0 Token Info Service to determine which scopes your token has access to (see below); and then deduct from the feed above which endpoints and operations requires access to these scopes.

                        
[Access Token] -----(Token Info)----> [Scopes] -----(APIs Discovery)----> [Operations/API Endpoints]

Example of using the OAuth 2.0 Token Info service:

Request:

GET /oauth2/v1/tokeninfo?access_token= HTTP/1.1
Host: www.googleapis.com

Response:

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
…

{
    "issued_to": "1234567890.apps.googleusercontent.com",
    "audience": "1234567890.apps.googleusercontent.com",
    "scope": "https://www.google.com/m8/feeds/ 
              https://www.google.com/calendar/feeds/",
    "expires_in": 1038
}

There is a lot more you can do with the APIs Discovery Service so I invite you to have a deeper look at the documentation to find out more.

Nicolas Garnier profile | twitter | events Nicolas joined Google’s Developer Relations in 2008. Since then hes worked on commerce oriented products such as Google Checkout and Google Base. Currently, he is working on Google Apps with a focus on the Google Calendar API, the Google Contacts API, and the Tasks API. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

1. The ACA spreadsheet generates a Content Submission Form and any content submitted is routed to a selected approver.
2. The approver receives an email notification, which they can authorize or reject.
3. Once authorized, the ACA spreadsheet writes the new content into the target Site using Apps Script’s Sites services. The new content is then visible to anyone with view permissions in the target site.

Approver receives an email containing the submitted content

ACA Workflow Diagram

Posted by John Gale, Solution Developer, Appogee

Want to weigh in on this topic? Discuss on Buzz

Editors note: This post is cross-posted from the Google Developers Blog.

Mike Procopio profile Mike is a Software Engineer for Google Drive, focusing on all things Drive apps. He gets to leverage his passion for the developer and user experience by working on the next-generation APIs that help unleash Google Drive. Before joining Google in 2010, he was a machine learning researcher, and enjoys engaging in illuminating statistical discussions at every opportunity.

• Will anyone use it?
• Will anyone pay?
• Does anyone care?
• How will we make $?
• Can we build it?
• Do we understand the problem?
• Will this solve the problem?
• Will it perform adequately?
• Will it integrate with other applications successfully?
• Can we build this with the budget & schedule we have?
• What is the best architecture for this project?

"Cognitive fixation causes people to focus on other peoples ideas and are, inevitably, unable to come up with their own."

"If the goal is to come up with a bunch of unique ideas or solutions to problems, then the group should be split up so that individuals can come up with their own ideas and these ideas can later be combined with other members ideas."

"...a group session after an individual session might be the optimal brainstorming technique."

• http://www.businessinsider.com/brainstorming-team-building-effectiveness-2012-1
• http://onlinelibrary.wiley.com/doi/10.1002/acp.1699/pdf
• I was videoed by InfoQ talking about Silent Brainstorming at SDEC12. Watch the video here.

Weve held many Office Hours on Google+ Hangouts over the last two months, bringing together Google Apps developers from around the world along with Googlers to discuss the Apps APIs. Weve heard great feedback about these Office Hours from participants, so weve scheduled a few more in 2011.

General office hours (covering all Google Apps APIs):

• TODAY: December 8 @ 10:00am PST
• December 14 @ 1:30pm PST
• December 20 @ 12:00pm PST

Product-specific office hours:

• Google Apps Marketplace - December 12 @ 12:00pm PST

As we add more Office Hours in the new year, well post them on the events calendar, and announce them on @GoogleAppsDev and our personal Google+ profiles.

Hope you’ll hang out with us soon!

Ryan Boyd   profile | twitter | events Ryan is a Developer Advocate on the Google Apps team, helping businesses build applications integrated with Google Apps. Wearing both engineering and business development hats, youll find Ryan writing code and helping businesses get to market with integrated features.

Link to article (By Sheung-On Choy, Sin-Chun Ng, and Yiu-Chung Tsang)
"Software agents can act as teaching assistants for distance learning courses by monitoring and managing course activities

...A number of researchers have proposed the development of software agents in teaching and learning situations. Jafari conceptualized three types of software agents to assist teachers and students:

1. Digital Teaching Assistant - assists the human teacher in various teaching functions
2. Digital Tutor - helps students with specific learning needs
3. Digital Secretary - acts as a secretary to assist students and teachers with various logistical and administrative needs"

This paper discusses a successful software agent pilot implementation of the first type in four Open University of Hong Kong (OUHK) distance learning courses. The Digital Teaching Assistant carried out the following tasks:

• "Send alert e-mails to inactive students (those who have not accessed the course Web site for a long period of time). The course coordinator decides the length of the inactive period and instructs the software agent to send the alert e-mails based on the established time.
  Send e-mails to inform tutors about inactive students and advise tutors to have proactive consultation with those students.
• Send e-mail alerts to those students who have not downloaded a particular piece of course material or who have not read an important piece of course news since it was uploaded to the file server. This helps prevent students from missing information or forgetting to download an important item, such as an assignment file.
• Help the course coordinator keep track of students? progress, and send e-mails to the coordinator and tutors about those students whose performance is at a marginal level.
• Retrieve information from the course timetable and send reminder e-mails to students. For example, it might send a reminder to students five days before an assignment due date and one day before a face-to-face session.
• During the period when assignments are submitted, the agent will monitor the assignment submission status and send e-mails after the due date to those students who have not submitted the assignment. It will also inform the course coordinator and tutors about those students."

In general, these tasks consume a lot of human effort for unintelligent information retrieval and processing, and with an agent such as the one mentioned above a lot of time can be saved on routine tasks, and more time can be spent on more productive activities, such as facilitating a more engaging online learning environment and content development.

A lot of lessons can be learned from this excellent article . Also, with more creativity and research I suppose the software agent can do a lot more stuff to minimize all the routine time wasting stuff most lecturers or facilitators hate to do.

Where is my R&D software agent to do my routine stuff ?