Skip to content

3.2 UI and Functionality Development Process

Trevor Hunter edited this page Oct 30, 2016 · 1 revision

User Interface Development

Based upon the concept we assessed the form factor of the table. Initially, the table was to take a square form, however, due to technical constraints, our decision was to take the rectangular form and this hosted up to six users simultaneously. We conducted ethnographic studies to observe coffee shops to understand how people interact with each other as our primary research. As part of our secondary research, we looked at existing touch tables and its available interactions. Based on our research and given the context of use, we decided to feed off existing interactions that are familiar to users.

Building on that, we decided to have a touch and drag interaction to explore the earth interface to expand the explorative nature of earth and also in terms of the news interface, we came up with interactions such as rotate, scale and moving of cards. Imbibing these interactions made us consider 3 user interfaces for which we bodystormed and tested each instance.

UI Preliminary Development

From the three user interfaces we looked at, the first entailed a split view of twitter feeds versus news articles on the other side this was as per the initial concept. Post our testing session, feedback, and bodystorm, The issue with this UI was that this hampered users on polar opposites of the interface to access either news or twitter but not both together.

UI Main Interface

The second interface showcased six pockets across the table. This UI was cultivated to allow users easy access to both tweets and news articles at their seat. Through feedback, the issue with this interface was that it hampered the social nature of the table and assisted individual attributes more. Also, this did not promote conversations. Also, this interface gave out a very cluttered look, therefore, was scrapped.

UI Entry Interface

Based upon more contextual inquiries, and unstructured inquiries, the third interface we cultivated was more intuitive and free off twitter feeds. The purpose of this interface was to allow each user to interact with news feeds and equally participate in discussions. Also, the twitter feeds would pour into the interface as the news card is interacted with.

The components of the UI also have evolved with iterations with changes in the background images, card layouts, fluid flow of the elements in the UI, and interactions.

Finally, to set the context straight to new users, we set up a 30-second video prompt so that users can understand a clear context and associated interactions with it.

Core mechanics & Back end Development

There were three elements to processing this prototype:

  1. Touch interaction
  2. Unity back-end (C# that handles the result of the interaction)
  3. PHP on the server that handles requests

How it started off was attacking the touch interaction problem, as we required multiple interactions at the same time without them breaking each other.

At first, I looked into writing all these gestures myself, this took unacceptably long.

Exploring Touch Interactions

So I managed to find a code base for unity called TouchScript https://github.com/TouchScript/TouchScript/wiki this allowed all gestures to be fully functional without arduous coding sessions, although the way to setup this code base in different environments is not well documented.

Next came the C# back-end within unity, this was simple but the multi-touch functionality would break at random points during testing phases. This area was just a learning experience with Unity's methods.

Finally to the PHP, this needed a zone to be set up dailyplanet.uqcloud.net with public access on the front end. This part was solely for gathering Twitter data as the API I used for News (NewsAPI.org) was handled within our Unity's back-end.

Integrating front and back end

As an example request to our back end, it needs a Geocode (world position) and a search term, so "dailyplanet.uqcloud.net/search.php?term=hello&geocode=-21.654321,77.654321,200mi" is a valid request that would print the results for me to grab using a WWW method within Unity.

Clone this wiki locally