Right now we have a glossary system running on https://padma.io which is based on a frontend built on Vue 2. Moreover, there is the issue with the implemented UX arising from the fact that when it was originally specced, not all assumptions were correct.
User Story
Instead of describing all the features here in detail, we assume as our basis the current system running on https://padma.io exactly as it is and then clearly differentiate how in this current spec we will deviate from that.
Here we will take the current system running on https://padma.io as the basis.
What is being introduced?
This RFW does introduce any new technical requirements, as it focuses only on producing the front end.
What is changed?
This has two parts. One is regarding the default, which is the user not having logged in. The other is regarding when the user has already logged in.
First, regarding the user not having logged in.
The tabs will have one more, PARTIAL, and TIBETAN will change to EXACT so it will end up EXACT, PARTIAL, and DESCRIPTION in that order (these will double up as a search button, so if there is a value already in the text area then the corresponding search function will be performed upon clicking any of the tabs)
The text area will become a single-line text box
Tokenize will be removed
The search button will say SEARCH and will not have options like now
The dictionary selection needs to be improved so that it becomes very easy to select all and deselect all except one
Right now the results page text is far too small, that is what the user will end up spending the most time with, so it has to become much bigger, it will be automatically truncated after 5 lines, with read more at the end of the truncation which expands that result
Second, regarding the user already having logged in.
All the same changes as above
It will remember your last configuration
Is This Really Necessary?
It is. There are many good reasons for why we can't continue simply by adopting the current system running on https://padma.io.
Motivation
Glossary is one of the most important and frequently used auxiliaries for translators, and is, therefore, a critical part of the Lopenling ecosystem.
Named Concepts
NA
Examples, Risks & Assumptions
Explain concretely what will manifest as a result of this RFW.
First, the frontend design and associated artifacts will manifest. Second, the frontend design will be plugged in with the backend.
Explain how is it different from what is already manifesting i.e. what we already have?
We don't have frontend at all for glossaries in Lopenling.
Explain what users/brands will experience as a result of this RFW. How will they feel as a result of it? How will they benefit as a result of it?
They will be able to manage their dictionaries in a single location and access it as part of the integrated experience they are having with Lopenling.
If applicable, provide sample messages for any new messages the system will display as a result of this RFW.
This can be handled once the designs are ready and it is clear what messages will be required.
Define what is out of scope in this request.
Everything to do with the backend part is out of scope.
What are the data protection, privacy and security assumptions made for this request (example, should this be GDPR, compliant etc)
None
Explain how this user story will be supported (i.e. customer support - if the user story fails technically, how will the user be supported).
It will not be supported.
Explain how this user story impacts revenue or billing (if applicable).
NA
State any additional risks identified as a result of this user story.
The only alternative would be to just adopt what we have in https://padma.io already. This anyhow is not a good approach, and this can be seen through the points already made in the above sections.
New Data
None
Business release date
The design part is to be completed post to having completed any frontend design requirements in:
Table of Contents
Housekeeping
None
ALL BELOW FIELDS ARE REQUIRED
The Problem
Right now we have a glossary system running on https://padma.io which is based on a frontend built on Vue 2. Moreover, there is the issue with the implemented UX arising from the fact that when it was originally specced, not all assumptions were correct.
User Story
Instead of describing all the features here in detail, we assume as our basis the current system running on https://padma.io exactly as it is and then clearly differentiate how in this current spec we will deviate from that.
Request Type A/B
This RFW is Type-A.
It connects with the following RFWs:
Most importantly, it is paired with the backend part:
Owner
mikkokotila
Summary
Here we will take the current system running on https://padma.io as the basis.
What is being introduced?
This RFW does introduce any new technical requirements, as it focuses only on producing the front end.
What is changed?
This has two parts. One is regarding the default, which is the user not having logged in. The other is regarding when the user has already logged in.
First, regarding the user not having logged in.
PARTIAL, andTIBETANwill change toEXACTso it will end upEXACT,PARTIAL, andDESCRIPTIONin that order (these will double up as a search button, so if there is a value already in the text area then the corresponding search function will be performed upon clicking any of the tabs)Tokenizewill be removedSEARCHand will not have options like nowread moreat the end of the truncation which expands that resultSecond, regarding the user already having logged in.
Is This Really Necessary?
It is. There are many good reasons for why we can't continue simply by adopting the current system running on https://padma.io.
Motivation
Glossary is one of the most important and frequently used auxiliaries for translators, and is, therefore, a critical part of the Lopenling ecosystem.
Named Concepts
NA
Examples, Risks & Assumptions
First, the frontend design and associated artifacts will manifest. Second, the frontend design will be plugged in with the backend.
We don't have frontend at all for glossaries in Lopenling.
They will be able to manage their dictionaries in a single location and access it as part of the integrated experience they are having with Lopenling.
This can be handled once the designs are ready and it is clear what messages will be required.
Everything to do with the backend part is out of scope.
None
It will not be supported.
NA
None
Success Metrics
We have introduced world-class UX for https://glossary.lopenling.org.
Conceptual Design
Whatever the above sections provide suffice.
Drawbacks
None
Alternatives
The only alternative would be to just adopt what we have in https://padma.io already. This anyhow is not a good approach, and this can be seen through the points already made in the above sections.
New Data
None
Business release date
The design part is to be completed post to having completed any frontend design requirements in:
The frontend implementation part is to be completed post to have completed: