Final Report:HappyToastMobile

From Cs160-sp08

Jump to: navigation, search

Contents

Team Members

  • Benjamin Sussman made all setup screens. Helped Lita with hierarchy. Added shortcuts.
  • Lita Cho made the More list, and created the Rename and Delete functionality. Fixed the hierarchy problems and made Rooms disappear.
  • Roseanne Wincek made backgrounds, drawables, and figures. Wrote report and made slides.

Problem and Solution Overview

Home media centers are becoming increasingly complicated for both light and frequent users due to multiple devices requiring multiple controllers. The shear number of controllers necessary to manage a multi-component entertainment system can create “device clutter” in a users home. While there are commercially available universal remote controls, these can be expensive, difficult to program, and hard to use. Furthermore, the increasing number of programming options and content providers can discourage users from taking the time to find and schedule the programming they desire. This application has two overarching goals: ease of use and accessibility. The first goal focuses on a universal remote control that provides a consistent, easy-to-use interface across multiple devices. This remote can be formatted for multiple locations, enabling the user with a uniform interface wherever television is viewed. The second goal is to integrate real time program schedule information so that the user knows what is currently broadcasting regardless of the user’s present location. Program schedules can be personalized for each user, allowing them to mark favorites and set reminders.

Target User Group

BorgTV Target User Group
BorgTV Target User Group

Our target user group is composed of anyone who owns a mobile phone and watches television. In particular, users that will gain most from BorgTV are those who have multi-component home entertainment systems and those who watch TV at multiple locations: even just rooms in the same home. The basic level of technology/gadget competence necessary to operate BorgTV is rather low. Any user who is comfortable with a cell phone and a remote control should be able to use all of the features of BorgTV. However, there are small feature improvements designed for power users.

Tasks

The three representative tasks that demonstrate BorgTV are those that have been used for the entire semester. We, as a team, feel as though these tasks are good examples of the scope of the two major functionalities of BorgTV: Universal Remote Control and Interactive TV Guide. They demonstrate the key features that add value to BorgTV users: media device control, personal TV guide listings, and simple configuration of a universal remote.

Task 1: Basic Device Navigation and Operation

The first task corresponds to what is likely the most common BorgTV operation, device control. The user is asked to find a particular device and then perform some simple commands. The interesting things to look for -- outside of the test measures described below -- during this task are hot-key usage and understanding of the device hierarchy.

Task 2: Basic Guide Navigation and Operation

The second task also corresponds to a slightly less common, but just as useful, functionality. The user is asked to find a particular show in the TV guide and then set a reminder to watch that show at a later time. The important issues to look for during this task are symbol recognition (i.e. an understanding that three bells means recurring reminder, etc.) and navigation technique (whether or not the user discovers the page scrolling).

Task 3: Device Setup

The third task asks the user to set up a new device in a new location. As this is the most difficult task to perform using existing methods, it is important that the user experience is improved in order to validate the need for our application. Because the setup interface is much like a wizard, it is important to tune to the style that best helps users understand the process. This is best accomplished by listening carefully to users reactions to the various steps of setting up a new device.

Design Evolution

Design Iterations

First Borg TV Sketches
First Borg TV Sketches

BorgTV changed significantly throughout the design process. The first sketches of the application involved a much larger, candy bar phone. The earliest designs were based on a touch screen phone. When the group learned that such functionality would not be available, a major design overhaul was made and the focus was moved from touchable soft-key based remote skins to a combination of mapped 9 button and D-Pad screens.


  • Group Brainstorm
    When the group made the first sketches of the application, they were based on the larger, touch screen Android Phone. The earliest renderings involved using soft keys everywhere, as well as using the phones internal accelerometer to switch between remote and guide modes. While this initial sketch hardly resembles the final project presented here, some of the underlying features of BorgTV are present. These sketches have the major functionalities: universal remote control and interactive TV guide. Other features that were established at this stage were programming reminders and simple remote setup. Please see the group brainstorm for more figures of this design.






Touch Screen Design with QWERTY Phone
Touch Screen Design with QWERTY Phone
  • Contextual Inquiry
    After the group brainstorm assignment, we learned that we would be using the Android QWERTY keyboard phones, with a smaller screen. At this time, however, we still expected to be a touch screen based device. In this iteration, we designed skins to look like remote controls for each device. This design used a lot of menu navigation via the Android menu system. While the final project also looks nothing like this design iteration, there were features developed at this point that are part of the final design. This iteration has location hierarchy breadcrumbs on the screen. The setup scheme first seen here is extremely similar to that used throughout the semester. For more figures, please see the group's Contextual Inquiry.








  • Low Fidelity Prototype
    This prototype is the first design iteration that does not use a touch screen. This limitation was really quite difficult for the group, as we focused all previous designs around a touch screen phone. However, our overall design and interface was truly strengthened by this restriction. The lo-fi prototype was the first design iteration to use the 9-button and D-pad mapped screens, which really became the cornerstone of our interface. This was a major design change, however, it tested well with users, who found it intuitive. While the design continued to evolve from this point, the overall concept was cemented here. For more figures, please see our lo-fi prototype.
