[bt-devel] Search dialog changes

[Martin Gruner]

Hi Eeli,

I find the current solution confusing. AND adds something between the words, OR 
doesn't and you can use a special syntax there? To be consistent and intuitive 
we probably need to have three modes:

-"all words" (adds AND, removes OR)
-"some words" (adds OR, removes AND)
-"free search" (no changes, syntax help)

And it should remember my decision. :D
An alternative to removing AND/OR in the first modes, you could switch to "free 
search" whenever clucene syntax items were detected.

What do you think?

mg

On Saturday 15 November 2008 11:19:59 Eeli Kaikkonen wrote:
> I committed some changes to the search dialog.
>
> The first one is the AND/OR search type. This has been requested by
> users and I have seen this very reasonable. The implementation was
> harder than I first thought. The AND search just adds AND between the
> words - but what to do if user writes AND or OR by hand? I resolved this
> by changing the type automatically to OR if the string includes AND/OR.
> It's reflected in UI. Also history was a problem - should the history
> have ANDs? I resolved this by saving the history items as they were
> written, not adding any ANDs there. The same history item may now work
> as both types if user changes the type.
>
> The second one is the help button. I don't know if help buttons
> generally are bad or good. I don't like them, mostly because I'm used to
> buttons which open the ordinary help system and in the worst case not in
> the wanted place. It also was a distraction in the UI: there were many
> buttons on top of each other which made it difficult to find the correct
> one (even though they were in line with the other respective elements).
> Instead of the button I added a link which should raise interest in
> users even more than a button. It's immediately clear that the link
> points to syntax help, not to any general help. It's also right next to
> the AND/OR items which are those which may need clarification. At the
> same time it hopefully gives the idea of the OR type owning the "full
> syntax".
>
> The third one is the Search button. It's now placed next to the search
> text field where it's immediately reachable with mouse after writing
> some text. I think the text field and the action button are closely
> related and should be next to each other. Moving the mouse to the bottom
> of the dialog has always annoyed me.
>
> The AND/OR button group serves also as a nice visual divider between the
> most important part - text field and Search button -  and the rest of
> the options area.
>
> The fourth one is the Analyze button - it's moved to the left corner of
> the dialog, even though it's not visible now. It took valuable space
> from the result lists.
>
>
> The help text must still be rewritten and the help dialog should be
> ported to use a dialog which has a scroll area and is non-modal.
>
> These changes need feedback about the UI and heavy testing. I can't
> possibly find all ways the Search dialog is used and the AND/OR system
> may break.
>
>
> --Eeli Kaikkonen
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel