[sword-devel] Chapter-centric browsing (was: iPhone frontend alpha screenshots)

[Jonathan Morgan]

On Tue, Nov 25, 2008 at 6:57 AM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> Jonathan Morgan wrote:
>
>> I do think that in general removing the arbitrary chapter limitation
>> would be a good thing, but these considerations and others could be
>> important to getting it right.
>
> Most modern translations have a passage structure. I have played with
> this idea: we could have a fixed rough passage division, handled by the
> Sword library or a frontend. When the user wants to see a chapter the
> frontend could load the chapter but also preceding and following context
> so that if the chapter breaks a passage the whole passage would still be
> shown. It could be something like this:
>
> Passage1: 2:5-3:4
> Passage2: 3:1-3:20
> Passage3: 3:20-4:2
> Passage4: 4:2-5:1
>
>  If user asks for ch.3 he gets 2:5-4:2. If he asks for ch.4 he gets
> 3:20-5:1. The frontend decides the visual details.
>
> Notice how the passages are not restricted by other passages. This is
> because it's easier to find a safe, large enough sequence for every
> verse/chapter. There's another reason, too. Different translations
> divide the passages differently. This way we would hurt those as little
> as possible when always choosing a larger, "safe" passage. Even if a
> translation's passage would be cut, the wanted passage would always be
> included.
>
> This requires some work, of course. The whole Bible would need the
> passage database. It should have professional quality (modeled in modern
> academic translations/editions).
>
> Pros:
> - works for all modules which use ch/v.
> - technically not too difficult to implement
> - fits well for the existing frontend styles, doesn't need any new UI
> techniques
> - no memory/speed overhead
> Cons:
> - may break the translation's own passage structure - one size must fit all
> - database needs work

I'll add another con - the poor user has no consistent mental model.
They can have no way to guess why one time they get 3:1 - 4:2 one
time, and 2:5 - 4:27 another time.  This could be especially
problematic if their module has a paragraph structure that is
different and is broken in some cases.

I think a continuous scrolling implementation is in theory better,
though this may be easier to implement for existing frontends.

Jon