Lo-Fidelity 9 Button Screen
Lo-Fidelity 9 Button Screen
Lo-Fidelity D-Pad Screen
Lo-Fidelity D-Pad Screen
  • Interactive Prototype
    This prototype was the first design iteration done within Android. Since the lo-fi prototype tested so well with users, we decided to make this iteration an interactive version of that prototype. While the basic functionality was the same, the design was refined. Most of these improvements came from comments from tested users. In this design, the buttons on the 9 button screen became hotkeyed: users could use the phones numeric keypad to control these screens. Default rooms were implemented. A common comment tested users had was that the hierarchy was overly complicated and unnecessary. In the interactive prototype, when a new location is created, a default room is created and used until the user wants to have more than 1 room at a given location. Due to its interactive nature, this designed used “Toasts” quite often, to give the user feedback when completing tasks such as setting reminders and favorites on the TV guide. For more screenshots of this iteration, please see the interactive prototype.
Interactive 9 Button Screen with Hotkeys
Interactive 9 Button Screen with Hotkeys
Interactive D-Pad Screen
Interactive D-Pad Screen
Interactive TV Guide with Toast for Reminder Conformation
Interactive TV Guide with Toast for Reminder Conformation
Refined 9 Button Screen
Refined 9 Button Screen
  • Interactive Prototype 1.1
    After the interactive prototype presentations, we received a lot of great feedback from our classmates. While the overall design stayed the same (9-button/D-Pad screens), it was further refined from previous iteration. The button labeling became clearer. While previous versions had unconfigured buttons labeled as “New”, we changed these buttons to read “New Location”, “New Room”, and “New Device”. We thought this would aid in making the hierarchy more transparent and manageable for the user. We also colored the HotKey numbers to green and white to better reflect those on the physical phone. We thought that this would make the mapping more intuitive for users. We added page scrolling to the TV guide, for power users.

Major Changes

9-Button, D-Pad based Screens
This design choice was made after the group was not able to use touch screen phones. These screens became the basis of our overall design and were well received by users in both the lo-fi and pilot user studies.
Phasing Out of Hierarchy
At the beginning of this project, the application was based on a complex hierarchy. In order to use a device, the user had to indicated his location and a room within that location. For the interactive prototype, we decided to use a default room that was created upon new location creation. The default room was used until the user wanted to add a room. However, if a user was a at device screen (a screen with multiple devices to choose from) and pressed the back button, he was taken to a room screen with Default Room configured and New Room buttons. This was found to be confusing in our pilot studies. In the final version, room screens are not available to the user at all until the expressly try to configure a second room or there are multiple instances of the same device at the same location.

Evaluation Techniques

The evaluation techniques that were most valuable to the group were really any that involved testing the product with real users. The low fidelity prototype was probably the most fun and useful. This is where our major design overhaul took place. It was validating to see that users understood and liked our design choices. The paper prototype was fun to make, as was testing it together as a group. The feedback obtained from presenting the interactive prototype to the class and the pilot studies was invaluable. Getting ideas, comments, and reactions from people not associated with building or designing the application was extremely helpful. When you are working on something, it is easy to get caught up in the details and lose sight of the big picture - which is the first thing a user sees. Also, we quickly became BorgTV experts, and our intuition about how to navigate through the program is not similar to that of a user.

Final Interface

Functionality

The basic functionality is well demonstrated by the three tasks.

  • Task 1
    The easy task is to simply turn change the channel on an already configured television. In order to do this, a user chooses Ch/Vol from the TV function screen and then uses the D-Pad to change the channel.
TV Function Screen
TV Function Screen
D-Pad Device Control
D-Pad Device Control


  • Task 2
    The medium task is to set a reminder using the BorgTV Guide. In order to do this, the user opens the Guide, which is available from all hierarchy screens. The user then selects his future show and chooses the bell icon on the show’s information page. There is a feedback to let the user know that the reminder was successfully set. A reminder then goes off at the specified time and lets the user decide whether to watch the show, turn the television on, or ignore the reminder.
