[LibreOffice add-on] Feature suggestion: “Academic Score”

[marcoagpinto]

Hello @FredKruse

I opened the check dialogue in my thesis and this is what it appears:

How can it be 0%? Microsoft Word 365 scores it at near 100% (their “Editor” evaluation).

Anyway, I had another idea for text scoring: ACADEMIC SCORE: 100% | 0/20 | 5/5 | A+ colour in bar: less than 50%=red orange between 50% and y green above y

The “academic score” would appear below the bar, and the bar could have three colours: red, orange and green.

The scale: 0-100%, 0-20, 0-5, A something (the adding of letters seem to depend on the scholar institution, so maybe it shouldn't be implemented).

[FredKruse]

Maybe it is a difference in philosophy. The score starts at the position, where the cursor is placed in the text. If you don't leave the dialog, it runs from 0 – 100% (1 – full text length) paragraph by paragraph (after reaching the end of text, starting with the first paragraph of the document). If you switch between dialog and text, the dialog starts again at the position of the cursor (0%).

[BloomingAzaleas]

@marcoagpinto:

Possibly you are confusing a "quality-of-writing" (editorial) score of a chunk of text with what the LT GUI widget "Checked text:" represents, which is a text scanning progress bar -- gives the user an indication of how much text remains to be scanned until end of document. Has nothing to do with editorial assessment.

[marcoagpinto]

Yes, I was trying to suggest a “quality-of-writing” like Office 365 has and so does the LanguageTool on-line.

[BloomingAzaleas]

@marcoagpinto :

Ah, then what you need in your description is a reference to the LT online feature. Keying on the coincidental "0%" of the "Checked text:" progress bar feature misdirected @FredKruse to that progress bar feature. I suggest re-stating your request as an enhancement for the LT offline version. Maybe find a Microsoft text snippet describing that O365 feature. Find or write up a description of the LT online feature. Provide additional reference pointers to other examples if they exist. All to give the LT team a more rounded idea of what you mean.

I suggest deferring design of GUI elements until there is convergence on functionality. The existing LT offline GUI is very state of the '90s Java Swing components. I've worked with @FredKruse in other issues on minor changes to existing elements but given how resistant LT is to presumptively simple changes to the existing design for readability (larger fonts & text boxes in the S&G pane, etc. given 2022 modern screen resolutions) I suspect there are technical debt barriers to adding whole GUI new widgets and their required real estate.

Additionally, such editoral assessment features might be consider for the Premium version only.

Regards.

[FredKruse]

It is right, the GUI is based on java swing components. A change to another technology is complex. From my feeling, the best would be to change to LibreOffice GUI-elements. But this is an enhancement for future work. How can we go on with this issue? If the technical behavior of the dialog or the design of the status bar is user confusing, we should change that. Do you have any concrete ideas?

[marcoagpinto]

“Checked text progress:” ?

[marcoagpinto]

@FredKruse

Also, the “Ignore” button in the check window is confusing.

I haven't clicked on that button because I don't know if it will add the marked word to ignore or if it just proceeds to the next error.

Maybe we should have a “Next” button.

[marcoagpinto]

or "Skip".

[BloomingAzaleas]

@marcoagpinto has a point about the Ignore button. Goes back to lack of public doc that should expand on the meaning of GUI elements. In isolation, the single-word label 'Ignore' presents as <ignore what?>, then possibly <do what?>.

I do note that the 3 buttons in the local vertical group together do give a hint: the "Deactivate Rule" button tells us that the visually associated Ignore buttons refer to an LT rule (Grammer Rules, Style Rules) that was triggered, then is asking 'should this rule be ignored for this specific text location?'. @marcoagpinto, the LT S&G pane function is not directly a spelling checker in the conventional sense, the controls for such are not offered. Compare to the LO Writer Tools->Spelling interface (LO native or LT version). In that interface, controls are offered to manage both the list of dictionaries to be used and the custom WORD lists for substitution and stops (ignores).

The GUI design of that LT S&G pane stack of 3 buttons clearly takes its cue from the design of a conventional spell checker interface, but the conceptual framework for what is being ignored has changed from that of a base function spell checker. My guess is this:

Ignore --> Ignore once the triggered rule indirectly indicated in the uppermost S&G pane text window.

Ignore All --> Ignore the triggered rule for the current dynamic user interaction something. Intended as temporary but over what dynamic user interaction scope is completely unclear. The current scan session of the S&G pane? The current open session of the document? The current LO instance session?

Deactivate Rule --> ignore_all+change the current persistent profile to deactivate the rule. Assuming the profile update is saved to disk, then the rule-set change persists across all subsequent LT activations.

Changing the button labels to other than 'Ignore' does avoid the word-association link with the spell check interface and its conceptual framework of WORDS (rather than RULES). The problem then for a different label is conveying complex meaning in ~15-20 characters of horizontal space. So, exploring:

ignore_button --> We mean ignore this rule trigger event. Don't care what rule was triggered. Want to convey (A) nothing will be done with the current rule complaint then (B) scan for the next complaint. 'Next' alone tells us (B) but is silent about (A). We could take a phrase-association cue from the LO Writer Edit->Find and Replace. In that function, "Find Next" (9 chars) means do nothing and resume scan.

ignore_all_button --> We mean ignore this trigger event and all subsequent trigger events during some concept of user interaction session for this specific rule. We now care about the specific rule because we have to temporarily disable it and not some other rule for this whatever_session. "Ignore Rule This Scan" is what we mean but that is 21 characters. Implies if we Close the S&G pane then re-open, the rule involved will again be active.

deactivate_rule_button --> ignore_all_button plus also persistently in the profile for all subsequent LT use. The existing label is in terms of RULE, so I suggest it is fine as is.

Regards.

[FredKruse]

I think, we should change the wording of the buttons, but the changes should be done in LT 6.0, because of the actual freeze of 5.9. We could orient on the original spelling dialog of LO. than the following changes in wording should be done:

• Ignore --> Ignore Once (the match is ignored temporary until the end of session or until the next change of paragraph)
• Ignore All --> Ignore All [for spelling errors] / Ignore Rule [for grammar errors] (this is also temporary until the end of session)
• Add to Dictionary / Deactivate Rule (makes the ignoring permanent - until change of options)
• Change --> Correct
• Change All --> Correct All

A small help text pops up, if you stay with the mouse cursor over a button (without pressing the mouse button). If you know, I'm not a native English speaker and my English is not as good as it should be. So, it would be a big help, if you could correct the small help texts, to describe the functionality of the button.

[BloomingAzaleas]

Just to clarify for all following this issue: as mentioned above, lacking documentation, the user interaction dynamic scope is still ambiguous. That is, by what visual signs or user actions or LT events does a user know that a "Session" for S&G purposes has started, that an S&G Session has ended? This is important for a user to understand because in turn it models the persistence duration of the Ignore and Ignore All choices in the sequence of actions a user might take with LT, including possibly multiple partial S&G scans or re-scans of a document, possibly also Recheck Document or Refresh Check Results actions.

A) An open then Close of the S&G pane? B) An open then close of the entire document? C) A Refresh Check Results closes the existing Session (whatever that is) and starts a new one? D) Something else?

Clarifying the meaning of "Session" is important to word/phrase choice for the buttons and the Help text popup.

How many characters available in the Help text popup? Knowing this allows us to consider how we allocate expressing meaning between the button labels and the Help text so that they complement each other rather than duplicate each other to the extent possible. We then design a button label and its Help as a unit.

@marcoagpinto ?

Regards.

[marcoagpinto]

At the moment I am stressed and can't think properly… sorry.

[BloomingAzaleas]

Take all the time you need. This thread isn't going anywhere.

Regards.

[BloomingAzaleas]

Also, regards issue topic discipline, this thread has wandered in to 3 topics:

1. The original "Academic Score" idea. @marcoagpinto still needs to elaborate functionality for this under this 7056 issue number.
2. Tweaking the English labels on some of the existing GUI elements and buttons, possibly in a complaint-context dependent (spelling vs. rule) way, along with adding coordinated Help popup text. This topic should be a separate enhancement issue.
3. Adding one button (Change All) that would expose additional functionality in the S&G pane. This topic should be a separate enhancement issue. Since this would affect the S&G exposed functionality for all languages, whoever decides global LT functionality (Naber?) should weigh in as there will be a support tail created as well.

Regards.

[FredKruse]

1. The first part of the second point is done. The labels of some buttons are changed. It also distinguishes between "Ignore All" and "Ignore Rule" (see tomorrow nightly). The change of help text remains. I will wait until one of you makes a proposal.
2. The help texts should be as short as possible. If you put the mouse cursor over the "Correct" button (former "Change") than you see a long text. It should not be longer from my opinion.
3. The question of what is a session depends on the function (this is compatible to the LO spelling dialog):
   • "Ignore Once": A session is the period from opening to closing of the document. A change of the affected paragraph deletes the "ignore once" information. A "Recheck document" or "Refresh check results" removes the "ignore once" information for the whole document.
   • "Ignore All/Rule": A session is the period between opening and closing of LO. Only the closing of the application removes the "Ignore All/Rule" information.
