StageIt

Unknown macro: {pagetree2}

GR6 - User Testing

Final Design

Task

Screenshot

Explanation

Signing Up/ Logging In

The login screen is simple and has an obvious signup container, along with a login area.

Creating/Selecting a Project

The dashboard lists saved projects for the user to choose to open.  The green button allows the user to start a new project - a dialog will pop up asking for the name of the new project.  We chose to keep functionality low on this page, so you can only create and choose projects.

Selecting a Stage

This is the main interface - the area where the user will make all of the edits to the formations.

Heuristic Evaluation:  The original computer prototype forced users to choose a stage before having access to any other function, so it was very limiting.  The current model flashes a tool-tip as soon as the project is first open, suggesting the user to select a stage first.  Another option was to have a default stage, and users would have to explore and find out they can change the default.

Editing Formation Name

When the user hovers over the current formation name (indicated in green), the tip to click and change the name pops up.  However, it was not intuitive to users to hover over that label.

Heuristic Evaluation:  The way to change the formation name was not learnable, so we added the tool-tip and editing icon that pop up when the user hovers over the label.

User Testing:  Each of the users we tested tried to double-click on the title under "Formations" (indicated in red) to change it.  This was not an implemented function.  

Other options:

  • When clicking save, allow users to change the formation name if they have not already done so.
  • When creating a new formation, force them to give the formation a name.

Edit Stage

Heuristic Evaluation:  Having blank divs with labels was not pleasing and did not indicate what the stage would look like.  Now, the options are clearly shown with images and labels, showing the user exactly what will happen when he chooses a stage.

Adding Dancers/Props

Paper Prototyping:  During the paper prototype, users had to click through multiple dialogs to add dancers and props.  For the computer prototype, we put it all together onto one dialog.

Heuristic Evaluation:  It was suggested to have a drag and drop system, but we went with the current model because it was efficient to add multiple dancers at once.

Changing Dancer Name

In the "Add Dancers" pop-up, there is a tip under the dancer preview (indicated in green).  Users would have to read the tip in order to know the default names are editable.

Heuristic Evaluation:  There was no way to know that double-clicking a dancer allowed you to give it a name.  By giving each dancer a default name, we made it apparent that text in the shape is an attribute.  The tip in the pop-up clarified how to edit it.

Other options:

  1. During presentations, we were also given the suggestion to allow the user to enter multiple names in the "Add Dancers" prompt, and these names will be used instead of the default "Dancer".

Moving a Dancer

In this model, we highlight the dancer/prop that is being moved.  

Heuristic Evaluation:  Users did not like that shapes change size to indicate they are being moved.  It was not externally consistent with any other program.  This attribute confused the user as to the shape's actual size and made it difficult to arrange dancers because sizes were skewed while moving.  Highlighting worked much better.

Arranging Dancers

Selected items can be arranged automatically.  If none selected, all dancers will be arranged. 

Paper Prototyping:  Users almost always overlooked this feature because it was hidden amongst other tabs.  To fix this, we put these under the "Tasks" header, to show that it is an action.  

Heuristic Evaluation:  In earlier prototypes, users chose the arrangement through radio buttons, and it was difficult to picture how the dancers would end up.  Now they can select based on these image icons, which is consistent with the Stage and Prop dialogs.  Also, it was not apparent that you can select specific dancers to be moved/which dancers were going to be arranged, leading to safety issues.  

User Testing:  We emphasized the select tool to push users towards learning that specific dancers/props can be arranged.

 


Tool Bar on Top

Layout choice:  We moved the toolbar to the top of the canvas - change in design choice.

Heuristic Evaluation:  We decided to move the tools to the top of the layout and lay them out horizontally in a toolbar because they are easily accessed this way.  Earlier, it was under the Formations menu, which put it farther away from Tasks and was not optimal functionality-wise.  By placing them in the toolbar, we also had space to give each tool a label, so it was not necessary to hover over the icon to see what it could do.

Resizing Items

Heuristic Evaluation:  At first it is not apparent that items can be resized.  But when trying to move them, sometimes the user would accidentally resize it.  To fix both of these issues, we added the resize toggle button in the toolbar.  This showed users that things were resizable and gave them the control to turn it on and off (for safety issues).

Selecting Multiple Items

The select tool was added to the toolbar, to make rearranging dancers more efficient. 

User Testing:  However, there were some more features related to selecting that the users expected: 

  1. Users wanted to be able to drag and highlight multiple items, as well as use keyboard shortcuts (like ctrl).  The current click-and-select is inconsistent with other programs and is inefficient.
  2. Users wanted to be able to change the sizes of the selected items simultaneously.

Drawing, Moving, and Deleting Arrows

Users can draw straight arrows, draw freeform arrows, and move arrows. 

Heuristic Evaluation:  Users can now drag and delete arrows instead of only being allowed to undo them.

Tabs on Top

Heuristic Evaluation:  The New, Undo, Redo, and Save buttons were not as eye-catching before, and were outside the canvas work area; these gave them the apparence of being separate from the whole editing process.  Now they are placed in tab-like buttons, to have external consistency.

Creating a New Formation


There are two ways to create a new formation - one button is in the top tabs and the other is under the list of formations.  It is in both locations for efficiency.

For efficiency and safety, the user is asked whether he wants to keep the same dancers for the next new formation.  This option always showed a positive result in paper prototyping, heuristic evaluations, and user testing.

Undo/Redo Functionality

Everything done on the canvas can be undone/redone.  This is for safety and efficiency, and the buttons are externally consistent with many other programs.

Saving a Formation

Heuristic Evaluation:  There was no feedback that the formation had been saved successfully, so now a label slides in (animation).  It's green and has a checkmark, giving it a positive connotation.  It also disappears after 5 seconds, to de-clutter the toolbar, while giving the user enough time to read it.

Other options:

  • This label can also be used for other feedback/indicators, after any major event.

Deleting a Formation

To keep deleting safe, the user is asked to confirm the deletion of a formation, and is told the action cannot be undone.

Changing Project Name

Individual project settings can only be found on the editing page of that specific project.  This menu allows you to rename the project.  Ideally, we would also have this option on the dashboard, but since editing is our main focus, we've only included it here.

Log Out

The logout option is externally consistent with all other programs - the option is under the username.

User Testing:  No one had any difficulty logging out.

Implementation

StageIt was implemented and hosted with Parse. The pages of the app are created using standard HTML, CSS, and JavaScript/jQuery. Twitter’s Bootstrap was also used to style the pages, though the bulk of the project page was created with standard CSS. The app consists of three HTML pages - the signup/login page, the dashboard page, and the project page. When a user first navigates to stageIt, if they have already logged in, they will be directed to the dashboard page. If not, they are directed to the signup/login page.

In the Parse database, Formations and Projects are stored in separate tables. Each Formation has a reference to the parent Project and a User, and each Project has a reference to a User. Users cannot have Projects with duplicate names, though this is allowed with Formations because the order is preserved.

The dashboard page displays all of a specific user’s projects by making an asynchronous query to the Parse database and returning the results into a table. When a user tries to create a new project, they are redirected to a page that automatically creates an untitled first formation in that project that is saved to the database. The user can click to see an existing project by clicking on the project in the table. They will then be redirected to the project page where they can see and edit the existing formations for the project.

In the project page, we created the stage with two HTML5 canvases - one to represent the stage selected by users and the other for users to draw arrows. We also used the Easeljs library to create a canvas that allowed for dragging and dropping of drawn arrows. The dancers and prop objects were represented by images, and we supported the use of three different shapes for dancers in four colors, and 5 different prop images. Dancer and prop objects were made draggable and resizable using jQueryUI. We used JavaScript to implement the functionality of the tasks and tools (ex. drawing arrows, arranging dancers).

Users are able to undo or redo all edits made to formations, which includes adding dancers/props to the stage, moving objects on the stage, naming objects on the stage, and deleting objects on the stage. However, they are unable to undo the deletion of an entire formation, due to the implementation of the backend - once we delete a row from the Parse database, we would not be able to recover it. For safety, we notify the user with a confirmation box telling them that deleting a formation is not undo-able.

Implementation Problems

Backend - this took up a lot of time since we initially didn’t know what framework to use (PHP, Rails, Parse, Node.js, etc), and we weren’t very familiar with server-side web-development. Once we chose Parse, structuring the database and the website in a way so that users could easily switch between formations in one project was difficult (and is still not fully supported). One of the usability problems due to this issue is that if a user accidentally refreshes a project page that they have just created, then the page will create a new “Untitled Formation” automatically, and will add it to the project. 

Evaluation

User Population

As stated before, our target population was choreographers and dance directors who are looking for a better way to illustrate their designs. The users we tested are choreographers for various dance groups at MIT, such as Fixation, Dance Troupe, and the Bhangra Team. All 3 of them are all current MIT undergrads who do choreographing in their spare time, but they all do different styles of dancing: hip hop, contemporary, and bhangra. This being said, we were unable to test professional choreographers for this task, but with the trained hand of an MIT student, I think we got close enough.*

User Testing

We modified the initial test from our prototype to include some new implemented features:

  1. Create an account and make a new project with your first formation.
  2. Name this new formation Blues Enter.
  3. Create a semicircular stage in this first formation.
  4. Add 5 blue circle dancers to the center of the stage in a vertical formation..
  5. Give each dancer a different name.
  6. Save the current formation and create create a new one, with the same dancers on the stage.
  7. Name this formation Green Enter.
  8. Add 5 more dancers to the stage as green triangles.. Move all dancers into 2 horizontals lines in the center of the stage
  9. Add 2 arrows to the stage, pointing outwards from the lines of dancers.
  10. Make one last formation, so save this one and make a new formation titled Circle Time.
  11. Move all the green triangles off stage.
  12. With the remaining Blue circles, arrange them into a big circle.formation
  13. Add one last prop, a flag to the center of the circle.
  14. Save and logout.
    We encouraged  the user to explore the interface while performing the tasks, and we also encouraged mistake-making such that they would be able to use the undo and redo functions. We decided a demo was not needed, as one of the main focuses of our interface was learnability.
Usability Issues