TV Guide Screen of Show For Which to Set Reminder
TV Guide Screen of Show For Which to Set Reminder
TV Guide Info Screen for Selected Program
TV Guide Info Screen for Selected Program
Toast Feedback Confirming Reminder Set
Toast Feedback Confirming Reminder Set
TV Guide Reminder
TV Guide Reminder
  • Task 3
    The difficult task is to set up a new location and device. Generally configuring universal remote controls can be very difficult. From the beginning, we strove to make this task much easier in BorgTV, but users still had problems with it. This iteration involved far more feedback than we had ever used before. There is feedback at almost every step of the setup. In order for a user to do this, he must go to the location screen and select a new location. He then names the new location and indicates the service provider. He then configures a new device, first by selecting the type of device and the brand. Then BorgTV tries different IR codes associated with the brand. When the correct code is found, the device turns off. Since there is no way for BorgTV to know if the device has turned off (since these devices generally do not emit IR codes), the user must tell BorgTV that it has turned off. This was always an area of confusion. Some suggested that we allow alternate ways to add devices, however unless we know the codes associated with that device, we cannot communicate with the device in any way. We discussed with users about potentially adding a list of all possible codes (showing them the enormous lists which accompany current universal remotes) and they unanimously agreed that reading through a list would be an inferior way and did not request it to be added as a feature. Below are screen shots of the many screen setup process.
Screenshots of the Entire Setup Procedure
Screenshots of the Entire Setup Procedure

Interface Design

Basic Device Screen
Basic Device Screen

The final iteration of this application is far more refined and has much more functionality than even the version shown to test users in the pilot study.

  • Hierarchy
While BorgTV is still built around a hierarchy, the final version tries to make this as easy as possible. We thought that overall, the hierarchy was important for super users, so we kept the hierarchy but do not make users interact with it unless they want to. The hierarchy allows users who want to configure multi component entertainment centers in two rooms in their home, for instance a bedroom and a living room, to do so. It also allows users to configure entertainment centers at completely different locations, for instance their home and the home of their parents. We strove to make this functionality available, but implemented default configurations for users that only want to control one or a few devices at one location. When a user opens BorgTV for the first time, they are immediately taken through the setup process. In earlier versions, the application opened for the first time to the location screen with only no configured locations. This first time setup involves the user naming their location and configuring a device, for example a TV. Now if a user never adds complexity to his personal hierarchy, every time he opens BorgTV, he is taken to a screen from which he can control that TV.



As was mentioned above, now rooms are only available to users when redundant devices are configured at the same location. For instance, if a user has a TV at his current location and tries to configure another TV, a device clash occurs and the user has the opportunity to make a new room.
New Room Setup When Device Clashes Occur
New Room Setup When Device Clashes Occur


In order to make the hierarchy more intuitive for the user, each type of screen was given a different background color. Now location screens are grey, room screens are green, device screens are brown, and function screens are purple. Also the cross motif backgrounds that were used before were replaced with highlighting of the corner buttons, as recommended by a classmate after the interactive prototype presentation.
BorgTV Background Colors
BorgTV Background Colors
Hierarchy screens now have menu options to allow users to rename or delete locations, rooms, or devices.


Menu Options in Hierarchy Screens
Menu Options in Hierarchy Screens













Users can also use hot keys whenever they are using device functions. For instance, if the user is in the channel changing D-Pad, they can still change the channel using the phone's number keys. There is toast feedback for this action.

Hotkey Toast Feedback
Hotkey Toast Feedback













Spinner While TV Guide is Loading
Spinner While TV Guide is Loading
  • Guide
Much of the guide has stayed the same from the last iteration, but some features were added to enhance usability. Since the TV listings XML file is rather large and take a long time to load, there is now a spinner to tell the user that this wait is expected.





Now users can scroll faster in time using the alt key and the D-Pad. The guide now has menu options. These options allow users to see a list view of shows marked as favorites or for which reminders were set. There is also search functionality that lets users search for programming by title.
TV Guide Menu Options
TV Guide Menu Options
TV Guide Search
TV Guide Search




  • Setup
Transparent Setup Dialogs
Transparent Setup Dialogs
The setup screens have now been configured to be transparent dialog boxes, so that the user can see from where they accessed the setup screen. This was done to again make the hierarchy more clear and easy to use.
The entire setup system has more toast feedbacks to aid users through this confusing process. Also, the setup procedure quits immediately after the correct code has been found.


Implementation

  • Hierarchy
