[sword-devel] frontend features, their applicability -- consistency?

[Nic Carter]

Ok, I'll keep this brief cause it's 2:30am & I'm on my phone, but I  
pretty much agree with Karl.
Re: bookmarks: PocketSword has a 2 min worth of effort implementation  
in there atm. This WILL change soon, as with loads of other features.  
I get to play catchup with all you big boys, cause I've only been  
working on PS for such a short period of time...

But perhaps this is the time for me to say I'm considering cutting  
support for the GenBook format? The iPhone has the kindle app, has a  
very cool CCEL app & is about to get the iBooks app (from Apple), so I  
can't see much point.

If there are other features the team here at CrossWire believe are  
extremely high priority for PS (or any other front-end, for that  
matter), speak up & I'll look into it. Unlocking of modules will be in  
the next release, due in a week or 2... :)

ps: I reckon that bookmarks sync between PS and a desktop would be a  
manual process (in that you need to hit a button to do it, rather than  
it all being automagic cloud-based syncing), so it would be something  
you could opt out of, for the persecuted country situation. &  
bookmarks might be something that happens between PS & MacSword, cause  
we can share all the same Obj-C code (says Nic, without talking it  
over with Manfred!). And is also a feature that would, of course, be  
part of the iPad version of PS... :)

Ok, bed time, can't wait to read other replies to this in the morning :)

(sent from my iPhone, hence this email is brief!)

On 15/04/2010, at 2:24, Peter von Kaehne <refdoc at gmx.net> wrote:

