Somewhat related: when talking about syncing user-created content, I found Craig Rairdin&#39;s BibleTech:2008 talk &quot;Beyond Mobility: Synchronizing User-Created Data Between Platforms, Readers, and Vendors&quot; interesting (though I&#39;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&#39;s worth thinking about syncing to non-Sword iPhone/Android/WinMobile/... applications.  It&#39;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">&lt;<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I&#39;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 &quot;Bible study&quot; 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, &quot;If you are in a persecuted<br>
place, avoid packet snooping/traffic analysis: Don&#39;t use the mod.mgr.&quot;<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&#39;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&#39;m simply not yet<br>
excited about having to expand this in Xiphos, because the value gained<br>
from doing so likely won&#39;t offset the anguish of its development.<br>
<br>
But why do I say that?  Because sometimes we have warped ideas of what&#39;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 &quot;everyone&quot; must want<br>
&quot;everything&quot; to work together.  On its face...um, yeah, sure, and while<br>
we&#39;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&#39;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&#39;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&#39;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&#39;t know that until this time.  I didn&#39;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&#39;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>
&quot;sync bookmarks from Xiphos to PocketSword&quot; 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 &quot;should&quot; 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&#39;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&#39;m asking because, when I think about some of the capability that we&#39;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&#39;t there.  And so she<br>
concludes erroneously that The Sword Project isn&#39;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&#39;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 &quot;prayerlists and<br>
journals&quot;), and per-verse user annotations in a &quot;yellow highlighter plus<br>
margin notes&quot; 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 &lt;scripRef&gt;.)<br>
<br>
Do other applications&#39; user communities not ask for the same things?  I<br>
notice that Crossway&#39;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&#39;s subwindow<br>
pane that&#39;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&#39;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, &quot;I used Application Foo from The Sword Project, and it doesn&#39;t do<br>
XYZ, so I just don&#39;t think Sword apps are adequate,&quot; we get a bad<br>
reflection on all of us.  The complaint&#39;s baselessness does not help us.<br>
<br>
I know we&#39;re all volunteers, and we all have different emphases and<br>
schedules and workflows and feature design goals.  I don&#39;t mean just to<br>
pick on a couple of Xiphos&#39; 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&#39;s no way to force any application&#39;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>