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

[Karl Kleinpaste]

Peter von Kaehne <refdoc at gmx.net> writes:
> 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.

Perhaps.  But if, as you suggest, ...

>> Xiphos uses the exact same bookmark storage format as BT.

> Is it not also the same format as BibleCS? I think so.

...then that example can be used instead: If I was a BibleCS user and
was moving to BT or Xiphos (still just within Windows), I would be
interested in hunting down where BibleCS stored its bookmarks, and
bringing them along for the ride.  And if I couldn't find an auto-import
facility for it, I'd be writing a bug report for it to become available.

There has never been such a bug/feature written against Xiphos, ever.
And we have a growing Windows community for Xiphos, of course.

Nobody real cares.  Real, in the sense of being a general user of our
software, as opposed to us, who are stuck on features for features' sake.

Xiphos has implicitly extended the semantic of that bookmark format,
simply by allowing a single bookmark to contain a fully general verse
listing.  Now, what will happen when I re-sync my Xiphos bookmarks back
to any other app which uses putatively the same format?  /oops/

> 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.

Abandon hope, all ye who enter here.

There is _physically_ no way for, say, PocketSword to achieve feature
parity with Xiphos (or BT or BPBible or...), simply because an iPhone
hasn't got the screen real estate to do what Xiphos does.  It's an
impossibility, due to the physical characteristics of the device.

It is, after all, a handheld device: A device that is deliberately
physically crippled in favor of making it mobile.  It *cannot* do what a
laptop or desktop does, fond fantasies to the contrary notwithstanding.

Example: Multiple simultaneous text display.  PS shows only one Bible or
commentary or dictionary at a time.  There isn't room to show more than
one.  And even there, unless you choose the tiniest of fonts, you can't
even see a complete Bible chapter.  I certainly can't make a commentary
follow along visually as I read a chapter.  Ergo, no feature related to
multiple texts can be achieved in PS.

My (very real) laptop is virtually attached to me at the shoulder strap
as things stand, plenty mobile enough for when I want an equally real
application.  PS is extraordinarily useful because it means I have a
Sword app in my pocket no matter what, even when I disconnect that strap
from my shoulder...but it is not and never will be a general study app.
I've even mentioned to Nic the need for a note-taking capability, but
would I ever expect someone to write a Xiphos-style journal there?
Absolutely not.  That is not what an iPhone is for.

> 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.

http://crosswire.org/wiki/Frontends:FeatureList

By its own admission, the page is idealist, so I'm not convinced that
the suggestions there represent a true baseline capability, but rather
lists all the bells and whistles one could ask for.

> 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

The Choosing page has been used by me as a motivator to get more boxes
filled in green.  It's a coarse and vulgar motivation, but it does mean
that e.g. we gained a non-modal module manager ("can continue working
while downloading"), and that we will have per-language font preferences
in our next release (now implemented).  A few things on the list Xiphos
simply won't or can't do, but Xiphos has, by far, the most green running
down its right-side column of any app.

> 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,

Of those, Xiphos is already there except for bookmark sync and text
comparison.  Matthew and I were discussing the latter a bit in reaction
to the Open Scriptures API discussion of a week ago; I see why it's
valuable but I'm not convinced that I (personally, anyway) want to add
it to Xiphos.