4. I would like to keep the basic functionality of the progress bar. It should count the paragraphs already checked. The check should start at the paragraph where the text cursor is positioned and end at the paragraph before (or at the end of the document, if we have started with the first paragraph). But the behavior of switching between document and dialog should change. The dialog should keep the start point. So, the progress bar shows the number of checked paragraphs from the start of the dialog until the closing of the dialog.
5. A "Change All" button in context of grammar errors makes no sense from my point of view. Other than spelling errors, grammar errors are strongly context-sensitive. In context of grammar errors, a global change of one word or a phrase is too error-prone.

[marcoagpinto]

@FredKruse

Tomorrow night I will test the nightly and provide some feedback.

I have been under terrible pressure and can't think properly.

[BloomingAzaleas]

Regards bullet 3 above: thanks for the clarification on the meaning of "session." Hopefully I have summarized correctly in the following table:

S&G Pane Button | Persistence of A Button Choice | Removes (Forgets) A Choice -- | -- | -- Ignore Once | Document open session | Close document, or LT Recheck Document, or LT Refresh check results Ignore All* *Same GUI button as Ignore Rule. For spell check events only. | LO application session | Close entire LO application (closing Document not enough) Ignore Rule* *Same GUI button as Ignore All. For LT style rule events only. | LO application session | Close entire LO application (closing Document not enough) Please confirm. Side-note: see how overloading the IgnoreAll/Rule single GUI button complicates the mental model with the context asterisk? As long as we are contemplating adding buttons (Change Once and Change All), then consider breaking out the overload in to two buttons. The upside would be the mental model is simpler: When a spell check event is triggered, the Ignore All button is active, the Ignore Rule is grayed inactive. When a style/grammar rule event is triggered, vice-versa. If we were not considering adding buttons anyway, then I would say stay with one button that changes labels with context. Regards bullet 4 above: agree, but still too many unstated scenarios. I have pasted the table below to lay out the user interaction scenarios I can think of and have proposed some behaviors, but there are uncertain or empty items yet. S&G Pane Sitting At A Complaint Stop | LO Document GUI Cursor | LT Toolbar Buttons Next, Check, Recheck, Refresh | S&G Scan Behavior On Re-gaining Focus | S&G Progress Bar Behavior Behavior On Re-gaining Focus -- | -- | -- | -- | -- Keeps focus through next S&G action button select | Does not gain focus | NO | Resume scan from current complaint position, possibly re-scanning current paragraph if a Change was made to the current paragraph. | Resume progress from S&G pane launch point position Looses focus. | Does not gain focus | NO | Resume scan from current complaint position, possibly re-scanning current paragraph if a Change was made to the current paragraph. | Resume progress from S&G pane launch point position Looses focus. | Gains focus. User may scroll but does not move cursor. | NO | Resume scan from current complaint position, possibly re-scanning current paragraph if a Change was made to the current paragraph. | Resume progress from S&G pane launch point position Looses focus. | Gains focus. User moves cursor out of current paragraph but makes no changes. | NO | ??? Do not know what S&G does in this case. May need decision on what S&G should do. | ??? Looses focus. | Gains focus. User modifies complaint paragraph text via LO GUI. | NO | Re-scan current paragraph. | Resume progress from S&G pane launch point position Looses focus. | Gains focus. User modifies text prior to current complaint paragraph via LO GUI. | NO | ??? | ??? Looses focus. | Gains focus. User modifies text after current complaint paragraph via LO GUI. | NO | Resume scan from current complaint position, possibly re-scanning current paragraph if a Change was made to the current paragraph. | Resume progress from S&G pane launch point position Looses focus. | Gains focus | Next | Effectively IGNORE the current complaint. Resume scan from current complaint position, possibly re-scanning current paragraph if a Change was made to the current paragraph. | Resume progress from S&G pane launch point position Looses focus. | Gains focus | Check text | ??? same as Next? Or something else? Do not know what S&G does in this case. May need decision on what S&G should do. | ??? Looses focus. | Gains focus | Recheck Document | Visually re-launch S&G pane session from beginning of document. | New scan session from beginning of document. Looses focus. | Gains focus | Refresh Check Results | ??? Not sure what this means in the middle of a scan. Maybe S&G should close? | ??? Regards bullet 5 above: agree. Change All for a grammar or style rule would need much more human guidance than the simple S&G interface can provide (or a monstrous AI). Regards.

