Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Scout » [SDK] Discussion: Proposed text entries and order
[SDK] Discussion: Proposed text entries and order [message #876276] Thu, 24 May 2012 09:41 Go to next message
Adrian Staudt is currently offline Adrian StaudtFriend
Messages: 1
Registered: May 2012
Junior Member
As requested in a comment 4 (b) of the ticket 380507 I am opening this discussion to debate which text entires should be displayed in general in the NLS selection view.

Bug 380507 (a) - Text input, proposal view and sorting of entries

In the ScoutPropertyView (Scout Object Properties) we have the possibility to enter a label, a title, ... by selecting an entry from a predefined list of text entries.

(1) With respect to Matthias Zimmermann's comment, the first question is which entires should be displayed at all in the NLS selection view.

(2) If this point is clarified, we should also discuss the sort order of the entries. The current sort order is alphabetical (c). I proposed ordering the entries by their 'string edit distance' (d). This is maybe not for all the optimal solution, we should check which points are against this implementation.

URLs:
(a) h**ps://bugs.eclipse.org/bugs/show_bug.cgi?id=380507
(b) h**ps://bugs.eclipse.org/bugs/show_bug.cgi?id=380507#c4
(c) h**ps://bugs.eclipse.org/bugs/attachment.cgi?id=216178
(d) h**ps://bugs.eclipse.org/bugs/attachment.cgi?id=216179
Sorry for the broken links, but the forum tells me that I need at least 25 post before I can add links

Cheers Adrian

[Updated on: Tue, 29 May 2012 13:46]

Report message to a moderator

Re: [SDK] Discussion: Proposed text entries and order [message #876297 is a reply to message #876276] Thu, 24 May 2012 10:33 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1252
Registered: October 2011
Senior Member
Here the links:
(a) https://bugs.eclipse.org/bugs/show_bug.cgi?id=380507
(b) https://bugs.eclipse.org/bugs/show_bug.cgi?id=380507#c4
(c) https://bugs.eclipse.org/bugs/attachment.cgi?id=216178
(d) https://bugs.eclipse.org/bugs/attachment.cgi?id=216179
Re: [SDK] Discussion: Proposed text entries and order [message #878528 is a reply to message #876276] Tue, 29 May 2012 13:39 Go to previous messageGo to next message
Matthias Villiger is currently offline Matthias VilligerFriend
Messages: 232
Registered: September 2011
Senior Member
I like your proposal. It helps the user to find the desired text entry more easily.
Because the more accurate entries come on top it is faster to get to the correct entry using the arrow keys.
Re: [SDK] Discussion: Proposed text entries and order [message #878661 is a reply to message #878528] Tue, 29 May 2012 17:10 Go to previous messageGo to next message
Ivan Motsch is currently offline Ivan MotschFriend
Messages: 154
Registered: March 2010
Senior Member
For me the proposal makes sense. There is nothing that i remember that would be an obstacle.
Looking foreward to this new feature.
Re: [SDK] Discussion: Proposed text entries and order [message #879546 is a reply to message #878661] Thu, 31 May 2012 11:59 Go to previous messageGo to next message
Eclipse UserFriend
Very good approach thank you.
Nevertheless I do have some issues to discuss.

In case of a huge amount of NLS entries is the search algorithm fast enough? Could you provide some performance measurements of the new algorithm vs the old one?

All other proposal fields implement an camel case match algorithm so far. Isn't it confusing if the NLS proposal field has its own matching strategy? Does the user not except the same behavior of all proposal fields?

Some new proposal field do have a highlighting of the match range in the result list. Do you have any thought about the highlighting?

-andreas
Re: [SDK] Discussion: Proposed text entries and order [message #879690 is a reply to message #876276] Thu, 31 May 2012 16:45 Go to previous messageGo to next message
Matthias Villiger is currently offline Matthias VilligerFriend
Messages: 232
Registered: September 2011
Senior Member
Some short thoughts from me:

For me a camel case search is not necessary here because we are not searching class names but free text instead. Therefore I think came case search is not that important for NLS entries. But anyway: it would be nice of course if camel case search would work as well.

Highlighting of the match range would also be nice, yes.

Afaik both enhancements are not available for NLS fields at the moment: Neither camel case search nor the highlighting. Therefore I see three enhancement possibilities here:

1. implement 'string edit distance' search
2. support camel case search
3. highlighting of the match range

I think these enhancements could be added independently of each other (eventhough 'string edit distance' search makes no sense when typing camel case search patterns?).

But anyway, the performance of the search must be kept on the current level.

regards,
matthias
Re: [SDK] Discussion: Proposed text entries and order [message #981840 is a reply to message #879690] Mon, 12 November 2012 18:46 Go to previous messageGo to next message
Matthias Villiger is currently offline Matthias VilligerFriend
Messages: 232
Registered: September 2011
Senior Member
After a more detailed analysis I came to the following result:

I agree that the current sorting is not optimal. The "better" matches are not placed on top of the list. And this is already much better in your proposal Adrian! Thank you!

However, what I think could be confusing is that the user has no clue whats the logic behind the order of the list. So if the user must search through the list she/he has no possibility to find the correct item very fast, because it is not sorted alphabetically. So you have to check line by line.

Therefore I suggest the following: As shown in the screenshot of the corresponding bug (screenshot) the "good" matches are already highlighted in bold font.
So how about using this as a grouping criteria so that all matches directly containing the search string within the development language (the bold ones) are placed on top, ordered alphabetically. All other matches (the non-bold ones) are placed below, separated by a line (also ordered alphabetically). The same way it is done e.g. in the ctrl+shift+t dialog of JDT.

What are your thoughts about that?

regards,
m
Re: [SDK] Discussion: Proposed text entries and order [message #986032 is a reply to message #981840] Sat, 17 November 2012 19:03 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas HuserFriend
Messages: 42
Registered: March 2010
Member
Hi all

I think we need to include in this discussion
a) what do we search against (all languages, the development language, the key)
b) how do we present the found entries to the user (displayed text, sort order, highlighting)

The current implementation searches against all languages (and the key), but only presents the development language in the proposal list (it will show the key and all translations when selecting the entry in the list...). The proposal list is sorted alphabetically (case sensitive) by display text in the development language.
Camel case search actually already works, e.g. when searching for keys. The search term supports wildcards * and ?. Highlighting of the match range is restricted to the displayed text in the development language (even though an entry might be found because it matches the key, or even its translation in some exotic language...)

I think that the main usability issue comes from the fact that the current setting breaks with commonly expected behavior of a drop down list. For example: If I start typing "Pers", I expect all listed entries also to start with "Pers". I do not care whether a totally unrelated text in some exotic language also starts with "Pers", such an entry simply is noise in my result list.
The main reason of confusion IMO comes from the fact that we search against multiple representations of an NLS entry (different languages and the key), but do not adequately present the result list to the user. I.e. the sort order and highlighting do not reflect which representation of the entry matched the search term.

a) what should we search against?
I would propose to restrict the search in the NLS drop down box to be performed against the development language and the key, but NOT against all languages. I usually don't care about other languages, I rather find it distracting and confusing when unrelated texts pop up for no obvious reasons.
Example: In a fresh Scout project, type "to" into an NLS field. This will find about 27 Texts. About 20 of these texts seem unrelated to my search term. E.g. the text "All" is included in the proposal list because of its Portuguese translation "Todos".

Usually I know quite well what I'm searching for and I type until the proposal list is small enough (5 or less entries) and then choose with the arrow keys. If I start typing and the proposal list does not include what I'm looking for, I will go back and adapt my search pattern (adding wildcards etc.). If I want to find a text based on a specific translation, I will do that in the NLS Editor, and not in an NLS drop down box.


b) how do we present the entries to the user?
The proposed patch by Adrian addresses this question.
Personally, I think that sorting by edit distance is not the proper solution to this problem.
It does not address the issue that we match the search query against two different strings (development language and key), but only use one of them to present the result to the user.

Edit distance search order (on the display text) might give better results if I actually want to search against the display text. However, it most probably gives unsatisfying results if I want to search by key.
Example: I know the (short) key of a longer text to be displayed as a tooltip. When I start typing the key, the corresponding NLS entry will presumeably appear rather at the bottom of the list (because with edit distance sorting any entry with a short display text containing the search term will appear first).

One more concern regarding the edit distance sort order:
How does the edit distance order deal with wildcard search terms such as "*person*prop*", or with camel case search terms such as "PSDT"?


So I would propose a different approach to improve the usability of the NLS drop down box:
- consistency with other similar fields: fancy search terms possible (wildcards, camel case), but presentation in drop down list is simple (alphabetical, non-case-sensitive sort order)
- it should be immediately clear, why an entry is included in the result list: highlighting and sort order must include the string that actually matched the search term
- it is important that the key is displayed in the proposal list (in the case where the display text matched the search term). Sometimes you have duplicate texts (words) with different keys.
Example: Same word, but in a different context (two texts that have different reasons for change should be stored as two different texts): PersonType=Type, CompanyType=Type.
Example: Same word in default language needs different translations in another language. EmailTo=to, RangeTo=to (in German: EmailTo=an, RangeTo=bis)


There are several possibilities to support the above criteria:

Variant 1
Change the proposal entry, depending on whether the key or the text matched:
- Icon column contains a "Text" or "Key" icon
- Proposal entry starts with the display text (key in brackets) if the display text matched. The display text is highlighted based on the search term
- Proposal entry starts with the key (display text in brackets) if the key matched. The key is highlighted based on the search term
- The proposal list is sorted alphabetically (non-case-sensitive) on the first string
- If both the display text and the key match, the display text is used to represent the entry in the proposal list

Example NLS Entries:
Person=Person
Persons=Persons
PersonMenu=&Edit Person...
PersonAll=All Persons
Company=Company
Companies=Companies
Items=Personal Items

Search for "Pers"

Icon | Text
---------------------------------------
T | Person (Person)
T | Personal Items (Items)
K | PersonAll (All Persons)
K | PersonMenu (Edit Person...)
T | Persons (Persons)

Variant 2
It might be better to keep a single entry of the form "[Icon] Display Text (Key)" (but still do sorting and highlighting based on the string that matched)...

Search for "Pers"

Icon | Text
---------------------------------------
T | Person (Person)
T | Personal Items (Items)
K | All Persons (PersonAll)
K | Edit Person... (PersonMenu)
T | Persons (Persons)


Variant 3
Maybe its better to list all matches on display texts first, and then all matches on keys, assuming that a typical Scout developer will usually search by display text and only occasionally by key. This comes very close to what Matthias described in the previous post.

Search for "Pers"

Icon | Text
---------------------------------------
T | Person (Person)
T | Personal Items (Items)
T | Persons (Persons)
K | All Persons (PersonAll)
K | Edit Person... (PersonMenu)


[Updated on: Sat, 17 November 2012 19:06]

Report message to a moderator

Re: [SDK] Discussion: Proposed text entries and order [message #986434 is a reply to message #986032] Tue, 20 November 2012 12:17 Go to previous messageGo to next message
Matthias Villiger is currently offline Matthias VilligerFriend
Messages: 232
Registered: September 2011
Senior Member
Hi Lukas,

Thank you very much for your analysis and different implementation possibilities. I realy like the idea to show why a proposal matched the search criteria by showing different icons!
However, your proposals all assume that we "only" search in the development language and the key. And this was the case in earlier versions of the scout sdk. Back then there were complains that people did not find translations that already exist and then created the same again. That's why we have changed this behaviour.
This can especially happen if your eclipse is not running with the same language as you are typing when searching for nls proposals. Imagine you have an English operating system and are developing an application in German. You would most probably search for German texts because all of your texts are translated to German only. But because your Scout SDK is running with dev-lang=english you would only find key matches.
But I totally agree, the main reason of the issue is that we are searching for matches in more places than we are displaying to the user. and this may lead to unexpected results.
So if I try to combine these ideas, something like this may result:

1. Search in key and all languages
2. Display the ones that match in the development language in the first group (before the separation line)
3. Display key- and "foreign"-language matches after the separator line

The corresponding search string would then be highlighted with bold font in any line and the icon would indicate what kind of match it is (development language, key, other language?).
Within a group the shown text would be sorted alphabetically (not case-sensitive).

To catch up your example it would maybe look like this (searching for "Pers", having german as development language):

Icon | Text
---------------------------------------
T | Person (Person)
T | Personen (Persons)
T | Persönlich (personal)
- ----------------------------------
K | All Persons (PersonAll)
K | Edit Person... (PersonMenu)
F | Erfasser (Typist=Person entering)

Where T=match in dev-language, K=match in key, F=match in "foreign" language

What dou you think?

regards,
matthias
Re: [SDK] Discussion: Proposed text entries and order [message #987528 is a reply to message #986434] Tue, 27 November 2012 00:22 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas HuserFriend
Messages: 42
Registered: March 2010
Member
Hi Matthias

Ok, I understand that you don't want to remove a feature that has been added previously on user request Smile So we'll stick with the search for all launguages.

I like the presentation of the three different matches in the proposal view (icon plus highlighting of the matched text, key=value for foreign language matches).

As soon as we are mixing different types of matches in one (sorted) group, I think it is crucial that we also sort by the string that matched.
Ignoring such a sort order might cause confusion (see Adrians initial example, where a "perfect match" was not listed at the top) -- sorry for repeating myself, but it wasn't totally clear to me whether this was included in your example.

The preference for texts in the development language (i.e. putting them on top of the list in a separate group) seems ok for me -- but then, I could also think of a use case where this is not a good idea: When I'm searching for a short key or foreign text which happens to be a common prefix to texts in the development language (it's actually the same problem as with the sort order described above...).

Well, maybe it would be best to try it out and compare different variants with some real life data...

Re: [SDK] Discussion: Proposed text entries and order [message #987713 is a reply to message #987528] Tue, 27 November 2012 17:24 Go to previous messageGo to next message
Matthias Villiger is currently offline Matthias VilligerFriend
Messages: 232
Registered: September 2011
Senior Member
Hi all,

I agree to the proposals as described in the posts before. therefore I implemented it accordingly for 3.9.0 M4.

New behaviour:
Proposals are divided into two groups: direct matches in dev-language and other matches.
the type of match is indicated using the icon and the two groups are separated.
Within a group the proposals are sorted alphabetically by the text that matched the search filter (better matches on top as explained by Lukas).

please test the new behaviour and check if it matches more the expected results. any more comments and ideas are welcome here and may cause bug 380507 to be reopened.

regards,
m
Re: [SDK] Discussion: Proposed text entries and order [message #988222 is a reply to message #876276] Wed, 28 November 2012 22:05 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas HuserFriend
Messages: 42
Registered: March 2010
Member
Hi Matthias

I was able to test the new behavior of the NLS dropdown box in a large project (> 2000 texts, translation to > 20 languages) -- and I like it Smile

There are still some (minor) issues, though Smile

index.php/fa/12536/0/
Sort order should be non-case-sensitive -- it is currently very hard to find short lowercase texts.

index.php/fa/12537/0/
There seems to be special logic connected to a '-' character. Any text following a '-' is grayed out. Probably not intended...

index.php/fa/12538/0/
Searching for short foreign texts which are a common prefix for many texts is hard. This is not an issue for me as I rarely search for foreign texts anyways.

It turns out that this is not a real issue when searching for keys, because for short texts, the key is usually the same as the text in the development language.
Generally, searching for keys works quite well because of the fact that keys cannot contain spaces. As soon as typing a multi-word key, other text entries are quickly eliminated because of the missing spaces in the key.

So I really like the partition into two groups with the development language in the upper group. I think that the new implementation is a great improvement over the current behavior! Thank you!
Re: [SDK] Discussion: Proposed text entries and order [message #988281 is a reply to message #988222] Thu, 29 November 2012 09:28 Go to previous message
Matthias Villiger is currently offline Matthias VilligerFriend
Messages: 232
Registered: September 2011
Senior Member
Hi Lukas,

Thank you for looking into it. And I agree to your findings. Both bugs have been fixed with the latest version.

Yes, when searching for a short pattern, to go through the list is hard. This is mainly because you get a lot of hits as your search criteria is weak if it is that short.

regards,
matthias
Previous Topic:Annotation @ConfigPropertyValue
Next Topic:How to get image in Image view
Goto Forum:
  


Current Time: Fri Mar 29 11:44:26 GMT 2024

Powered by FUDForum. Page generated in 0.02978 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top