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!
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?
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.
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.
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. :-)
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).
(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.
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.