Design

Landing Page

The landing page shows an overview of some main albums, such as recently added and albums of children, which users can directly go to. It also has an alert if a user has content in their queue. The navigation bar presents common options to the user, such uploading.

Queue Alert

The “Review Your Queue” alert is red, which calls action to it more than the other elements.

Color Scheme and Content Wells

Response To: Heuristic Evaluations

The color scheme of Coshare’s landing page in GR4 was initially light blue with black text. This combination was not aesthetically pleasing, and to be specific, diverted user focus away from the content. The blue background also clashed with the darker blue links.

The background is now white, with black text and gray content wells and green/red buttons. This lets the user better focus on the content and recognize the buttons better. Having grey content wells now make the different content sections much more distinct.

Browsing Page

On this page users can browse and interact with their content across all of their albums. Users can add content to albums, delete content, zoom in on images, and manage their albums. Users can view more details about a picture by double-clicking it.

Adding Content To Albums

Users can drag and drop content to add them to new albums. We chose this approach over other ways to add to albums (ex. buttons) because although it was harder to implement, it is externally consistent with many other applications, and therefore more intuitive.

Classifying Content

Response To: Paper Prototypes
Our model of classifying content significantly changed, where users can add a picture to multiple albums, instead of giving multiple tags to a picture. The ability to group common pictures is similar; however, using our albums model allows users to more easily see their existing ones rather than having to remember what common tags they were using. Drag and dropping content to albums fits a user’s mental model better than dragging tags to content; paper prototype testers were sometimes confused with the concept of tagging.

Separate Wells

We divided our types of albums into separate wells. During our computer prototype we had them all together, but this did not provide enough of a distinction.

Deleting Content

Response To: Heuristic Evaluation

When users delete content (from albums or the whole website), an undo alert appears. This necessity for safety was brought up during the computer prototype evaluations. We chose to have an undo because it provides safety and also is more effiicient for a user to click this only when they make a mistake, instead of having to click on a confirmation dialog every time.

Displaying Favorited Content

We chose not to change image sizes in the mosaic if they were favorited. While this was our initial plan, we chose to display images with constant height and proportional width instead. This makes it easier for users to scan content of similar sizes, while our prominent favorites album serves the overall purpose of highlighting favorited pictures.

User Queue Names

Response To: Heuristic Evaluation

We have special lists of content that each user needs to act on. At first we named these “Content To Edit”, but testers were confused as to what this meant. So we renamed them queues, which provided a clearer sense of their purpose.

Content Details Modal

When a user double-clicks on a picture, a modal appears with more details, which users can edit. Other pictures that have albums in common are shown as smaller thumbnails. Double-clicking on this picture will expand it full screen. Clicking on a video will play it.

Modal View

A modal was used over other alternatives (ex, linking to a new page) because it allows the user to easily return, both physically and mentally, to their previous place of browsing by leaving it in the background. The darkened background, however, brings all focus to the modal.

Add To Favorites Action

Response To: in-tutorial user testing

We initially had a star overlayed on the picture that users could toggle to add to favorites. However, depending on the color of the picture, this star was not consistently easily visible. Instead using a link separate from the picture makes it much more obvious; the text makes its action clearer as well.

Upload View

When users select content to upload, Coshare displays a preview screen, so they can review which content they selected before submitting it. Users can also put the content into a new or existing album.

Removing Content from being Uploaded

Response To: in-tutorial user testing

Users can click the red X next to every piece of content to prevent it from being uploaded. This was provided as an extra safety measure.

Adding Uploaded Content To New Albums

Response To: in-class user testing

Users can enter the name of a new album to create a new album containing the uploaded content. The alternative would be only allowing them to create new albums in the browsing page. This would streamline the upload modal; however it would require users to then reselect all of the content they just uploaded to move it into a new album, which is much less efficient.

Mobile View

The mobile screen is very simplistic, allowing the user to select content to upload and then displaying the same preview modal as dektop uploads, but with a size adjusted to fit the mobile screen.

Simplicity

No navigation bar or any other features are visible. This is because the user will have a single action while using mobile- to upload content. All other actions are done much more efficiently on a desktop browser.

Confirmation Alert

Response To: In-class user testing

A confirmation alert provides feedback that content has successfully been uploaded to the site. This is neccessary as the user has no other way of confirming this due to the intentional restrictions of the mobile view.

Summary

Our final design relied on several key relationships. Firstly, Users are each a member of a Couple, in which another user is their Spouse. Each Couple has any number of Children and pieces of Content related to their Children. This Content can be organized in Albums, which are shared between Spouses in a Couple. There are several types of albums, which are explained below.

The interface for our site primarily revolved around the Browse Page.

Albums

Dividing Albums Into Wells

Implementation

Javascript MVC Framework

The front-end of Coshare used a lot of Javascript to poulate the page and respond to user actions. We set up an MVC framework that allowed us to efficiently trigger actions that would clearly update the backend and front-end together and keep them consistent with each other, as well as access any necessary information from the model. This setup kept our code more organized, made it very clear what actions we should trigger in certain situations, and made code easier to understand when looking at our teammates’ work.

A javascript model object contained all albums and their respective content. Actions would fire functions of the album model or overall model. These javascript functions would modify the javascript models, send data to the backend via AJAX, and then would update the front-end with Javascript to reflect any changes.

Bootstrap

Bootstrap was used for a lot of front-end elements, such as buttons and modals. Bootstrap has a very clean design, and it allowed us to spend more time on the user interaction capabilities/experience instead of rebuilding similar assets.

Django

Django was chosen for our backend, as it is simple to use, and members of our group already had experience with it. Django allowed us to set up a very clear MVC model which served our purposes very well. Its flexibility with changing models was very important in the design process as we changed the way our objects were related. In the end, a Couple consists of 2 Users and multiple Albums. Albums contain multiple Contents each with their own metadata. A Content object can belong to multiple Albums. Each User has a queue. Couple also can have multiple Children, each with their own album.

Django templating was very effective in allowing pages to use the same base templates, such as the navigation bar, which allowed more effiecient coding and ensured consistency.

AJAX

Whenever we needed to update the backend with disrupting the front-end usage (ex. reloading the page), we sent data to the backend via AJAX. AJAX interfaces extremely easy with Javascript and DJango, and allows us to update the front-end accordingly when it succeeds. The usage of AJAX allows the user’s interaction with the application to continue without interruption.

Packery

Packery, a Javascript layout library, was used for the mosaic display of content in the browsing view. It was chosen for its ability to fit content of different sizes together nicely, and dynamically adapt to any window resizing.

Evaluation

Who we tested:

We conducted our user testing with members our family that had a spouse and children. Each user uses the computer at a very basic level for simple tasks like emailing and browsing the web. Because they each had a spouse, had children, and had basic computer skills they were representative of the target group of the average couple with children.

How we tested them:

As we tested them remotely, we used screen sharing to see how they directly interacted with our interface.
Each test was tailored to meet the real life specifications of each user (text surrounded with quotes in the briefing and text was changed for each test.)
Accounts were made for each user prior to each test.

Briefing:

Purpose of application: To help parents manage co-owning digital content of their children and family
You are a parent of "list children".
You and your spouse have already created accounts on CoShare and CoShare recognizes you both as each other's spouses.
You have a iPhone with a web-browser.
I have given you a folder of photos that you should put onto your desktop.

Tasks:

Task 1 - Bulk upload and organize content from desktop

Upload these pictures, from the folder I gave you.
Organize them by:
1. Add the pictures to the site
2. You didn't remember "a detail about that event" was so you added the pictures to your spouse's queue to look at and edit.
3. Add the uploaded pictures to a new album that is appropriately named.

Task 2 - Retrieve content added by spouse

Unfortunately you were unable to see "name event in one of the pictures". Luckily, your spouse was their to take some pictures.

Locate these pictures
Mark three as favorited

Task 3 - Mobile upload and desktop refinement

You just took a cool picture of "child" from your phone. Upload it to CoShare via the mobile site.

Upload this picture from your iPhone to CoShare’s Mobile Site.
Login to your CoShare account on your computer.
1. find the picture
2. give it an appropriate description
3. add it to a new album with an appropriate name

Demo:

We did not use a demo because we thought it was unnecessary and would cause us to lose some valuable information from the evaluations.

Usability Problems:

