Future directions

JSword and BibleDesktop are a community effort. Each developer brings to the table personal interests and abilities. This ultimately drives how this software changes. Below is an outline of some changes for the future. Please feel free to join and post to jsword-devel anything you wish to add. You may also register with Jira, our development planning tool (sometimes called a bugs database, but it is much more than that) and add your ideas there.

  1. Strong set of tools suitable for biblical research.
    1. Translation comparison. Two translations in parallel columns are represented as a "word diff" in a third column with strike out and additions clearly represented.
    2. Transliteration display of non-Latin alphabets.
    3. Improved search.
      1. Transliteration search
      2. Accent insensitive search.
      3. Synonym and related term search.
      4. Stem search for supported languages (e.g. depluralization, root words, ...)
      5. Strong cross reference. (E.g. find all verses having a particular Strong's number; Find all the ways that a strong's number is represented in the text)
  2. Improved usability:
    1. Persistence to the desktop. It remembers "view" choices, window sizing and placement.
    2. Personalization of the desktop. The user can choose what makes up the desktop and how it should be arranged.
    3. Ability to create a personal commentary, notes, annotations and the like for a bible. (All this requires is the ability to write a module.)
    4. Better display of the Bible text. (Since it will be a full fledged browser, with javascript, make it more interactive)
    5. Better navigation in Search History.
    6. Allow for customization on a per module basis (e.g. font characteristics, view settings, ...)
    7. Integrated help.
Some architectural changes:
  1. A framework which would make it easy for others to develop optional capabilities that can be easily discovered, imported, used and, if not needed, discarded. Ultimately, a core download should be pretty small and feature light.
  2. Rendering using a modern browser.
  3. An ability to work directly with OSIS files.
  4. A lightweight core API that can be used on mobile devices such as phones and PDAs. (We may have this already)
  5. Able to use any 1.5.0 Java runtime, with GJC being a specific target. The goal is to be fully open source. Currently we are reliant on closed source java.
  6. Use 3rd party code as a replacement. E.g. preferences, plugins, ....