Design 1 - For Elderly

This design is meant to be used by elderly users. To accommodate them, the design uses a strong metaphor of a physical calendar, pictures to convey information scent, and only necessary information.

1A 

This is the home page designed for elderly users.  The physical calendar is the main focus of the page, as it can be easily understood by less technologically savvy users.  Within the calendar, all events are depicted simply to create an easily readable calendar.  An event on the calendar is represented by the picture of the event's main user (usually the child who needs to be driven to or from an event) along with the time of the event.  Clicking on the event will direct users to a page that looks like 1B, with all the fields filled in with the correct information.  The page has the bare functionality of viewing a calendar, a button to direct users to add an event, a button to direct users to help find a carpool, and a list of what is on the calendar for the current day.  These choices were made to minimize confusion for the user, giving them a straightforward way to complete the most common tasks.  Going along with the scenario, the user wants to add an event, and so clicks the "Add Event" button, directing them to 1B.

1B 

This page makes event creation simple.  It asks the most basic questions: who, what, where and when.  After these fields have been filled out, the right panel is populated with a list of users that are free at the given time, and by checking them off, the user can request carpools from others, or assign themselves as the driver for an event.  This auto-generation of available drivers is key as it helps users avoid driving conflicts, and matches up users who carpool together often.  After completing the creation of the event, the user is redirected back to the main page as seen in 1C.

1C 

The Main page is visible again, now updated with the new event.  Notice there is a notification on the "Find Carpool" button, as the user has initiated a request for a driver for the recently created event.  When another user offers to drive for the conflicting event, the user in this case will recieve another notification, and the driver details within the event will be updated automatically.  Through the process of initially viewing the calendar, adding an event, handling conflicts within the addition of events, and finding an available driver, this interface uses as few screens as possible to avoid confusion with elderly users.  Furthermore, the "Today" panel is useful as a quick reminder of responsibilities for the given day.  Lastly, the use of metaphors helps with learnability for older users, and pictures within the calendar helps remove the need for small text, and improves information scent.

Design 2 - Visual Interactive Calendar

This design focuses on a useful, unconventional representation of a calendar.

2A 

The main page is a large view of a calendar, with many options to help highlight information that the user needs.  The uppermost tabs toggle which events are shown within the calendar: events for everybody, a few children, or one at a time.  The tabs below this give the user the ability to view the calendar by day, week, or month.  Each of these views is useful in different cases, and giving the user the ability to choose the view helps relay the most useful information.  Another useful part of this representation is the ability to see who is driving to and from the event.  A buffer is added to the top and bottom of the event, and this buffer's color helps the user see who is driving, or indicate if no one is assigned to drive yet. Outside of the calendar, the only button is a minimal plus sign, which extends to show "event" or "carpool."  Clicking "carpool" will lead to the screen in 2C, but for now the user wants to create an event, so presses "event" and the screen changes to look like 2A.

2B 

The screen does not reload upon clicking the "event" button, simply a new event brick is added to the calendar.  Shading, size and color will convey to the user that this block is stacked above the rest of the screen, and is draggable within the calendar.  The user drags the event to the correct location and once released, text boxes appear, prompting the user for the event details, title, location, time, and user associated with the event, then a "find driver" button is available to be clicked.  This draggable block creates an interactive calendar, that a user can feel comfortable with by directly manipulating the information.  By clicking the "find driver"  button or the "carpool" button within the plus, the user is taken to page 2C.

2C 

This is the user's hub for carpooling.  On the left side is a list of events that do not have a driver assigned, then a suggested drivers list below each event name.  By checking off as many names as the user wants, then clicking the ask button, requests are sent to all checked off users.  On the right pane are requests from other users to carpool.  A user can reply to these requests with a simply yes or no button to the right of each request.  This makes responses easy and fast.  When a user replies that they can drive for a requested event, the calendar is updated with the driver's name in the driver field, and the driver's calendar is also updated to contain the agreed upon event.

Design 3 - Augmented Physical Calendar

This design is meant to use the metaphor of a physical calendar, however augment it by adding features otherwise impossible without a computer interface.  

3A 

The main view of this interface is a calendar, however the current week is expanded, adding one row for each child.  This row contains all the events for the given child so information can be more easily read.  The view drop down menu on the left lets the user select which calendar to display: the whole family calendar, the user's personal calendar, or each of the kids' calendars.  The bottom right portion of the screen is a quick view "Today I Need to" section which has the driving assignments for the user.  This is a fast way for the user to get the most useful information.  At the top right is the inbox count (here it is a zero for no messages), and clicking on this brings the user to the inbox in 3C.  When the user wants to add a new event, the click the add button, and are taken to a modal seen in 3B.

3B 

This is a simple modal to create the task.  Title, Time, and location are requested.  Furthermore there is a section to enter the event as a repeating event.  In the driving field, the user can type in who is driving (and a request is sent to that user or list of users).  The user is then returned back to the home page of 3A with the updated event on the calendar.

3C 

This inbox is a convenient way to communicate with other users and coordinate carpooling.  All requests show up as a list of events, where a user can click on the event to see details, then hits the yes or no button to respond to the request.  To request a ride, users hit the calendar icon seen at the bottom, and choose an event from their own calendar, which is then inserted into the request field.  Users can list off those they wish to send requests to and all requests will be sent.  When a request is accepted, the calendar is updated, and event details are refreshed to reflect the change in driver.

  • No labels