Home » Eclipse Projects » Eclipse Scout » [SDK] Discussion: Proposed text entries and order
| | | |
Re: [SDK] Discussion: Proposed text entries and order [message #879546 is a reply to message #878661] |
Thu, 31 May 2012 11:59 |
Eclipse User |
|
|
|
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 #986032 is a reply to message #981840] |
Sat, 17 November 2012 19:03 |
Lukas Huser 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 |
Matthias Villiger Messages: 235 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
|
|
| | | | |
Goto Forum:
Current Time: Wed Sep 25 04:32:56 GMT 2024
Powered by FUDForum. Page generated in 0.04517 seconds
|