FinalPrototype-Group:Group18

From Cs160-sp08

Jump to: navigation, search

Contents

Team Members and Roles

  • activity, XML, database
  • XML, layout, graphics, report, PowerPoint, poster
  • networking, database, activity

(Members of Group 18 - "C-x M-c M-butterfly")

Problem and solution overview

With the increasingly active schedules that people have today, users interact between their active schedules and the constant barrage of events and groups. People often try to organize activities with a mess of back-and-forth threads of emails and text messages, and sometimes proposed get-togethers fall apart when organizing occurs in such a haphazard and delayed manner. To alleviate this problem, our mobile application integrates a personal calendar system and an event management tool that helps users check their own daily routines against rapidly forming events. With this application, users can receive immediate feedback if an event's time or location changes, allowing them to manage their schedule with the most amount of time possible.

Target user group

This application is primarily geared towards professionals involved in collaborative work with colleagues on different schedules, oriented for both work and personal events. It caters to these users with active social calendars who will be able to manage their schedules with the device most widely carried around today - the mobile device - to prevent missing meets with their friends and colleagues. These busy bees hardly have the time in their lives to bother with the time-involved process of organizing together a multitude of contacts with entirely different free times. Thus, by targeting these people to join groups of fellow users with similar interests, our groups-oriented application saves them time by naturally sending invitations tailored to their interests.

Tasks

  1. The Easy
    • What: Check for new events in your groups.
    • Why: The user is not expected to add anything, so this is the place to discover any anomalies in the view-only tasks, which stand independent of the add/edit-oriented tasks.
    • How:
    1. Use down D-pad key on the groups list screen [the first screen] to scroll through the groups that the user is already in. Groups that have new events have a bright red notice next to them, indicating new groups that the user hasn't seen.
  2. The Medium
    • What: Look up your schedule for the day to see if you can add a new personal event, and add a new personal event accordingly.
    • Why: The personal calendar was integrated into the groups list to streamline our application and remove the concept of having two "modes". This task allows us to see if the user could still manage to find the personal calendar when it is linked to by a button on the Groups List screen. It also forced the user into the months mode, which linked then into the day mode. This task allows us to measure the efficiency loss that comes out forcing the user into these 2 modes, rather than giving them a choice of the month, week, and day mode that we originally planned.
    • How:
    1. Start at home screen (can access this by hitting menu button (physical one)).
    2. Hit "Day Planner" button.
    3. When the date picker floats over, select today's date from the calendar.
    4. Once the day's list of events appears, select "Add Event".
  3. The Hard
    • What: Create a group, and then add a new event to that group. Afterwards, invite a member to the group.
    • Why: This will be the stress test for our navigation system, as the user will be moving in and out of the general groups list page to perform a variety of connected tasks, from creation of groups to the events subset, to the members subset. The sequential nature of this task requires successful completion of the preceding tasks as a prerequisite, allowing users to experience the entirety of the system in a fluid manner.
    • How:
    1. Start at the home screen if not already there.
    2. Click "Create a group" button
    3. Fill out the form, and hit "save".
    4. Once in the groups list, select that group from the list.
    5. Once in the group's events screen, click "Add New Event" button.
    6. Fill out the form, and hit "save".
    7. Repeat for adding a new member.

Design Evolution

UI Evolution: Sketches, Low-Fi, and Pilot Usability

  • The navigational structure of our application has slimmed down and simplified since the first twin flowcharts plotting our original vision of a clearly defined split between the personal and shared group-oriented side of the planner. The merging of compacted versions of the two sides reflected our shift towards tighter integration and a clearer single goal.
  • We departed from the default grey hatched background and bulky silver widgets of the default Android look to establish our own unified look with softer shades of white and gray to remedy the otherwise stark, harsh color contrasts of the default Android offering.
  • Color coding hinted at types of behavior of widgets, with green for saving actions, RSVP-ing, and other go/constructive actions, while pink and red shades signaled cancellations and removals. Orange and golden shades meant slowing down, such as with the option to decide later. More recent stages saw the propagation of the color coding across the rest of the interface, such as the continued theme of green for creating a group, and the sun-like yellow of the day planner.
  • Form-filling screens now display error status bars to prevent empty form fields, and to facilitate proper form entry. These bars sit fixed at the bottom of the screen, ready to display warnings.
  • Floating popups appear after adding items such as new events or members to display confirmation feedback that a member or event as added.
  • The group profile's images were originally single fixed images, but later iterations involved a spinner and ultimately a selection of images that would be scaled downward to fit more nicely with the interface.
  • Status messages on blank pages with no groups or events were added in the most recent stages of this development time, as to both utilize space wisely and eliminate user confusion about blank screens where they have not added any items of their own.
  • Left-right bars have evolved from button-looking buttons to overly subtle image bars meant to hint at using the navigational D-pad. After the interactive prototype user feedback, they were made slightly less subtle again, as they had vanished too much into the background to be noticed.

