[jsword-devel] Some navigation features in jsword

[DM Smith]

Yingjie,

Would you mind joining our "bugs" tracker and adding these to it. That way they won't get lost:
http://crosswire.org/bugs/browse/BD

I see a few things to track:
Chapter change buttons
Bible view paging
Case-insensitive search  (This would go in http://crosswire.org/bugs/browse/JS)
Name search
Auto-extension for verse lists.
User control over index features. (This would go in http://crosswire.org/bugs/browse/JS)

If you add them to the wrong "project" that's no big deal as they can be readily moved.

Otherwise, I'll try to get to it this weekend. 

See below for comment on searching for Ram.

On Dec 18, 2009, at 7:53 AM, Yingjie Lan wrote:

> Thanks a lot for the quick response. I think jsword is getting along the way to become a very nice bible study tool. I did some word search when I study the Bible and I encountered some other issues here:
> 
> 1. If you search for "Ram", you got "ram" as well, but "Ram" is a man's name, so giving me the verses containing "ram" are really not what I meant -- and there are a lot more verses containing "ram".

The problem here is two fold:
1) Names are not specifically identified in any of our modules/books. So it is not possible to find only those references to the name Ram. It would be great to have a listing of names per verse so that we could mark them up some how.


2) Our search, as you notice, is case-insensitive. Typically, a case insensitive search is what a user wants. Any word can be capitalized if it starts a sentence. Sentence identification is not hard for English Bibles, but English commentaries often have abbreviations ending with a period, making sentence identification problematic. And in some languages, such as German, words in middle of a sentence may be capitalized. Other languages don't have upper and lower case (e.g. Arabic, Hebrew, Chinese, ....)

The best we could do is double index each word. Right now we normalize each word to lower case. We could also store the word as-is. This would require searching a special field to get that behavior.

You might not have noticed but searching "Ram" will also find "rams" and "rammed" as we also do stemming by default for those languages for which we have stemming rules.

It might be nice for a user to control whether the search index uses stemming or not.

> 
> 2. If you save your verse list to "Ram.lst" (you have to append the extension, otherwise you won't be able to open it later, it would be nice if the extension is automatically added), then you do another search (say for "Uz"), you have to use "save as", otherwise it will override the "Ram.lst". In this use case, it might be more reasonable if a warning message box is issued and one can specify/choose a new file name. In fact, I think saving as a file might not be as convenient as saving as a bookmark (containing just the verse numbers, not the verses).
> 
> Please see my other comments below:
> 
>> Both of these are good ideas. I'll
>> add them to our issue tracker for BibleDesktop.
>> 
>> See below.
>> 
>> On Dec 18, 2009, at 3:18 AM, Yingjie Lan wrote:
>> 
>>> Hi there,
>>> 
>>> I am using jsword more often now, and soon found that
>> some convenient navigation features are quite desirable:
>>> 
>>> 1. use space bar to pagedown the text (bible text,
>> and/or other text).
>> 
>> It should be straight forward to add it to the Bible
>> viewer. We probably should tie the up/down keys to
>> scrolling, too. (They seem to be but it is not working well
>> on a Mac.)
> 
> We can have space (shift+space) for pagedown (pageup, following the firefox and other popular software tradition), and the Bible text viewer is the most desirable place to have it, as it is used the most often, and usually contains multiple pages. It would also be nice to have it in other places but might not be that useful, but if not too much trouble, having the same feature might give users a uniform/universal way of navigation through text panels.
> 
>> 
>> But to add it to the other viewers, we'll also need to add
>> the notion of focus or active view. We had this at one
>> point, but it was confusing a good number of users. What was
>> active was not clear.
>> 
>>> 
>>> 2. navigate to the next chapter/book with just one
>> click on a button.
>> We probably should add <- and -> buttons around the
>> book/chapter picker for this. It might also be good to tie
>> it to <- and -> keys too.
> 
> That's a great idea! maybe <-, -> for next chapter, 
> shift+<-, shift+-> for next book, something like that.
> Just remember, this operation is always based on the book/chapter picker. If you had performed some kind of search, and you'll leave those search results if you  perform those actions.
> 
>>> 
>>> 
>>> Maybe there are already some good ways to do it, but I
>> am just saying that providing more habutal/obvious ways of
>> navigation would make jsword more user-friendly.
>> 
>> We have the up/down keys working on the dictionary picker
>> and the general book picker. You have to click in the window
>> to get them to work and this is an example of how it is not
>> visually obvious what is focused.
>> 
> 
> OK. I wonder if there is some kind of color scheme change (such as background/foreground color) when focused. This is usually the standard feature in GUI systems, but I am not sure if Java has that too.
> 
>> 
>>> 
>>> Thanks and appreciate the good effort in providing
>> this wonderful software!
>>> 
>>> Yingjie
>> 
>> In Him,
>>     DM
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>> 
> 
> Bless,
> 
> Yingjie
> 
> 
> 
> 
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel