<br><br><div class="gmail_quote">On Tue, Mar 3, 2009 at 6:52 PM, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are a bunch of SWORD/JSword applications. Until very recently, The SWORD Project for Windows and Bible Desktop (BD) were the only ones available for Windows. Mac OS had BD and MacSword. On Linux, there was BibleTime, GnomeSword (now renamed Xiphos) and BD. (This is not to minimize AlKitab as it like BD runs on the same platforms.)<br>
<br>
This is changing. Xiphos now runs on Windows. Soon BibleTime will run on Windows and Macs.<br>
<br>
In discussions on the sword-devel mailing list, we have noted that these apps do pretty much the same thing, with some significant feature differences. No one app has run away with the prize. There are a variety of reasons, but I think the most common reason is that a user's favorite app works the way that they want to approach scripture reading and/or study.<br>
<br>
The current layout of BD assumes that the primary use is that of reading the Bible. Our goal for Bible Desktop is to have a simple, uncluttered interface, where the user can show/hide/adapt it to suit their desires. This is not quite full reality. We have had requests to show/hide the right hand panel and to show/hide the built-in daily reading plan.<br>
<br>
We have also had requests to make it a premier study tool complete with deep linguistic analysis.<br>
<br>
I think to make BD the killer application, we need to address both of these ends of the spectrum.<br>
<br>
Here is where my head is at regarding this:<br>
1) The user should be able to show/hide components of BD.<br>
2) The user should be able to organize those components as they see fit: side-by-side, tabbed, separate windows, ....<br>
3) They shouldn't have to do it each time they start the application.<br>
<br>
Today, for the Bible view, you either get a Multiple Document Interface, aka MDI or a Tabbed Document Interface, TDI. I don't like that dichotomy. And there is no Separate Document Interface, SDI, where each BibleView gets its own top-level window. Sometimes I want the tabs, but other times I want to see two tabs (out of several more), side-by-side. There are times that I'd like to tear off a tab and make it a separate standalone window. (And I imagine, I might want to put it back.)<br>
<br>
The other thing is the notion of plugins. The idea here is that a plugin would be independent from the main application and could be added/removed and shown/hidden at will. Once added and shown, it could be place as above. This probably will satisfy 1).<br>
<br>
It was noted that the NetBeans and Eclipse look and feel get in the way. Largely, I agree. But, they provide these capabilities for free.<br>
<br>
This and solving the rendering problems that Peter noted are the two strategic implementations I have for a 2.0 release.</blockquote><div><br>I've been interested recently in the things that made the web a success when other options failed.<br>
<br>One of those things, I think, strangely, was the poor UI controls.<br><br>There isn't a tab container, tree view, dialogs (except for yes/no/ok) <br></div></div>And the upshot of this is that people don't in general need training to use new websites, where as it's common to see people going on word/excel/etc training courses. Good UI design keeps things simple, and I think this is good both for the power user and the beginner.<br>
<br>I would totally support getting rid of MDI and TDI and replacing them with some sort of history/favorites mechanism.<br>The study books could probably share the same system too. You can only read one thing at a time, so I think concentrating on 1st class navigation makes sense.<br>
<br>We could have a single input box that we parse on every keypress and give feedback somewhere to explain what we think the user is trying to do. When the user types "Gen 1" we have a status bar say "press return to view Genesis 1". If we can't parse the input as a Bible reference then we change the status text to say "press return to seach for whatever". Much like the Google search box can to much more than search, we empower the BibleDesktop input box.<br>
<br>We could potentialy do something interesting by changing the rendering from HTML to Java2D, or even JavaFX. That way we could overcome the limitation of scrollbars and a pre-populated text box. By only rendering the text of the screen, we could have whole Bible scrolling that was way faster than the current rendering.<br>
<br>Anyway, that was all a bit radical.<br><br>Joe.<br><br><br>