[FredKruse]

@BloomingAzaleas I confirm your first table is right. The second table is a little bit too complex, I fear. After I have changed the concept a bit, there are the following points:

• If you call "Check Text" or "Recheck Document", a range for grammar (and spell) checking is defined until the dialog is closed. A lost and gain of focus of the dialog doesn't change the range.
• For "Recheck Document": the range begins with the first paragraph and ends with the last one.
• For "Check Text": There are two possibilities:
  1. If a part of text is selected, the range begins with the first character of the selection and ends with the last character of the selection.
  2. If no selection is made, the range begins with the paragraph at the position of the cursor and ends with the paragraph before (At the End of the document, the check continues with the first paragraph).
• If the dialog lost focus and gained it again, the check will be continued with the paragraph the cursor is positioned. It can be at another paragraph and the text can be changed. (NOTE: If the cursor is set to a paragraph before the beginning of range, the check end at the paragraph before the beginning of range.)
• A new range is defined only, if you call "Check Text" again.
• The progress bar shows the progress inside the range (e.g. 10% means 10% of the range is checked, 5 / 100 means 5 paragraphs from 100 inside the range are checked).
• If you go to the document and call "Next ..." the cursor moves to the next mistake. If you change after that to the dialog, the dialog will continue at the position of the cursor.
• If you call "Refresh Check Results" nothing happens directly. Intern all caches will be refreshed, and the background check is done again (Note: The dialog reads the errors from cache, if the concerned paragraph was already checked. If not, the check will be run and the user has to wait until the result is ready).

[BloomingAzaleas]

Updated my table from your instruction, using your terminology of "range" and other re-wording. Significantly changed cells or added case rows highlighted... well dang that highlighting does not appear to carry over to the table appearance here. I find a table is a good way to force a compact enumeration of all the behavioral cases and serves as a start of code test cases.

Bullet 1: "A lost and gain of focus of the dialog doesn't change the range" -- yes, losing then re-gaining focus of its own should not change the S&G pane state. I listed that as Case 20 for completeness. The LT S&G UI behavior issue is what might gain focus in the meantime, in this context it is the LO Writer GUI of an open document. What the user does there CAN change the range. Cases 50+ in updated table.

Bullet 2: Case 100 in updated table.

Bullet 3: Replaced my original case with 2 cases (90, 91) in my table from your instruction. However, your 3(ii) sentence is garbled. "If no selection is made, the range begins with the paragraph at the position of the cursor and ends with the paragraph before..." Before what? Before the current complaint paragraph? Also, this implies a new range has been set.

"At the End of the document, the check continues with the first paragraph" -- I cannot say that I have previously encountered LT wrap-around scan (wrapscan) behavior. My scans have always ended after footnote processing. Maybe that is a change you have in mind? A user-visible complication for understanding this behavior is where is the visible "End of the document?" Is it the last visible paragraph on the last page of the document? Not necessarily if footnotes are present. In the current version of LT, recall that footnotes are processed after all visible paragraphs, meaning the the visible "End of the document" is the last paragraph of the last footnote, not the last visible paragraph on the last page. A user-visible complication for the concept of wrapscan in LT is then that footnotes are processed after the visible end of the document but, for footnotes, the LO GUI cursor appears to jump backward in the document to the first footnote then forward again scanning footnotes. A wrapscan would then appear to jump from the last footnote back to the beginning of the document. Truly a roller-coaster ride for the user.

I note most text editors of my acquaintance that offer wrapscan either have an Option to enable/disable that behavior or, upon a scan reaching end of document, pop up a question "Continue scan from beginning?"

Bullet 4: A) "If the dialog lost focus and gained it again, the check will be continued with the paragraph the cursor is positioned." -- Case 30. B) "It can be at another paragraph and the text can be changed." -- Cases 51, 52, 60, 61. Yes, but does the active scan range change? Seems in some cases (C) it does. C) "If the cursor is set to a paragraph before the beginning of [currently active?] range, the check end at the paragraph before the beginning of range" -- Case 61, the active scan range is re-positioned to begin at the new cursor position and now ends at "the paragraph before the beginning of range." But this may contradict Bullet 5.

Bullet 5: Cases 90, 91. However your sentence is ambiguous. "A new range is defined only, if you call "Check Text" again" seems to contradict Bullet 4 item (C). Maybe "A new range is defined ONLY, if you call Check Text"? Means all that Check Text does is set a new range. NOPE, not true, it also launches a scan. "A new range is defined ONLY IF you call Check Text"? NOPE, not true, other actions can set a new range. "A new range is defined WHEN you call Check Text."? This would seem true. Maybe you mean WHEN?

Bullet 7 : Case 80

Bullet 8: I have observed instances of stale cache behavior after changing text in the current complaint paragraph or forward via the LO GUI (rant: because of S&G pane text readability), meaning LT displays a complaint about text that does not then exist in the document AND LT loses sync with the actual LO cursor position such that a Change gets applied in the wrong place in the doc text. This suggests that LT is not or can not monitor for text edit events in the LO Writer document pane and thus point update its paragraph cache. A user forcing a Refresh seems to work until the next edit in the LO window. I have not attempted to systematically reproduce this particular dynamic behavior bug. Thus I propose that the S&G pane CLOSE as a user-visible sign of a behind-the-curtain refresh. Among other things, I suggest the validity of the then active scan range is questionable after a cache refresh. Paragraphs surrounding the current position may have been deleted or new ones added via the LO window. A user can always re-launch with a 'Check text' at the current LO cursor position.

