Charitable Connections

GR4: Computer Prototype

Platform and Software Requirements

For best results, use Mac OSX and Google Chrome.  Do not resize the screen after loading the page as window resizing is not yet implemented.  Good default sizes range from 800 x 800 to 1400 x 800.

Getting Started

To begin using the application, navigate to http://web.mit.edu/goneil/www/6.813/gr4/charitable_connections/home.html .  This is all of the setup required.  Now for a scenario, just view GR3's scenario: GR3

Page Descriptions

Home

The home screen is the first page a user would see when opening our application.  This page gives the user options to either create an event or view past events and messages.

Create Events

In this page, the user fills out details about the event they are planning to hold.  The goal is that the details of the event will help us match them with businesses likely to donate.

Shallow Features:

  • No data is passed to any sort of filtering mechanism.
  • Event is not saved to be displayed on My Events/MyAccount page
  • Calendar does not resize well

Business Suggestions

The business suggestions page is the page that the user sees after they have completed their event creation.  This page should contain businesses that are good matches for the events.

Shallow Features:

  • The user interface is completely implemented but all of the displayed data is canned
  • Businesses would normally be related to the users event, but here they are hardcoded
  • The message would normally be autofilled with details from the events, but here it is autofilled with static data
  • Sending a message does not actually do anything as there is no backend
  • Business "info" is taken straight from google, whereas is a business was to actually use our website, they would be able to create their own info.  It should be more about causes that they support than just generic information about the business

My Events/ My Account

The My Events page displays a history of the user's past activity. The main sections include current events that the user is in the process of planning, past messages sent and received by the user, past events that the user has organized through the site, and a list of businesses that have agreed to donate to the user's events.

The first iteration of the interface is completely implemented, but the layout may change slightly with further iterations.

Shallow Features:

  • The data is all canned, but of the appropriate amount and size for each field
  • The user's past activity would normally be saved in the backend

Max Kolysh's Heuristic Evaluation: HW2.pdf

Tal Tchwella's Heuristic Evaluation: HW2.pdf


  • No labels

1 Comment

  1. Unknown User (jks@mit.edu)

    • Wiki presentation: Good description of prototype depth and pointer to relevant scenario
    • Fidelity:
      • Good computer prototype that seems reasonably hi-fidelity in look, with the exception of:
        • Date and location pickers don't fill the logistics of my event
        • Size isn't included until I'm sending an email
        • None of the clickable links in My Events display anything - the views for these items (current/past events, messages) should have been fleshed out if the final implementation will include them
      • Good coverage of your GR3 scenario.
    • Usability:
      • Great color scheme, font selection and logo - apart from the dark blue text that can be hard to read against the thatch background pattern. Perhaps make the background a solid color.
      • Homepage:
        • Needs some explanation of what the site is for, rather than just the giant logo.
        • The two key buttons should be more prominent.
      • My Events page should contain current and past events, but not clear that it should contain Connections and Messages. Consider bringing these two elements to the homepage/dashboard.
      • Create Event:
        • Good message about 'event details will appear here' to avoid empty, confusing space.
        • Granularity of event type is confusing: there's a mix of high-level things (cooking, education) and lower-level activities (basketball and soccer, instead of 'sports'). Try to come up with a more comprehensive and coherent list. Same applies for donations.
        • As we've talked about before, it's important to convey to the user that their event description is so YOU can find a match for them. Similar to a dating website, you have to fill in specific information about your event, so the system can do the matchmaking for you. If the user doesn't understand this, they may be frustrated by their lack of control over describing their event (e.g. specifying details about the event type, and what their goals are).
      • Suggested businesses: 
        • Business detail views need more contrast between different pieces information.
        • Instead of hiding/displaying the message composition box on demand, maybe it can always be present on one side of the page, with the business list/detailed view on the other side. Selecting businesses could populate the message, and you can send multiple messages pertaining to the event.