Project 5
Deployment
Design Revision
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.
Task List
| Title | Instruction | Rationale |
|---|---|---|
| Submit Translation Request | Given an academic research paper, create a request to translate that document into another language. | Submitting a translation request is an essential functionality of our app. We’re interested to see if the user experiences any friction in filling out the required fields from the document, in particular choosing/creating a tag and uploading the document content. |
| Request to translate an existing document to another language | Create a request to translate an existing document on the website into a different language of your choice. | We want to discover if our interface is successful in directing users to “duplicating” an existing translation request with a new language rather than creating a new one (copying & pasting content from the original) |
| Search for a document | Search for the document that fulfills the following criteria: requests an English -> Turkish translation versa, is published after 2013, and is related to computer science. | We want to test whether the filter component provides users with an efficient and intuitive way to search through translation requests and documents. We’re looking at how users map different filtering criteria to each input component. |
| Translate a section and edit it | Translate as much of the searched document as you’d like into your chosen language. After publishing, make an edit to your translation(s). | We would like to see if our design makes an appropriately sized split of text for users to feel comfortable translating both a practical and impactful amount. In addition, we would like to determine if the physical placement of our input box next to the original text makes it easy for users to translate a section as conveniently as possible. |
| Export a translation | For the searched document and translation, combine the translated sections into a single translated document and copy it to your clipboard. For the section you have translated, choose to export that section | We want to study whether the user is able to find and navigate the export translation page easily, especially the action of selecting one of many section translations to export. |