Case | @FK Bullet | S&G Pane Sitting At A Complaint Stop | LO Open Doc GUI Cursor | LT Toolbar Buttons Next, Check, Recheck, Refresh | S&G Scan Behavior On Re-gaining Focus | S&G GUI Behavior Behavior On Re-gaining Focus -- | -- | -- | -- | -- | -- | -- 10 |   | Keeps focus through next S&G action button select | Does not gain focus | NO | Should not change active scan range. Resume scan from current complaint position, possibly re-scanning current paragraph if a Change was made to the current paragraph. | Resume Progress Bar from S&G pane launch point position 20 | 1 | Looses focus. | Does not gain focus | NO | Should not change active scan range. Resume scan from current complaint position, possibly re-scanning current paragraph if a Change was made to the current paragraph. | Resume Progress Bar showing % from S&G pane launch point position. 30 |   | Looses focus. | Gains focus. User may scroll but does not move cursor. | NO | Should not change active scan range. Resume scan from current complaint paragraph. | Resume Progress Bar showing % from S&G pane launch point position. 40 |   | Looses focus. | Gains focus. User moves cursor out of current paragraph but makes no changes. | NO | Should not change active scan range. Resume scan from current complaint paragraph. | Resume Progress Bar showing % from S&G pane launch point position. 50 |   | Looses focus. | Gains focus. User modifies complaint paragraph text via LO GUI. | NO | Should not change active scan range. Re-scan complaint paragraph then proceed normally. | Resume Progress Bar showing % from S&G pane launch point position. 51 | 4 | Looses focus. | Gains focus. User modifies a paragraph FORWARD of the complaint paragraph but WITHIN current scan range via LO GUI. | NO | Should not change active scan range. Resume scan from current complaint paragraph. | Resume Progress Bar showing % from S&G pane launch point position. 52 | 4 | Looses focus. | Gains focus. User modifies a paragraph FORWARD of the complaint paragraph AND beyond current scan range endpoint via LO GUI. | NO | Should not change active scan range. Resume scan from current complaint paragraph. | Resume Progress Bar showing % from S&G pane launch point position. 60 | 4 | Looses focus. | Gains focus. User modifies text PRIOR to complaint paragraph but WITHIN current scan range via LO GUI. | NO | Should not change active scan range. HOWEVER, re-position the SCAN_CURSOR to the changed paragraph to ensure the changed paragraph is re-scanned then proceed normally. | Resume Progress Bar showing % from S&G pane launch point position. 61 | 4 | Looses focus. | Gains focus. User modifies text PRIOR to complaint paragraph and PRIOR to the current scan range via LO GUI. | NO | Resets the active scan range to start at the modified paragraph and end at the paragraph just before the previous active range. | Reset the Progress Bar for the reset scan range. NOTE: this is the only visible sign the scan range has been changed since the S&G pane lost focus. 80 | 7 | Looses focus. | Gains focus | Next | Effectively IGNOREs the current complaint. Should not change active scan range. Resume scan from current complaint position. | Resume Progress Bar showing % from S&G pane launch point position. 90 | 3,5 | Looses focus. | Gains focus | Check text, with an active text selection | Resets S&G pane active scan range to be only the selected begin character to end character of text. | Resets Progress Bar to 0% at current LO cursor position to WHAT ??. NOTE: this is the only visible sign the scan range has been changed since the S&G pane lost focus. 91 | 3,5 | Looses focus. | Gains focus | Check text, with NO text selection active | Resets S&G pane scan range to begin at current LO cursor position paragraph through . NEEDS CLARIFICATION. | Resets Progress Bar to 0% at current LO cursor position paragraph. NOTE: this is the only visible sign the scan range has been changed since the S&G pane lost focus. 100 | 2 | Looses focus. | Gains focus | Recheck Document | Resets S&G pane scan range to begin at first document paragraph through the end of the document. | Resets Progress Bar to 0%. NOTE: this is the only visible sign the scan range has been changed since the S&G pane lost focus. 110 | 8 | Looses focus. | Gains focus | Refresh Check Results | ??? NEEDS CLARIFICATION. Propose that the S&G pane CLOSE as a visible signal since this action re-builds the complaint list, something a user can understand. A user can always ‘Check text’ re-launch from any point in the document. | Propose S&G pane CLOSE. Regards.

[marcoagpinto]

@FredKruse @BloomingAzaleas

This ticket seems well oriented.

After all is implemented, I will see what more I can suggest.

[FredKruse]

@BloomingAzaleas

• 61: When you set the cursor before the initial paragraph (last call of "check text"), it is inside the range, but near the end of the range. E.g.: If you set the cursor at the paragraph before the initial cursor position, the paragraph at cursor position is checked and the progress bar shows 100%. The check of range stops with the last error in that paragraph.
• 90: The range begins with the first character of the selected range and ends with the last character of the selected range.
• 110: OK, the dialog should be closed to clarify the situation for the user. This has to be implemented in the next days.

@marcoagpinto All points of the table are installed in the latest nightly except point 110

[marcoagpinto]

@FredKruse

Cool!

Thanks!

[FredKruse]

Point 110 is changed.

[FredKruse]

I think, the issue can be closed as solved.