"Add Content" can be confusing, if it is adding it to the site or the selected album.
1. Type: Internal Consistency
2. Severity: Minor
3. Solution: Replace with Upload
"Submit" is not consistent with other sites.
1. Type: External Consistency
2. Severity: Minor
3. Solution: Replace with Upload
Dragging a single file without selecting (clicking on it) it does not work.
1. Type: Efficiency
2. Severity: Major
3. Solution: Consider adding the functionality for this. This could however breach internal consistency.
"Choose File" and always having "No File Chosen" on the mobile site is confusing.
1. Type: Internal/External Consistency
2. Severity: Minor
3. Solution: Replace with Upload button and remove the "No FIle Chosen" field
No idea there was functionality for editing the description and didn't know how.
1. Type: Learnability
2. Severity: Major
3. Solution: Add right click functionality for editing the description as well as a button at the top of the mosaic for editing. (Similar to remove content button)
Confusing that the description when added was not displayed in the mosaic.
1. Type: Learnability
2. Severity: Minor
3. Solution: Add functionality for the users to be able to show descriptions below pictures in the mosaic. Option in account settings or in the mosaic button bar.
Likes the idea of using a trash can album for removing content
1. Type: External Consistency
2. Severity: Minor
3. Solution: Add a static album that when content is added to it removes it from all other albums.
Upload Modal having album selected to "None" gives users the idea that it might not get added to the site even if they submit content properly.
1. Type: Internal Consistency
2. Severity: Major
3. Solution: Change "None" to "All Content"
Upload Modal gets too big and the submit button is inaccessible if the picture height is too big.
1. Type: Bug
2. Severity: Catastrophic
3. Solution: Set a max height for how each picture is displayed in the upload modal. Also, make that div scrollable for an overflow and not the entire modal.
When a picture belongs to too many different albums, the modal height gets too big and the submit button is inaccessible.
1. Type: Bug
2. Severity: Catastrophic
3. Solution: Make that div scrollable for an overflow and not the entire modal.
Submit Query Button's text overflows the size of the button
1. Type: Bug
2. Severity: Minor
3. Solution: Increase size of button or change text to upload
When a user wants to delete a picture, the first intuition can be to right click an image.
1. Type: External Consistency
2. Severity: Major
3. Solution: Add menu that pops up when a right click of an image happens that provides some common functionality
Children albums should be included in list of albums to upload too.
1. Type: Internal Consistency
2. Severity: Major
3. Solution: Add the children albums to the list of albums to add to when uploading. There is a chance that all pictures being uploaded belong to a specific child.
User thought that dragging a piece of content in the queue to a different album may remove it from the queue.
1. Type: External Consistency
2. Severity: Minor
3. Solution: Not a good idea to add this, because this would not remove content from other albums, so implementing this would disrupt our internal consistency. The actual solution would to make the remove from queue button visible at all times (even when content is not selected).
Wasn't immediately clear that double clicking an image would bring up modal.
1. Type: Learnability
2. Severity: Minor
3. Solution: I think the problem is that the mouse over icon changes when a picture is selected guiding the user towards dragging the content. This drives the user to not try double clicking the content. How ever other users didn't have a problem with this so it most likely better to leave the mouse over icons as they are.
Removing uploads from upload modal looks weird
1. Type: Aesthetic
2. Severity: Cosmetic
3. Solution: Have the x icon over the top right corner of the image rather than off to the side

Reflection

We should have worked out our paper prototypes more before starting our computer prototype. we had to do a lot of expensive changing because we hadn't really settled on a design. The paper prototype session was very helpful, and after it we decided to completely change the strucutre of Coshare by using albums instead of tags. With such a big change, doing another paper prototype iteration ourselves would most likely have been very helpful.
We should have focused on the front-end more during the computer prototype iteration, and not even started on the backend. We started the backend in parallel with the front-end in GR4, but spending time in the backend resulted in less time for the front-end. The user heuristic evaluations were all centered around the front-end layout with no expectation of a working backend; redefining our front-end approach would have led to a more complete prototype that could be intricately critiqued instead of critiques about more fundamental problems that just weren’t implemented.

We should have had all members of our team become more familiar with interacting with the backend, instead of relying on one person for it. Teaching the team about Django basics would have allowed more efficient solving of front-end/back-end interaction bugs that slowed down development.

A major thing was starting out as a completely site that would never reload and execute all operations with Javascript and Ajax. However, in some cases it was a better design to use page redirects sometimes instead of AJAX. Considering this choice more before implementation would have saved us trouble, as we had implemented a lot of Javascript functionality that in some cases was no longer even used with page redirects and reloads.

We should have researched more from the start how to deal with content effectively. We didn’t realize that rendering large amounts of content could be problematic. However, our site had issues we had with memory usage of images. This affected usability as users couldn’t upload many full sized images without slowing down page renders. Also, an issue with displaying videos was a function of intrastructure limitations- <video> elements are not very reliable. Testing earlier the assumption that these would work smoothly would have led us to better planning around this obstacle.

However, all of these problems are great learning points for future projects. Having studied and gone through this comprehensive design process, we now have a better idea of how to get worthwhile prototypes to users at low cost, and iterate more effectively on the design. We also have much more defined ways to analyze UI design, which leads to better communication and easier logical decisions as a team.

Child pages

CoShare - GR6