Major UI Changes

  • "Add New Event" dates pickers
  • This page type was done primarily using EditText widgets in early revisions because we found that it would be both easier to control on our development end, and because it was our early solution to creating a layout of widgets on limited screen space using tight positioning of widgets with the right alignment and spacing to achieve this feel without clutter. We have changed these to DatePicker and TimePicker widgets due to their ease of use, and the level of visual feedback that they provide to the users.
Image:g_addeventtimepick.png Image:Toastaddevent.png
  • Feedback from fellow developers during our high-fidelity demo suggested that they were expecting something more distinguishing like a DatePicker and TimePicker. After exploring pickers built on the page itself to reduce the number of clicks, we decided to use set date and set time buttons to trigger the pickers in a prompt floating over the screen, hence allowing us to free up whitespace with the labels now within the button themselves. (Fig. 6a and 6b). Like the pickers, we added error status bar during the pilot study stage in response to feedback in the high-fidelity stage about the EditText fields not preventing impossible entries like a 13th month after December.
  • "Add Group / Invitations" text labels in the list view
  • During our low-fidelity prototyping, we made "Add New Group" look like an ordinary itemized group in the list at the very top of that list. (Fig. 1a and 1b). That way, the task of adding a new group would feel like creating a group on the spot from a "blank" group list item, much as Internet Explorer 7 uses a blank tab alongside the existing tabs as a way to start a new tab. As it turned out, we found less control over Android's ListView than we had hoped, so by the time we had reached the interactive prototype, we had split the screen layout into a scrolling list below and a fixed row of buttons above - including Create Group and View Invites. We propagated this layout across the rest of the pages, such as the events and member lists, in order to maintain a uniform look to take advantage of familiarity with the first page.
  • Physical keypad menu trim
  • The menu played a larger role during the initial stages of our development, particularly during the low-fidelity prototyping because of the two-prong nature of the navigational hierarchy at that time. Half of the menu was to be dedicated to a mode switcher between the two modes - personal calendar and group event planning. When the page navigational structure simplified into one branch towards the interactive prototype and pilot study stages, we further brainstormed how best to use the menu. Our team elected to only use the keypad menu minimally, for quick access to the distinct core sections - the groups list home, the events search, and the personal month planner. Task-oriented functions would stay off this navigation-oriented menu, as we did not want those functions to be hidden from view in this menu.
  • Same-level navigational hierarchy D-pad left/right hints
  • Our application's original hierarchy of page navigation involved two points that branched off into three subsections side-by-side on the same hierarchical level - personal calendar into day/week/month, and the groups list into group events/members/profile. Narrow buttons on the left and right edges of the screen allowed users to hit the D-pad left/right keys to the far left and right to access the neighboring subsection. By emphasizing the relationship between the subsections, we intended to offer visual cues of how to access these relevant pages.
Group Profile Group Events Group Members
Image:g_profilefinal.png Image:g_eventsfinal.png Image:g_membersfinal.png


  • During the interactive prototyping, we moved away from using actual widget buttons for these left and right strips, and made those strip images considerably more subtle to prevent users from confusing them for buttons. Our pilot study results, however, revealed that we had made them so low-profile that users were delayed in noticing them when they needed those cues. We switched off the bar concept completely, and altered the graphics to give the page and illusion of depth such that the strip cues would seem to sit behind the page, as though the current in-focus page was jutting out a bit more.
  • Moreover, we avoided using three-button navigation at the top of the pages where these strips were in use because we wanted to be sure the screens immediately to the left and right were accessible in one D-pad key press. Thus, subsection pages like the group members and events list pages simplify to one add button at the top, and the group profile page aligns edit and leave group functions vertically towards the bottom where it would not look clumsy.
  • Events search
  • Our intended ability to enter a search query for an event and pick from a page of results materialized as a page in the low-fidelity prototyping, but only after exploring various search implementation techniques during the interactive prototyping did we opt for an autocomplete event selector in our pilot study. The ability to suggest keyword hints in real time was an important usability plus for us, and we preferred that users be able to pick from the live suggested results instead of having to pick from an ordinary results page.
