Talk:BibleTime2FrontendNavigator
The navigator is the most important widget in a Bible application (after the text display). Therefore it's worth analyzing deeply. I hope this is useful or at least entertaining.
Contents |
Most biblestudy pages in www which use some kind of a navigator beyond a simple text widget have usability problems. The most common problem is the drop-down list, which is an editable or non-editable combo box.
Problem with long list
When you show any number of items in that list it puts them one after one vertically. If the amount of items goes over some threshold a scrollbar is showed up. And here comes one usability problem. When user opens the list of the books of the Bible, it starts with the Genesis etc. If he wants Galatians he has to scroll down. But if he uses the location marker of the scrollbar, he has to have supernatural powers to get it to right location fast, because that location is only few pixels tall. Usually it takes moving down, moving back up, down again, frustration... Another option is to use the arrows, but they are slow. That kind of widget is just not designed for large amount of data.
Still one note about dropdown lists. Why to limit the number of visible items to e.g. 10? If there are tens of items, the problem I described comes up. Using as much space for the list as there is in the screen gives user direct visibility to more items and using the scrollbar, if it's necessary, is easier because the "resolution" is lower. (This is a more general note, but applies to BT if dropdown lists are used somewhere.)
Some applications have a tree list for navigation. A permanently visible list takes valuable screen estate and has the same problem with a combobox list: you have to scroll, and when you have opened some books/chapters, you have to scroll much more. Not good.
The same problem is inherent with the current BibleTime navigation widget. The idea is great, but one has to first shoot at a block (between up/down arrows) which is couple of pixels tall and a bit wider. Then he has to move the mouse with less than one pixel resolution (I tried!) and that's impossible. No hint of good usability.
Problems of the current implementation
There are also other problems with the current implementation. First, how to scroll the list of items is not self-evident to users - there are no similar things in other applications. You have to read docs (which the users usually don't do) or find it by accident.
Second, the up/down arrows are problematic. Usually "up" in spinbox denotes larger number and vice versa. But when you are browsing a document, "up" means back and it's contrary to the verse/chapter numbers. Do it either way but it's still confusing and that cannot be solved. Right-left arrows are better, they are the standard in modern multimedia. "Right" is always forward.
The scrolling mouse button is great once you are used to it. I noticed (by accident) that it works with the navigator also. But compared to the arrows and the document reading direction "up" is now "down"! Where's the logic? Maybe there cannot be one.
The other idea
Then something about the idea in this wiki. Generally it's good. There are some problems, however.
First: user clicks - nothing is highlighted. Why? If user clicks the widget he wants to edit it. I can't think of no other case. So, the part under the cursor should be highlighted immediately. It could be the book name, chapter or verse.
Second: if the widget looks like one text area but is really several, it's unnatural for users. There are no text areas which have many separated text areas inside it in other applications. Why not use visibly separate widgets if the user has to press tab anyways?
Third: the mouse is the best and easiest way to navigate for many users, there's no escaping that fact. Having the possibility to write with keyboard is obligatory, but so is using mouse only.
A new idea
I made a navigator mockup which tries to solve some of these problems. It's not perfect in any way, it creates some problems of it's own. For example, it takes much more space than some other solutions. But here it is.
There are three widgets for book, chapter and verse. Each one can work as the current idea in the wiki so that it has completion etc. Additionally each one has it's own backward/forward navigation arrows. They are self-explanatory. Then there is a combobox downward arrow indicating a dropdown list. I have located it under the text so that it's easily distinguishable from the navigation arrows. It's not familiar to users but is clearly visible and very natural after trying once. It almost begs you to click it to see what happens.
The "book" widget could also recognize chapter and verse number if the user writes them with keyboard. After parsing it just moves the numbers into chapter and verse widgets. Using tab key is more cumbersome than using space if you are a seasoned typewriter.
The difference between this and other similar ideas is mostly in the dropdown list. We know that there are so many books in the Bible and so many chapters and verses in each book. So we can make a nondynamic table instead of a list. In the picture the user has clicked the opening button in the book widget. Usually you get a short list with a scrollbar. But here you can see all the books at once, just move there and click.
The dropdown list has book names categorized. It helps to find a book visually. Categorizing can be done with colored background, now it's quite ugly (and takes more space because it has empty spaces). If a module has only OT/NT, the missing books are removed from the list. Apocrypha can be added.
This is the old way, used in some applications, to move to some book:
- Click the button to open the list
- Move to scrollbar
- Click and hold down
- Move, trying to find the right book
- Move back because you went too far
- Move forward because you went back too far (OR move to up/down arrows and start clicking them)
- Release button
- Move over the right book
- Click
And this is the new way:
- Click the button to open the list
- Locate the right book with your eyes (I think this is very natural after some time, because they are not only listed but also sorted in categories)
- Move to the book
- Click
There can be similar tables for numbers: 10 rows, as many columns as you need for the book in question. Moving to Psalm 80 is as easy as moving to Psalm 1. Not so in any implementation I know (when working with mouse).
A competitor's solution
UPDATE: The Word has a navigator which is quite similar to this. Here is a screenshot.
It has only one text field and a dropdown list. The list has submenus. This navigator is more simple than my mockup. It takes three moves to go to a different verse (and you can't move to another book without selecting ch. and v.), but the application has several other ways to navigate.
I'm not sure which one is better. If you want to move inside one book, it's easier to have a direct link to all chapters without selecting a book. But with The Word's solution you need only one click, three moves and one click to move to any verse (versus my 6 clicks and 5 moves). Maybe these two could be combined: from book selection list you can navigate to chapter list OR click the book name. If you want to change the chapter only, you can open the chapter list directly. One downside of submenus is that when you move the mouse too slowly, a submenu appears even if you don't want it. There has to be a delay, The Word has it (about 0.5 sec) and it works quite well.
The navigator activates the text when clicked (or F4 pressed) and it gives a list of completions. Very quick and handy. Also it activates the text after pressing enter, so after you have read your verse you can start typing another without pressing F4 or something.
BTW, the parsing algorithm can take a plain chapter:verse without book name and use the current book. e-Sword does that, but it doesn't recognize one number: it takes you to the first book name beginning with that number if that exists (e.g. 1Sam). Ideal solution would take one number as chapter.
This makes me think if the chapter and verse text areas are needed at all. In my proposal they give a good visible hint for user to meanings of navigation and dropdown list arrows. We could as well have three dropdown menu arrows under one text area. But then we need separate (6 or 4) buttons for forward/backward navigation. Unless we add links to the top and bottom of every html page and feel it's enough. The Word has links also (like it has toolbar buttons and a tree list window).
--Eeli
Many Bible programs have a treeview navigator. There are some advantages in it. It's easy to find. It's always there. It gives a feeling of some kind of safety. It's also familiar, you can see what it is by just looking at it. But I don't know if there are any real advantages.
Note that I'm talking about Bible view here, not necessarily general books. All Bibles have same books/chapters. We don't necessarily know anything about other books, they may have have any number of headers and nesting levels.
Too narrow
It has all the disadvantages of normal treeview panels. First, it's always too narrow. If you have only abbreviations of book names, numbers of chapters and numbers of verses, it may be wide enough. But if you want to use the names of the books, it would take too much screen space to leave it open. User can find the place even if he doesn't see the whole name, so this might not be crucial.
But problem becomes more important if we want to use modern passage navigation. The whole idea of TOC is that you can easily find what you are looking for. But narrow panel restricts the view to only the beginning of the TOC item. You cannot browse through the list rapidly with your eyes, but you have to hover the mouse to see the tooltips or drag the panel wider. Human brains are good at comparing things and selecting something relevant, but restrecting the view to one item at a time is not natural for them. Of course they actually may read one at a time, but the natural way is quite different than moving mouse to see an item, then reading it, then putting it in memory, then moving mouse again to read another... My main point here is that reading real paper book TOC is easy because you can let the brain do the subconscious work, but restricted view makes you do much work consciously with your eyes and hands.
BibleExplorer has an interesting mix of ch/v and passage TOC. You can see that it takes quite much space and even then can't show the headings. (Notice also how it adds "Chapter" in every place redundandly. Like I didn't know that number means a chapter here. It's actually distracting, not helpful.)
File:Bibleexplorertreeviewnavigator.png
Too short
The other problem, maybe greater, is hight. Even with my 900px high monitor the BibleExplorer view can show only a bit more than half of the book names at once (and what if we add apocrypha here?). Open Job and Psalms and it adds almost 200 lines. After that open Psalm 119 - if the treeview has verses, it's 176 lines more. After that you really want to collapse the tree unless you are willing to scroll up and down, trying to find a book name between books, chapters and verses.
Using the tree
With treeview you are using the same view to find books, chapters and verses, or possibly passage headers. It sounds good - after all, it's a treelike structure. But think it for a while. You want to start reading a book in the Bible. So you have to find a book name. Or you want to move to another chapter and find a chapter name. The problem is that there are book names, chapters and verses mixed up there and if you have opened some subtrees you see all of them. Normal treeview is not clear enough to make distinction between the levels, you have to really read what it reads. You have to find a book between books and chapters.
Fixing the problems
I don't know if this is worth fixing at all, but here are some hints:
- use only abbreviations of book names (width, visibility)
- don't add extra text like "Chapter" (redundancy, visual clutter, width)
- calculate the initial width of the widget intelligently
- don't show verse numbers in treeview (after selecting a chapter user can find it within the text) (height, navigating)
- try to separate different levels visually but not distractingly (navigating)
Conclusions
What you can do (apart from selecting an item) with a decent treeview panel is:
- scroll it up and down with mouse
- scroll it horizontally
- open and close subtrees
- collapse the tree
- drag it wider and narrower
- move mouse over an item to see it in a tooltip
- hopefully hide and show it again
But these all (except hiding and showing) are really unnecessary! With a properly designed navigation system we shouldn't have to do at all these things which are not related to the task at hand but to a deficient widget.
--Eeli
