[Loadstone] Loadstone enhancements (updated)
Rogalski at o2.pl
Mon Feb 2 06:25:46 GMT 2009
Regarding Loadstone GPS as powerful, exceptional navigation software,
finding it irreplaceable mobility aid for the blind,
striving to make Loadstone a perfect tool
that may be ahead of different such applications,
with intention not of complaining, but improving,
I'd like to share ideas and report bugs collected during last half a year among both beginners and experts of Loadstone,
suggest the following enhancements and request for the following features.
Opinion of Loadstone team is most crucial here, but, of course, feedback from Loadstone users is equally welcome.
I personally know two symbian programmers; maybe we all could start an international cooperation, discuss which functions and to which extent can be incorporated, and then share the job (discuss who can work on what)?
- Problem: Automatic route creation, perceived as the most important, most useful and long-awaited ability of navigation software for the blind, is very limited and time consuming in Loadstone, especially without any access to the PC, on-line tools and the Internet.
Route creation is understood here as an automatic guidance from one point to another, which includes recording, playing, browsing and reversing a path.
* Solution 1A: Chained points: not just checking of points should be important, but the sequence in which those points are checked.
* Solution 1B: Loadstone should guide to the next point if you pass the previous one (namely pay attention to the points which had already been passed and not announce the other).
* Solution 1C: Point sequence would depend on how the points are arranged in a checkpoint file.
-- All that would make it possible to reversing routes.
* Solution 2A: Creating an additional menu, called "tools", that contains shortcuts to all on-line Loadstone tools, provided they are all fully accessible from a Symbian phone and optimized for Nokia Web Browser.
* Solution 2B: Route creation or other operations would be partially processed by Loadstone web server.
The idea is: Firstly, input file together with set parameters are chosen in a special dialog box, then a suitable request is sent via http, and then, after remote processing, the final output is sent back as a downloadable file.
* Solution 2C: Incorporating breadcrumb generator and checkpoint list generator to Loadstone
(meaning: checkpoint file with directional comments would be created from NMEA file directly on the phone).
* Solution 3: Introducing additional Settings tab, called "Logging", which acts as a kind of NMEA sentence filter.
The idea is: In order to make a route creation process less complex, to decrease amount of data processed on a phone or server, and to transform Loadstone into a powerful data logger, such as Wintec WBT-201, Royaltek RBT-2300 etc., you can set which NMEA data and under what conditions are to be saved in a .log file. These conditions are as follows
(Note that ideas below are based on different hardware data loggers and on Aspicore GSM Tracker application):
-- Entry saving upon a specified time interval (eg. every 5 seconds).
-- Entry saving upon a specified distance (eg. every 50 metres).
-- Mix of both (eg. NMEA entries are saved every 5 seconds, unless the distance of 50 metres is exceeded before).
-- Entry saving upon a specified time interval, depending on the velocity (eg. within speed of 1-10km/h - every 5 seconds, within speed of 10-50km/h - every 10 seconds, etc).
-- Dynamic platform: smoothing of speed deviations, too rapid and non-typical for a particular transportation mode.
-- Maximal speed above which the entry is not created.
-- Maximal accuracy (HDOP) above which the entry is not created.
-- Minimal angle (eg. 20 degrees) - entry is saved only if heading equals or exceeds this value.
* Solution 3B: Push-to-log: a mapable key (eg. long #), which causes manual adding NMEA entry when key pressed.
- Problem: Loadstone database engine for phones with SYmbian 3rd Edition (eg. Nokia N82) seems to work more slowly than on Symbian 2nd phones (eg. Nokia 6680), especially during import or export.
* Solution: Check if it's true, please.
- Problem: Polish RealSpeak "goes mad" and reads point information in a completely incoherent way.
As a consequence, it is impossible to use the official version 0.71 at all.
* Solution: There is a need for adding a space between point name and point distance.
- Problem: When Loadstone catches a fix, but the user doesn't move, then instead of a message eg. "Last heading: North", there is: often a message "Speed: 0km at , heading: North"
(message translated from Polish).
* Solution: "at" or the whole string about speed should be removed from this message.
- Problem: It is tricky to refresh status of GPS fix (key 3 in navigation mode).
You have to choose another shortcut and press 3 again. Multiple pressing of "3" causes no reaction.
* Solution: Key 3 should work as other keys (satellites, accuracy etc.), namely, each pressing returns current value.
- Problem: It's impossible to use all the localization technologies for a particular receiver simultaneously.
* Solution: If you eg. select an internal receiver, all technologies available for it should get turned on together automatically, as it is in Nokia Maps or Wayfinder Access.
- Problem 1: Selecting GPS receiver (internal or Bluetooth) is too complex.
It requires goig both to Settings and to GPS menu.
Therefore it is not confortable to quickly switch between different GPS receivers.
Problem 2: Internal receiver doesn't work properly or doesn't work at all on Nokia N82.
* Solution: GPS source (internal / Bluetooth, and then eventually name of external receiver) should be selected only via menu GPS, option "Find GPS", in order to avoid additional necessity to go to "Settings" or choosing a single technology).
- Problem 1: The technology Bluetooth appears even under Internal receiver technologies.
Problem 2: In spite of choosing that "Bluetooth", there is "No signal" message" even if Bluetooth receiver is turned off.
Problem 3: As it can be observed on the Loadstone mailing list, that "bluetooth" present under Internal receiver, causes a mess and is not clear for most users.
* Solution: Bluetooth technology should be removed from "Internal" group, as Bluetooth is a technology much more related to external, Bluetooth receiver, than to internal receiver technologies.
- Problem: If during an import process the user doesn't keep watching over the phone, he won't know if all points had been imported or which were wrong and why.
* Solution: Full error messages (plus such data as filename, time of beginning and end of import, and eventually the wrong lines) should be saved in a separate file, called eg. "Errors.log" inserted in an "ImportExport" subdirectory.
- Problem: Loadstone options are sometimes unclear.
* Solution 1: For better clarification, an option "Export" in the menu Checkpoints, should be changed into "Export as database".
* Solution 2: The filename "DefaultBluetoothGPS" should be renamed into "DefaultGPS", as the default may be internal, not bluetooth receiver.
- Problem: Some options are available even if they cannot be used at all.
* Solution 1: If a point is checked, then an option "Check point" should not be available for this point.
* Solution 2: If a point is locked, then an option "Lock point" should not be available for this point.
- Problem: At least in Polish version, there is not enough space for UserId in a window "About" and it doesn't show up.
(Unfortunately, the license message cannot be shortened due to translating reasons).
* Solution: USerId should be provided in a separate window, meaning, as another option called "UserId".
- Problem: Point announcement parameter (setting to 0) is not consequential.
* Solution: This window should be organised exactly like the "Comment announcement", namely with an options "Offf", "Approaching", "Arriving", "Both".
- Problem: It's not clear how to show all the search results in one list.
* Solution: Adding a parameter called eg. "Show All" or "Unrestricted" in search results Settings.
- Problem: Checkpoints are sometimes announced too early or too late.
* Solution: In checkpoints announcement, the priority should be given to approach distance and not to approach time, as the distance seems to play more crucial role here.
Problem: Many users ask for easy automatical announcements of points which are being passed.
* Solution: Loadstone might constantly check if there is any database point within arrival radius; if so - announce it.
Additional setting can be introduced, if Loadstone should announce only checkpoints, only points in database or both.
- Problem: Manual checking of a large number of points is quite "laborious" without access to a PC and on-line tools.
* Solution 1: Adding an option "Select all" to the Checkpoints menu, which would select all points in the loaded database as checkpoints. Optional configurable limitation can be set to 1000 points by default.
* Solution 2: Adding an option "Select all" to search results.
- Problem: Operations made on checkpoints list files is quite difficult without access to a PC and on-line tools.
* Solution: Adding an option "Browse checkpoints" to the Checkpoints menu.
Checkpoints might be browsed in the form of a list, arranged as they occur in the checkpoints file.
Some operations should be easy available:
-- Check/uncheck with star [*]
-- Del with [Shift]
-- Select all
- Problem: Quick showing or checking of points recently added to database, requires too many key presses and good brain memory. It is not always easy to remember the names and sequence of added points.
* Solution: Adding a function which sorts database points according to the field ID (timestamp) and displays the results in a form of a list, in descending order. The number of points displayed is set in Loadstone Settings.
The function can be useful eg. while checking bus stops for a particular bus, and also for creating checkpoint files where it is enough to check only some characteristic points of a route.
- Problem: It is quite tricky to find out when a point was created, especially without any access to the PC, on-line tools and the Internet.
* Solution: Adding an option "Show creation date" to the "Current point" menu.
This date can be calculated from the field ID (timestamp) of a given point.
- Problem: Point removal can be achieved only partially. They change priority to 4, but still exist in the database, making that large and messy.
It's difficult to filter out such points without any access to the PC, on-line tools and the Internet.
* Solution: Deleted point should disappear from database file totally and completely.
- Problem: Quick update of a nearest point requires quite many key presses.
* Solution: Making a shortcut for update of a nearest point coordinates.
- Problemm: If one uses Auto-Announce quite often, then has to turn it on each time Loadstone is started.
* Solution: Introducing additional setting, if Auto-Announce should be turned on automatically upon startup.
- Problem: It happens that there is no time for making a text label to a point.
* Solution: Some GPS devices for the blind, eg. Polish Navigator, have an option of recording voice labels for each point.
This function could be also introduced in Loadstone.
The assumption is:
-- The labels are stored in a separate subfolder, and named with date+time creation or the timestamp (ID field of a related point).
-- An additional prefix, eg. "Sound" can be added for better clarification.
-- Shortcuts for recording and playing such sounds, as well as reference to these options in "Current point" menu, are also needed.
-- Equally important is the integration of such sounds with point search and point exploration.
Each sound file is directly related to its point and belongs to that point.
A sound file cannot exist without its point - meaning, if a point is deleted, its sound should be deleted as well.
(While deletion, Loadstone would check if there is any sound related to the point; if so, deelete it as well;).
- Problem: Loadstone menu is not always intuitive enough.
* Solution: It might be rearranged for better operation, as follows
(Note that only suggested changes, and not the whole menu structure is presented below):
*** Mode: Exploration mode, Navigation mode, Training mode.
*** Memos: Record memo, Play memo, Browse memos
The assumption is:
-- Memos are displayed in a form of a list, in descending order;
alternatively, the folder with memos is being opened.
-- Memo content can be "scrolled" with right and left arrows;
Volume of playback can be changed with up and down arrow.
-- Creation of multiple memos is possible (recording of the 2nd one won't overwrite the 1st one).
-- Memos are stored in a separate subfolder, and named with date+time creation, and not as "memo.wav".
-- An additional prefix, eg. "Memo" can be added for better clarification).
Alternatively, after recording has stopped, a window appear, where you can enter a filename).
*** Tripmeter: Start / Show / Pause / Resume / Stop (tripmeter).
-- Apart from trip distance, tripmeter could show as well:
Trip time (from the beginning),
-- If one is following a loaded route, the tripmeter could show as well:
Name of starting point,
Name of the destination,
Trip distance to the destination,
Trip time to the destination (calculated from average speed and distance),
Arrival time (returned as hours and minutes, calculated from average speed and distance).
-- All these data should be presented in a form of a list, and be refresh with key 9, as it is in Wayfinder Access.
*** Logging: Start / Show / Pause / Resume / Stop (logging).
-- Here, "Show" returns logging time, excluding GPS drift (being not in motion), if achievable.
-- Creation of multiple log files is possible (recording of the 2nd one won't overwrite the 1st one).
-- Logs are stored in a separate subfolder, eg. NMEA or Logs, and named with date+time creation, and not as "nmea.log".
-- An additional prefix, eg. "NMEA" or "Log" can be added for better clarification).
Alternatively, after logging has stopped, a window appear, where you can enter a filename).
*** Sun (options concerning soon, as they are now).
*** Moon (options concerning moon, as they are now).
*** Settings (as they are)
*** Help: About, License, User ID.
-- Here, "About" returns the version number and the date of compilation.
"License" returns info about GPL, as it is now.
"UserId" returns that 5-digit number, calculated from "USerName".
- Problem: Loadstone shortcuts are not always intuitive enough.
* Solution: 1: Shift+5 should announce the previous checkpoint.
* Solution 2: Shift+6 should announce curent decimal latitude and longitude.
- Problem: It is easily forget to save checkpoints.
* Solution: The assupmption is:
On exit, you are notified of existence of unsaved checkpoints and a window appears, where you can enter a filename.
- Problem: Checkpoint file format deviates too much from database format.
Therefore it is more tricky to create checkpoints on PC and forces user to make additional text edition steps.
* Solution: Below is an example of format modfication:
Current database format:
Current checkpoint format:
Desired checkpoint format (after modification):
The assumption is:
-- Checkpoint format should be as similar to a database format as possible. It differs only with a fullstop after first two digits of coordinates (minutes) and with quotation marks (comment field) at the end of the line.
It was unnecessary to place coordinates at the beginning of the line (exchange point name with coordinates).
-- In order to avoid conversion conflicts, Loadstone should accept all checkpoints formats:
1. The first one (coordinates only):
2. Current checkpoint format:
3. Expected checkpoint format:
- Problem: It is difficult to observe the progress of import, export or search.
* Solution: During these operations, only the message eg. "Importing..." should appear on the screen,
with a progress bar (read by Talks, as in the case of software installation);
under SoftKey 2 - "Cancel", under SoftKey 1 - nothing.
-- Actually, import, export or search require quite much CPU and memory. As a result, the phone slows down to such extent that any further operations become almost impossible.
- Problem: In case of search results, area results etc., it's impossible to determine at which item of a list the focus is placed.
* Solution: These data should be presented in a form of a list, similar to that which is in Nokia Maps or Wayfinder Access.
Then Talks would say eg. "1 of 15".
- Problem: Making new Loadstone users to learn shortcuts more efficiently.
* Solution: If while scrolling through menu, you "stand" on function to which a hot key is assigned, that hot key could be spoken after function name.
Wayfinder Acces does it, saying eg. "Where am I = 8", Refresh list = 9".
That "hints" could be turned off in Loadstone Settings.
- Problem: Sometimes it would be practical to use several databases at once.
* Solution: Introducing a function "Append database" and add it to the "Database" menu.
The assumption is:
-- The appended database can be read-only and treated as secondary.
- Problem: Auto-Announce interval is limited by the predefined values.
* Solution: This setting should be organised exactly like the "Search radius", where the user can provide the exact value.
- Problem: Although "Use checkpoints only" is checked, Loadstone shows different points from the database.
* Solution: Showing area or searching in a particular direction should return only checkpoints
(meaning, should as if limit the database to checkpoints only).
- Problem: It's not possible to get automatical info of proximity to a locked point.
* Solution: Locked point should be announced while approaching and arriving.
Auto-announce of a locked point could be also introduced.
That parameters are set in Loadstone Settings.
- Problem: Sometimes there is a need for quick remote sharing current GPS location or a given point.
* Solution: Adding options "Copy to clipboard" and "Send" to the "Current point" menu.
-- Here, as in many programs, "Send" develops into: via SMS, via MMS, via e-mail, via Bluetooth.
-- SMS of current location could optionaly contain info about heading and distance to a nearest point in the database.
-- If possible, Loadstone could recognize such SMS and automatically navigate to this position.
- Problem: It is tricky to make a selected database and checkpoint file loaded at startup.
* Solution: Making appropriate Settings "Save as default" in "Checkpoints" and "Database" menus.
These data can be stored in a separate .ini files.
- Problem: It is not intuitive for some users that in order to apply Settings, additional SoftKey1 (OK) press is required.
* Solution 1: Saving settings should occur immediately after making change or upon going to a next tab,
as it is in Nuance Talks.
* Solution 2: Changing a button name from "OK" to "Save" or "Apply" for betterclarification.
- Problem: Upon Loadstone crash or battery discharge, all settings are gone and have to be made for scratch.
* Solution: Loadstone should try to restore the previous session after next startup, as it is in Mozilla Firefox.
Session is understood here as:
-- Recently choosen checkpoints,
-- Recently loaded database,
-- Recent state of Auto-Announce, "Use checkpoints only", "Isolate checkpoint".
- Problem: It is possible to enter capital letters under "Update point" option,
but it is not possible to search for capital letters under "Find point" option.
* Solution: Ability of entering capital letters should be blocked.
- Problem: Comment field placement.
* Solution: If possible, comments field might be stored in database files, after "Name" or "ID".
- Problem: Searching, browsing and exporting of points is quite limited.
* Solution 1: Most GPS applications, eg. Nokia Maps or Wayfinder Access, have an option of searching points by category.
This function could be also introduced in Loadstone for more effective operation.
-- If possible, additional field in the database, eg. "Type", could be created, beforefield "name".
-- While entering a point or while searching, point type could be entered manually or selected from a predefined list.
-- A long time ago, there was a separate table, "Point type", but it is much more practical to insert point type in a database record, next to point name.
-- The problem, however, is compati bility of database (files) that have no category field, with those that have this field.
* Solution 2: SOme GPS applications, eg. Nokia Maps, have an option of searching points from phone contacts and by address,
as well as of calling the phone number directly.
These functionalities could be also introduced in Loadstone for more effective operation.
-- I know that it can be done only if a better database engine is available.
More information about the Loadstone