Project Phase 6: User Testing & Final Release
User tests
User test #1
Report
When faced with the initial home page, the user skimmed the “You must be logged in…” message and attempted to click the disabled request translation button. He took several seconds to explore the navigation bar and find the login icon. He explained that he thought the login icon was an “exit” button. The user easily found the button to create a Translation Request, imported the provided document title, author, and content fluidly, and added several tags to the request. When he was asked to add a new Tag that wasn’t pre-populated in the list, he became stuck and could not continue without prompting, until I directed him to the Filter component where he could add a new Tag. When arriving at the Request Description input box, he asked what he should write there, and wrote a redundant description about his request. When looking at the translation page, he was unsure how to translate something and looked for icons indicating where to do that. After this speedbump, he was able to translate a section with ease. When exporting a translation, the user didn’t initially recognize that he could click on a section to see alternative translations. Once he selected to export his chosen sections, he mentioned that he would like to see a popup that confirmed the text was copied. When creating a new Translation Request from an existing document, he had trouble finding the correct icon on the Translation Request preview and mentioned that it was not an intuitive symbol. Overall, he found that the app was very functional but the layout was not as intuitive as it could be.
Opportunities for Improvement
- Location of place to create Tags is not obvious (physical, critical)
Why: This issue is currently occurring because the form to create a Tag is currently in the Filter component, which is unhelpful because a user would be prompted to create a Tag while they are in the Translation Request form Future design: We plan to move the create Tag icon/form into the Translation Request form so that when a user needs to create a new Tag, they can do that without leaving the page
- Login and Create Translation Request icons don’t represent functionality well (physical, major)
Why: The Login icon was described as looking like an “exit” button, and the Create Translation Request button was not understood at all Future design: To remedy this confusion, we will change the Login icon to a Profile icon, which is a more familiar interface that represents User actions. We will replace the Create Translation Request icon with the icon used for Viewing Translation, which better represents the act of translating.
User test #2
Report
Starting off, in the main page, the user saw the login page, but was confused for a second on how to actually login, and scrolled down to view some documents, before he saw the actual login page and created an account. Then, he started doing the tasks described in the task list. He first mistook the filter to be the translation request creation interface, and only after he clicked the translation request button did he realise he was doing something wrong. In the translation request creation page, he did not see the language he wanted to translate to, and I had to step in to show him where it actually is. When creating the language he wanted (Azerbaijani), he was a bit confused as to what name to put down, as the language has many names depending on who you ask (just from the language's wikipedia page: Azerbaijani, Azeri, Azeri Turkic, Azeri Turkish) Moving onto the searching document task, he found the filter super intuitive, now that he didn't mistake it for the translation request page. Afterwards he focused on translating a document. While translating, he seemed a bit distracted, and while asked about it, he seemed the interface was a bit too cluttered. It was great while you were analysing the overall document, looking at other people's work, but when you were translating, he said he only wanted the original text and what he was translating. Moreover, he was translating into Azerbaijani on an English keyboard, and even though Azerbaijani uses the Latin alphabet, he still didn't have easy access to some of the unique letters in the language's alphabet (ə). While exporting the translation, he didn't like how the text on the screen seemed to move around a lot, but he found the general idea very intuitive.
Opportunities for Improvement
Language Creation (conceptual, major) Right now, languages are created freely by users as tags, this has the convenience of being both free to understand, and implement. However, having them as their separate concept, and have them created and maintained by some central authority could have a lot more advantages: Getting rid of confusion about names of languages, adding additional language-specific features to make translating easier, etc…
A Separate Interface For The Act Of Writing A Translation (physical, medium) Doing a translation can often be a very difficult activity, especially academic material. Having any other information on the screen during the act can be very distracting, so it might be a good idea to create a separate minimalistic interface for translating sections.
User test #3
Report
At the main page, I asked Maria to create a translation request from “Cien años de soledad” to English. She tried to click a forbidden button several times, until she asked me, “Is there any other way to create a translation request besides this button?” I told her that she should read the banner at the top of the screen. Then, she created her account and was able to create the translation request. However, she was staring at the screen for several seconds trying to figure out where her translation request ended up. Maria also didn’t see the button to translate a document to a different language right off the bat. I saw her looking at the screen puzzled. Furthermore, I noticed she was struggling to get to the year 2013 with the year slider. Besides that, she said that “the filter is super cool, except the year slider—biggest hurdle”.
Opportunities for Improvement
- Year slider (physical, moderate)
Why: The year slider gets too narrow for small intervals. It’s hard to dominate the mouse. Future design: Increase the distance between two years.
- Submit translation request button does nothing when clicked and user is not logged in (linguistic, major)
Why: Maria clicked several times on the same button and didn’t understand why it wasn’t working. Future design: When clicked on the button and it is not allowed, show a tooltip telling the user to log in.
Design revisions
From P5:
Change: Change location of adding Tags
Rationale: Users had issues locating the add Tag form. The form to create a Tag is currently in the Filter component, which is unhelpful because a user would be prompted to create a Tag while they are in the Translation Request form. We moved the create Tag icon/form into the Translation Request form so that when a user needs to create a new Tag, they can do that without leaving the page.
Change: Delete Request Description input
Rationale: The Request Description input box caused confusion to the user as they did not know what additional context would be helpful to provide in the request. The user spent time trying to come up with a description that ended up being redundant. We deleted the Request Description input altogether as we don’t foresee it adding additional value to our Translation Request.
Change: Change Login and Create Translation Request icons
Rationale: The Login icon was described as looking like an “exit” button, and the Create Translation Request button was not understood at all. To remedy this confusion, we changed the Login icon to a Profile icon, which is a more familiar interface that represents User actions. We replaced the Create Translation Request icon with the icon used for Viewing Translation, which better represents the act of translating.
From P3:
Change: Added create new request, export translation, and view translation icons
Rationale: Initially, the user would have to click on the translation request preview in order to navigate to the translation view for that request. Only from there could they export the translations or create a new request from the same document. However, in our current iteration, we added button icons with hover tooltips to inform the user of the action of each button and to accelerate the exporting and requesting option for experienced users.
Change: Scoped down implementation to remove AccessControl concept
Rationale: Initially, we wanted to give the users the ability to limit who had “viewing” and “translating” access to their uploaded documents. In that way, they could pick what translators to share their requests to based on the stats on their profile. Now that we do not have the functionality implemented, we can foresee how this affects the case we made for our app in our impact case: 1) users may have protected or copyrighted work they are hesitant to upload to the app [con], 2) with any users able to view and translate a document, the app invites more academic collaboration and allows everyone to practice their lingual skills [pro]
Change: Create Export Translation page instead of a form for each section
Rationale: In our original wireframe, when a user exported a document, a popup appeared and displayed each section one by one, with the original section on the left and translated sections listed on the right. Then, the user had the option to select their desired translation for each section. In our revised design, we decided to have a separate page, with a layout very similar to the Translation page, displaying the highest voted translations by default. Then, again similar to the Translation page, the user has the option to click on a section to view the alternate translations and select one. This allows the user to see all of the translated sections at once, and also improves the efficiency and learnability of the export function.
Change: Disallow users to choose how the document that was requested for translation gets separated into sections.
Rationale: We made this change for two main reasons: Firstly, if the user is misinformed (or maybe ill-intended), he can mess up how the document gets split into sections. This would divert the cooperative efforts of the users into a suboptimal efforts. Secondly, we realized that even the basic algorithm we first implemented seemed to work surprisingly well, and in the future it can be improved upon very easily.
Change: Remove Tags and Upvotes to multiple concepts
Rationale: In our initial design, we had it so that users could upvote both SectionTranslations and TranslationsRequest, and we could have any Tag for both Documents and TranslationRequests. . We decided to change this to only have Upvotes for SectionTranslation, and only allow language tags for TranslationRequests and only allow other tags for Documents. We thought this was a good idea because these concepts are so tightly connected together that it was somewhat unclear what the distinction between Upvoting a SectionTranslation and a TranslationRequest was, or between tagging a TranslationRequest and a Document, and which would be appropriate in a given context.