These are problems that each user encountered as we did one final round of user testing with our final prototype:

Issue with...

Users

Severity

Possible Solution

Renaming a formation

The first impression of each user tested was that double clicking on a formation listed in the formation panel would allow them to rename the formation. This is not permitted as we thought that it would allow users to misclick and click away from whatever their current formation is.

Moderate

Solution: Implement the double click as a way to rename the formation, in addition to the current implementation of allowing a click on the name at the top. We could also make it more obvious to the user that they could rename the formation through the current means.

Formation Selecting

When selecting the default arranging of dancers, the expected behaviour of the user is that they will be able to move all of the dancers at once as if they are selected, so they would essentially be moving the whole formation. This was not implemented.

Moderate

Solution: Implement selection such that an arrange with no one selected will select all.

Select Tool

Prompt to confirm select is not apparent to the user at first glance, as they will try to move the selected items without confirming the total selection.

Moderate

Solution: make the prompt more obvious by changing location to a more central location on the screen, for example the top left or top right. Or make the contrast greater, by changing the color with respect to the stage.

Select Tool

Having a multiple select box would be helpful. To maintain consistency with other programs like powerpoint, having a click and drag box such that you will be able to select multiple dancers at once without individually clicking them all does a lot for efficiency

Major

Solution: Implement a box with the selectable jquery class

More select Tool Issues

Select to arrange was unclear on first try, but on second try the user was able to figure out how to select in order to arrange only a couple of dancers, and not all of them.

Minor

Solution: link arrange and select together, allow the user to select some or all before prompting for a arranged formation, or move the select button to be clearer. Overall it would decrease the efficiency of the formations minimally by adding an extra prompt.

Rename Project/Formation

One user could not tell the difference between a project name and a formation name. Renaming the project name, which is under the Project Settings tab,
could be confused with changing the formation name.

Minor

Solution: make the abstraction of formation and project clearer, don’t make this setting editable in a tab connected to the stage formation edit.

Offstage

The area for offstage is a bit unclear, and there might not be enough room to hold more than 10 dancers in each area of the offstage.

Cosmetic

Solution: make an offstage “drawer” on each side, such that you can stick dancers in each drawer and hide them, accessing them only as needed.

Resize Ability

When selecting multiple dancers, you could also allow resize, as well as move, delete, and arrange

Minor

Solution: Another feature that is expected that we could implement.

Notes Box

Clicking on the text in the Notes box does not allow the user to edit the box, clicking anywhere else will prompt text.

Major

Solution: make the text as well as the whole box clickable, so the user can edit the text box.

Other feature suggestions:

Stage markers in the form of a grid, editable by the user to accomodate each stage.
Invert Selection possibility
Add more keyboard shortcuts, or a keyboard toggle for resize as well as more shortcuts.

Overall the program was very accepted for being an extreme improvement with respect to previous methods of choreographing, and everyone is very enthusiastic that this is a palpable object now.

Reflection

We’re really excited and proud of what we’ve accomplished this semester.  Going through the design process was tedious and difficult, but our website would not be in the state it is without the constant thought of “How can we make this more usable and intuitive for the user?”  In fact, we’re so dedicated that since the website is not perfect yet, we plan to keep working on it this summer, continuing to use the iterative design process.

Design stage: 

Paper prototyping was very helpful in coming up with new ideas. We realized that what is obvious to us is not necessarily obvious to other users, especially when it comes to wording. For example, the wording for “Arrange Dancers” had to change in each prototype we made before it was immediately obvious to users of the system. Though we initially had trouble coming up with designs that were sufficiently different from each other, this was actually very helpful during the implementation stage. We looked back on our previous designs after getting heuristic evaluations to see ways to improve certain aspects of the interface.

Implementation: 

Though the user design stage was important and informative, because we had primarily no web development experience, the actual implementation of the interface proved to be  the most difficult part of the project. We had to leave certain things out of the final implementation that were included in the prototype simply because they were out of the scope of the class, and were more than we could do in the given time. If we could do it again, we would probably try to make sure that everything in the prototype was something that could reasonably be done in the time of the semester.

During the implementation, we continued the iterative design process in an effort to make things as usable as possible, with the help of the heuristic evaluations. Some of the evaluations gave very helpful tips on making the interface as usable as possible, and we realized how important it was in getting people familiar with principles of usability and who were unfamiliar with the project to test the interface. Things that were obvious to us weren’t necessarily obvious to others.

Usability of the interface aside, the backend of the interface was actually very important to the project, and if we could do it again, we would try to get this sorted out earlier in the implementation so that we could focus more on the actual interface. Given that neither of us had experience developing the backend of web applications, WeTriedGoldStar.jpg :)

User Testing:  

If we were to do it again, we’d be a little more open-ended with the tasks.  We had the problem of making our tasks so strict, the users rarely deviated from them and explored the interface.  They followed the rules so strictly, they never had to use Undo and Redo.

One thing we did well was user test on a variety of users within the choreographer category.  We tested on experienced and inexperienced choreographers, and spanned through different levels of web development experience.  The diversity of our users gave us a valuable variety of input which we put towards our implementation and evaluations.

  • No labels

1 Comment