StageIt
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. |
||
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.
|
||
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. |
||
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.
|
||
Moving a Dancer |
|
In this model, we highlight the dancer/prop that is being moved. |
||
Arranging Dancers |
|
Selected items can be arranged automatically. If none selected, all dancers will be arranged. |
|
|
Tool Bar on Top |
|
Layout choice: We moved the toolbar to the top of the canvas - change in design choice. |
||
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.
|
||
Drawing, Moving, and Deleting Arrows |
|
Users can draw straight arrows, draw freeform arrows, and move arrows. |
||
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. |
||
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.
|
||
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. |
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:
- Create an account and make a new project with your first formation.
- Name this new formation Blues Enter.
- Create a semicircular stage in this first formation.
- Add 5 blue circle dancers to the center of the stage in a vertical formation..
- Give each dancer a different name.
- Save the current formation and create create a new one, with the same dancers on the stage.
- Name this formation Green Enter.
- Add 5 more dancers to the stage as green triangles.. Move all dancers into 2 horizontals lines in the center of the stage
- Add 2 arrows to the stage, pointing outwards from the lines of dancers.
- Make one last formation, so save this one and make a new formation titled Circle Time.
- Move all the green triangles off stage.
- With the remaining Blue circles, arrange them into a big circle.formation
- Add one last prop, a flag to the center of the circle.
- 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, |
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.
1 Comment
Sarah E Lehmann
Overall: Well done!