Review of Run App

@HughB , @myownself and @everyoneinsterested, do we open a different thread to discuss this other app ? I think Gordon's app is a nice base whose main screen could be modified, there could be an extra screen accessed through swipe up/down to access to what myownself described (completion state of specific running activities).

You opened a thread previously and you and I described what we had in mind - I suggest that we discuss there. I agree that Gordon's app is a great base.

@HughB , @myownself and @everyoneinsterested, do we open a different thread

@Gordon - would you prefer the RUN app is left as is and we clone and evolve a new RUN++ App. I personally think there is milage in fixing some of the issues on the existing RUN app. For example cadence would be better replaced with PACE_NOW which could be calculated from current fix and 2-3 fixes ago. AT MILE/KM intervals pace could be a pop up for 20 seconds with a buzz that then goes back to the standard screen. This is how most of the running apps seem to work.

If we clone and evolve - maybe we should rename RUN to basic-RUN to make it clear that its a simple example app from which others can be derived.

I can't speak for Gordon, but as for me: I found out about this watch because I was looking for a sports watch, so the sorts of things I want to implement/see implemented are things that friends with sports watches have described. That includes the things discussed on the other thread, and possibly more.

Actually @Fteacher at build 2v11.44 it's possible you got one in the midst of the HRM changes, which definitely would have been a step back - so a newer build might be better.

@HughB basically (much like you'd said about the Anton clock) I'd like it to be a good learning tools and starting point for other apps. So I'd like the code to stay simple enough that people could look at it and go "I can start from this and tweak it to my liking" without duplicating a bunch of code, but that doesn't mean it can't have new features.

I don't really want it to turn into a big, sprawling, kitchen sink type app. I'm thinking:

• Distance/pace/etc calculations to be added to a library in BangleApps/modules, so the app itself is mainly UI. Maybe the library can provide a whole bunch of different stats that the app could then choose from/use.
  
• Settings menu for selecting miles/km/etc for pace - unless we can just use the current locale settings for it?
  
• We could have the pace popup as you say? It probably needs to be possible to turn it off.
  
  

I guess maybe if we could do it so the code is clean there's an argument for having a setting screen for 'BOX1: ...', 'BOX2: ...' where you choose what appears in each of the boxes?

I'm happy to make changes to move the calculations into a library. That could be a good starting point? If done right it could allow folks to contribute new stats and then have those appear in whatever run/exercise app decided to use them.

My gut feeling from this and the other thread is that actually everyone wants something different, and different sports will want different stuff displayed.

I think we can go some way towards helping by making the app a bit customisable, but at some point we'll make it very customisable, and then someone will say "well I go cycling and running and I want to be able to switch" and then we end up with a bunch of different profiles too, and soon it's just this huge, unmaintainable app that's a bit daunting even for new users. I'd like to try and avoid that as much as possible :)

Ok, I've just created a branch for an updated run app. What do you think? https://github.com/espruino/BangleApps/c­ompare/run_module?expand=1

• There's now an exstats module which any app can use to get stats on exercise.
  
• You can now choose what (if anything) should go into each one of the 6 boxes from settings
  
• The distance that pace is over is configurable
  
• GPS/HRM enable options are now gone, because you can just remove any boxes (HRM/distance/etc) that need those devices and they will no longer be powered on
  
  

cadence would be better replaced with PACE_NOW which could be calculated from current fix and 2-3 fixes ago

I've added a 'Current Pace' option for statistics that just uses the GPS reported speed. Personally I feel much more confident using that than calculating it from raw GPS coordinates as the GPS itself has a much better idea what's going on

From what I've seen I like it very much.
And we can choose the number of boxes \o/ !!
I have to try it to tell if something is working in an unexpected way.
Then, there might be stuff to check with the recorder app.

Ok, I've just created a branch for an updated run app. What do you think?

How do I install this ? Apologies, I could probably fugure it out but short on time.

Looks like you have been busy.
When don't we rename RUN to SIMPLE-RUN and just say in the README

This app is deliberately small, minimal and easy to understand.  It has workable features but is not configurable.  We'd like to keep this small to act as a tutorial piece so please only contribute simple/minor enhancement or bug fixes. 

Then the new configurable app can be called RUN and we take it forward.

BTW gpstouch has a geotools module and distance between 2 lat / lons would be agood thing to put into that. I'm not sure how you make a generic library that can be used by other apps other than making the other app a dependancy.

