Bug 154306 - LanguageTool Server - GUI/UX enhancement of the settings
Summary: LanguageTool Server - GUI/UX enhancement of the settings
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.5.1.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: LanguageTool
  Show dependency treegraph
 
Reported: 2023-03-21 10:44 UTC by Marco A.G.Pinto
Modified: 2024-05-17 15:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Old GUI vs Suggested new GUI (40.12 KB, image/png)
2023-03-21 10:44 UTC, Marco A.G.Pinto
Details
Mockup (24.42 KB, image/png)
2023-04-21 09:29 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco A.G.Pinto 2023-03-21 10:44:12 UTC
Created attachment 186111 [details]
Old GUI vs Suggested new GUI

Hello!

The built-in LanguageTool Server settings are too hard to use.

I was looking at:
https://languagetool.org/insights/post/product-libreoffice/#how-to-enable-languagetool-on-libreoffice

It is too hard to use.

I always come up with easier solutions for the tasks (UX - User Experience).

The regular user should always use the things “out of the box”, simple and clear.

What if instead of the current GUI, we could use my suggested one (attached)?

This “API” word, the regular user won't know what an API is.

Keeping it clear to all users from novice to advanced.

Thanks!
Comment 1 Heiko Tietze 2023-04-05 08:26:22 UTC
As minor adjustments I would drop "LanguageTool" from the labels. The premium settings are better placed under the "( ) Premium" radio button - and indented, so we can provide the locale specific settings under the last item.

Changes that need discussion is the removed disclaimer (data is sent to external server), easy to add. And the split between Premium and Local where the first is probably always assigned to the same address and we can drop the URL, and the second needs this setting.

Daniel, what do you think?
Comment 2 Daniel Naber 2023-04-05 19:44:52 UTC
Heiko, I mostly agree with your comments. One setting should be there where the base URL can be set. "Local server" doesn't quite fit for that. "Other" might be needed. All other settings imply a specific base URL that can be hard-coded.
Comment 3 Heiko Tietze 2023-04-06 06:44:49 UTC
Alternatively we could use a checkbox above user name "[x] Use free service" and keep the UI as it is. What do you think Marco? Missing a bit the actual problem (besides this need to explain the UI per tip in the edit field), which would be clearer with the checkbox.
Comment 4 Marco A.G.Pinto 2023-04-06 06:58:05 UTC
Hello!

I believe that things like typing the server by the users is far too complicated.

All should work out of the box and be as simple and powerful as possible.

This is QA and UX in the field.

The "User eXperience" is crucial, to be able to achieve the best results with the less effort possible.

This is what I do, I always create things as simple and powerful as possible, that even a 6-year-old kid can use.

My PhD app, even a kid can use it… I turned something extremely complex into something very usable and friendly.

:-)
Comment 5 Eyal Rozenberg 2023-04-19 17:54:41 UTC
I agree that we should gray-out, or hide entirely, fields which are unusable with the current choice.

However, I don't like the choice of labels, nor the assumption that anything that's not LanguageTool's own servers is a "local" server.

I would suggest a 3-state choice: disabled, LanguageTool free service, and custom (not with these exact labels). If you choose the custom option you get to enter an address, username, password and API key; for the first option, the settings would be either grayed-out or hidden; for the second option - grayed-out but having their proper values (the free-service URL and empty username and API key).
Comment 6 Daniel Naber 2023-04-19 18:40:28 UTC
(In reply to Eyal Rozenberg from comment #5)

> If you choose the custom option you
> get to enter an address, username, password and API key;

It's just address, username and API key, there's no need to enter a password. Also, username and API key are optional.
Comment 7 Heiko Tietze 2023-04-21 09:29:02 UTC
Created attachment 186829 [details]
Mockup

The topic was on the agenda of the design meeting but did not receive further input. 

The proposed update of the UI is welcome, ideally a bit further simplified. The first option corresponds to "Disabled", the second to the free option. I think telling the user where the free service is hosted is in the meaning of open source. The third option combines the advanced/premium access with any other provider. The current static information is better suited for tooltips, input hints as shown for the base URL are helpful.
Comment 8 Dieter 2024-05-09 10:48:08 UTC Comment hidden (obsolete)