Design

The purpose of ShutterConnect is two-fold:

1. enables users to find and review photographers based on several criteria.
2. allows photographers to create a profile page with their business information, thereby advertising themselves to potential customers.

The website consists of three main pages:

• a homepage, from where users can search for photographers based on criteria such as location, price range or event type. The homepage also allows new users to signup, or log in if they already have accounts.
• a search results page, which displays results of a user's search query.
• a photographer’s profile page, which gives an overview of the photographer’s work. Photographers can also edit their pages.

All the pages have a top horizontal bar that allows redirection back to the homepage.

A detailed discussion of the top bar and the 3 pages follows.

Top Bar

The top bar provides consistency of look and feel across all of ShutterConnect's pages, while also increasing efficiency of navigating back to the homepage. The top bar also allows users to log in or log out in one click.

When designing, we considered using a tab bar with different tasks, such as "find a photographer" and "leave a review". However, we decided to show only the tasks that were applicable to the particular page that a user was viewing. For example, having a "leave a review" tab at the top of the search results page might be confusing to a user. We therefore decided to appeal to the simplicity heuristic.

Homepage

We considered designing and implementing a site with a prominent login page, which required all users to signup before having any access to the website. However, we opted to allow users to have access to as much functionality as possible without being forced to register.

We considered using designs similar to travel websites, but decided that these pages look busy. We therefore opted on a minimal design, which is consistent with sites such as Google's search page that most users are familiar with. We also did not want to present too many options to users right at the outset. Instead, we opted to make it easy to start and show options when necessary.

SearchPage

We considered having a confirmation page in which a user could alter their search parameters before seeing the actual results of the page. However, we decided that it would more efficient if, upon entering a search query, a user saw their results immediately, and then had the option of changing their parameters based on the results received.

Photographer's Profile Page

In Page Editing

We decided to use editable fields instead of forms for logging in. In-place editing using editable fields has the following advantages:

• Efficiency: users don’t have to go to a new page to do edits; they can make changes as they appear. For example, when looking at his profile, a photographer may notice a required change in their 'About Me' section. The photographer can make this change immediately instead of going to a new page, editing one of many fields and clicking save.
• The profile page looks exactly the same for photographers as it does to users. This way, a photographer can see exactly what potential customers would see without having to sign out and view their page as a user.
• However, editable fields are not easily discoverable. We therefore decided to use the following redundant clues to make this feature more apparent:**  Background color changes to yellow upon hovering on editable fields (consistency with Flickr, a website which photographers would be familiar with)**  Cursor changes from pointer to an 'I' bar to signify editability**  Dashed light gray margins around editable areas

Prominent Elements

An important design decision on the photographer's profile page was which fields to make prominent. We opted to have the following elements stand out (tested using the squint test):

•  Name of photographer
•  Price
•  Sample work
•  Star Rating
•  Section headers (e.g. about me, reviews)

The following modifications helped ensure that the above fields were indeed prominent:

• Sample work: implemented using a widget in which photos were displayed with a black background to stand out from the white page.
• The photographer's name and section headings: are displayed in a larger font and have a lot of surrounding whitespace.
• The photographer's price was displayed in a larger font, and placed in its own column to the right of all other fields.
• In order to make a photographer's ratings, we used color. This was one of the few places where we use color in the page.

Screenshots

|

Implementation

Internals of Implementation

The backend of Shutterconnect was built using Flask, a python-based MVC micro-framework. In particular, we wrote the controller using Flask libraries, the server runs on Werkzeug and the view is written using Jinja templates.

The frontend makes extensive use of HTML5, CSS, JQuery, JQueryUI and JQuery extensions. We use Google’s Webfonts to give our headings a distinctive look.

Design Decisions and Consequences

Jquery UI Widgets

Since we were using JQuery extensively, we decided to also use JQuery UI for widgets instead of using another library like scriptaculous or YUI. This had two effects on usability: a clash in appearance, and a rethinking of some interactions.

The standard JQueryUI themes did not match the minimal, gloss and gradient-free design of the rest of the site. This inconsistency was noted by several of our reviewers during computer prototype, and we had to tweak the css of the themes to better match our site.