Image:g_findevents.png Image:g_findevents2.png
  • Month and day personal planners
  • A glance at our team's original low-fidelity navigational branching shows a month/week/day view combination for the user's personal non-collaborative planner. As will be discussed in detail in the unimplemented features section later below, we scrapped the week view of the planner because, to put it shortly, the week view lacked enough space to put any useful amount of content detail inside the time blocks. Additionally, the day view can be accessed by picking a given day in the month view, which negates the need for a day/week/month mode switching system in our low-fidelity prototype.
Image:g_cmonth.png Image:g_cday.png
  • Since the time of the low-fi tests, the default starting view for the planner has shifted from day view to month view, for it would be easy to navigate to a certain day from the broader month view, and not vice-versa. In our pilot study, we also scrapped the brainstorm ideas for adding snippet information below the month's day numbers, which would have originally placed an event count directly below each of those day numbers. The month view as implemented in the pilot study is no longer a floating picker above the groups list page for performance and legibility reasons, and instead uses a blank page in the background.

Evaluation Technique and Prototype Usability

Of all the techniques employed throughout our development period, the low-fidelity prototype proved to the be most beneficial. The paper and scissors medium allowed our team to form quick, rough renditions of a tentative interface that would present only the main features. This way, neither we developers nor the users would be distracted by fussing over the details, as we would be able to focus only on what was important at an early stage, and subsequently have our demo draw feedback relating to those core features rather than comments about fonts or colors in an unpolished stage.

One of the earliest examples where the low-fidelity saved us time was our team's debated over whether a Cancel button would be more intuitive than the physical Back button on the phone's keypad. It saved us the trouble of building every page like this, and then figuring out from a high-fidelity demonstration that we had to undo all that work. Implementing these buttons in low-fidelity took a pencil and mere seconds, and yet it proved to be enough to guide us in a better direction.

The paper's easy manipulability allowed us to quickly iterate, test, and experiment with revised iterations of designs based on the feedback. This way, by the time our team headed into the high-fidelity prototyping stage, the refinement changes would be channeled into a design rapidly shaping into something in line with our final product, and thus less likely to go to waste.

Final Interface

Final UI Design

Functionality

  • View a list of your invitations to join groups
  • Accept invites
  • Decline invites
  • Postpone invite decisions
  • View a list of groups you have joined (with snippet text indicating how active it is - number of members and events)
  • View details about a group in its profile page
  • Edit group's profile details
  • Leave group, thereby removing your membership
  • View a list of events under a particular group
  • Add new events to a group
  • RSVP to an event
  • Un-RSVP to an event
  • Edit event details
  • View a list of members assigned under a particular group
  • Add new members to a group
  • View a personal calendar of events in the form of a day and month planner
  • Search for events by autocompletion

How Functionality is Used

  • The Groups List:
Our application starts with a groups list page, which shows a scrolling view of names of groups the user has joined. From here, three pages are accessible - a quick create groups button, a list of invitations to join new groups, and a personal day planner.
  • The Group Profile
Selecting a group from the list brings the user to the group's profile page, which displays details about that group. Using the left and right D-pad keys brings up neighboring pages about the other aspects of that group, namely the list of members in that group and the list of events being hosted by that group.
From that selected group's members and events pages, the user would be able to select the green "Add Member" and "Add New Event" buttons respectively, which both sit in focus at the top of their pages.
  • The Group Members
To proceed with adding a new member to that group, the users would fill out the form with the name and and phone number, or select from the phone's contacts list. They would then hit the "save" button at the bottom (or the cancel button to leave).
  • The Group Events
To proceed with adding a new event to that group, the users would fill out the form with the name and other details, select starting and ending dates and times from date and time pickers brought up by clicking those appropriate set buttons, and hit the "save" button at the bottom (or the pink cancel button to leave).
  • The Day and Month Planner:
The day planner (the personal non-collaborative events calendar) is accessible either via the groups list page with the top button, or through the keypad menu button.
  • The Month View:
The month view is the default view upon startup, and it highlights the current day, which the user can then move around to select another day within this month (or automatically to another if the user selection moves off the edge of the current month). From here, the user would enter the day mode.
  • The Day View:
The day view shows a list of the user's agenda for the day. If it's blank, it shows a message indicating that this there aren't any activities yet. Hitting the left and right D-pad keys brings the user to the previous and next days, and the date in the title bar will change to reflect that.
  • The Events Search:
Events search can be reached via the keypad menu, and once on the page, users can entering a search query in the search field that autocompletes as the user types, as hinted by a Start typing... hint in the text field. Live suggested results appear in a dropdown, and the user can select directly from those results. A green "view" button is set in place to prevent accidental selections from this dropdown, and a pink "exit" button returns the user to the main page - the groups list.

Implementation

  • Database
  • Each phone running our GroupSync application has a SQLiteDatabase to store all of the groups. It is comprised of only a single table, designed to be able to return large amounts of data quite quickly. Each entry in the Database is indexed on a char[] corresponding to the group name. The data returned from a query is actually a serialized Group object, which can be reconstructed efficiently and reliably. Deserialization returns a reference to a Group object whose entire structure(instance vars including other objects) is reconstructed, and therefore very fast to access.
  • We chose this implementation for 2 reasons. The first reason is that the size and depth of our data structures, especially Groups is quite substantial. It would have taken possibly 7 or 8 self referenced tables in order to represent the same amount of data. The second reason actually stems from the first, performance. There are several queries that get executed in the code quite frequently, and their cost (some more than others) would be much higher given a 7 or 8 table Data Base that they must scan over. Serialization and deserialization on the other hand is actually quite quick, and all operations on Groups (and its Events, Members, etc.) only take one query to get, and another to write.
  • Event Search
  • Although we do not anticipate users joining an overwhelming number of groups, the amount of events can be considerably higher. Our application offers a way to more quickly find specific events by using the AutoComplete widget that accesses the events in the database, and runs on an ArrayAdapter.
  • Day Planner
  • The day planner starts with a month view of a calendar using the DatePicker widget through java.util.date. Selecting any of the dates brings the users to a ListView showing the day view of their personal planners. As for the activity life cycle, the physical Back keypad button was configured to return to the month mode with the last date selected remaining so. Consider if a user moved from the default current day (28th) of the month to another day (16th), and then viewed the 16th and back. Hitting back would bring the user back to the more recently selected 16th being highlighted, and not the 28th.
  • Layout Techniques
  • Because of the difficulties in Android for changing the ImageView dimensions in the activity code, we wrapped an ImageView inside a RelativeLayout as a workaround. We also nested various view objects such as ScrollView, RelativeLayout, and LinearLayout to prevent more important buttons from vanishing beyond the edge of the screen upon scrolling, in order to keep those controls accessible. Also, we tended to go overboard in the xml in terms of wrapping various objects such as buttons or textviews into RelativeLayouts, which made them modular and easy to change.
  • Error Status Bars and Popup Messages
  • Screens involving filling forms, such as add event, add member, or add group, display status bars at the bottom edge of the screen that provide warnings when something in the form isn't filled properly, or at all. These error status bars utilized TextView and ScrollView with the aforementioned technique to keep it fixed at the base of the screen. Additionally, those same screens provide confirmation feedback that a member or event as added, in the form of floating pop-up messages using with the Toast library.
  • Activity Life Cycle
  • All of our non-data entry screens are dynamic, and update as the user [or other users in the group] goes from screen to screen, so most of the activity code is contained in the onResume method. All the layout objects and the buttons are loaded in onCreate, since these happen only once.

Implementation Difficulties

  • Network and Database
  • The SQLite Database was actually quite hard to get working correctly due to inconsistencies in the Android API. The API allows BLOB's (data represented as their byte structure) to be added to the data base, but only Strings, integers, floats, and doubles can be queried out of a cursor. This posed a very big problem considering we were using Serialization which is represented as a byte array. We could put a serialized object into the DB no problem, but we could only pull it out as a string. This of course could not work because String.valueOf(byte[]).toByteArray() which will be the calling order will return a different byte array than your serialized object!!!! We got around this by implementing a method that would turn a byte array into a special character delimited string, and a reverse method that would turn the string back into a byte array. We then just stored the special string representation of the serialized object in the DB.
  • Networking didn't pose that large of a problem for us in terms of implementation except the fact that Android breaks the java.net.Socket class. Because of this we ended up "wizard of oz'ing" network implementation. Note: There are server and client java files in the project that implement a special object read/write over a network. They can be ported into the project once the SDK is fixed.
  • Activity Life Cycle
  • Our system became extremely slow as more groups were added, due to the number of database queries everytime onResume was called. One of the major things we focused on towards the end of the project was streamlining the life cycle [to prevent daisy-chaining activity creation], and speeding up database calls to make the screen loading more efficient.

Reference of Select Screenshots and Figures of Implemented Changes

Low-Fidelity Prototype Interactive Prototype Pilot Study/Final Prototype
Fig. 1a) Groups List Fig. 1b) Groups List Revised Fig. 1c) Groups List Final
Image:g_list_low.png Image:g_list.png Image:g_list_new.png
Fig. 2a) Add Groups Fig. 2b) Add Groups Revised Fig. 2c) Add Groups Final
Image:g_addgroup2_low.png Image:g_addgroup2.png Image:g_addgroup2_new.png
Fig. 3a) Add Members Fig. 3b) Add Members Revised Fig. 3c) Add Members Final
Image:g_addmember2_low.png Image:g_addmember2.png Image:g_addmember2_new.png
Fig. 4a) Group Members List Fig. 4b) Group Members List Revised Fig. 4c) Group Members List Final
Image:g_members3_low.png Image:g_members3.png Image:g_members3_new.png
Fig. 5a) A Group Event Fig. 5b) A Group Event Revised Fig. 5c) A Group Event Final
Image:g_singleevent_low.png Image:g_singleevent.png Image:g_singleevent_new2.png
Fig. 6a) Groups: Edit Event Fig. 6b) Groups: Add Event Revised Fig. 6c) Groups: Add Event Final
Image:g_editevent_low.png Image:g_editevent.png Image:g_addevent_new.png

What was left unimplemented

  • Profile images ideally draw from the phone's image gallery so that users can utilize a possible built-in camera phone, as well as possible scraping from online photo services like Flickr. Ultimately, we decided to allow users to select from only a select set of images in a repository, as some of our users did not seem too interested in spending that much time in selecting profile images for group profile pages.
  • Week view of the personal planner was left out of the originally planned trio of day, week, and month modes. After careful consideration from user testing and feedback, we agreed that the limited screen space of the mobile device was awkwardly insufficient for week view, which was only large enough to display blocks sizes - a step up from the numbers of the month view, but too small to show all of the details. Furthermore, the day view can be accessed intuitively by selecting a given day in the month view, thus removing the need for a day/week/month mode switching system like the side-by-side navigation system in our low-fidelity prototype stage.
  • Screen transition animations played the role of providing visual cues that would reinforce our left/right side-to-side navigation - particularly the events/members/profile trio located one level under the groups list screen. The animations we explored in our experimental implementations were impossible to implement, along with many, many other features, so we fell back to the approach we are using now.
  • Integration of phone functions into the personal calendar was a part of the original vision of the application. It would show all text messages sent and received, photos taken, and all incoming and outbound calls in a single personal calendar as a personal history to reference against the times of group events. This feature dropped out after we decided it did not herald enough importance to the core features and mission of our application.
  • Display options and sorting options were one of our team's higher-rated brainstorm ideas during the contextual inquiry step, as they would have granted users control of filtering and reordering their list of groups and events. However, changing the order of lists means that we need to store more data in the db and on the local memory. This created slowdowns in screen loading time, which were unacceptable to us. After both user feedback and discussion among ourselves, we decided this feature carried too many downfalls for it to be worth implementing.
  • Editing permissions was a point of debate among our team members, as we felt that the complexity of implementing different levels of permissions - group leaders and users - for editing various aspects and details of groups was not worth the level of usage it would see across users. We settled on 2 levels of permissions: The creator would have all access, where a member could only view and RSVP to events. This permission system is both simple to implement, as well as fits best with our target users.

Any wizard of oz techniques that are required to make it work

  • Networking:
    • Originally we planned to implement networking through the GTalk Service provided in Android. We decided on this implementation to cut out the need for a centralized server. Ultimately though, we thought that this implementation would be very slow, and therefore inferior to a server/client implementation. We implemented a server and client program, the latter which implemented an easy interface to read/write objects and get return values over a network connection. Unfortunately, the TCP protocol and therefore java.net.Socket's functionality is broken in the current Android SDK, so we were unable to deploy the system in our application (although the source is still going to be included in the project).
    • Instead, we had to "Wizard of Oz" the networking functionality of our network. We did this by injecting a few Data Structures in the main application, and using them as if they we over a network. One example of this is a list of groups we have been "invited" to join from other "users." Our code for displaying this information is the same that it would have been given a network, except that instead of reading the data from a server we just ask the main application for all of our group invitations. Another example is for sending group invites. Currently a pop up appears when you add a new member to a group stating "Invitation sent," even though in reality nothing is sent to the group member.
    • Note: This can be easily ported into our application once a workaround or SDK fix is released for Android. If you really would like to test it you can run the server and write code that creates mock groups to be written/read from the server. You can then make calls to GroupClient.* methods to read/write to the network.

Appendix



[add comment]
Personal tools