Somewhat related: when talking about syncing user-created content, I found Craig Rairdin's BibleTech:2008 talk "Beyond Mobility: Synchronizing User-Created Data Between Platforms, Readers, and Vendors" interesting (though I'm not sure that it solves all of the problems, because some of them fundamentally cannot be solved). The MP3 can be downloaded from the website.<div>
<br></div><div>Since listening to that talk, I have occasionally wondered if it's worth thinking about syncing to non-Sword iPhone/Android/WinMobile/... applications. It's probably not feasible, though.<br><div>
<br>
</div><div>Jon</div><div><br><div><div class="gmail_quote">On Thu, Apr 15, 2010 at 1:25 AM, Karl Kleinpaste <span dir="ltr"><<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I've had some philosophical meanderings about frontends over the last<br>
several weeks.<br>
<br>
One of the best things about The Sword Project is that a whole herd of<br>
applications has been able to grow up around the core engine. Support<br>
constructs based on platform capability, workflow ideals, toolkit<br>
provision, and other qualifiers have led to a lot of interesting<br>
variability in how each application particularly presents the generic<br>
concept of "Bible study" to the user. We have a wiki page on choosing the<br>
right application, in order to distinguish some of their features.<br>
<br>
But there is concern in my mind about a lack of consistency in how we do<br>
things, and possibly more importantly, where consistency matters.<br>
<br>
The immediate example that brings this to mind for me is the recent<br>
discussion on bookmark storage and sync. The goal sought is an ability to<br>
sync bookmarks across applications, providing e.g. desktop -vs- handheld<br>
consistency. A fine goal, on its face.<br>
<br>
But that mis-interacts with the general net.paranoia level with which we<br>
(are supposed to) provide our applications. Notably, if the storage is<br>
off-site, then the user will access a network resource, and that bumps<br>
sideways into the necessity of ensuring that the user wants to allow that,<br>
bearing in mind the general perspective of (notably) module managers, for<br>
which we are obligated to warn the user, "If you are in a persecuted<br>
place, avoid packet snooping/traffic analysis: Don't use the mod.mgr."<br>
<br>
This brings a couple problems. First, we have the necessity of the<br>
interaction: Does the user allow this to occur? If the user declines --<br>
for now, or forever -- then we are left with an application that still<br>
must provide bookmark storage. That means that we must create 2 retrieval<br>
methods for bookmarks, and that complexifies the bookmark subsystem in the<br>
application.<br>
<br>
The result is that, regardless of whether network-sync'able bookmarks ever<br>
get implemented, every application must still provide its own method for<br>
doing so locally. That will be OS-, language-, toolkit-, and<br>
filesystem-dependent, thus usually not portable. I'm simply not yet<br>
excited about having to expand this in Xiphos, because the value gained<br>
from doing so likely won't offset the anguish of its development.<br>
<br>
But why do I say that? Because sometimes we have warped ideas of what's<br>
important. Generally speaking, we are often not like our users.<br>
<br>
In a related discussion in the Xiphos devel list, it was pointed out that<br>
we as developers sometimes have an odd perspective about interoperability,<br>
because we keep multiple applications installed in order to test our<br>
features and our modules, and so we think "everyone" must want<br>
"everything" to work together. On its face...um, yeah, sure, and while<br>
we're at it, we love baseball, motherhood, and apple pie, too. In<br>
reality, how many Joe Averages are there, who particularly care whether<br>
bookmarks can be sync'd among Xiphos, BPBible, BibleTime, PocketSword,<br>
Bible Desktop, and BibleCS? Do you (does anyone) actually do remotely the<br>
same kind of study in 2 different applications? Do you care whether your<br>
tightly-managed bookmarks in Xiphos are directly usable in PocketSword,<br>
which doesn't yet provide bookmark titles, has no hierarchy, and no multi-<br>
verse support? For facially similar applications (say, Xiphos and<br>
BibleTime, or BPBible and BibleCS, or...pick any pair), does Joe Average<br>
actually use 2 such applications, so that sync rises to the level of<br>
interest, or in fact does he look over a couple of the available<br>
possibilities, and then come down in favor of using just one?<br>
<br>
Can we even claim to know? If so, how?<br>
<br>
A prime, on-point example: Since the Dawn Of Net.Time, there has been code<br>
in GnomeSword/Xiphos to import BibleTime bookmarks. But the code to do so<br>
was so unsupported that it simply stopped working well over a year ago,<br>
when BT left behind its KDE specificity.<br>
<br>
Nobody noticed, nobody cared. I have never seen a bug report or feature<br>
request concerning BibleTime bookmark import. Not one, not ever, in all<br>
the hundreds of bugs that have ever been reported against Xiphos over the<br>
last decade.<br>
<br>
Having noticed the problem because of the discussion on bookmark sync'ing,<br>
I mentioned it to our devel list. Terry stepped up and fixed it with a<br>
few lines of code. I tried it out; yup, now it works. This caused me to<br>
look a little bit into BT bookmarks, at which point I discovered something<br>
really important:<br>
<br>
Xiphos uses the exact same bookmark storage format as BT.<br>
<br>
I didn't know that until this time. I didn't know because I had never had<br>
cause to want BT bookmarks in the first place, because Xiphos is my<br>
application of choice, and I do my study in Xiphos, where my bookmarks are<br>
extensive, featureful, titled, commented. Apparently, Terry simply<br>
inhaled BT's format whole when he first implemented them for GnomeSword.<br>
<br>
_In practice_ no one cares about that beneficial compatibility, even when<br>
compatibility comes literally for free.<br>
<br>
The practical use case for bookmark sync is undoubtedly desktop -vs-<br>
handheld device, and not for different applications that run in the same<br>
(physical) environment, that is, desktops. And so where we would be<br>
concerned with sync is between, say, Xiphos and PocketSword...whose<br>
respective metaphors for bookmarks are virtually unrelated. What will<br>
"sync bookmarks from Xiphos to PocketSword" mean, when my titles, my<br>
hierarchy, and my multi-verse references will simply vanish during the<br>
operation? Would I ever want to sync back the other way? No, never,<br>
because too much information would be lost.<br>
<br>
Now please let me generalize and extrapolate: This in turn makes me wonder<br>
about baseline capability, and what "should" be part of any Sword<br>
application. Certainly there are obvious qualifiers on which we would<br>
agree about the bottommost bare minimums: Show selected Bible text,<br>
generally on a per-chapter basis; provide for module installation; provide<br>
search somehow; provide commentaries along with or alongside Bible text;<br>
support UTF-8 to get correct display. We could create a list of those<br>
kinds of real bare minimums. (We wouldn't /entirely/ agree on the list,<br>
of course. But we could probably come close.)<br>
<br>
How far beyond these bare minimums should we expect any (all) apps to go?<br>
<br>
I'm asking because, when I think about some of the capability that we've<br>
brought to Xiphos in the last couple years, I realize that a lot of it has<br>
no analogue or counterpart in any other Sword application.<br>
<br>
Along comes Jane Random, who desperately wants Critical Feature XYZ in her<br>
Bible study application. She hears about The Sword Project, finds an<br>
application, tries it out, and sees that XYZ isn't there. And so she<br>
concludes erroneously that The Sword Project isn't worth her time, and<br>
worst of all, she tells her friends about her search for XYZ and how The<br>
Sword Project didn't measure up.<br>
<br>
And to think that we have PR problems on our best days...<br>
<br>
As to those Critical Features:<br>
<br>
Take user-created content, for example. Aside from the original personal<br>
commentary that many apps support, Xiphos provides multiple such<br>
commentaries, and user-created genbooks (what we call "prayerlists and<br>
journals"), and per-verse user annotations in a "yellow highlighter plus<br>
margin notes" metaphor. We do these things because users keep asking for<br>
user-editable content. Our support has gotten good enough that users now<br>
write bug reports about really picky things, like the need to provide<br>
links in their journal text that *either* navigate directly *or* put the<br>
verse list machinery to use. (This mostly means the distinction of<br>
whether to use sword:// URLs or <scripRef>.)<br>
<br>
Do other applications' user communities not ask for the same things? I<br>
notice that Crossway's new ESV iPhone app is already getting raves because<br>
it provides a note-taking facility. The iPhone is decidedly *not* well-<br>
suited to composition beyond trivially short texts, yet note-taking is<br>
already considered important there. Why do other Sword apps not provide<br>
more user content creation?<br>
<br>
Consider also image support: Aside from simply displaying images, Xiphos<br>
has provided image resizing since the first time I knew of an image-<br>
containing module, realizing that a monster 3506x2055 map cannot be<br>
expected to be viewed (by a sane person) in an application's subwindow<br>
pane that's only 500x300. And even so, Xiphos provides external image<br>
viewing (click the image) so that the entire problem can be punted to<br>
something more appropriate when the application itself is simply not<br>
adequate to showing what needs to be showed: A map resized from 3506x2055<br>
to fit within 500x300 will be close to useless, so we let the user hand<br>
the image to an external viewer that can select and zoom.<br>
<br>
In late 2007, I first mentioned on this list a need for other apps to gain<br>
an ability to do image resizing. There were enthusiastic followups at the<br>
time to say that this really should be done. But no other app has done so:<br>
<a href="http://crosswire.org/wiki/Choosing_a_SWORD_program#Image_Module_Support" target="_blank">http://crosswire.org/wiki/Choosing_a_SWORD_program#Image_Module_Support</a><br>
<br>
On the one hand, feature distinctions are useful for advertising one<br>
application over another. It's a marketing thing: We of the Xiphos team<br>
can talk up our additional capabilities. On the other hand, I worry that<br>
a lack of consistent provision of some features will lead to a kind of<br>
backlash. We have enough trouble with PR; if people post in public<br>
forums, "I used Application Foo from The Sword Project, and it doesn't do<br>
XYZ, so I just don't think Sword apps are adequate," we get a bad<br>
reflection on all of us. The complaint's baselessness does not help us.<br>
<br>
I know we're all volunteers, and we all have different emphases and<br>
schedules and workflows and feature design goals. I don't mean just to<br>
pick on a couple of Xiphos' features specifically; there are surely things<br>
done by other apps that Xiphos is yet missing.<br>
<br>
Where does feature consistency matter?<br>
What does bookmark consistency buy for us, other than as a talking point?<br>
Where can we safely ignore whether our applications are consistent with<br>
one another?<br>
What are we to do about providing a sufficiently consistent baseline<br>
user experience?<br>
There's no way to force any application's development team to do new<br>
stuff, so how can we encourage teams to provide more capability, as a<br>
lower bound?<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div><br></div></div></div>