There is significant progress in the project since last week. I reflected my initial ideas and conceptual work in Bug 195455 . The support for lightweight Find/Replace enhancement was great. Thank you for all the great ideas and responses. Discussion about this feature is continuing in Bug 99294 now.
Currently, I'm implementing (3a) from Kevin McGuire's comment which is:
As of today, remaining work is showing Options group and Scope group in the Find/Replace dialog in a good style, adding shortcuts, making sure of good performance.3) Have it take up space in the layout somewhere,
3a) current option is within the text editor itself ala Firefox
I've converted Direction group in the dialog having "Forward" and "Backward" radio buttons in it, to a compact button that switches the search direction. This saves a significant amount of space on the Find/Replace bar and will be far more functional than having 2 radio buttons for this task IMHO.
An issue that may arise when I'm implementing (3a) approach is supporting search in ConsoleView etc. (anything other than the editor) in a good way. I think of carrying the same functionality ( offering Find/Replace in a bar ) in Toolbar of the ConsoleView. I expect to face a few issues about searching outside the editor.
This is it for now.
You can keep track of my progress in lightweight Find/Replace from https://bugs.eclipse.org/bugs/show_bug.cgi?id=99294 .
Thank you for all the ideas,interest and support.
2 comments:
It is neat UI, but I think search bar is too complicated. If user need to tweak options or something they could simply use the regular search dialog.
Also, separate button for search direction is an extra click if you need to get back to the previous entry you just missed by clicking next too many times, and then you'll have another extra click if you need to continue after that. Classic search dialog in Eclipse has the same usability issue. Compare it with the similar search bar in FireFox, which instead uses Next and Previous buttons and require just one click for searching in any direction.
All in all I think search bar should use single row height and most optimal UI is probably something like this:
[x] Find: [_____] [Next] [Previous] [Options...]
where "Options..." would simply open regular search dialog. Does it make sense?
BTW, a feature like FireFox's "Highlight all" would be also really handy.
Thank you for comments.
The direction issue is about choices I guess. Since we may not know if the user actually wants to change the direction or just find something backwards then continue forwards, I think that there are 2 possible behaviour in this case:
1. putting Next & Previous like Firefox.
This is good for mouse users. However, a user may want to set his/her direction and just continue in that direction. In Firefox, you cannot really set your direction backwards, the default direction is forwards (when you hit Enter). You just use "backwards find" button with your mouse. In this case, a keyboard shortcut may solve this but it's usability won't be equal to Enter key.
2. Having one button to change direction (current form). This style clearly has all the disadvantages you mention but when the direction is changed, user can continue in that direction by just hitting Enter.
Well, I can still implement both styles (even change this in the end since this is a small one) but I guess we should decide on the common user behaviour first.
About including/excluding "Replace" field in the bar:
In its current form, I tried to keep both Find and Replace facilities visible at the same time.
However, I can arrange a bar-switch behaviour or open a second bar on top of "Find" bar for "Replace". Is it a good solution?
I'm investigating into "Highlight All", too.
Thanks again.
Post a Comment