SPIKE: What does it take to implement the new design

[EllDoubleYew]

Comment on this issue a good writeup of what all needs to change both on the backend of core and react components themselves (which ones need to be rewritten?)

[EllDoubleYew]

So in no particular order I will try and list out each of the epics that encompass the implementation of this design. Under each are good places to start assigning tasks but are not "committal" in the sense that I am not guaranteeing more or less will be required for each of the tasks. Some I may start to describe the technicalities just so that it is more evident of how a task may be more or less involved than it looks on the surface but I will try and keep this higher level in general.

Create the status bar at the top of the screen

• Generate a "path" to the current check (i.e the "Luke > Translation Words > Angel")
• Bring the online status back again. Probably wont be too bad because we have implemented this type of feature before.

Implement the new navigation menu

• Make the current menu collapsible using the chevron arrow to drop everything down.
• Implement a sliding "drawer" for selecting books and checks. This is going to be used all over the navigation menu so it needs to be as generic as possible so that we can call it from some prop on the top level component of our navigation menu and populate it with whatever component we need. There may be a better implementation for doing this but that is the first thing that comes to mind.
• Build out the chevron system so that we can populate them with whatever we want in terms of the book name and the type of check. This component should know when a project is loaded and when a check is loaded so that it knows how to render (i.e when you are loading a project you shouldn't see the blank chevron for loading a check yet).
• Create a component that lists out all of the books that a checker can load in. This can be seen in the third panel of the screenshot above. I would assume that each book in that list can be replaced with a locally stored tS project/tS project saved to a repo on your Door43 account since we wont always have every book available. This component will be passed into our sliding drawer menu and should also be able to populate the chevrons.
• Move the select app menu into the sliding drawer for when you load a tool after loading in your project. This will be responsible for populating the current check chevron as well as initiating a project load. This is represented as the fourth panel in the mock-up above and will lead straight into the fifth.
• Load the list of words or phrases into the navigation menu. This will be the only critical changing information that will be held in the navigation menu itself rather than in the sliding drawer so its important that this is addressed carefully.
• Implement the completion circles seen next to each of the words or phrases seen in panel five. There are some really complicated implementations of reflecting the completeness of each word or phrase very accurately along with some more "hacky" solutions that would display the same information in a way that is a little less accurate. In the end each word or phrase should start as an empty white circle and slowly work towards a full blue circle with a full blue dot in the middle when each check in that category is complete.
• Load in the list of verses to be checked in our sliding drawer to the right of the navigation menu when a check is being performed.
• Align the current check with its category and highlight it blue across the category and check so it is visually implied that it is your current check.
• Use an arrow above and below the current check in the list of checks as seen in panel five. This will effectively replace our next and previous buttons in the current build.
• (This one is optional but worth looking into) Experiment with one of the many react animation libraries. Some of the changes the menu will frequently be going through would make more sense to the end user if the navigation bar changed in a more fluid way. This is ultimately up to Klappys prioritization but I think that it would give a lot more polish to our final product. Here is a good place to start looking.

Implement the new "T-Pain" (Which I vote we call "Scriptural Pane Organized Notationally by Group Environment" or S.P.O.N.G.E)

• Assuming that plus button shows or hides this content (May need Thomas to chime in on this one so that I am not missing something) a good start would simply getting a collapsible that visually looks like the sponge. It would just be a blank container with the "[+] Add resources" inside of it as a button that does nothing.
• Build out the front end to support a potentially infinite number of resources to be displayed in this drop down menu. As they are added the "[+] Add resources" button should scoot over and if it gets too wide you should get a scroll bar across the bottom. We are given a space for resources that can go much further or not as far as the late tpane and we need to capitalize on that flexibility in our implementation. Ideally we should have an abstract resource component that the add resources button can be a part of.
• We need a workflow for adding a new resource. I am not too sure what that looks like yet but we could start with a modal that displays a list of the UGNT/ULB(For GL)/TL for now because those are the three resources we have available right now. In Luke's world you would click one of these resources in the modal, it would call an update to the core store about what information should be in the sponge and the sponge should be updated to reflect the core store.
• We need some information in the core store about what resources are loaded. Each time the user adds a new resource we need to load that into the core store and have the sponge reflect this information in the store. This is the only back end change that we should need to make to implement this new resource display.
• Highlight the current word or phrase that we are looking for inside of the resource. Each resource component should have some flag that lets us know if that information is available so that we don't waste time looking for information that does not exist.
• Create a close button in the top left of each loaded resource that effectively removes that information from the core store and then the sponge itself. In doing this all of the content around it should fall back towards the left side of the screen.

Implement the new translationAcademy display area

• The menu should slide in and out when you click the arrow on the right side. Arrow points out when its slide in and points in when its slid out.
• The word or phrase and its definition should be displayed at the top of the area with a horizontal line rendered below to separate it from the translationAcademy information.
• Render the translationAcademy resource down below the definition of the word that we are checking.
• Allow the translationAcademy resource to "pop out" of the main window. Clicking this should pop out the entire component that was in that menu and completely hide that collapsible menu and the arrow to expand it. Closing this window will bring it back into the main view.

New selection area This is mostly styling changes but I will still try and break down all the changes that we are going to need to make. We are actually simplifying the current component quite a bit by segmenting off a lot of this information. In my opinion this still still necessitates a rewrite of the targetVerseDisplay component that we currently have.

• Display the target verse to the right of our flag display and remove the well that is around it right now per the design specs.
• Implement the slider bar for marking words/phrases correct or flagged. If we want a click and drag effect to be a part of this we are going to have to implement some sort of canvas over the component or use some animation library to make it look right. A good start would be clicking on the right side marks the word correct in context and clicking on the left side would flag that word for review.

Implement the new propose changes area Again this is mostly styling but we still probably need to rewrite the current component that we use for this.

• While it is not show in the mock up above my understanding is that this component should drop down as well. So just as we have done for the other components, lets start off by getting a simple drop down working (Stylistically modified react bootstrap panels may be the best way to go for these since they are small and fall vertically but thats up to the implementer)
• Use a text box where the user can type a word or phrase that they are proposing the selected word be changed to. There is no saving to continue, everything you type in this box should update the check store in real time.
• Add a collection of check boxes with "Spelling", "Punctuation", "Grammar", "Word Choice", "Meaning", and "Other" under the text box. Ibid on the whole check store thing.

Implement the new comments box

• Implement the basic drop down as we have done with the previous components. We can drop down into a modified version of the current notebook paper that we are using for comments. It looks like Thomas has opted for college ruled over the wide ruled which I am a fan of so lets be sure to reflect that.
• Since save and continue is gone we need to be updating the check store as the user is typing. We cant depend on any way that they might decide to change checks or if they even change the check at all and the last thing we want to happen is for people to lose work. Lets make sure that the check store reflects the screen.

[mannycolon]

Side Nav Bar Component: Because of the action that is now expected from the tC logo on the side nav bar component, based on the new mockups, the logo should now be its own component that will hold:

• The side nav bar component (that includes hierarchical ordered buttons (will explain below) ).
• The Check Menu view. (In other words, will contain the list of words/phrase to be checked).

Thus, the tC logo will act as a switch button that will toggle views from the checks list to the side nav bar component or vice versa.

tC logo: Clicking the tC logo will change what will be displayed on the left side of the app. The new mockups give me the impression that we should order the side nav bar buttons in a hierarchical order. In other words, when the user opens the app the buttons will render on the screen in an on-demand fashion. so this means that the sign in / login button will be the first button to be render and then the rest of the buttons will render one by one based on an order that could be the one suggested below by myself or determined by the stakeholders.

1. Login: Rework the login component so that it allows non-door43 account holders to save an alias/nickname to be used or attached to the projects h/she is working on.

2. Load: Once the user is signed in or an alias/nickname has been slected, the Load sidebar button will render on the side nav bar component and then the load your project modal will open.

3. Tools: Once the user has loaded a project the Tools sidebar button will render on the side nav bar component. Then if no tool has previously been downloaded then the package manager will open and prompt the user to download their first tool (We could use a toast notification for this but it will have to render for more than seven seconds so that the user is able to read it). If tools were previously downloaded or just finished downloading then the user will be prompt to select the tool he desires to use.

4. Sync: Once the user has selected a tool, the Sync sidebar button will render on the side nav bar component. If the project was loaded from local storage or loaded using a door43 project URL a toast notification will pop up to let the user know that now that they loaded a new project they could sync or save it to their own repo on door 43.

5, 6, 7 Will all render in order after the previous toast was generated.

[mannycolon]

Create the status bar at the top of the screen

Creating the status bar will be fairly easy. It will obviously its own component holding the directory for the project and app and the status online/offline status. the directory will have to be implemented maybe it should be included in the store somehow (TDB). And the code to display online or offline is already save it a component inside the side nav bar.

[mannycolon]

Implement the New T-Pain

• I believe the tPnae should only display no more than 1-3 verses and then when clicked a modal should pop up to allow the user to read more from that chapter or book.
• However, based on what i see in the mockups it will render more sliding down the div or view. In order to implement this, an event should be generated when the plus button is click that will change the number of verses the user can see and will slide down the to accomodate displaying more verses.
• In addition, based on the mockups the t-pane will not be a tri-pane anymore but a multi-pane. In order to implement this a lot of code will have to be changed to accomadate for the ability to dynamically select/upload bible versions. We shouls create a spike to research what will it take to implement this new feature/functionality and how we can implement it.

[mannycolon]

Implement the new translationAcademy

• I was thinking if maybe we could make translationAcademy a pop-up floating div?? sounds crazy but just wanted to make this suggestion and see what you guys think.
• Nevertheless, implementing the transationAcademy slide in/ slide out section should be fairly easy. Although, it could take a day or half day to learn how to make a div slide in and out using react and not using jquery (this will depend on who implements it).

[mannycolon]

targetVerseDisplay component

Implementing the switch button to mark the check as flagged for review or correct in context is not as simply as it sounds. in order to make this happen we will have to make sure that this component will check in the store to see if that check was previusly checked and make sure taht when checks are changed the view will change accordingly, i encountered this issue before with retained and replaced. Thus, some code will have to chnage in order to account for this with the store.

[mannycolon]

Propose changes Implementation

This component will not to be re-written but just new code will need to be added

• Just like with the switch button on the targetVerseDisplay, some code will need to be added in order to account for checks that were previusly selected in this component once the user starts switching checks or reopenes the appp and expects to see those checks that he/she sleected previously.
• Besides the above remarks I dont really see any other bigger challenge for this component since the rest of the work is basically styling the component based on the mockups.
• Add a new check boxes such as: Spelling, Punctuation, Grammar, Word Choice, Meaning, and Other under the text box and account for all of them in the check store.

Comments box Implementation

• Implement the basic drop down comment box should be fairly easy that is actually how I previously implemented it.

[mannycolon]

@EllDoubleYew @klappy @benjore @ihoegen @RoyalSix I dont think saving in the check store in real time is a good idea for any of the components since it may affect the apps performance with unnecessary saving on each character typed or selection made. it is possible that performing the check and then saving maintains a better app performance. we need to figure out another way to save. Savings in the check store in real time sounds like a bad practice and something that could cause a lot of problems in the future.