[bt-devel] New passage selector proposal

[Patrick Zimmermann]

Thanks for the feedback.

I put my answers below your questions.

Blessings,
Patrick


On Thursday, 19. April 2012 01:40:17 Jaak Ristioja wrote:
> On 19.04.2012 01:14, Patrick Zimmermann wrote:
> > Hello,
> > 
> > since IRC doesn't seem to be a good place for feature proposal and
> > feedback, I repost this as an email. This should give everyone more
> > time to respond.
> 
> Yeah... sorry, I wasn't actually there for long.
> 
> > I made up a new GUI for selecting passages and doing searches in
> > BT. I would like your opinion on this before starting with the
> > implementation to prevent extra work.
> > 
> > The basic idea behind all this is to provide a quicker workflow for
> > accessing bible passages. Passages of which I may or may not know
> > the exact verse, i.e. I have to search.
> > 
> > http://devel.bibletime.info/images/0/09/SelectorProposal.png
> > 
> > Any feedback is very welcome.
> 
> I very much like your proposal and think that regarding UI design of
> BibleTime this is the best path to follow. The current search dialog
> is too previous-century.
> 
> However I have some questions:
> 
> 1) When exactly does the search (proposals) screen appear? Is it that
> when I click on a specific a part of the key (book/chapter/verse) then
> it jumps to the selection screen. How do I start searching for regular
> text? This was a bit vaguely described.

The GUI can operate in two modes, auto search switching and forced search 
mode.

In auto search switching mode it will open the search screen as soon as there 
are no more possible proposals left, or said differently, when the entered text 
does not seem to be a passage name. The search button should change 
color/shape or something to indicate this.
While typing the number of passages shown in the button selector at the bottom 
will shrink until there is none left and then the search screen is shown (or 
the "SEARCH" overlay, depending on what proves to be better).

When in forced search mode (entered by pushing the search button), no attempt 
is made to resolving the search term to a passage. This should mostly not be 
needed, but in case I want to search for "john" or something that could be 
resolved to a passage it is necessary.

I'm thought about making the parts of the key clickable too. The problem I see 
with this approach is, that the area to click on is quite small (in worst case 
the space of a "1"). I thought about overlaying three buttons: book, chapter, 
verse when hovering over the text box, but that would collide with selecting 
the text. Something like this is in fact needed to quickly switch chapters. 
But I don't have any ideas at the moment. I thought I'd leave it out for 
later. Any ideas welcome.

> 2) How does one use the selector bar to quickly switch to
>    a) a different passage from anywhere else in the open work(s)?

As written above, an unsolved problem.

>    b) the previous/next book/chapter/verse?

I thought previous / next buttons in the text area could be used to go to the 
next / previous chapter. This doesn't work well when I want to skip through 
chapters, but I think one rarely wants to do that.
Selecting verses can be done by clicking on them. Is there a need to select 
previous / next verses? What are verse selections for anyways (except drag-
and-drop to bookmark them)?
I think it's not necessary at all to have a quick way to select the *next 
book*. But the "next chapter" button could be changed to a "next book" when 
displaying the last chapter of a book.
Selecting a *different book* would be done by clicking into the text selector 
field, which should clear all text and open the book selector.

> 3) Is it comfortable for the user who uses only keyboard/mouse/touch?

Only mouse and touch users can use the button selector exclusively.
Only keyboard users can use the text selector.
Only mouse users might have a hard time with searching, but I think I can live 
with that. :-P

> 4) I didn't quite understand the Add/Replace menu. Please clarify how
> it works.

The idea is to combine the currently existing two buttons "add work" and 
"replace work" buttons into a single button. That button should, as it does 
now, open a dropdown menu. The distinction whether I want to add or replace is 
done by having all two "headings" in the menu list "add" and "replace". Below 
them are the normal entries that are known from the current buttons.
This is not touch friendly and might/should be changed into a selector that 
shows up in the central area, but I would leave that for later, since 
selecting works is not on the "hot path", at least not for me. And I would 
like to take an iterative aproach, at least to some extent.

> 5) Why double-click on the search results? Can't this be done in
> single click, i.e. something like google.com does that the search
> result item title is single-clickable, and the match is shown below
> the search result item and is not clickable?

Hm, the reason I said double click is because the single click was already 
reserved to show the result in the search window. Changing the searchwindow to 
directly show search results seems like a good idea.
For now I would like to keep the search window the way it is. Redesigning that 
window can be done later on. Again, I want to take an iterative approach.

> 6) What exactly are "Search mode" and "Auto search mode"?

Already explained above.

> 7) Does adding/replacing works in the search screen or the regular
> display screen constitute a new history item in the back/forward chain?

Didn't think about that. Sounds like a good idea. Again, I would favor the 
iterative approach and leave that for later.

> 
> Some proposals:
> 1) I think the search screen also needs a way to quickly select ALL
> installed works for search. And we need to figure out what to do after
> clicking on a search result in this case.

As said, I'd leave refactoring the search screen for later.

> 2) It were good if it were possible from the main window to open a new
> (empty) subwindow with no works open but only displaying a "search all
> works" screen which were like a "home"-page.

Good idea.

> 
> ***
> 
> Regarding implementing all of this I'm afraid you'll run into several
> obstacles which require extensive amounts of refactoring in both the
> frontend and backend. The simplest way might as well just to disable
> all existing frontend code for the display windows and start
> implementing the new display windows from scratch.
> 
> Somewhere hidden between all the legacy spaghetti code you might also
> bump into a serious issue (and a bug) about how to handle the display
> of works in parallel if the passages of those works provide don't
> fully overlap (e.g. if one work has new testament only, but the other
> has old testament only).
> 
> In general I think this would be a huge refactoring effort, much
> larger than refactoring the configuration system was. On the other
> hand I hope that I don't discourage you to try something I have
> previously failed to do by myself alone.
> 
> I will be extremely busy and mostly away during the following month(s)
> and summer, but after that I might occasionally have some time to help
> you implement/test all of this.
> 

I must confess that I already started implementing a bit.

My approach would have been:
-Start from scratch (no bibletime source) and implement a model to handle the 
selection state (I have a rough interface already, but I am not at all sure 
whether I am heading in the right direction).
-Either base that model on plain sword or use the CSwordKey as basis. Only do 
a rough, single module implementation for testing.
-Implement the text selector
-Implement the button selector
-Remove the singleton stuff from the search window to allow multiple search 
windows to be instantiated. I already did that and it worked.
-Either subclass CDisplayWindow and put the selectors and model class in there 
or start off with a new MDI window and only copy the code for the actual 
display window over
-Port my code over to use the bibletime backend. The connection points should 
be few, since it's only about retrieving available books/chapters/verses and 
selecting them.

So the only connection points to existing code are the CDisplayWindow, if I 
choose to subclass from that, and the interface between my selector model and 
the selection logic there currently is in bibletime.

I don't have a deep insight into bibletime code. So please correct me if this 
approach can't work or you think it's better done differently.


In principle the same selector model could also be used for books, 
commentaries and lexicons. But taking the iterative approach means leaving 
them for now. They can either stay the way they are or later on be migrated to 
also make use of the new selector model and get their own selector widgets. 
(The text selector works badly for normal books, the dropdown boxes as they 
currently have are be better suited I guess, but implementing a drop down box 
selector should be possible).

If this approach works out I don't have to touch existing code much.


Do you mean the following bug?
https://sourceforge.net/tracker/index.php?func=detail&aid=2993283&group_id=954&atid=100954
Yes, I will probably bump into it. But I don't think I have to solve it, do I?

> 
> God bless!
> Jaak
> 
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel