Final-GroupYourLife

From Cs160-sp08

Jump to: navigation, search

Contents

Team Roles

Max Preston: Descriptions of nearly all functionality, implementation details for color scheme and add fixed/flex/recurring event screens, features that were left out/wizard of oz/misc section. +various other misc things

Gerard Sunga: Parts of the final interface section, namely the "Most Difficult to Implement" and the "Calendar View" part of it.

Cole Lodge: Implementation details for the database, alarm, and options screen. Target user group.

Hannah Hu: Design evolution, implementation details for the event algorithm.

Problem and Solution Overview

Some people never learn to manage time efficiently and worst, have to deal with forces beyond their control. This might lead to missing meetings and classes, falling behind on schoolwork and professional duties, and bad moods. Your Life is a scheduling application designed not only to keep track of your scheduled events, but also to schedule your unscheduled events. And it lets you do all this while on the go. This allows for less stress and worry, helping keep the user from forgetting that reading assignment due tomorrow afternoon.

Target user group

The target users of our application are people on the go with busy schedules: specifically college students. Most college students have extremely busy schedules, going between school, work, and recreation. They are also likely to find our key feature, flex events, useful; with papers, homework, and reading constantly piling up, automatic scheduling will help college students allocating their time. The busy schedules and constant homework make college students the ideal user group for our project. Most college students already use cell phones and are familiar with cell phone calendars, this should allow them to quickly learn how to use our application.

Representative tasks

Easy task: Navigating the calendar and viewing an existing event

  • Two events will be set up beforehand. One will be visible onscreen, and the other will be on a future date. The user should be able to navigate to the first event via the D-pad. For the second event, the user can either use the D-pad to jump times and/or weeks to the event, or use the menu to designate a date to view. Since this task shows the basic functionality of the calendar system, it was chosen as the easy task.

Medium task: Adding a flex event

  • A flex event is one that has a set deadline, but can be done at any convenient time before then. Examples include homework assignments, readings, and projects. The user should be able to add a new flex event, review the confirmation that tells when it was allocated, then find that event on the calendar. This task displays one of the main features of the application, the "flexible event". As such, and since it is moderately difficult to perform, it was chosen as a task.

Hard Task: Editing a recurring event

  • A recurring event is one that repeats on certain days. Examples include lectures, discussions, and club meetings. The user should be able to find a recurring event and edit its details, including its days of recurrence and ending date. Since this task involves traversing multiple screens and using the basic navigation, it was judged to be one of the harder possible tasks, and thus it was chosen to be the hardest task.

Design Evolution

Calendar Screen

Low-Fi Prototype

Image:GylMockupLoFi.jpg

The original calendar screen showed time slots by the hour. We did not think the screen would be smaller, and so for the interactive prototype we had to reduce the number of hours shown. We also decided that half-hour slots would be better and more detailed. The contextual inquiry assignment was the one that led to this decision. Test users were asking for smaller time slots, although they were fine with the number of hours shown. We end up showing just two hours at a time, due to space constraints.

Also, navigation was different. In the lo-fi version, we had the idea of keeping the current time slot box at a certain position on the screen, and the whole screen will scroll or shift with each D-pad press. This proved to be too hard to implement, and users found it a bit confusing to look at. It was probably because we used a huge sheet of paper to represent those time slots and we shifted it around under the view screen. But in any case, because such an interface would be difficult to implement, we scrapped it.

Interactive Prototype

Image:Taskselect.jpg

We rushed on our calendar design, so it ended up a bit messy. Each time slot is a button to press, and any occupied time slot were colored with a blue bar. Comments on our evaluation forms overwhelmingly said we needed a way to distinguish tasks and connect the time slots to show different durations.

Pilot Usability

Image:HH_weekview.png

We used a grid view to show time slots now. Event titles are used to show which events occupy what slot. This was much better than the interactive prototype, but users complained that there was no easy way to SEE the time slots. They said it would be great to have some borders between slots to separate them out. The black background also lacked pizazz. Users wanted different colors for different tasks.

Final Version

Image:GYL_final_calendar.jpg

In our final version, we still used a grid to display time slots, but this time there are grey borders to outline the slots. A white background was used instead of black. A color scheme was used to distinguish between types of events, and we still display the event name for each slot that the event occupies. If more than one event share a time slot, the event title for that slot would belong to the most recently added, and there will also be an additional "+" to indicate multiple events. The current date and time will be highlighted at the top with a gold hue (see above image for an example of the current date being shown). Also, in the title section at the top of the screen, the current week shown will be detailed (e.g., April 28 to May 04).

Event details popup

Low-Fi Prototype

On the left center, you'll see the lo-fi version of the event details popup. Its layout has not changed, although we didn't have the little point at the top left corner in the final version. It wasn't necessary.

Interactive Prototype

Image:Taskview.jpg

This design was the only one that never had major changes. We kept this design through the rest of the revisions of our applications.

Pilot Usability

Nothing changed since the original layout, although the transparency of the background was made slightly more opaque for better readability. Users didn't complain. Sorry, we forgot to get a screenshot of it at this version.

Final Version

Image:GYL_final_taskdetails.jpg

Nothing changed from Pilot Usability.

Event details adding/editing screens

Low-Fi Prototype

On the right side of the above image, you see our lo-fi version of the event details inputting screens. We had text input for the starting time and date, with radio buttons for AM/PM. Duration was also text-inputted. We had a huge block for notes, and a radio button for "recurring" on the bottom left. If this was selected, the "Add Task" button would have led to the recurring screen. Otherwise, it would have gone straight to the event-adding algorithm and the task would be added as a fixed task. We later removed this radio button idea, and had the user go to the recur screen after the details screen regardless of whether the task is fixed or recurring. We did this to make this recurring option more obvious to users (rather than sticking it in a corner as a radio button).

Interactive Prototype

Image:Taskinput.jpg Image:Recurtask.jpg

Because of time constraints, we also rushed on these screens. Evaluations from our presentation said using Spinners would be too tedious, and disallow arbitrary durations (in this version, we only allowed 30-minute intervals).

Pilot Usability

Image:HH_taskscreen.png Image:HH_recurscreen.png

We placed the event title and notes near the top of the screen, since intuitively users would first want to add those details before assiging the date and time. Setting the date and time is now done by a DatePicker and TimePicker respectively; users wanted a better way of selecting date and time instead of Spinners, so we chose those. We also chose to display the set date and time next to the buttons so users can make sure they didn't make a mistake. Duration is inputted by direct text entry; again, Spinners proved too cumbersome. This was put to the bottom right because we had the idea of having time-related content on the bottom, and text content at the top.

Also, the checkboxes in the recur screen were set tightly next to each other. We figured that the wide spacing in the interactive prototype was too much and unnecessary. We also used a DatePicker for setting the ending date, again for ease of use.

Final Version

Image:GYL_final_taskscreen.jpg Image:GYL_final_recurscreen.jpg

Image:GYL_final_confirmation.jpg

The only changes from the pilot usability is the addition of an alarm for the event, and a little background color. Black got dull very fast. We also added a confirmation dialog that comes up after "Add Event" has been pressed, and shows that indeed, the task has been allocated.

List view of events

Lo-Fi Prototype and Interactive Prototype

We did not have a list view option for the lo-fi prototype and the interactive prototype. Only after we got our evaluations from the presentation did we start work on a list view.

Pilot Usability

Image:Cole_ListView.png

Users of the lo-fi prototype, and comments from our interative prototype evaluations, asked for a "day-view" option. Although we had plans for a day-view since the beginning, time constraints kept us from implementing it for the interactive prototype. Existing calendar applications have "day-view" as simply a list of events on that particular day, ordered by time, so we followed that model.

Final Version

Unchanged from Pilot Usability.

Final Interface Functionality, Design, and Implementation

Calendar screen (initial screen):

  • Navigating time and date with arrow keys
  • View an existing event by pressing enter after selecting the event with the arrow keys
  • Delete an existing event by selecting the delete event button on the view event pop-up
  • Edit an existing event by selecting the edit event button on the view event pop-up. This will jump to the appropriate modified add event screen with the relevant information already filled in
  • View multiple conflicting events in the interval view by selecting the overlap of the events with the arrow keys and pressing enter
  • Go to the add new fixed or flex event screen with the specified date/time already inputted by selecting an empty space on the calendar with the arrow keys and pressing enter
  • Jump to the calendar list view for the specified date by navigating to a date box with the arrow keys and pressing enter
  • Menu:
    • Jump to a specific date or time with a calendar or time picker, or jump to the current date-time
    • Go to the add fixed or flex event screen
    • Switch to the calendar list view
    • Go to the options screen

Calendar screen implementation:

  • The layout of the entire interface (found in the xml file) was carefully hard-coded, requiring repeated trial and error to make the view visually optimal.
  • The overall interface involves seven listViews (one for each day) with five rows: one for the day in question and the other four for each thirty-minute interval within the given two-hour span.
  • The event-tracking subsystem is maintained within a two-dimensional array, checking the current time and week, then querying the database for the events within each interval.
  • The drawing subsystem is similarly maintained within a two-dimensional array, checking event types and quantity prior to setting a color for each time interval. This also required a custom adapter for each list view to support setting the background and text color of each box in the grid.

Image:GYL_final_calendar.jpg


Calendar list view screen:

  • View all the events on a day and navigate to them with the up/down arrow keys
  • Navigate to different days with the left/right arrow keys
  • View information about a event by selecting it with the arrow keys and pressing enter
  • Delete an existing event by selecting the delete event button on the view event pop-up
  • Edit an existing event by selecting the edit event button on the view event pop-up. This will jump to the appropriate modified add event screen with the relevant information already filled in
  • Menu:
    • Jump to a specified date or time with the calendar or time picker, or jump to the current date-time
    • Go to the add fixed or flex event screen
    • Switch to the calendar view
    • Go to the options screen

Calendar list view screen implementation:

  • The list view is a simple Android List view using a list item adapter.
  • All of the events for the current day are taken from the DB and added to the list adapter.
  • If the left or right key are pressed, the day is changed accordingly and the events updated.

Image:CL_ListViewSS.png


Interval view screen:

  • All functionality is identical to the calendar list view screen, except it only displays the events within a half hour at a time, and the left and right arrow keys switch to the next or previous half-hour rather than to the next or previous day

Interval view screen implementation:

  • Interval view used the same implementation as the list view.
  • The only difference was changing from a full day to a short length of time

Image:CL_intervalViewSS.png


Add flex event screen:

  • Textviews:
    • Set the event title
    • Set the event notes
    • Set the duration hours (only two digits can be entered, and they must be numbers)
    • Set the duration minutes (only two digits can be entered, and they must be numbers)
  • Buttons:
    • Open a datepicker to set the deadline date of the flex event. The selected date appears next to the button.
    • Open a timepicker to set the deadline time of the flex event. The selected time appears next to the button.
    • Open a list of possibilities to set the alarm and how early before the event it will go off. This setting will be displayed next to the button.
    • Add flex event button, which brings up a pop-up which says where the event was added and returns to the previous screen
    • Cancel button, which returns to the previous screen

Add flex event screen implementation:

  • The xml was created initially with DroidDraw and manually modified to tweak text and button sizes and alignment. The xml was also manually modified to determine the focus-orientation of the various widgets and to make the duration boxes only allow two digits.
  • Data is initialized based on the bundle sent from the calendar screen. (if adding a event at a set time/date or editing a event)
  • A simple algorithm is used to display the appropriate human-readable text adjacent to the date, time, and alarm buttons.
  • The add event button sends a bundle containing all relevant information to the event adding algorithm activity, and finishes the add flex event activity after adding the activity and displaying the info pop-up. (if the event is being edited, it instead replaces the old version of the event)

Image:CL_FlexTaskAddSS.png


Add fixed event screen:

  • Textviews:
    • Set the event title
    • Set the event notes
    • Set the duration hours (only two digits can be entered, and they must be numbers)
    • Set the duration minutes (only two digits can be entered, and they must be numbers)
  • Buttons:
    • Open a datepicker to set the start date of the fixed event. The selected date appears next to the button.
    • Open a timepicker to set the start time of the fixed event. The selected time appears next to the button.
    • Open a list of possibilities to set the alarm and how early before the event it will go off. This setting will be displayed next to the button.
    • Next button, which goes to the recurring event screen
    • Cancel button, which returns to the previous screen

Add fixed event screen implementation:

  • The xml was created initially with DroidDraw and manually modified to tweak text and button sizes and alignment. The xml was also manually modified to determine the focus-orientation of the various widgets and to make the duration boxes only allow two digits.
  • Data is initialized based on the bundle sent from the calendar screen. (if adding a event at a set time/date or editing a event)
  • A simple algorithm is used to display the appropriate human-readable text adjacent to the date, time, and alarm buttons.
  • The next button starts the recurring event activity, and when it receives the bundle back from the recurring event activity, it sends a bundle containing all relevant information and the recurring bundle to the event adding algorithm activity, and finishes the add fixed event activity after adding the activity and displaying the info pop-up. (if the event is being edited, it instead replaces the old version of the event)

