<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I think looking at other applications for inspirations is great.
Especially ones that are very different. It often results in wonderful
ideas.<br>
Eric, see below for embedded response to your points.<br>
<br>
The current view has 3 lines:<br>
Line 1: search selection radio buttons and bible picker<br>
Line 2: search text input area and optional input ("..." button) when
in passage lookup mode.<br>
Line 3: additional optional input (present on search and match) and a
"Go" button that does the work.<br>
Each line is fairly tall and as a result takes up a lot of vertical
pixels.<br>
<br>
At this point we can lay it out pretty much any way possible as long as
it keeps current functionality (what it does, not how it does it).<br>
Here are the "requirements" that I see from examining the code:<br>
* A user can have more than one search at time.<br>
* Each is maintained with its own View (tab in TDI mode or window
in MDI mode).<br>
* A user can search one of three ways passage lookup, word search
or verse match.<br>
* Each View can display a different bible from the other views. In
MDI mode this can create a parallel bible view.<br>
* A users search request is always processed and is displayed to
the user as a list of ranges of verses. (This is true for passage
lookup as well. The user has great freedom in entry input. "g.1.1" will
result in "Gen 1:1". If persistent naming is off then this becomes
apparent as the users input is replaced with the resultant range list.
If persistent naming is on then it maintains the user's input as typed)<br>
* If the user is doing a word search or a verse match, they may
further restrict the search to a specific portions of the bible with a
range list.<br>
* If the user is doing a passage lookup, then instead of free form
input, they may use a dialog to construct the passage range list.<br>
<br>
Here are the "requirements" on usability coming from users:<br>
* Show the request when showing the results. Currently for word
search and verse match, the results are put into the View: text entry
on the passage lookup card and that card is displayed. This flipping is
"surprising" to the user.<br>
* Don't have a confusing display. (widgets that have dual purpose
confuse the user.)<br>
* Don't occupy a lot of real estate. This may be real (number of
pixels) or perceived (number of widgets).<br>
<br>
Eric Galluzzo wrote:
<blockquote cite="mid1093923019.9397.47.camel@localhost.localdomain"
type="cite">
<pre wrap="">On Mon, 2004-08-30 at 13:08, DM Smith wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Here is a mock up:
</pre>
</blockquote>
<pre wrap=""><!---->
[snip]
Hmmm. I'm not sure I like this terribly: 5 lines is an awful lot of
real estate. Let me see if I can reduce it by comparing with the
Mozilla interface.
In Mozilla:
* The "address bar" contains both toolbar buttons and the editable
address field.
* Searching is done either in a sidebar or by typing something in
the address field and selecting "Search for XYZ" in the
dropdown.
</pre>
</blockquote>
I use mozilla's firefox and it has a different way of doing search and
sidebar. So I can't comment on the mozilla browser.<br>
<br>
I did find that when you switch from one tab to another the address
changes to show the address of the tab.<br>
<br>
It may be possible to move some of the widgets to the toolbar and have
them be tied to the active View (tab or window). I have only seen
buttons in Java's JToolBar. So I don't know if we would have to use
something else. If we use something else, we loose the ability to move
the toolbar (it is free w/ JToolBar and not worth "buying", IMHO)<br>
<br>
In mozilla everything on the address bar is related to finding
addresses. I'm not too sure our toolbar is all that useful, but it has
an eclectic group of unrelated functions.<br>
<br>
Since we can hide our toolbar, we would need an alternative way of
doing input or remove the ability to hide the toolbar. I think we need
to have some of the widgets always visible (user text input, bible
selected and resulting passage range list.)<br>
<br>
<blockquote cite="mid1093923019.9397.47.camel@localhost.localdomain"
type="cite">
<pre wrap=""> * There is no equivalent of the bible dropdown, the restriction or
passage fields.
Applying this to the Bible Desktop, we could perhaps reduce the amount
of real estate required by:
* Getting rid of the radio buttons and putting the search and
match and the corresponding fields in a sidebar
</pre>
</blockquote>
I find that I don't use the sidebar because it is not initially shown.
I think I will find it more useful as I use search and match. If we
were to put core functionality into it, I think it will need to be
displayed from the start.<br>
<blockquote cite="mid1093923019.9397.47.camel@localhost.localdomain"
type="cite">
<pre wrap=""> * Getting rid of the radio buttons and displaving a plain text
field that "popped down" a search and/or match option
* Putting the "Find" field on the same line as some of the other
fields (say, the Restriction field, which shouldn't be too
large)
</pre>
</blockquote>
This is doable. The only problem I see is in MDI mode when windows are
put side by side for a parallel passage view. The widgets become very
squished. This is why I move the bible picker to a separate line from
the search selector.<br>
<blockquote cite="mid1093923019.9397.47.camel@localhost.localdomain"
type="cite"><><br>
Another possibility is to have just a plain text field with a "More<br>
Options >>" button that pops down the other four lines. Selecting
a<br>
radio button in the "more options" section would cause the plain text<br>
field to behave in that manner, and the settings would persist even if<br>
the "More Options <<" button were pressed in order to reclaim the
real<br>
estate. Does that make any sense at all? It's kinda late. :)<br>
</></blockquote>
Yes it does. And thanks for the input.<br>
<blockquote cite="mid1093923019.9397.47.camel@localhost.localdomain"
type="cite">
<pre wrap="">
- Eric
_______________________________________________
jsword-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
</body>
</html>