Each level within the hierarchy was made as an Activity. First, the 5 editable buttons were initialized by their respective "New" names. Then the five cross button was populated by calling into the database and changing the text within that button. Every time I went into another level within the hierarchy, all the names of their parents must be passed until the root. So, to go to a device, room and location must be passed. This so that the breadcrumbs can be set within the title as well as query the database. The onActivityResult method was overwritten to send information to parents within the hierarchy-- such as new names, deletion and renaming a new item within the hierarchy. The Nine Button Menu Layout was changed to be bunch of Linear Layouts rather than an Absolute Layout in order to be more module.
When making our upgrades to our application, a lot of limitations of Android were found. How to send data within the application was very difficult to grasp. We didn't know if onActivityResult was able to handle multiple result codes or only if we were able to send one thing at a time. We discovered in order to send multiple results, a queue called ActivityPendingResults must be sent and set results within the query which is every hard to find. Another difficulty was hard coding all the shortcuts to the various signals. There was no way around that, all shortcuts were created manually. The main difficulty was making the code more modular. We know Android a lot better than when we created the first parts of the application, and we would have done a lot of things differently now. The main one would be combining all the levels of the hierarchy into one Activity.
  • Guide
Horizontal scrolling was a major issue creating the guide. There was plenty of Android support for vertically scrolling lists, however, there was no support for horizontal. While there are some hints at support with functions like "horizontalScrollBarEnabled", they don't actually do anything.We ended up using a list of custom views, each containing a gallery (the only horizontally scrolling widget in all of android). Each horizontal key event triggers all N of the galleries to scroll in that direction.
Automatic View manipulation was also very difficult to implement. A tremendous amount of time and difficulty was devoted to programmatically modifying views. Views aren't actually initialized until after onResume (after onPostResume, actually), any clever modification of views requires workarounds. For example, when loading screens, one cannot simply display a different layout until loading is complete, because the loading screen won't show if onCreate hasn't yet returned. Instead, we must launch a separate thread which loads the guide information and kills the loading dialog when it's done. Also, the default loading cursor is ridiculous. In the TV guide, the user can simply begin typing to start a search. The first character of the search is caught by the TV guide activity. The subsequent letters are caught by the search dialog. The issue is that if we initialize the search dialog to contain the letter typed in the guide, the cursor will be before the letter. So, if one type "Hello" in the guide, the search box will be filled with "elloH". I would just move the cursor position, but since the edit text isn't really created until long after onCreate, there is no way to automatically move the cursor. The workaround solution involves launching a separate thread which sets the cursor position after launch, but it must wait an arbitrary 50ms before doing so. So if the user types too fast, the search query gets all messed up. "Hello" might become "elolH".
  • Setup
One of the many difficult pieces of BorgTVs implementation involved allowing database access from multiple Activities. This is designed to be done using Android's ContentProvider framework, however this framework is not only excessively confusing but extremely bug prone. One of it's worst qualities in its design is that it forces both the ContentProvider designer and consumer to have a complete understanding of the backing database. It doesn't provide a clean abstraction for how the data is stored unlike other frameworks like Django or Microsoft's SQLServer Query objects in C#. Because we knew that this problem could cause confusion down the line, we wrote our database to use the URI to specify exactly what action we want, completely ignoring the "where" and "whereArgs" arguments. This allows Activities to consume the interface using static methods to create the appropriate URI. Whenever we need to do a database query, insert, delete or update, we call the respective method on the content provider with a URI created statically in the DataDefs class.


Features Left Unimplemented

When our team first brainstormed about BorgTV, there were two features about which we were very excited: program sharing and suggestions and GPS location selection. Neither of these features was implemented in the final version of the application, however. We envisioned that the TV guide would have features to allow users to suggest a program to contacts in their address book via text message or direct BorgTV message. We thought that this could be extended to allow users to invite their friends to watch a show at a future time, similar to a third party reminder. This feature was not included in the final version of the application since BorgTV is still running in the emulator and cannot yet interact with other Android phones. We, as a team, decided that our efforts would be best focused on the features associated with the basic tasks that could be best implemented in the emulator in its current state. The GPS feature was omitted for the same reason. Since Android phones will be equipped with GPS, we thought it would be neat if the phone could predict which location the user wanted or if a new location was necessary. However, since GPS was not functional on the emulator, we would have had to use wizard of oz techniques to implement this feature. Thus, GPS location selection was excluded in favor of manual location selection. However, in a production version of BorgTV, GPS location selection would be extremely helpful in streamlining the hierarchy – something that we strove to achieve manually.


Wizard Of Oz Techniques

The only true wizard of oz technique that was used in the final version of the application was device controlling IR codes. Not only did we not have access to these proprietary codes, the emulator is not capable of sending such codes. We emailed the instructors, and this technique was approved. In a commercial product, we would be able to license these codes from a provider for a fee.

Deliverables

Android Code

Happy Toast Mobile Borg TV

Final Presentation

Happy Toast Mobile Final Presentation (.zip)

Poster

Happy Toast Mobile Poster



[add comment]
Personal tools