> Thanks Karl, this is brilliant!
>
> Karl Kleinpaste wrote:
>> This brings a couple problems.  First, we have the necessity of the
>> interaction: Does the user allow this to occur?  If the user  
>> declines --
>> for now, or forever -- then we are left with an application that  
>> still
>> must provide bookmark storage.  That means that we must create 2  
>> retrieval
>> methods for bookmarks, and that complexifies the bookmark subsystem  
>> in the
>> application.
>
> Would this be required? I would think that every application stores  
> its
> folders of internal settings +/- may provide a import/export/sync
> capability. Does this need to be amalgamated functionality? I would  
> not
> think so.
>
>>
>> The result is that, regardless of whether network-sync'able  
>> bookmarks ever
>> get implemented, every application must still provide its own  
>> method for
>> doing so locally.  That will be OS-, language-, toolkit-, and
>> filesystem-dependent, thus usually not portable.  I'm simply not yet
>> excited about having to expand this in Xiphos, because the value  
>> gained
>> from doing so likely won't offset the anguish of its development.
>>
>> But why do I say that?  Because sometimes we have warped ideas of  
>> what's
>> important.  Generally speaking, we are often not like our users.
>>
>> In a related discussion in the Xiphos devel list, it was pointed  
>> out that
>> we as developers sometimes have an odd perspective about  
>> interoperability,
>> because we keep multiple applications installed in order to test our
>> features and our modules, and so we think "everyone" must want
>> "everything" to work together.  On its face...um, yeah, sure, and  
>> while
>> we're at it, we love baseball, motherhood, and apple pie, too.  In
>> reality, how many Joe Averages are there, who particularly care  
>> whether
>> bookmarks can be sync'd among Xiphos, BPBible, BibleTime,  
>> PocketSword,
>> Bible Desktop, and BibleCS?  Do you (does anyone) actually do  
>> remotely the
>> same kind of study in 2 different applications?  Do you care  
>> whether your
>> tightly-managed bookmarks in Xiphos are directly usable in  
>> PocketSword,
>> which doesn't yet provide bookmark titles, has no hierarchy, and no  
>> multi-
>> verse support?  For facially similar applications (say, Xiphos and
>> BibleTime, or BPBible and BibleCS, or...pick any pair), does Joe  
>> Average
>> actually use 2 such applications, so that sync rises to the level of
>> interest, or in fact does he look over a couple of the available
>> possibilities, and then come down in favor of using just one?
>>
>> Can we even claim to know?  If so, how?
>>
>> A prime, on-point example: Since the Dawn Of Net.Time, there has  
>> been code
>> in GnomeSword/Xiphos to import BibleTime bookmarks.  But the code  
>> to do so
>> was so unsupported that it simply stopped working well over a year  
>> ago,
>> when BT left behind its KDE specificity.
>
> Part of the reason is probably general direction of user mobility.
> People move Windows->Apple or Windows-> Linux, but after a bit of
> messing around, few move Gnome->KDE or vice versa.
>> Xiphos uses the exact same bookmark storage format as BT.
>
> Is it not also the same format as BibleCS? I think so.
>
>> I didn't know that until this time.  I didn't know because I had  
>> never had
>> cause to want BT bookmarks in the first place, because Xiphos is my
>> application of choice, and I do my study in Xiphos, where my  
>> bookmarks are
>> extensive, featureful, titled, commented.  Apparently, Terry simply
>> inhaled BT's format whole when he first implemented them for  
>> GnomeSword.
>>
>> _In practice_ no one cares about that beneficial compatibility,  
>> even when
>> compatibility comes literally for free.
>
> See above. KDE to Gnome (or back) is not a common move in established
> users. Last time I used KDE is 8 years ago.
>
>> The practical use case for bookmark sync is undoubtedly desktop -vs-
>> handheld device, and not for different applications that run in the  
>> same
>> (physical) environment, that is, desktops.  And so where we would be
>> concerned with sync is between, say, Xiphos and PocketSword...whose
>> respective metaphors for bookmarks are virtually unrelated.  What  
>> will
>> "sync bookmarks from Xiphos to PocketSword" mean, when my titles, my
>> hierarchy, and my multi-verse references will simply vanish during  
>> the
>> operation?  Would I ever want to sync back the other way?  No, never,
>> because too much information would be lost.
>
> I would think that this is the main place where syncing has a role to
> play. And the order of the day is clearly for mobile application
> developers to become equally featureful as desktop frontends.
>
>> Now please let me generalize and extrapolate: This in turn makes me  
>> wonder
>> about baseline capability, and what "should" be part of any Sword
>> application.  Certainly there are obvious qualifiers on which we  
>> would
>> agree about the bottommost bare minimums: Show selected Bible text,
>> generally on a per-chapter basis; provide for module installation;  
>> provide
>> search somehow; provide commentaries along with or alongside Bible  
>> text;
>> support UTF-8 to get correct display.  We could create a list of  
>> those
>> kinds of real bare minimums.  (We wouldn't /entirely/ agree on the  
>> list,
>> of course.  But we could probably come close.)
>>
>> How far beyond these bare minimums should we expect any (all) apps  
>> to go?
>
> We had some time ago a debate of what we would consider a "fully
> featured frontend" - and large part of this was what was considered
> necessary functionality.
>
> In essence it meant that every module could be displayed fully in all
> its features and then some. The canon and versification problematic  
> has
> of course thrown a major spanner into the works, making at this moment
> exactly none of the frontends truly "fully featured". But that aside,
> the debate took place about a year and a half or so ago around my  
> revamp
> of the website and discussions which applications may
>
>> I'm asking because, when I think about some of the capability that  
>> we've
>> brought to Xiphos in the last couple years, I realize that a lot of  
>> it has
>> no analogue or counterpart in any other Sword application.
>
> Again, the feature comparison page on the wiki was meant to create  
> some
> impetus towards standardisation and mutual convergence. I think it  
> has.
> One of the really fascinating outcomes (for me at least) was how  
> during
> compiling the comparison lists slowly a picture emerged of  
> applications
> developing in parallel and ignorance of each other, calling  
> essentially
> the same feature different names
>
>> Along comes Jane Random, who desperately wants Critical Feature XYZ  
>> in her
>> Bible study application.  She hears about The Sword Project, finds an
>> application, tries it out, and sees that XYZ isn't there.  And so she
>> concludes erroneously that The Sword Project isn't worth her time,  
>> and
>> worst of all, she tells her friends about her search for XYZ and  
>> how The
>> Sword Project didn't measure up.
>
> I think part of the answer would be to move the comparison page out of
> teh wiki into the general website and link + refer to it from various
> frontends. At the moment it is meant mostly for developers.
>
>> And to think that we have PR problems on our best days...
>>
>> As to those Critical Features:
>
> beyond complete module support this is for me: user content, image
> support, rtol, syncable bookmarking + commenting (sometimes called
> tagging), text comparison (see jsword), decent parallel display,
> integration of commentary in parallel views (see jsword), zip install,
>
> Peter
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page