I am unsatisfied with my UI. There are two primary changes I want to make; possibly three. This is the reason why I haven’t done any serious work on the site for a month; I’m going to have to redesign everything.
The UI issue
The first issue is which UI to use. Single document, dual column, or floating columns. These approaches are nicely exemplified by biblehub.com, netbible.org, and biblegateway.com.
Single document is of course the easiest. However, I like the floating column approach of bible gateway for comparison — although, bible hub also does have a “comparison” view. I think actually biblehub’s concept of “tools and views” super encompasses both other approaches, in a way. But I am really drawn to NetBible’s interface.
As this is a bootstrap site it seems as if building towards a bible hub type design is best, easiest and most natural. Of course I do not mean copying their design I just mean the way in which their UI works seems very common among many different websites. Still, having a default two column view ala netbible is very appealing. Maybe a combination of these approaches.
The Document Format Issue
The next issue is the document format. The underlying problem is that DokuWiki markup code is not designed to do the kind of formatting necessary for a bible. It will not be possible to both have the bibles formatted the way they are on other sites or in print, and also print them nicely on DokuWiki. However, using DokuWiki will always be preferable to editing text files because of the revision system on DokuWiki.
Following are some ideas on how DokuWiki can manage a more advanced format without looking too bad.
Putting Verses on a Line
If each verse was on a line instead of a paragraph, then paragraph markers could be considered important (i.e. natural) markup for paragraph separation between verses. The downside is that editing becomes slightly more difficult, and we still have no method of indenting lines.
Using the XBR plugin
Similar to the above, this will make DokuWiki respect line breaks. The advantage is perhaps slight, as without this plugin we only need to add \\ to markup line breaks. The downside is that then we will basically have to concatenate all the verses and this is more trouble than just putting verses on a line
Using HTML
If we use html tags we can use html to format the document and it will display on the DokuWiki when viewed normally. The downside is editing becomes much more difficult, and there will be lots of html tags since html tags break sectioning (ex. ===).
Creative Use of Doku Markup
It may be possible to use DokuWiki markup creatively. For example, any lines which are indented could be set using double space (marking them preformatted) or by using blockquote. The least minimally invasive from an editing perspective is using double spaces or 4 spaces to induce pre-formatting, but there is also the quote symbol> which acts like a mini quote-block. This allows us to assume lines run together, then use \\ to line-break and > to indent a quote block when necessary. In fact we wouldn’t even need to use \\ since the quote block symbol handles the common use case. It does not display 100% the way we want on DokuWiki since the verse numbers are also indented along with the text, but this is a minor concern; it displays reasonably nicely (better than using spaces to pre-format) and we can easily re-interpret this behavior in the renderer.
Non-Doku Markup
This is what we would use if we were using a text file. However, there are really two cases here; one where the text is stored the way we are storing it now, verse-in-a-paragraph, and two, if the text were considered a document (verses concatenated together). Therefore let us consider each of the three cases:
a. using nondoku markup with all the verses concatenated together. In DokuWiki terms this would allow us to use natural paragraph breaks. Then we would just need a symbol for starting a quote block. such as %. The % symbol (for example) could suddenly start a quote block, and %% could be used to continue an indent block. Genesis 9:26-27 might read as follows in such a system:
26 He also said, %“Blessed by the Lord my God be Shem;[b]\\ and let Canaan be his slave.
27 %%God enlarge Japheth,\\ and let him dwell in the tents of Shem;\\ and let Canaan be his slave.”
In this case, we use the missing markup of % and %% to separate text that otherwise would be assumed to run together, and we would also need a paragraph marker.
Verse Control Tags
We could have something like [3i] or [3q] at the front of a verse, to indicate the text of that verse should be indented or the start of a new quote block.
Off-text formatting/Database
If stored in a database, we could have flags such as “indent this line”, or “paragraph marker after this line”. This is convenient because we could also store headings for a line in the same row.
Markup Required?
One pertinent question is, do we absolutely need markup to be inside the text? Since we are already using markup for notes, yes. But what about markup for formatting? Since we need to have quote blocks appear in the middle of text, unfortunately, yes. So one way of looking at it is that we will need some sort of markup for this, but exactly how or what I do not know.
Manual HTML+CSS
What about just using HTML and CSS right from the start? This is based on the idea that the document isn’t going to change much. This may or may not be worthwhile. I do not favor a complex document. However it will provide the best reading experience. It is more likely though that this is the end-approach generated out of a document or database. The question then is what markup or system (above) will be simpler and easier than just HTML from the start?
No Conclusion and (almost) No Standard
So far I have no real conclusion. I took a look at various translations on BibleHub and it is apparent that each one is using a different rendering system. However on bible gateway various bibles seem to use similar markup, leading me to believe they have a standardized system. The entire thing is very confusing.
I wish to keep using DokuWiki. This means I will need to assume all lines run together (in the reader app) and will need to introduce special markup to handle quote blocks. However it seems the amount of information that can be added to the text is immense, including linking nearly every word to a Strong’s number (essentially creating an interlinear bible). Many such goals would be more easily done in a database. Ultimately I may be forced to consider some sort of OSIS-like markup system. For now I will sleep on it, and this week I will do some more research into the systems that the main sites seem to be using. I will remember my conclusions here when I get to them.