Assignment Three:

Scenarios

   Emily KathrynAddison BrooksGrace AndersonGabriela Garcia-Marquez

Comparative Analysis

   Meeting WizardYahoo! CalendarMeet-O-Matic"Calendars for the Web"
   Final Distance

Initial Design Ideas

   Design #1Design #2 Design #3

Work Distribution


Scenarios

Emily Kathryn

It is the beginning of the Spring term, and Emily is working through the start-of-semester chore of coordinating meetings with the senior projects she is advising, her research group, and fitting in TA office hours that students will actually be able to attend. Having nailed down times for her smaller groups, she decides to give VERN, a UI class project, a try for deciding when her office hours should be held.

Already having a full schedule, Emily figures that Tuesdays at 3:00 PM, Wednesdays at 5:00 PM, and Thursdays at 9:00 AM are all free on her Outlook calendar, and might be good times for office hours. She remembers that one of her goals was to schedule her office hours such that more people could make them, having inadvertently scheduled the hours conflicting with a Haas lecture series last term, and decides to find out what time the students can meet before locking it down to the three times she has proposed.

She logs into the VERN web page for the first time and creates a password. After having created her account, she loads up the “Schedule a Repeating Weekly Meeting” page, which displays a weeklong calendar to her. She quickly marks up her preferred hour-long meeting time at Tuesdays at 3:00 PM, Wednesdays at 5:00 PM, and Thursdays at 9:00 AM. She also marks as unavailable her fixed commitments, including classes, the facility meeting, and her research group.

She marks up her preferred and unavailable times, enters the class mailing list into reccipients, and sends out the Meeting Manager request to the class, with a time limit of three days to reply.

Three days later, Emily receives an email saying that VERN has found two best meeting times. The time that the most students have said they can attend is Wednesdays at 6:00 PM. The best time that Emily had set as preferred was Wednesdays at 5:00 PM. Emily logs into the site through the link in the email, and is presented with a graphical calendar visualization of the times of the week that students in her class are most available, with the two times mentioned in the email highlighted. Deciding that she doesn’t want to stay that late, she opts to go for her preferred time of Wed at 5:00 PM, selecting it on the calendar. VERN emails out a message to the class, saying that the time decided on is Wednesdays at 5:00 PM. The meeting manager remains open, in case Emily needs to refer back to it for changed office hours later in the term.

Addison Brooks

Addison has an important task in IMSA: bringing home the bacon! He is in charge of fundraising and has been fairly successful in raising money for IMSA. The IMSA exec board is having a strategy/brainstorming meeting to plan out the activities for the rest of the semester and Addison has been invited.

Addison opens the email with the meeting description, and clicks on the link to get into Vern. Looking at his schedule, and comparing to to the suggested meeting times there are a few times that are okay for him, and another time slot that conflicts with one of his other activities (a weekly online gaming party with his buddies). IMSA involves a lot of people, most of whom are fairly active already so scheduling a meeting time can be difficult at times. Addison marks off the times that are "good" for him, and makes a mental note that if push comes to shove, he'll punt on the gaming party.

Addison monitors the results of the meeting scheduling over the next few days, it looks like none of the times really work that well for people. Ironically, the slot that seems to work for everyone else is the time he normally reserves for playing Warcraft with his buddies. He goes back into Vern and updates his meeting and sacrifices game time. As a result, a meeting time that is acceptable to everyone is found and the meeting gets finalized.

Grace Anderson

Grace is having two group project assignments due next week, one for IS 213 on Tuesday and one for ARCH 241 on Thursday. She wants to schedule meetings with the two groups as soon as possible. Lacking viable alternatives, Grace used to coordinate such meetings through emails, even though it often took considerable time and patience to finalize a meeting. Fortunately, her classmates at SIMS have recently introduced VERN to her. So now Grace and her groups could use the system to schedule meetings in no time.

After logging into VERN, Grace selects the alias of the two groups she would like to meet from a list of contacts. Then a calendar shows up on the screen, displaying the schedule of each member in the two groups. Grace selects several time slots that are possible for each group to meet, then instructs VERN to send out email notifications to members of the two groups. Each email contains a link to the particular calendar screen for each group. After several hours, Grace returns to VERN to check the meeting statuses. All members of the IS213 group have agreed to meet on Wednesday from 1:00pm- 2:00pm. Whereas, there are only two out of three of the ARCH 241 have responded, with one indicating that he is not available in any of the time slots specified. Because the meeting times suggested by Grace have already been optimized based on all group members’ scheduling info, the group has to meet without that member. By the end of the day, the last member of the ARCH 241 team has responded to the VERN message, and their meeting is set at 10am on Thursday.

