Re: [Languagetool] Configuration redesign

2012-05-24 Thread Daniel Naber
On Donnerstag, 24. Mai 2012, Marcin Miłkowski wrote:

> > For interactive use, we can probably assume that rules don't get
> > disabled for performance reasons, so we could actually always run all
> > rules and even display the number of matches for the "disabled"
> > rules.
> 
> I don't really get it. You mean we should only display the disabled 
> rules in the config dialog for OOo?

We could display a text like this at the bottom:

"+ 12 matches by 4 rules wich are disabled"

This could be a link to a dialog which then shows these 4 rules and their 
matches and a checkbox to re-enable each rule.

Regards
 Daniel

-- 
http://www.danielnaber.de

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel


Re: [Languagetool] Configuration redesign

2012-05-24 Thread Marcin Miłkowski
W dniu 2012-05-24 00:29, Daniel Naber pisze:
> On Mittwoch, 23. Mai 2012, Jan Schreiber wrote:
>
>> I agree with Daniel that that sounds suspiciously like too many clicks,
>> but otoh the 1300+ German rules are very difficult to navigate through
>> in the GUI without folding. The French ruleset is even larger. Any
>> improvement in this area is very welcome.

I don't think scrolling is less painful than clicking. For Polish, it's 
simply unreadable to have such a long list. To display a category, you 
would have to click one button, to close the dialog, again one button. 
The same number of clicks as with collapsing.

> I think the best approach is to have context-aware configuration. For
> example, it a rule matches, always display a link to disable that rule or
> its category. This way the user does not need to visit the configuration
> dialog at all.

It would be also reusable when the user forgot about some rule but knows 
it was reacting to a sentence: simply enter the sentence and see what 
rule it activates, disable the offending rule. I like it.

> The other use-case of re-enabling rules could be covered in a similar way:
> at the bottom, display the rules which are disabled and offer a one-click
> way to re-enable them.

This is a good idea.

We should also have a different GUI in the editor. I mean something more 
in the style of:

http://www.inetsoftware.de/other-products/jortho

The code is GPL but we only need to have squiggles that are clickable in 
Swing, so obviously we wouldn't reuse code from that project.

But instead of a list of matches in the bottom window (which could be 
hidden in normal cases, as users usually don't need them), we could have 
a table in the style of CheckMate 
(http://languagetool.wdfiles.com/local--files/checking-translations-bilingual-texts/lt-checkmate.png),
 
because it's simply easier to read and use.

> For interactive use, we can probably assume that rules don't get disabled
> for performance reasons, so we could actually always run all rules and even
> display the number of matches for the "disabled" rules.

I don't really get it. You mean we should only display the disabled 
rules in the config dialog for OOo?

>
> In a nutshell: most users should never have the need to visit the
> configuration dialog.

The trouble is, for example, that the HTTP Server has just been made 
sensitive to the GUI configuration, and without doubt, some simplistic 
interfaces to LT in other software won't allow to configure rules. So we 
cannot simply get rid of the dialog completely. It's not that I love it, 
it simply might have some use cases: for example, I want to build a list 
of rules for Chicago Manual of Style (I have to use it at times), and 
for Computational Linguistics - when you have a variation on the style 
guide like this, you might now the name of the rule rather than the 
actual sentence it matches. It would be then possible to configure it 
without knowing exactly how it works. But if it's hidden most of the 
time (like Mozilla's about:config), then it's really fine!

Regards,
Marcin


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel


Re: [Languagetool] Configuration redesign

2012-05-23 Thread Daniel Naber
On Mittwoch, 23. Mai 2012, Jan Schreiber wrote:

> I agree with Daniel that that sounds suspiciously like too many clicks,
> but otoh the 1300+ German rules are very difficult to navigate through
> in the GUI without folding. The French ruleset is even larger. Any
> improvement in this area is very welcome.

I think the best approach is to have context-aware configuration. For 
example, it a rule matches, always display a link to disable that rule or 
its category. This way the user does not need to visit the configuration 
dialog at all.

The other use-case of re-enabling rules could be covered in a similar way: 
at the bottom, display the rules which are disabled and offer a one-click 
way to re-enable them.

For interactive use, we can probably assume that rules don't get disabled 
for performance reasons, so we could actually always run all rules and even 
display the number of matches for the "disabled" rules.

In a nutshell: most users should never have the need to visit the 
configuration dialog.

Regards
 Daniel

-- 
http://www.danielnaber.de

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel


Re: [Languagetool] Configuration redesign

2012-05-23 Thread Jan Schreiber
> By the way, just because collapsible checkboxes are hard to implement in 
> Swing, maybe we should have just a list of categories in the first 
> dialog, and open another dialog with a list of rules in the category chosen?

I agree with Daniel that that sounds suspiciously like too many clicks,
but otoh the 1300+ German rules are very difficult to navigate through
in the GUI without folding. The French ruleset is even larger. Any
improvement in this area is very welcome. --Jan

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel


Re: [Languagetool] Configuration redesign

2012-05-23 Thread Daniel Naber
On Mittwoch, 23. Mai 2012, Marcin Miłkowski wrote:

> I propose the following scheme (for backwards compatibility):

Sounds good.

> By the way, just because collapsible checkboxes are hard to implement
> in  Swing, maybe we should have just a list of categories in the first
> dialog, and open another dialog with a list of rules in the category
> chosen?

I'm not sure... it sounds like a lot of clicking and several small usbility 
issues that need to be addressed. But I cannot offer anything better for 
now, I'm afraid.

Regards
 Daniel

-- 
http://www.danielnaber.de

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel


[Languagetool] Configuration redesign

2012-05-23 Thread Marcin Miłkowski
Hi all,

we need to slightly change the design of our configuration files because 
they do not store the disabled and enabled rules per language. As soon 
as we enable country variants, the problem will get more severe.

I propose the following scheme (for backwards compatibility):

* "disabled" / "enabled" property will be defined for all languages, but 
no longer used when saving

* "disabled" + short language code - rules disabled / enabled per 
language, for example:

disabled.en = HUNSPELL_RULE

* "disabled" + short language code + _ + country variant - per language 
and country variant, for example:

disabled.en_US = HUNSPELL_RULE

this way you could have:

enabled.en_UK = HUNSPELL_RULE

Now, we need also options for rules. Even if options are basically 
key-value pairs, they are defined per rule, which might be configured 
differently for a language (and even for a language variant). This 
introduces a lot of complexity, which is inevitable, I guess, because 
you might want to use different rules in British and American English.

We could have the following scheme:

options = HUNSPELL_RULE.en_US.checknumbers.false, 
HUNSPELL_RULE.pl.nosuggestions.true

The rule will get the key-value pairs ("checknumbers" = false) to be 
parsed. We should have a way to define value types in the rules 
themselves. I think we might have:

- boolean for checkboxes
- int for level-style settings (sliders?) - for example, severity of the 
error to be found
- String (input box) for anything else?

There would be a "Configure" button to the right of the rule name in the 
Configure dialog. There could be also another button "More..." that 
opens a link for rules with URLs defined.

By the way, just because collapsible checkboxes are hard to implement in 
Swing, maybe we should have just a list of categories in the first 
dialog, and open another dialog with a list of rules in the category chosen?

All answers and suggestions will be appreciated!

Regards,
Marcin

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Languagetool-devel mailing list
Languagetool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/languagetool-devel