Image:GYL_final_taskscreen.jpg


Recurring event screen:

  • Buttons
    • Back button, which returns to the fixed event screen
    • Add event button, which adds the fixed or recurring event and returns back to the current calendar screen. The event is fixed if no days of the week are checked.
    • Open a datepicker to set the end date of the recurring event.
  • Checkboxes:
    • Choose the days of the week the event should recur on (monday-sunday, none are checked by default)
    • Choose whether the recurring event has an end date (the end date or lack thereof is shown next to the checkbox, and it is automatically checked if the user sets an end date)

Recurring event screen implementation:

  • The xml was created initially with DroidDraw and manually modified to tweak checkbox, text, and button sizes and alignment. The xml was also manually modified to determine the focus-orientation of the various widgets.
  • Data is initialized based on the bundle sent from the fixed event screen (if editing a recurring event).
  • A simple algorithm is used to display the appropriate human-readable text adjacent to the use deadline checkbox based on the currently selected checkboxes.
  • When the add event button is pressed, it sends a bundle containing all relevant information back to the add fixed event screen, which handles the rest.

Image:GYL_final_recurscreen.jpg


Options screen:

  • Select the delete all events button with the arrow keys and press enter to delete all events from the calendar (with a confirmation dialog)
  • Selecting the Typical start/end of day buttons allows the user (with a time picker) to select the earliest/latest time a flex event can be allocated.
  • The alarm sound option allows the user to choose if the alarm will make a sound when it goes off.
  • The save button saves the options, cancel reverts the changes.

Options screen implementation:

  • All of the options are held in a database table, and are updated when the user hits save.
  • The options are taken into account by the alarm, and the event allocator.


Image:CL_OptionScreenSS.png


Help screen:

  • This screen is accessible from the options screen.
  • It is simply a scrolling text view with information about our application.

Help screen implementation:

  • It is an alert dialog that has all the text for a helpfile.

Image:CL_helpScreenSS.png


Database implementation:

  • The Database is used to hold all persistent data: events, flex events, recurring event, options, alarms.
  • There is a table for each of the above; all of which (besides options), have foreign keys referring to the event table.
  • All accesses to the database are through the CalendarDBadapter, which handles adding, deleting, updating, and searching events.
  • The adapter allows an easy way to access the database, and keeps all SQL in a contained place.
  • Several "event between" functions were created to search for events based on time ranges, these functions use complex SQL queries.
  • When ever fetching data from the db, the function returns a Cursor.
  • Public static variables were made for each column to make access to the data within the cursors easier.



Event algorithm and implementation:

  • The event algorithm is the brain of the application. It adds new events to the database, and in the case of editing events, updates the event in the database, via the create() and update() functions defined in the database code. The algorithm works behind the scenes; the user never sees it in action.
  • The algorithm is activated when the user presses "Add Event".
  • For fixed and recurring events, it simply adds them to the database.
  • For flex events, this was the most difficult part of the implementation. Both fixed and recurring events had to be considered when finding the best empty spot for the flex event. The algorithm must take all days between the current time and the flex event's due date, and check for any fixed and/or recurring events.
  • Any events found will be added as a Calendar to a Vector of Calendars.
  • Once the due date is reached in searching, the vector is sorted by Java's Calendar compareTo, and the algorithm will do its little magic:
Initialize the flex event's starting time at the current time or the customized lower-bound time, whichever is later
For each currentEvent in the vector:
  check for three conditions:
  - flex event's total time is completely within currentEvent's total time
  - flex event's total time is partially within currentEvent's total time
  - flex event's total time completely surrounds currentEvent's total time
  If any one or more of these conditions are satisfied:
    set the flex event's starting time to (currentEvent's time + currentEvent's duration)
    if the flex event's time is past the customized upper-bound time:
      set the flex event to the next day, and to the lower-bound time
  • In short, the algorithm looks for the earliest empty time slot that can accommodate the flex event.



Alarms and implementation:

  • Within the add/edit screens for all types of events, the user can set an alarm at a set time before the event.
  • If the time is updated for an event the alarm is moved appropriately.
  • When the alarm goes off the user: the alarm can be dismissed or the user can go to the event. Going to the event takes the user to the day of the event and displays the events information.

Alarm Implementation:

  • All alarms are held in the database, allowing for them to be edited and deleted.
  • There is one android alarm that recurs every 15 seconds; which calls the alarm receiver.
  • The alarm receiver checks for all alarms that need to go off and calls the alarm activity for each alarm.
  • The alarm manager provided with android is very limited and does not allow you to have more than one active alarm per activity.
  • The alarm manager also requires that you recreate an intent in order to delete an alarm, making it useless as far as editing an alarm.

Image:CL_AlarmSS.png


Color scheme design:

  • There were several criteria for deciding on the color scheme:
    • We wanted pleasant colors that were easy to look at, while still remaining distinct.
    • Text should be easy to read and the transparency should be appropriate so that buttons highlight when the focus is on them.
    • The color scheme on the different screens should vary and correspond to their function. In this case, the background colors used for the add events screens are similar to the colors used for the corresponding event displays on the calendar.
    • We wanted color to differentiate other things as well. For example, the current date and time on the calendar screen are gold so that it's easier and faster to tell the current date/time.

Image:GYL_final_calendar.jpg


How students will use our application:

  • The intent is for our application to be used by students to view, edit, and add daily events while they are on the go. The various calendar views make it easy for students to view their schedules and find what they are looking for.
  • They will be able to do things such as entering their class calendar, setting homework deadlines, and scheduling parties.
  • With the alarm feature, they can ensure that they will not miss important events.



Most Difficult to Implement:

  • The interface for the calendar system's week view was the most difficult to implement. This involved trying multiple possible implementations for the display of the dates and time intervals as well as figuring out the bugs and limitations of each before arriving at the final decision of using a ListView. Hard-coded TextViews were one option, but the fact that they were not selectable eliminated them from contention. A GridView of TextViews (which would display a grid of textboxes) was also planned for use, but the problems in updating the grid view proved to be the deciding factor in not using it. It would not update the displayed text for a given period of time and required user activity to do so (in the form of moving the cursor around). A single ListView was chosen afterwards, but it did not meet the needs of finding out which column was highlighted (necessary for non-menu navigation). The array of ListViews was chosen when it was seen that it solved that issue.

What was left unimplemented

Unimplemented features:

  • Sharing events with friends
    • The SMS system is very hard to use and the XMPP system requires a Google account. The usefulness of this feature simply wasn't worth the tremendous amount of work necessary to implement it.
  • Choosing different alarm tones
    • Android's file interface is incredibly difficult and cumbersome to use.
  • Flex event to-do checkoff screen
    • This can already be done by simply editing or deleting the event.
  • Choosing different time steps for the calendar screen
    • Two hours is the most readable version, and it just didn't seem like adding this option would really be worth it.
  • Wrap-highlighting of intervals and days
    • Android simply doesn't support specific highlighting in general, and does not exhibit expected behavior because of button presses (in that the button press will carry over after the highlighting is completed, resulting in extra movement).
  • Loading bars when changing time and date intervals on the calendar screen
    • We implemented this, but since our loading times are in a gray area between too fast and too slow, this lead to either instability or usability problems, and we had to take this out. Specifically, if the delay on the loading bars was less than two seconds, Android would become extremely unstable and randomly crash. However, at more than 1.25 seconds, the loading bars greatly slowed navigation.


Wizard of Oz techniques used:

  • None. Everything implemented is fully functional. Nothing is half-functional. Every feature deemed impossible was dropped.


Misc: Emulator/Android Bugs:

  • When selecting an event on the calendar screen, the enter button and the center button has to be held down slightly longer than normal. The directional buttons work with this, but the aforementioned buttons do not.
  • Internal focus cannot be set on list views, so when scrolling on the calendar screen, the focus always reverts to the top row. This is also the same reason the aggregate list view was not used, since there was no means to implement the basic navigation with this limitation.
  • Highlight color cannot be changed, even though there is an option. We still got highlighting to appear by messing with the colors and transparency for a while, but it doesn't look as good as it necessarily would.


Deliverables

Presentation:

http://vis.berkeley.edu/courses/cs160-sp08/wiki/index.php/Image:Your_Life.zip

Final Poster



[add comment]
Personal tools