[jsword-devel] Suggestion for improving display

[DM Smith]

How about if instead of switching back to lookup, we just left the user 
on the same card? Several people have commented on how they were 
suprised by the flipping.

If they wanted to see the passage, they can use the side bar.

If we always showed the sidebar, it would become obvious that it 
contains the search result. Would that be good to do? The user can 
always hide it and we could make it a preference as to whether it is 
initially shown.

Joe Walker wrote:

>My opinions are:
>- if we were to use Lucene rather than Ser then getting rid of the
>radio buttons would be sensible (see separate email)
>- The restriction toggle would then be missing, maybe we could make
>the restriction line hidden unless the toggle is on (it would be
>placed between the find text-box and the go button) This would reduce
>it from 5 lines to 3 which it is currently.
>- My usability concern is that it might make is less obvious that the
>passage pane could be edited whenever you want, however since the
>select button is more obvious now that is probably less of a problem.
>
>Joe.
>
>----- Original Message -----
>From: DM Smith <dmsmith555 at yahoo.com>
>Date: Mon, 30 Aug 2004 13:08:03 -0400
>Subject: Re: [jsword-devel] Suggestion for improving display
>To: Java SWORD Developers Mailing List <jsword-devel at crosswire.org>
>
> Here is a mock up:
> 
> 
> When search or match is selected Restriction is enabled and Select is disabled.
> 
> We can go one further, if we can merge search and match. We can get
>rid of the radio buttons altogether.
> If Find is non-blank, "Go" uses it and restriction to fill in passage
>and displays the passage.
> If Find is blank, and Passage is not then "Go" displays the passage.
> "Select" will change the passage as it does today.
> 
> I don't know if getting rid of the radio buttons would be too confusing.
>
>
> 
> 
> DM Smith wrote:
> 
>Several people have made suggestions/requests for improvements in the
>lookup/search/match area.
> Perhaps Mark meant that the divider between the LHS and RHS could not
>be moved to the left. This is a side-effect of sizing the combo box to
>the size of the longest bible name. I  changed it from having a
>prototype that always truncated medium size names to one that
>displayed them all.
> 
> If we put this on a line to itself, it will show the full bible names
>and also allow the divider to be moved. It will still limit the amount
>of travel to the left, but in my testing it seems to be a reasonable
>limit. Any smaller and the reading area becomes too narrow, IMHO.
> 
> Someone suggested that search and match should not jump back to the
>lookup screen. This would allow the user to see their search request
>and the answer at the same time.
> 
> I suggest that we merge the three cards into one. The basic idea is
>that all three perform a search, the interpretation depends upon
>context. In each case the result is a passage. In the case of the
>lookup, it replaces the search request with the results. In the case
>of the other two, it puts the result in the lookup card and switches
>to it. In the case of search/match, the lookup can be restricted.
> 
> There still would be a Bible ComboBox picker. 
> There still would be a radio button group of lookup/search/match. 
> There still would be an entry area for search request. 
> There would be a restriction widget, which would be active if either
>search/match is selected.
> There would be a lookup passage button, which would be active if the 
> There would be a result text area, which would show the results of
>the lookup/search/match
> 
> So from a layout perspective 
> Row 1: Bible Picker (or this can be on the same row as radio buttons
>as it is now.)
> Row 2: lookup/search/match radio buttons 
> Row 3: Search input w/ Go button 
> Row 4: Search restriction input or Passage Selection button or both. 
> Row 5: Passage result. 
> 
> In the case of lookup, row 2 would not change, but row 5 would have
>the interpretation of row 2.
> 
> Someone else suggested merging search and match and trying to deduce
>which the user wanted. This would prevent the confusion concerning the
>difference between search and match. I don't think this would be too
>difficult.
>
>  
>