Second, the availability of well-designed widgets (such as dialogs and date-picker) led to a rethinking of some interactions in the site. For example, we had originally intended the “leave a review” controls to expand in-page when the user clicked “leave a review.” However, this was inconsistent with the usage of modal dialogs for other interactions such as “sign up”. The user reviews indicated that modal dialogs were more inline with user expectations than a sliding behavior would have been.

AJAX and in-page interactions

We wanted to avoid causing page transitions as far as possible since page transitions cause a context-switch on the part of the user (source: Designing Web Interfaces). So, we made extensive use of AJAX and in-page interactions.

For example, when you click “leave a review”, you see a dialog in the page itself instead of being taken to a new page. This dialog appears instantaneously and in the context of the photographer’s page. This way, there is no context switch required.

Another example is the use of click-to-edit fields in the photographer’s profile page. This allows the photographer to see his profile exactly as his clients see it and gives him the ability to update just the parts that he desires; if he wants to update the phone number, he clicks it and edits it right there...  he doesn’t have to go to a different page filled with forms that might confuse him.

However, the cost of using AJAX is the potential decrease in responsiveness due to increased network chatter. In order to minimize this, we do as much of the work on the client’s side as possible. For example, checking whether the email is malformed, or whether password and “repeat password” match are both done locally.

HTML5 usage

We also make extensive use of HTML5 features. For example, we HTML5’s ability to provide in-field help text instead of using labels in space-constrained areas such as the username-field in the top bar.

The problem with this pervasive HTML5 usage is that our site is inaccessible to users with legacy browsers.

WebFonts usage

Since different OSes come bundled with different fonts, getting a web page to look the same across platforms is a challenge. A solution is to use the Core Fonts, or to use generic font names such as “sans serif”, but that severely limits our graphic design palette. By using Google’s Web Fonts, we were able to pick distinctive fonts while ensuring that pages look consistent across platforms. Several of our users commented favorably on our fonts.

Reflections

If you did it again, what would you do differently?

We should have been more aware of the widgets that are available before deciding on a design. For example, we had wanted the "leave a review" controls to appear in view when the link was clicked. However, if we had known about Jquery UI's dialog, we would have been able to prototype that and would have benefited from user feedback much earlier.

Risk assessments

The primary risk in our site was the extensive use of ajax interactions and in-place events. For example, instead of having a seperate "edit your profile" page for photographers, we allow them to interact with the page inside the page itself. The problem was with making this discoverable and usable (as discussed earlier). It was difficult to prototype this at the paper stage (because things like "hover to change background" is hard to do on a paper). So, there were important things that we couldn't test until we reached the computer prototype stage.

Decisions about what features to prototype

As far as our paper prototype, we chose not to implement most user feedback messages (upon successful creation of a profile page) and validation symbols (such as during signup) and therefore did not get feedback about this until we user tested our website on some of our classmates. In addition, most of the validation and instantaneous feedback functionality could not be fully tested until we had a working backend, thereby limiting the range of feedback we received from our test users.

We had four major design features: signup, search, profile creation and viewing, and leaving reviews. It was therefore relatively straightforward to get all of them tested during the prototype stages. In fact, we were able to test all three of our designs during paper prototype, and come up with two different versions during computer prototype.

Which prototype techniques to use

For paper protoype, we decided to test:

• overall look and feel of the site (e.g. google-esque look vs kayak-esque look)
• workflows (how to leave a review? should we have a link always visible or show it only in profile page)

For computer prototype, we decided to test:

• aesthetic choices: fonts, margins, layouts
• use of dialogs
• use of "flash" messages

For the final prototype, we added functionality that depended critically on performance of backend. For example:

• The quality of the natural language parser for search determined how flexible we could be with inputs.
• Instant validation of email addresses/usernames or instant updating of search results based on user criteria would depend on performance of database backend and network latencies.

The paper prototyping exercise was valuable in challenging our assumptions and allowing us to incorporate feedback from multiple test users and realize a hybrid design.

How results of our observations were evaluated

The scoring of cosmetic/minor/major/catastrophic was very helpful in prioritizing which observations we should attend to first. After that, we focused on UI suggestions/problems that came from several users. We also focused on observations that seemed general rather than edge cases as a priority to have the maximum impact on most users. We added a lot of help messages and validation messages to guide users along and cater to all kinds of potential confusions.