Same here. I just copied the code in the web ide and tried to send it to the watch. I ran a few errors:
-Module exstats not found (ah, yes...)
-Error parsing JavaScript, but uploading anyway.
SyntaxError: Unexpected character '@' (87:0)
-You have more open brackets than close brackets. Please see the hints in the Editor window.

@Gordon and @HughB the approach of having one app light and efficient and easy to learn from seems great (+it looks advanced enough for me to stop using the Garmin, I just need the recorder app to behave better).
On the other hand, how is it a bad thing to have a kind of fork of that app that would be heavier because it would accomodate more specific users ? I understand if Gordon has to do all the maintenance that's really extra annoying work, but, you don't have to Gordon, or do you ?

@Fteacher I didn't see anywhere that said forks etc. were bad, so maybe we understood things differently.

@Gordon I don't know if I feel a library is necessary, because I don't see the problem with code duplication here - people can copy/paste what the run app has that works for their app and add what doesn't (or re-implement... just making a user interface isn't the fun part for everyone).

Edit for clarity: I'm also not saying a library is a bad thing, nobody is obliged to use what is already there, I'm just saying that the run app is simple enough that someone can take what they want from it as is.

On the other hand, how is it a bad thing to have a kind of fork of that app...

I don't know if I feel a library is necessary, because I don't see the problem with code duplication here

A fork is no problem at all - but what I want to avoid is duplicated code for calculating stats. For instance when I first did the app, distance recording was wrong and @HughB fixed it. Maybe after there are forks someone discovers a similar issue - we don't want to have to copy/paste that change to every fork. Same for adding more options or types of stat - ideally we make it so if someone adds another type of stat to display, you can then get that stat in other apps pretty easily - when someone contributes everyone benefits.

Right now the app was pretty simple, but when you start adding configurable locale settings/etc things are going to start getting more complicated.

I understand if Gordon has to do all the maintenance... but, you don't have to Gordon, or do you ?

It depends - what happened with Bangle.js 1 is often apps stopped being maintained after the first 6 months - and then if there's a problem it was me that had to sort it. The 'Run' app is an attempt to replace 'BangleRun' that had exactly that issue and turned into a maintenance nightmare because it was written in TypeScript and mostly undocumented... So I guess with this one I'm a bit more worried about maintenance precisely because the last one was such a pain.

It depends - what happened with Bangle.js 1 is often apps stopped being maintained after the first 6 months - and then if there's a problem it was me that had to sort it. The 'Run' app is an attempt to replace 'BangleRun' that had exactly that issue and turned into a maintenance nightmare because it was written in TypeScript and mostly undocumented... So I guess with this one I'm a bit more worried about maintenance precisely because the last one was such a pain.

Maybe not my place to say, but I don't think you should feel obliged to take over unmaintained apps. If an app that someone else contributed has a problem, and the original authors have lost interest, that is a gap for someone else to step in and take part - either by adopting the existing app, or creating a new one. In some cases, it might inspire someone to do something even better than the original. I can understand how having all the apps under one roof (repository) with one list of issues could give you the feeling that you need to take responsibility, but you've already provided an amazing platform, you don't need to shoulder everything yourself.

Ok, I've just merged the branch in with a few tweaks and committed it, so you can try it out properly (with the development app loader)

It's a few months that I'm following regularly what's going on with bangle.js and I never realised there was a dev app loader !
Yeeeeaah ! We can configure the number of boxes and they are well dispatched when they're fewer! Gordon, that's a huge step forward for runners (a stride ?!).
I already have some comments in mind about the app, I'll keep them for me for now, and come up with a list after I tried the app a bit more.

• I won't open a topic for that, but as dedicated bthrms are much more precise, maybe the precision % cursor could be dragged higher (if it's a different indicator for wrist and for bthrm, of course, which would be strange anyway). For me the bthrm is all the way up to 100% all the time. Just an idea, maybe stupid.
  

Gave RUN v0.03 a field test, over 1.8m walk/run.
Like it !. Like the ability to slot in different boxes. Wish I could do these apps as quickly.

Some issues below noted, not sure I will get time to investigate further this week.

DIST never updates - just says 0m all the time.

PACE(Cur) wobbles a low, needs to use points more spaced out (every 5th point), or set GPS into pedestrian mode, or use a Kalman filter.

The labels for PACE (AVERAGE) , PACE(NOW) collide. I think A PACE and C PACE would work better.

In Dark Theme time does not display. You just get a white box. If you change background to Magenta through customise then it works magenta on white. Something odd going on with the layout manager.

Screesnhot below was not my test run, just to show layout issues.

1 Attachment

