Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/876276/#msg_876276
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.
Cheers Adrian]]>Adrian Staudt2012-05-24T09:41:43-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/876297/#msg_876297
(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]]>Jeremie Bresson2012-05-24T10:33:59-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/878528/#msg_878528
Because the more accurate entries come on top it is faster to get to the correct entry using the arrow keys.]]>Matthias Villiger2012-05-29T13:39:18-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/878661/#msg_878661
Looking foreward to this new feature.]]>Ivan Motsch2012-05-29T17:10:50-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/879546/#msg_879546
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
]]>2012-05-31T11:59:31-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/879690/#msg_879690
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]]>Matthias Villiger2012-05-31T16:45:24-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/981840/#msg_981840
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]]>Matthias Villiger2012-11-12T18:46:58-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/986032/#msg_986032
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
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)
]]>Lukas Huser2012-11-17T19:03:18-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/986434/#msg_986434
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]]>Matthias Villiger2012-11-20T12:17:14-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/987528/#msg_987528
Ok, I understand that you don't want to remove a feature that has been added previously on user request 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...
]]>Lukas Huser2012-11-27T00:22:30-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/987713/#msg_987713
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]]>Matthias Villiger2012-11-27T17:24:18-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/988222/#msg_988222
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
There are still some (minor) issues, though
Sort order should be non-case-sensitive -- it is currently very hard to find short lowercase texts.
There seems to be special logic connected to a '-' character. Any text following a '-' is grayed out. Probably not intended...
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!
]]>Lukas Huser2012-11-28T22:05:39-00:00Re: [SDK] Discussion: Proposed text entries and order
https://www.eclipse.org/forums/index.php/mv/msg/354916/988281/#msg_988281
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.