MapRun - Proposed New Features

[Peter Effeney]

A new version of MapRun6 is being worked on.

Please post your comments here on potential/proposed/suggested enhancements to MapRun.

Also rate the importance of the first 16 points below in this Google Form.

Candidate New Features

1. Removal of the need to include codes in event named. These would become optional and would need to be included until all users upgrade (the new MapRun would use the Settings set as part of publishing an event)
2. Include the new results system for “All Results” in the App (rather than RouteGadget)
3. Potentially allow clubs to provide their logo and colours whilst using events from that Club, MapRun would have club branding (still with “powered by MapRun”). This would probably be a premium option with a paid subscription required (as another way of covering costs)
4. Option to display a message on opening an event (eg special instructions, warnings, club news etc)
5. Add a version of MapRun for Apple watches (and the required changes to the MapRun App)
6. School Mode - Potentially automatically obfuscate or anonymise student names for privacy reasons (TBC)
7. Allow published events that don’t have a Map (kmz). Satellite imagery would be shown in the App and in the new results system (but RouteGadget can’t handle this)
8. Extra info upon first install - Give more information recommending allowing MapRun to run in the background, location services, avoiding battery saver mode etc
- Score schemes:
9. ScoreB with a designated pivot control (ScoreB currently has runners visit odd numbered controls first and then even numbered controls (or vice versa), with the changeover being when they visit two of the second set in sequence. A new variant of ScoreB would do the same except the change over would be at a pre-determined control (like a “pivot” control)
10. A simplified Mass Start (ie simple countdown to a specific start date-time at which S1 punches for everyone and their time starts)
11. A scheduled finish time option (where the time remaining counts down to a specific date-time - eg for a 60 min event scheduled to start at 3pm, the time remaining would count down to 4pm even if the runner started at 3:10pm) (Early starts wouldn’t  get extra time).
12. Support the simplified Mass Start and Scheduled Finish in MapRunG on Garmin and MapRun on Apple watches
13. A “Rogaine” set of changes to better handle Rogaine scoring, including graduated penalties for late completion
14. For line courses make the display of the control Id optional ie the 6th control with a “control Id/flag id” of 35 is currently displayed as 6(35) and both numbers are displayed on punching. The change allows for just 6 to be displayed.
15. Scoring - add an extra setting to control whether points can be earned after the time has expired or not (current this is so)
16. Option to have silent punching of all controls EXCEPT Start and Finish


Bug Fixes/Minor changes

- Improve auto-upload of results - to retry more times and give a message if it fails to upload
- Remove the dual red/blue track display
- Improve the accuracy of the run distance (by applying some smoothing to the track)
- Improve recording of the timezone of the run

Interface to MapRunG (Garmin Watch)
        - Improve error checking in the interface to MapRunG (on Garmin watches)
        - Check that a valid event is selected before uploading a result
        - Check for duplicate retrieval of tracks

QuickStart
        - Fix bug in not allowing editing of existing events in some cases
        - Show the length of the course as it is created

Improve Revision of Results (HITMO)
        - Show repeat/extra controls in a different colour and warn the user if their revision hasn’t changed the classification of the run (eg Mis-punch -> OK, or changed the score)
        - Fix the issue where deselecting a control does not change it’s colour back to red
        - Improve handling of large tolerances in HITMO (ie much larger than the setting in the event)
        - Check various scenarios in Start Anywhere

Results
- Option to show extra punches in time order rather than at the end of the list of punches
- Check the default activity type for MapRun in Strava

Miscellaneous
- Fix early start with a PIN for mass start events (MX)
- Fix MX (Mass start at a fixed Date-Time), where in some circumstances it is possible to get numerous repeat punches of S1
- Allow an increased radius for Events Near Me (ie a “Show More” option)
- ScoreB - review how punching of extra controls is displayed (not to turn green)
- Enforce checking the specified minimum App version for an event
- Display folder names when listing events
- Improve the menu on the home page so that tapping labels works as well as buttons
- Timestamps on location points - better validation that all times are ascending to avoid strange results in Strava and live tracking
- Spinner when loading a CheckSites event
- Search/Filter options and settings
- More tolerant of different KMZ formats


Technical
- Upgrade to the latest version of Android and iOS tools for compatibility with new devices
- Changes to accommodate a growing volume of events and results (eg ability to load events and results from large-scale Cloud Storage (transparent to the user))
- Improve Webview zoom levels and soft keyboards (eg when logging in to Strava or Garmin)
- Review Firebase Error logging on iOS
- Set a maximum size of log-file to upload
- Give a better error message if MapRun tries to email, and it can’t find an email client on the device

[thall]

Hi Peter,

I think one of the most frustrating things can be when you run back through the start location and finish by accident. This also makes it tricky to think about setting "start anywhere" courses. I think a pop up when you finish - something like "did you really mean to finish? - yes/no" would be a good optional extra. Other than that the school mode privacy option is something a few people have asked about and makes sense to me.

[Peter Effeney]

Tom,

Thanks for the comment.

I agree - accidental finishes are a pain.

An earlier version of MapRun had precisely the feature you mentioned, and that feature is currently in MapRunG (Garmin watch). However, we found people usually tuck their phone away while running and tend to ignore unexpected beeps, and so generally wouldn't see the pop-up dialog.... and then either:
-  they ran to the next control with the question remaining unanswered ... and it all got a bit messy from there, or
- they thought they had genuinely finished, but didn't confirm that and so no finish was recorded for them.

So we removed the feature, and concluded we shouldn't ask people to interact with their phone during a run (unless of course, the punching is via QR Code or NFC tags).

So then, how to improve the situation (aside from the current approach or locating F1 in a non-accidental-punch-location.):
- I think the most promising suggestion has been to, punch finish, but keep tracking the runner for say 20-30 seconds, and if they are continuing to run (or walk or ride), then un-do the punch of finish.

- Other suggestions??

Peter

[MichaelRaz]

Fully agree that people should not need to interact with the phone while running however perhaps the finish should be the exception.  Currently the process is not consistent between MapRun6 and G.  Suggestion (maybe not thought through completely):

-Finish punch buzz is different (three beeps?)
-Expected action is user (after catching their breath) pulls out phone and confirms Finish.
-App continues to time/track until user confirms Finish.
-If another control is punched after (finish was not confirmed by user) the ‘finish’ is maintained as an extra punch and run continues until Finish is again punched and confirmed.  I’m suggesting this option for the circumstance where the finish was actually correct but not confirmed properly so it could still be used in HITMO to correct the results.

There is a risk the the user does finish but does not confirm so the app continues to run but this can occur now if the user decides to end the run but does not stop the app.

I’m sure I have not thought this through completely and coding complexities need to be factored in.  One advantage of a confirmed Finish is it would be consistent with MapRunG

Michael

[d-dixon]

"Removal of the need to include codes in event named." is by far the highest priority for me and ideally I'd like to take that further - how many of the event settings could be (optionally) grabbed from the kml (or IOF xml) file?  Firstly scoring would be great - thus allowing completely arbitrary scoring per control (the more complex scoring schemes may be trickier...).  Then, how about some event-level settings in extension fields to cover a lot of the other settings?  Line vs. score, time limits, etc?
This would be valuable as it would mean that complete event setup could be scripted or automated and I'd know that all my events could be set up similarly each time, without having to remember to check the settings (or change the kml file name).
Thanks!
David

[Peter Effeney]

David

Thanks for your comments. What you say is essentially what is proposed.

Ever since MapRunF and then MapRun6 were introduced, when an Admin creates an event, the settings are  stored in a separate json file. When the phone downloads the event, it gets three files: Map (KMZ), Course (KML) and settings (json).

You can see this is how we implement settings that are NOT in the event name (eg live tracking on/off, date ranges for events, ScoreP parameters etc).

We have maintained the original approach of using the filename for the main settings for backwards compatibility (and the fact that we have not enhanced RouteGadget to understand the settings file).

Anyway, this approach gives us great flexibility, and what we are saying is that it is time to drop the backwards compatibility (including RouteGadget).

Regards
Peter

[1andythornton]

Hi Peter,

Re new features:

1. Forgive me if the facility already exists to do this but: Could the Club or Team that users have provided in their User Details be displayed (by default) in the results list?  (There maybe a reason why it shouldn't be included?)

2. Re "accidental finishes"
Some of the suggestions already made look good.  
Eg. Having a special, unique, and non-changeable (difficult-to-ignore!) alert for the finish which then requires user action to confirm they actually intended to finish, otherwise timing and punching other controls continues.

Also, might it be possible (for the event administrator) to be able to set a "finish-only" punch tolerance?   So for example the finish punch tolerance could be set to say 5, 8, or 10m  compared to the tolerance for all other controls being set at say 15m.  Meaning that a user would be much less likely to gps punch the finish by accident as long as a little thought has gone into finish placement, since the user would have to go to the precise finish to get the punch. (Allowing users to pass "near" the finish with much less risk of an accidental finish).
Not sure if this gives rise to other problems though?!

Regards Andy

[d-dixon]

Peter Effeney wrote

David

Thanks for your comments. What you say is essentially what is proposed.

Excellent - thanks Peter!

[d-dixon]

1andythornton wrote

 ...the finish punch tolerance could be set to say 5, 8, or 10m. ...

Something to bear in mind - when I'm sprinting in because I only have 12 seconds before the time limit is up, the last thing I need is to have to hunt around even more for the final beep!  I'm already occasionally tempted to throw my phone at the finish so that it gets there a couple of seconds ahead of me...

David

[Peter Effeney]

One needs to be a bit careful about reducing the punching tolerance on controls - especially the Finish.

In a perfect world, the tolerance could be made to be essentially zero, so that the runner needed to touch the feature.

However, in practice, the tolerance is there for:
- inaccuracy in the placement of the control (ie the lat/lng that MapRun is comparing to could be a metre or two (or more) off the real feature,
- A phone GPS can easily be 5-7 m inaccurate.

So if the tolerance is too small the runner could be at the finish location and not have a punch.. very undesirable at the finish (for other controls, just run past and use HITMO at the end).

In general, the larger the tolerance, the more reliable the punching. (but obviously overly large tolerances are not desirable either).

Administrators have the ability to set an appropriate tolerance for each event, but I would think carefully be fore reducing it too much.


Peter

[JohnG]

Hi Peter
To make MapRun more attractive to younger people, could a version be developed where ‘cartoon characters’ momentarily appear at control locations with appropriate linked sound?
JohnG

[JohnG]

Hi Peter

Re school mode, Agee there is need to review access to data.  We have set up school events so they can only be accessed by PIN.  However, the childrens names can be accessed through results.

My recollection is that when editing results, eg a competitors phone hasn’t worked, they are cloned and controls added.  The controls list is updated but there is a need to manually amend the score.  Can the score update be automated?

[Peter Effeney]

John

Thanks for making this suggestion.

We are keen to see what level of interest there is from other MapRun users for this feature.

It looks like it would require a reasonably significant enhancement to implement this.
We are thinking:
- a set of cartoon character images (those that are not copyright)
- potential for an Admin to add their own images
- when setting a course, allow assignment of an image to each control
- when downloading a course, download the images for that course and display them as needed.

Other users reviewing this suggestion, please add your comments (indicating an interest to use this feature).

Peter

[Peter Effeney]

John,

Thanks for the comment.

Given that one of MapRun's prime purposes is to display a results table of participants immediately after they finish, our recommendation where there is sensitivity about disclosing identities, that runners enter an alias instead of their name. This may be applicable for school events.

The proposed enhancement is to essentially automate the generation of an alias.

Regarding editing of results ... Admin HITMO should generate a score (which is editable). (Although not for ScoreP (parameterised scoring).

Peter
 

[patmacleod-f]

I agree that removing the codes from the event name is perhaps the most beneficial enhancement. One I don't see listed, but is perhaps in the pipeline anyway, or it exists and I have missed it, is a URL link to an event in the new results system, which is a great improvement on old Routegadget.

 

[Lawrie Brown]

Hi Peter

I'll add my vote for the listed bug-fix "Improve the accuracy of the run distance (by applying some smoothing to the track)". Its something I've been very aware of, seeing consistently longer distances reported by the maprun system compared to that provided in other apps (eg I use OruxMaps on my android phone). And also seeing significantly differing distances from people walking/running the course together reported by their various phones. There is clearly a varying amount of jitter in the GPS tracks for different phones. So it would be good if the track could be smoothed enough to see consistent distances in these cases.

Thanks
Lawrie

[Peter Effeney]

Pat,

The "new" results system is now ready for wider use, and it now supports URL's direct to individual events and groups of events. The details are:

https://maprunners.weebly.com/access-to-results.html

Peter

[MichaelRaz]

Peter, is there a sunset date for the current system?
Thanks
Michael

[Peter Effeney]

Michael,

No specific sunset date has been set.

A couple of thoughts:
- I need to investigate whether it is feasible (and advisable) to redirect existing links from RouteGadget to this system.

Alternatively,
- I may investigate a more "dynamic" RouteGadget option, that creates the RG event files and results files "on-the-fly" when needed... This would allow disk storage to be reduced as RG currently has a duplicate of all event files, results and tracks

Currently, I just want a bit of time to confirm there are no problems with the new system... including its performance under load.

Peter

[MichaelRaz]

Thanks Peter.  Although I did not suspect it would be soon - just making sure as I'm scoring for an adventure race in a couple of weeks that depends on the old system!

Michael