Gabriela Garcia-Marquez

SIMS has recently released the results of its branding survey. Anno wants to schedule a town hall meeting in about a month. It's really important that everyone who wants to come can do so. It is difficult to acquire everyone's schedules, especially across faculty, staff, and students. Anno asks Gabriela to coordinate this meeting. Gabriela's typical process of checking her outlook calendar with those of other staff and faculty members will leave out the student population. Compiling a list of student classes and research meetings to find available times is tedious and will leave out the availability of professors. Gabriela logs in to VERN using her designated username and password. From the welcome screen, she will send out an email requesting that people click on the link and fill in their calendars. Fortunately, SIMS has the sims-announce mailing list, which will send the email to every person who should receive it. 5 days later, she logs back in to VERN. She clicks on the Town Hall Meeting link and views a calendar display with all the responses thus far. She is told that 47/121 invitees have responded. Gabriela decides 47 is not a critical mass so waits 3 more days. When 81 people have responded, she looks on the calendar for the best available time. Not everyone's available, but it's the best she can do. She confirms the time and all emails are sent out notifying the SIMS community of the scheduled meeting time.

TOP

Comparative Analysis

Though a number of free, web-based, meeting scheduling software applications are available, none are specifically tailored to fulfill the needs of the SIMS professor and student. Existing applications such as Meeting Wizard and Meet-O-Matic possess useful features such as reminders, graphic grids displaying attendees' availabilities, and various response compilation options. However, all these features make the process of initiating a meeting a lengthy one. The SIMS community needs a focused, fast, and easy-to-use solution for scheduling meetings with groups of people. VERN accomplishes this by:

  • allowing users to store scheduling information, for future reference, in their personal profiles, when initiating a meeting or when setting up their account.
  • Remembering the user's weekly schedule and pre-filling new meeting forms and meeting invitations with suggested times
  • enabling a meeting initiator to easily modify a meeting time
  • identifying key people
  • Displaying at a glance, in a grid in varying shades of gray, quartile percentages of people able to attend during a time slot
  • notifying the user of time conflicts before confirming a meeting time

Meeting Wizard

Meeting Wizard is an online meeting scheduling and invitation service that proposes to solve the problem of getting a group of people together at the same time. Because its problem statement mirrors that of VERN almost exactly, it offers the closest system on which to do our comparative analysis.

How it works:

  • You invite participants providing a number of optional dates/times
  • Participants respond to invitations by indicating when they are available
  • You confirm the meeting or event after reviewing responses

Strengths:

  • summarizes their responses
  • updates you on the results
  • sends confirmations
  • sends optional reminders prior to meetings
  • Requires only that you and your participants have access to e-mail and a browser
  • Allows for enough flexibility to make changes, add personalized notes, make cancellations and handles most other situations that might arise.
  • Free
  • Don’t need to be sharing common calendars among users
  • Web-based: most recent version is always available through the browser, requires no downloads or IT support
  • Collates all information and all responses in one place (see MeetingWizard?_Confirmed.bmp)
  • Organizes and standardizes the event information so that important details aren't missed, and users become familiar with a standard request-response interface
  • Not graphic intensive
  • Emails are sent in plain text
  • Offers ability to propose multiple times, suggest new times, confirm times, change times, and send automatic reminders
  • Users don’t need to post their personal schedules
  • Users aside from the organizer don’t need to have a login account

Weaknesses

  • Doesn’t integrate with other calendar systems
  • Labor intensive to organize a meeting (see MeetingWizard?_NewMeeting.bmp)
  • Need to select dates and times for each proposed meeting
  • Only sends invitations to participants proposing up to 12 alternate times
  • What if you want to compile people’s schedules over the full work day of an entire week?
  • No way of assessing meeting attendees’ schedules outside of the proposed times. If the proposed times don’t work for everyone, the cycle must be repeated until a time is found, which brings the user back to the same problem he or she had with email


Meeting Wizard New Meeting

 

Meeting Wizard Review Request

 

Meeting Wizard Confirmed

TOP

Yahoo! Calendar

Yahoo! Calendar is a web-based application that is seamlessly integrated with Yahoo! Mail. Calendar can be used for personal scheduling, or it can be shared with a group. When inputting an event, users can choose to make it public or private. Only public events will be visible to the group. All users must register to have password access to Calendar.

Strengths

  • Easily accessible on the Web, no downloads or IT support
  • Free
  • Easy to input information
  • A group of people can share the same calendar
  • Can accommodate any sized group
  • Anyone can initiate a meeting - democratic
  • Has private and public filters so calendar integrates personal events (that other cannot see) and group events (that everyone can see)
  • Emails meeting invites
  • Email invites feature a calendar view of the month. Dates are clickable so the invitee can see what their schedule looks like
  • Has reminder options
  • Displays day, week, month and year views
  • Not graphic-intensive
  • Stores email addresses for easy communication with group members
  • Group members can input their personal schedules into calendar, so information can be compiled for the long-term
  • Integrates with Yahoo! Messenger and Yahoo! Groups, so group discussions can be done via chat, email, and bulletin boards
  • Syncs up with Outlook and most PDA's; a mobile phone version is being developed

Weaknesses

  • Does not identify key people
  • Does not display flexibility of time slots
  • When inviting to a meeting, cannot suggest alternate meeting times
  • Does not have special features to handle schedule changes (unless everyone has input their schedules into the calendar, and available time slots are accurate and visible)
  • Log-in profile/account needed for users to access shared calendar
  • Users might not want to share a view of their calendar; not as useful unless everyone does

Yahoo! Calendar

 

Yahoo! Calendar Event Input Screen

 

Yahoo! Calendar Event Input Screen

TOP

Meet-O-Matic

Meet-O-Matic is a web-based application specifically for scheduling meetings. The initiator chooses possible meeting times, and the application sends the initiator an automatically-generated email, pre-filled with the proposed meeting times. The initiator then forwards the email to the invitees. The email includes a to a webpage where they can select preferred meeting times and add a comment. It also has a link for the initiator to a webpage that monitors responses. When invitees respond, the initiator immediately receives an email with their response, and a recommendation of the best time to meet based on the respondent's choices.

Strengths

  • Free
  • Is open-source, so it can be customized to a user's unique needs
  • No need to register
  • Platform-independent
  • Users don't need to share a calendar
  • Can use app's email to invite people to meeting or use your own
  • Features an invitee table to monitor response progress
  • Can select various possible meeting times
  • Gives the option of saving a meeting profile
  • Compiles and displays results of overlapping availabilities in an easy-to-read grid

Weaknesses

  • Need to know how to program in order to customize it
  • Cannot reuse schedule information for future meetings if it is not saved
  • No reminders
  • Initiator has to forward the email generated by the app, instead of the app automatically sending out an email as soon as meeting dates are chosen
  • Email overkill if the group is large, since the initiator receives an email every time someone responds

 

Meet-O-Matic Homepage

 

Meet-O-Matic Auto-Generated Email for Forwarding to Invitees

 

Meet-O-Matic Invitee Response Page

 

Meet-O-Matic Compilation of Responses for Meeting Initiator

TOP

"Calendars for the Web"

"Calendars for the Web" is an event calendaring software program. Event times and their frequency are input, and calendar views are output in various formats. However, it has no features specifically for coordinating meetings.

Strengths

  • Merge group wide events into individual calendars
  • Monthly, weekly, daily and list display
  • Email notifications
  • Repeating events with exceptions
  • Easy to use - works with any web browser
  • Customizable templates
  • Various export formats: HTML, GIF image map, JPG, PNG, and text
  • Event import from popular programs like Microsoft Outlook
  • Option to purchase a desktop version, or a Web version (server/host app)

Weaknesses

  • Cost - ~$50.00 - $100.00
  • No option to invite people to a meeting
  • Must be downloaded to your desktop
  • Is more tailored for general event calendaring, rather than for organizing, scheduling, and coordinating meetings
  • Can choose the option of animated GIFs in your calendar for an additional $10.00. Woo hoo!

 

"Calendars on the Web" Calendar View

 

"Calendars on the Web" Event Manager

 

"Calendars on the Web" Holiday Manager

TOP

Final Distance

Final Distance is a class scheduling web-based application developed by a UC Berkeley student. To input classes, users select a department from a pull-down menu, and input the class number. A weekly class schedule is displayed as colored boxes in a week calendar view.

Strengths

  • Easy to input information
  • Focused on one task
  • Clearly displays output
  • No user ID or password needed
  • All functions and output contained on one page

Weaknesses

  • Is not a meeting scheduler
  • Platform-specific due to use of Java applets
  • Doesn't work with SIMS schedule (I couldn't generate a SIMS schedule for this example)
  • Cannot save info for later use

 

