Ultimate Team FINGUTAS feat. Cap.Lyle (Radio Edit)

Summary

by Paris Buttfield-Addison

The idea of enhancing the way in which we interact with colleagues and friends (“the group”) on a daily basis –– beyond work –– using the ‘technologies of work’ inspired us to consider a frictionless, ‘calm’, system where the world in which the group live is presented, made available for interacting and interpreted/displayed to them in a way that allows them to make better use of their time in the group for non-work activities.

A lot of research has been conducted into the idea of improving agents for automated scheduling (e.g. Berry, Gervasio, Uribe, Myers and Nitz, 2004), and many attempts made (particularly in user-centred design-drive research) to create location-aware event planning mobile software (e.g. Pousman, Iachello, Fithian, Moghazy and Stasko, 2004). Our idea builds upon, and improves, intelligent agents of the past.

The implementation of Grok would consist of both a visible layer (the active interface) and an invisible layer (the invisible hand). A semantic natural language parsing system interprets the needs of the user and helps to formalise it into either a commonly use standard (for example, a calendar) or way of representing things (a map, or series of chat bubbles).

The views, integrated together, are:

Calendar view – schedules events like a normal calendar and adds all the appropriate information. This is easy for people to understand, because people already use calendars.
Maps view – users are tethered to event location and their trajectory/speed to arrive in time is shown.
Social view – bubbles that represent people and events are shown, and all communications related to the event are shown.

Designed to integrate with the “ambient data” of the areas around us, our system allows everyday people to meet up for work or play without requiring direct communication or the use of a formal, calendar-like tool. By understanding the context in which individuals are placed, for example “we should have coffee”, we take the next logical step –– integrating data from services such as Google Latitude, Foursquare or Find My Friends we know what venues (e.g. coffee shops) the users prefer, as well a suitable time (based, of course, on their preferred modes of transport and how long such transport takes) and then we arrange the meeting.

The system is based around Events, it creates, arranges and manages the events. People attend events and keep doing whatever they are currently doing, using the things they already like eg photo streams, dropbox, google docs. Grok just then shows everyone else at the event what people are currently doing and provides an easy way to view this data. Grok is designed to work with you, letting you use what you already like and just making it easily available, an unhindered interface to everyone.

The assistant not only adds the meeting to a commonly accessible medium but it also goes beyond the scope of scheduling and uses the users past preferences (possibly Foursquare or commonly met at places that do the same thing e.g. coffeeshops) to suggest a meeting place. Using services like open table (or equivalent magic checking) Grok can see how many tables are free at this place for the amount of people that are going and can advise other suitable venues if the initial suggested one is not suitable.

While Grok has the ability to connect and read/write with a number of cloud and social networking services, it is not dependant upon them to be used. Grok acts as an aggregator to link to and display information from cloud services that people already use in their everyday life, allowing users greater control over where their own data resides (similar to Oulasvirta, Raento and Tiita, 2005). In addition Grok will actually try and use the surrounding area intelligently, e.g. if a meeting is in a room with a Microsoft Surface or Smart Glass, or do the participants have Google Goggles? Grok will let people in the event know so they can use it. It will do the handshaking (e.g. Eagle, 2005).

There are a number of privacy considerations for Grok:

Where is the information stored? Where is it processed?
Who owns the information?
Can it complete self-audits, filtering based on what information has been sent to whom, so if something hasn’t gone as intended then the path the information took can be determined?
All elements of Grok should be option (i.e. location sharing, reading your social networks, monitoring and collecting things that are created the event).

While Grok will actually be mostly silent, hiding in the background, it will be the primary way of viewing, changing and accessing the shared info in the event once it’s actually underway. Some usage scenarios we’ve considered:

‘We need to meet sometime’ or ‘We should have coffee’ (and will take the next step).
It will know from previous services such as Find my Friends or FourSquare what venues the participants prefer and will organise for both of them a time that works based on distance and mode of travel for each participant.
This will be a seamless activity for the user after the initial conversation trigger.
It will use facilities like Open Table to check the availability of locations and will then offer the best alternative to the users only when necessary – the intention is the user does almost nothing!
The system can even offer to order the usual if it knows enough to do so.

The possibility to collect together information/data created from the event means that everyone can collaboratively collect the information and it is instantly shared between all the people that attended. This is zero config takes the barrier to entry out of the sharing service. For business meeting this has obvious advantages, but for things like events or holidays it also has great application.

To validate our concept in the short time available to us we chose “Wizard of Oz” prototyping –– initial interviews with members of the public allowed us to tweak and change the prototypes to suit, and as the idea solidified the fidelity of the prototypes got higher and higher until eventually we had a set of wireframes to test with.