I am replacing all my suggestions in this thread with the following two
proposals:
1) Display a message in the status bar for each match which
basically says “There was a match".
Because:
It keeps the status bar relevant regardless of
whether there is a match or not.
2) When there is no match, replace the current status bar message,
("Did not find an element meeting the search criteria.")
with something along these lines:
"In current search direction: No element (or no
more after the selection) meet the search criteria."
Because:
This message would tell the user that the red
outline (if there is one) in fact is correct!
Also: It would as well keep the user informed
about the fact that preceding Find-command
(the preceding search) started/continued from
*after* the red outline.
Longer justification for the last proposal: Blind spot in the tool.
The tool, as is, has a blind spot, namely the previous element match.
Imagine a document like this:
<html>
<p class="a">Bar</p>
<p class="a">Foo</p>
<p>Bar</p>
</html>
If you first create a search that looks for <p> elements whose text
equals "Foo", you will end up selecting the middle <p> element and if
you click on «Find» once more, you are (currently) told that the tool
«did not find an element meeting the search criteria». (Mostly) fine.
Now, if - after previous step - you alter the criteria to look for
attributes whose content equals "a", you will get the same message that
no element matched the criteria - meaning that current element is a
blind spot (as long as search direction is "Down"). But if you now
change the search direction to «Up», then (too) only a single such
element will be found (namely the first <p>) - meaning that the current
red outline element once again ended up as a blind spot.
I believe I would prefer that, as soon as one alters the search
criteria, the current read outline will be included in the search. But
as long as this is not the case, the message when there is no match,
ought to inform the user that, actually, the currently red outline was
not included in the search.
(Part of the problem here is that the tool matches elements - despite
the fact that the search criteria defines character matches. Another
part of the problem is that there is no simple way to make the search
tool start from the top of the page: If you close the search tool, all
its settings are lost. And so you can - to avoid the blind spot - for
instance search for the root element, so that the tool, when you search
downwards, will find both instances of <p class="a">. This feels
cumbersome. But a goog status bar message would at least help me getting
used to it.
Leif Halvard Silli
On 13 Mar 2018, at 21:02, Leif Halvard Silli wrote:
On 13 Mar 2018, at 9:53, Hussein Shafie wrote:
On 03/12/2018 11:09 PM, Leif Halvard Silli wrote:
Relating to XXE 8.0 (and perhaps earlier versions as well):
When the (new) Find Element dialog locates an element that matches
the
search criteria, the element receives a red outline. This way the
users
knows that there is a match.
But if an element this way has been matched (and has received the
red
outline), and you - after that - changes the search criteria and hit
“Search” once again, then there is no (visual) signal that shows
you
that the new criteria works.
We cannot reproduce this behavior. When a new criteria is specified:
- If this new criteria matches an element following currently
selected element (red box around it), this other element is selected
(new red box).
Confirming your first “if”.
- If the new criteria does not match any other element, sentence "Did
not find an element meeting the search criteria" is displayed in the
status bar found at the bottom of the main window.
Confirming your second “if”, with a “but”:
But (and assuming that second “if” occurred /after/ first
“if”) I note that you did not say that second “if” would make
the red outline from first “if” /disappear/. My expectation was
that it would. I will explain why etc below.
--> May be you have uncovered a bug. May be XXE crashed when you
clicked "Find" with the new criteria. Please open a console and check
for low-level error messages there.
If you cannot do that, please explain how to reproduce this behavior:
---
you - after that - changes the search criteria and hit “Search”
once again, then there is no (visual) signal that shows you that the
new criteria works.
---
I trust that there was no crash. It is only a matter of user
expectations and so on.
How come?
Well, if the new criteria does not match anything, I would expect
the
red outline to disappear. But that does not happen. Thus, the fact
that
the red outline remains, does not mean that there is match. In other
words: Once there has been a match, the visual feedback is the same
whether or not the new criteria matches the same element or not.
Would I would like to suggest is that if the criteria does not match
anything, then the red outline is removed. This way the user gets to
know that there was no match for the new criteria.
We don't agree with what you suggest: "if the new criteria does not
match anything, I would expect the red outline to disappear." Why
that?
Because it the outline is a signal that something is found. Why does
it remain when nothing is found? It is confusing.
For instance, in Apple’s TextEdit.app for MacOS, if the Find/Replace
tool locates "foo", the match(es) of “foo” get highlighted in the
document (it is a “live” search). If you then continue to search
for “fooBAR”, and there is no “fooBAR" in the text, the
highlighting disappears. The highlighting in fact disappears in the
moment your search does not match anything.
It is the same in the Find-in-page tool of today’s Web browsers
(checked in Firefox and Brave).
And it also the same for the Find tool of XXE’s very own source
editor.
Vim (I checked MacVim) behaves the same way as well.
From memory, I know that I have used one tool which behaved like
XXE’s Find/Replace tools, but with the the difference that for each
match, there is a momentary higlight - in the form of a momentary
flash - to signal ”the moment of the match”. After “the moment
of the match”, the highlight color would go back to yellow.
The only exceptions I have found (appart from XXE’s Find/Replace
tools) are Nisus Writer Pro.app (a MacOS word processor with heavy
reg.ex support), if the Find/Replace dialog window performs your
first “if“, and then your second “if”, the selection of first
”if” remains. However, in defence of Nisus Writer Pro, the Nisus
Find/Replace dialog window includes its very own ”status bar” in
the bottom of the dialog window. Thus it is much more difficult to
overlook. Also, in Nisus, the feedback from the status bar does not
(as in XXE) disappear after 10 seconds.
The red outline is a very strong feedback signal. This in itself can
make users overlook feedback from the statusbar. Since the dialog
window is possible to move around, it is even possible to move it over
the status bar - so that its message (which is displayed only for a
few seconds - while the outline remains) gets hidden from the users.
Also, in XXE, the status bar of the Find/Replace dialog window is
located in the document dialog window - another reason why it is easy
to overlook the signal from the status bar.
For XXE’s Find/Replace pane tool, I can understand why it behavs
like it does. But in that case, there is dialog window that pops up in
your face telling you that nothing was found. But in the case of the
element Find/Replace dialog window tool, there nothing equivalent -
nothing that “pops up in your face”.
Example use case: Is looking for the perfect match, so to speak ....
And so, after first “if”, the user tries to either simplify or
complicate the search critera of first “if”. In other words: The
uses wants to match the very same element found in first “if” but
with another search criteria. (May be the user needs to broaden or
shrink the search criteria.) The user ends up with a valid search
criteria which however does not match the element of first “if” -
and also does not match anything else in the document. However,
because the red outline from first “if” remains even after second
“if” has been performed, the user is wondering whether or not
there was a match. (Of course, this user did not look into the status
bar).
If the new criteria does not match anything, the following sentence
is displayed in the status bar (during about 10s):
---
Did not find an element meeting the search criteria.
---
This feedback is deemed sufficient.
If only the user understands how it works, it is sufficient.
Anyway, this RFE could be solved at least in these ways:
1) A momentary flash to signal a match. And a lack thereof to signal
no match.
2) Making the red outline disappear when nothing is found;
3) Adding a status bar as part of the element Find/Replace dialog
window.
4) A combination of 1) and 2).
5) Teaching the users to understand how it currently works.
Leif Halvard Silli
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