Final Distance

TOP

Initial Design Ideas

One of the basic issues that kept coming up in the design discussions on Vern was the scope. There is a tension between the additional context that is provided by being interfaced into a Calendaring and/or EMail system and the competing desire for simplicity. Some of the benefits of an integrated design are:

  • Ability to make suggestions for meeting times if the schedules for all attendees are known
  • Ability to make use of existing mailing lists in order to easily schedule meetings for a group

Some of the drawbacks are:

  • General scope bloat - the temptation to start adding many features and options, de-focusing the design and sacrificing a simple clean design in favor of sprawling functionality
  • Scheduler starts to lose functionality for people who are not already in the system (a noted drawback of the calendar used in CalAgenda)
  • Adding yet another calendar system to a user population that already has too many calendars
  • Calendar protection starts to become an issue: people want to hide their calendars from people, and in some cases, people will schedule bogus meetings to keep people from hijacking time slots for meetings.
    • Will we need to implement some kind of privacy policies?

Following our initial design priorities, we decided to avoid any semblance of trying to solve general calendaring problems, and focus the design around simply scheduling meetings and making no assumptions about external calendars. As a design branch, some of the designs take advantage of internal Vern knowledge about meetings that a user has already scheduled. There are real functionality benefits, and restricting it to internal calendar information during the prototype phases gives the opportunity explore the possibilities.

There were three major design paths that we wanted to explore. They share many things in common:

  • Oriented around a grid based calendar view
  • All are heavily visual and color oriented
  • None assume interaction with external calendar, but do use email in order to notify users
  • All use a voting based system, similar to eD and will inform users of the current status of the meetings
  • All support displaying how many respondents have replied to the meeting request, to give an idea of how close the meeting is to being finalized.

Design #1: Java Applet Oriented Graphical Interface

This design was based on a Java applet that allows users the ability to use the mouse to drag over a calendar area in order to select meeting times. A prototype of the applet has already been developed and we include screen shots of it in action as part of the mockup screens. In addition to the obvious Java applet design, the following design issues are also examined

  • What happens if there is an inability to schedule a meeting based on the original set of meeting times? An interaction flowchart was generated that looked at how this might be dealt with.
  • Does the Java drag and drop interface offer significant advantages over pull down menus and other more textual interfaces?

The additional graphical features of the Java applet are offset by the additional page size, and complexity. However, it offers the most potential for easy "drag and drop" style interaction.

The following two designs share the same interaction flow, but implement the user interface somewhat differently: examining the differences between a tabbed/non-tabbed interface. In addition, these two design differ from the Java interface by exploring another set of features:

  • Supporting aliases/groups for scheduling meetings. Meetings are often scheduled for the same group of people, for example, a project group or research group. A useful convenience would be for vern to be aware of such groups and allow you to schedule for them more easily
  • Selecting available versus unavailable times. A question that came up very often was distinguishing being between the two methods of handling meeting times: only reveal times explicitly marked as available for the meeting, or make available any time not already set aside for some other meeting.
  • Using "alt" style popups over regions in order to expose further details about a meeting (such as the attendees, etc...)
  • Check meeting times that Vern is already aware of in order to suggest meeting times

 

Flow Charts:

User Process Flowchart

 

Organizer Process Flowchart

 

Meeting Conflict Resolution Flowchart

 

System Screenshots:

Sign In Page

 

New User Sign Up

 

Calendar View

TOP

 

Design #2: Tabbed HTML/Javascript Interface

The tabbed interface is somewhat similar to the existing eD design. The tabs allow users to move from task to task very directly. This interface is somewhat more complex than the next interface.

 

Flow Charts:

Sketch:

TOP

 

Design #3: Non-tabbed HTML/Javascript interface

This interface is in many ways the most lightweight and straightforward. It doesn't depend on Java, and the lack of tabs simplifies the design even further. This interface, if kept simple enough, may be usable even on a web enabled PDA. The mockups for this design also show prominently the fraction of the respondents that have responded to a meeting request. Various features are spread across the three different prototypes but as we move forward, the intent is to pick the set of features that make the most sense and merge them into the design that moves forward.

 

Flow Charts :

Screen Shots:

Calendar Display

 

New Meeting Screen

 

Pending Meetings List

TOP

Work Distribution

The work distribution information for this assignment has been placed in a composite Work Distribution table to reflect the distribution of work for the entire VERN project.

TOP