...
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.
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?
In retrospect, less time should have been spent implementing the back-end, and more time improving the front-end features.
...