Checks Side Panel (First Pass)

[katherinejensen00]

User Story As a user, I want to be able to view the results of checks so that I can easily see all of the check failures I need to address so that I can have the most accurate/error free translation possible.

Description Create a side panel for checks that can display all of the different check states. Note this is the first iteration on the checks side panel.

Figma Link

Implementation idea

• [ ] Create a side panel for checks (separate tab from editor but can be arranged next to editor)
• [ ] Create Check card (note will be shared between marginal component and island component/webview which means making badge optional)
• [ ] Create Check States that can actually be seen without clean up (Active, Denied) and use those check states when creating check cards to display in the side panel list (see Check States part of Figma design)
• [ ] Create a menu item from the editor menu that opens the checks side panel island component/webview

Note: Fixed state will be implemented as part of the Clean up task that will create more check result list state and Checking will be implemented once a bug is fixed that currently would make it flaky.

For developing purposes on this case: hard code Repeated words as the check whose results display

[katherinejensen00]

@paranext/paranext-ux Should clicking on a check card take you to the spot in the Scripture text where the text that needs to be edited occurs?

[merchako]

@paranext/paranext-ux Should clicking on a check card take you to the spot in the Scripture text where the text that needs to be edited occurs?

Yes, correct @katherinejensen00. When a card it focused, the related editor should scroll to and highlight the relevant range.

[ianhewubs]

Yes, correct @katherinejensen00. When a card it focused, the related editor should scroll to and highlight the relevant range.

Where "relevant range" means either:

1. Highlight the character(s) or marker in the source project/resource which was identified by the check result.
2. If no character or marker is identified, highlight the verse(s) containing the result.

[Sebastian-ubs]

Hi, what's the scope of this issue? Is it

• "Just a component that's not yet used in Paratext"
• "A component that's part of the shared editor webview and can interact with it?" (or something else)?

Asking because it differs from the original task breakdown.

• 1233 is not added to the current sprint

Recognizing that there is no ux design showing a standalone checks tab that can be freely moved around (like the current result list). Is #1234 still needed @ianhewubs ?

[katherinejensen00]

@Sebastian-ubs This task is what we are calling the "island" component that is next to the editor. We need a separate implementation for the margin inside of the editor (see #1287). This component will be used in Paratext and other tasks will add on functionality. We are just trying to break this up into bite size pieces so more people can work on it and it is easier to get through all of the stages.

After the UX demo on Monday, I created tasks based on the designs and didn't realize until we get into planning yesterday that there were some cases already created that were similar but maybe hadn't been updated since the demo. My goal today is to clean that up today so everything is synchronized and nothing gets lost.

[Sebastian-ubs]

Thanks @katherinejensen00, I understand how we got here. Still trying to get clarity on the outcome / scope of this story Does

This component will be used in Paratext

mean "as part of this story" or "in another story"?

So is the outcome of this story

• a component that can show check results
• that is showing the real check results (although not able to change the scope right now - until #1284 and #1285 are implemented)
• that shows up
  • ~(a) as part of the shared editor webview/tab (shows up always until #1309 is implemented) OR~
  • (b) as a separate webview/tab?*
• can select relevant scripture text or verse in the editor (like described in Ian's comment)

or parts of it / something else?

*the concept of the island always staying with the editor makes me think (a) 🤷 @merchako / @ianhewubs what was your intention? but the discussion in the dev sprint planning about closing a webview makes me think you are talking about (b). I have added the task to clarify this in https://github.com/paranext/ux/issues/172, but likely it is needed soon.

[ianhewubs]

Ideally, the "island" implementation needs to be a webview and its location should be dependent on program settings (Setting to be implemented in a later phase).

We intend to make it possible for a results island (one per project) to appear to the side of any project (right side for LTR Paratext UI language, left side for RTL UI).

We expect there to be PT9 devotees who want exactly one "results list" to appear on the right side of Paratext, always (but be movable as required).

Styling should be consistent. In both cases the island is a dockable frame which can be moved as required by the user.

The later phase program setting would look something like:

Results list behaviour

• [x] Display check results to the side of any project window
• [ ] Single Results List for all projects (Paratext 9 behaviour)

Initial implementation request: Make results appear next to a project (useful for UX testing). It would mean we can gauge reaction of users to that. It will help us discover whether users need the results in the PT9 location, or if a flexible approach is better.

(PT9 uses this fixed location for check results because it guarantees that the user will know where the window appears and (more importantly) it means the results list has the maximum vertical real estate in which to exist. It messes also up your layout very minimally. Dropping a results list next to the project would be much more disruptive.)

[katherinejensen00]

@Sebastian-ubs This component being used means that in this story this component/webview will be able to be opened (I am assuming from the menu but I can make that more explicit in the case) and viewed and it will display the checks results list in a limited way until 1284 and 1285 are completed. Navigation is being handled in 454.

The island is a separate webview. I am asking Matt and TJ right now if it is possible to automatically open that and keep it next to the editor, but I don't think we have done anything else like that yet.

[ianhewubs]

The island is a separate webview. I am asking Matt and TJ right now if it is possible to automatically open that and keep it next to the editor, but I don't think we have done anything else like that yet. @katherinejensen00 @tjcouch-sil @lyonsil

If it is tricky to make the checks "island" appear next to the editor, placing it at the absolute right side of the application, full height, like in PT9 is fine. Someday we'll want to be able to place tabs next to or below other specific tabs, but if we can't do it today, that's OK.

I expect that for many layouts, placing the checks immediately next to the editor will create an disappointingly small checks window and cause the rest of the user's layout to be squeezed in potentially annoying ways (and this is what we want to test: Is the proximity and potential for multiple check views more useful than the annoyance of a proliferation of new windows in the user's layout?). Showing checks/results on the side of the application avoids that. (i.e. We put the Results List on the right side in Paratext 9 for several good reasons.)