Difference between revisions of "Frontends:FeatureList"

From CrossWire Bible Society
Jump to: navigation, search
(Module installer features)
(Workflow)
Line 11: Line 11:
  
 
Ideally, a Sword frontend would allow:
 
Ideally, a Sword frontend would allow:
* Re-arrangement of the layout of the application's areas.
+
* Re-arrangement of the layout of the application's areas. Including of undocking and docking of subwindows
 
* Removal of unwanted features.
 
* Removal of unwanted features.
 
* Plug in of new or alternate features. E.g. whiteboard collaboration, Facebook integration.
 
* Plug in of new or alternate features. E.g. whiteboard collaboration, Facebook integration.

Revision as of 22:04, 6 June 2008

Ideal Full Featured Sword Frontend

What makes an ideal frontend is dependent upon the platform and the targeted audience. A handheld, 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.
  • 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.

Workflow

Today each Sword frontend provides a different workflow. This is good for users as it gives them the ability to choose one that works best for them.

Ideally, a Sword frontend 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, either side-by-side or above-and-below
  • Parallel view for commentaries, either side-by-side or above-and-below
  • Search (see below)
  • Hyperlinked scripture references
  • Dictionary lookup of words, Strong's numbers, morphology, ....
  • Full unicode support/proper encoding support for all interface elements and all modules
  • Provide customized Input Methods for non-Latin input (especially where Keyman-style input is not possible, as on mobile platforms)
  • Font choice on a global level and on a per language and/or per module level
  • Transcoding and transliteration support (probably implemented with ICU).
  • Resolution independence, adaptable to both low and high resolution and small/large screens.
  • Speech synthesis to read content.

Module support

For bibles, the following should be able to be turned on and off (if included in the underlying module and if the frontend does not implement that feature in some other way):

  • Headings
  • Cross references (display & toggle)
  • Footnotes (display & toggle)
  • Strong's Numbers (display & toggle)
  • Morphology (display & toggle)
  • Toggling and/or simultaneous display of textual variants
  • Red letters of Christ
  • Toggling of Hebrew cantillation (important), vowels (less important), & morpheme segmentation (important?) and of Greek accents (fairly unimportant)

Genbooks, dictionaries and commentaries should all be supported.

User resources

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

Search Features

Search should have the following features:

  • Multiword search
  • Phrase search
  • Search Ranges (user definable)
  • Implemented for all modules, both keys and content
  • Search in multiple modules simultaneously
  • Search history
  • Prioritized search
  • Search for similar verses
  • Fuzzy search for approximate spellings
  • Wildcard searches
  • Full boolean searches (AND, OR, NOT, NEAR, ...)
  • Narrowed searches (searching with in the current set of results)
  • Proximity searches (searching across verse boundaries)
  • Searching SWORD features (keys, content, notes, Strong's numbers, morphology, headings, ....)
  • Related content searching (e.g. find verses having a Strong's number with a particular morphology code)
  • Searching for words with or without accents
  • Searching using transliterations
  • Bookmark/Saved Verse List search (e.g. custom topic searching)
  • Stemmed searches, language/content specific
  • Stop words, language/content specific
  • Compound word searches
  • N-gram searching (needed for languages that don't space words, such as Vietnamese.)

The search should also be able to complete a search very quickly (<5 seconds). It should by default match on full words (that is, searching for eat doesn't match verses with meat). This will probably be done using (C)lucene.

Ideally the different Sword search engines would be supported.

Usability

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


Module installer features

Installing/Upgrading/Deleting 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).
  • 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 upgraded modules.
  • Summarize available new modules upon demand.
  • Summarize available module upgrades 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 frontend and standalone.
  • Make newly installed modules immediately seen by frontends without restarting.

Presentation:

  • Show a listing of installed modules.
  • Show a listing of modules by site. (These listings of installed and available modules can be unified.)
  • Classify modules by content type (Bibles, Commentaries, Daily Devotionals, ...)
  • Classify modules by language, using full, localized language names, not codes.
  • 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 frontends MUST be GPLv2 licensed. (This should be obvious. The SWORD Project is GPLv2-licensed. All derivative works, such as frontends 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.)