Ideal Full Featured SWORD Front-end

What makes an ideal front-end is dependent upon the platform and the targeted audience. A hand-held, such as a PDA or phone, or an application targeted to children, probably would not be full featured.

Cross-platform

Runs on multiple platforms, e.g. Windows, Linux, Mac, PDA, Java ME.

Has native installers for each platform.

Has the appearance and behavior of a native application for each platform, current with each revision of the platform. E.g. Win98 and Vista applications have a different appearance.

Portable

USB

Provides an installer for the portable version (or clear instructions on how to install it manually).

Able to be run from a USB flash drive.

Installs modules to the USB drive.

Able to use modules installed to the USB drive.

Able to use modules already installed to the host computer.

Leaves no trace on the host computer. For example, no registry changes, preferences, host font installs....

Able to be installed/copied from the USB drive to the host computer or otherwise copied to another USB drive.

CD or read-only SD cards

Able to be run from a CD.

Able to use modules on the CD.

Able to be installed from CD to host computer.

Able to install modules to host computer.

Warns user when data is being left on the host machine.

Workflow

Today each SWORD front-end provides a different work-flow. This is good for users as it gives them the ability to choose one that works best for them.

Ideally, a SWORD front-end would allow:

Re-arrangement of the layout of the application's areas. Including of undocking and docking of subwindows

Removal of unwanted features.

Plug in of new or alternate features. E.g. whiteboard collaboration, Facebook integration.

General UI features

Bible reading

Direct passage lookup

Easy navigation from one book/chapter to the next/previous.

Parallel view for Bibles and Commentaries, either side-by-side or above-and-below

User resources

The front-end should support user created material. Users should be able to put references in to any passage in the bible, or to any other module.
Users should be able to create both commentaries and hierarchical books (and possibly dictionaries, i.e. topical notes).

Users should also be able to manage (create, edit, save) verse lists, possibly with comments on each verse.

Users should be able to manage bookmarks in a tree list. These bookmarks should be so that they could be shared between different frontends. A Standard for bookmarks is under discussion.

User generated material should be for that user alone (on a multi-user OS), unless specified by the author for viewing by all users.

↑ To allow for saving search results as a "verse list" and utilizing all the features available (such as cross-references and dictionary lookup)

↑ Similar to using the separate Sword utility emptyvss.exe, but restricting the search scope to within available books. e.g. For modules that are NT only

Usability

The front-end should be easy for users to use. Most of its features (and all of its major features) should be able to be used without having to look at the manual. Also, it should not contain bugs or crash.

Media

Front-end capability to provide multimedia additions to modules.

Pictures (image modules or even integrated illustrations)

Audio recordings (important for many cultures)

Video clips (we live in the YouTube generation)

Module installer features

Managing modules

Before connecting to the Internet, warn users that their network activity might be externally monitored in countries or work locations where Christians are persecuted.

Allow remote installation of modules from both the CrossWire website and other websites the user adds to their list.

Predefine the CrossWire download site.

Allow the user to downloaded and install zips (via the remote installer).

Allow local installation of modules (e.g. from a CD or phone SD card).

Install modules by drag'n'drop to the front-end application (e.g. local zip file).

Work over a proxy.

Automatically detect network settings.

Before downloading, provide the user with the size of the download, so that they can decide whether to download or not.

Allow the user to cancel a download.

Allow the user to queue download requests. (The application may download serially or in parallel. If in parallel, should not overtax the download site or the user's machine)

Show the progress of the download.

Allow downloading to a shared location.

Allow downloading to a private location.

Downloading should be fault tolerant, not leaving an unusable module in the download location.

Allow auto-notification of new modules.

Allow auto-notification of updated modules.

Summarize available new modules upon demand.

Summarize available module updates upon demand.

Allow the deleting of shared and private modules.

Hide modules that require a later release (e.g. don't show modules that require 1.5.20 when you only have 1.5.10 installed), but permit the user to unhide them.

Offer to delete obsolete modules (i.e. read every .conf, make a list of the contents of all Obsoletes entries, offer to delete any matching installed modules)

Running

Be able to be run from within a front-end and standalone.

Make newly installed modules immediately seen by front-ends without restarting [low priority].

Presentation

Show a listing of installed modules.

Show a listing of modules by site. (These listings of installed and available modules can be unified.)

Allow the user to filter modules so that they see only the one's they want. (E.g. Only English, Greek and Hebrew and no Glossaries)

Have a search facility to find modules of interest.

Show the parts of the conf meant for users.

Other

All front-ends MUST be GPLv2 licensed. This should be obvious. The SWORD Project is GPLv2-licensed. All derivative works, such as front-ends and utilities, must be GPLv2 or they would be in violation of CrossWire's copyright and the copyrights of 3rd parties whose code has been incorporated into SWORD, e.g. the FSF.