Looks to me something broke GPS?!
I also did test yesterday and didn't manage to get GPS anymore, despite agps download.
Wasn't a problem before.
Main things I changed: updated from 2v11 to 2v11.61 and installed Bluetooth HRM.

I reviewed the last version of this app in the wrong thread.
I forgot to mention that I like the app too. Maybe a version with a bit of extra designing wouldn't hurt. I'm thinking about something like what @myxor did with the circles app. If he's in the mood of putting a bit of visual joy in a variant of this app...

@Fteacher just responding to your points on the other thread here...

The "distance" item didn't work. It showed 0 meters all the way long (the recorder app found distance though).

Eeep, sorry about that - I'll try and figure out what happened. I was sure I took it out to test, but maybe I forgot to commit a change.

"pace now" is expressed in kms/minutes, is it possible to have a speed item (expressed in kms/h) ? the bar in the number 0 reduces readability, another font for numbers ?

Yes, a speed item would be good. In fact that could just use the current locale

In an ideal world, 2 boxes, 4 boxes or 6 boxes, by triggering a different layout would also trigger a different font size, but that opposes the simple code approach.

I'm fine with that. It's just a one-liner... if (statIDs.length<=4) fontValue="12x20:2"; or something like that

@HughB maybe just a running average for the current speed would be best? Or I guess a small median filter...

... just updated, fixed distance and added a 'speed' option.

Also, I noticed that the distance calculation had a Math.round in it, so every second it'd round distance travelled to the nearest meter. I have removed this now - the upshot is that when you're standing still, distance will now tick up slightly - but when running it should be more accurate.

I guess one option is to detect if the GPS thinks it is stationary, and if it is, don't add anything to the distance.

when you're standing still, distance will now tick up slightly

Its possible this may not be significant, when I did the accuracy test I was seeing a very low, 0m difference between 2 points when using AGPS.

I'll try and give this a test run tomorrow lunchtime and let you know.

Any thoughts on the label collisions / overcrowding. I would have done a PR at the weekend but was not sure I fully understood how the new Estats module worked without more study of the code.

Any thoughts on the label collisions / overcrowding

I did change the titles (A Pace/C Pace). But in the app the title font size is in a variable, so I guess we could run over all the titles and see if they fit in the allowed space - if not we could go for a smaller font.

Hi @Gordon - have tested v0.05, on a quick walk / run at lunchtime.

• Labels have been adjusted as you say.
  
• Distance is broken - showing 2.5m for a 1.29m circuit
  
• Speed and C PACE match. When it says 4 mph C_PACE shows around 15m/mile.
  (ignore the screesnhot as I did not press STOP immediately and it decayed)
  
• C_PACE wobbles - we know about that one, needs to be averaged over a greater distance
  or filter.
  
• Steps are good indicator that Distance is broken 2000 steps for me is ~ 1mile.
  
• Screenshot below.
  

1 Attachment

Argh - just realised I was checking the distance not between the current and last fix, but the current and last but one fix. I think if you upload (from dev loader) now it'll be sorted.

For C PACE I just added a simple average. If that's not good enough we can always do a median filter

Dev loader? Is this different to a merge on my report and a push to my loader?

@HughB Gordon refers to this app loader. Though it's v0.05 in both dev app loader and regular app loader.
Unfortunately it's a bad week where the chances for a run (and therefore a test) are extremely low for me. I do agree with HughB, the configurable layout is great. So we now have all the "live" infos. The thing I'm looking for now, is where do I find (on the watch) average pace and average HR when my run is over.
The usecase is:
1) I run and I have the live data I need (done !).
2) When I just finished my run, I can stop the recording and check (on the watch) how I performed (and the average HR and speed are important data in training).
3) Then, if feeling geeky, once at home I can export the data into various mobile or computer apps (done).
For the 2) should we try to get this data displayed through the recorder app, or from the run app ? If from the run app, it could be a final screen with all the boxes (or extra boxes ?)

I guess one question is: do we save the 'simple' data (duration, average speed/BPM) from each run somewhere automatically? We could just stick that in a text file and realistically it wouldn't full up the Bangle's storage.

The next step I guess is turning recording on/off automatically. I guess we just have a setting in the Run app for Record run and when that's true it just records the data for every run?

I think the export should really be via the Recorder app to stop us duplicating as much as possible. You could then record multiple runs from different apps and get the data in the same place, in the same format.

For graphs, I'd say put in in the recorder app too. Potentially we could make the graphing code a library so you can still display that information from inside the Run app - or maybe we just have a way of jumping straight to the recorded track inside the run app.