Let's talk about Goals!

[johnkeel-thork]

How does the app work

At the moment there is a DB in my server and a simple API
The app uses a simple API to fetch or send data (using JSON format).

First Question: I been using this for this type of small projects: https://getcockpit.com/ but should we keep it? What are the cool kids using these days?

What is the end goal of the app?:

Download Tracks

• Download, preview the track, filter section, open with the user preferred navigation app
• Downloaded tracks are available offline unless the user clicks the "Delete" button
• When you download a track you will also get notifications about track updates

First issue, how can we make this more clear? How can we make it that the user knows that when he downloads a track from that point on he will get notifications about track updates unless he hits the "delete" button for that track.

Report Track Problems

• Pretty much what's already done on the Android side, 3 step report, takes track name, location, problem description and optional photo.

Would be cool if we could allow the user to draw on the screen to suggest an alternative or record a small GPX file with a possible alternative

News Feed

• Simple news feed that the TET Admins maintain on the server side. As always the app just fetches the feed from the API

This is not implemented yet

Provide Statistical Data

• We want the users to be able to "Sign-In" (need a better term) to a track so that the app can provide the TET Linesman and Admins with track usage statistics so they can plan detours and alternatives to heavily used sections.
  BUT please keep in mind that, at least for now, we want to collect ZERO user data, no IP, no emails, names, nothing.

My idea here is simple, when the user "signs-in" to a track, the app will check (measure distance to track) and when the user is ACTUALLY on the track the app would ask for a token from the server, the server would reply with XXXXX token and the app would store that token. From that moment on every time the user enters a section / track the app would send to the server XXXXX is at TRACK X in SECTION X and that's the only thing we store. When the user signs out or gets away from the track the app would tell the server to expire/delete that token and the app would also delete it. This way what is then moved to a statistics DB is only "hit" counters for each track/section. Alternatively we can think about storing other data that might be off interest like time frame, "1 rider at track x section x for x amount of time".

Give Back to the Signed-In User
If a user signs-in to a track it would be cool if he could get something back from it, and not just let them contribute with stats in the background. So I was thinking of a new screen for "Current Signed Track":

• Show Real-time data about how many users are riding the same track and how many are riding the same section.
• Show track progress and section progress: Total track and section progress with distances and progress bar showing how much is missing to reach track end and how much to section end.
• We could do the same for Waypoints: "Distance to next waypoint", and maybe a box with information about the next waypoint (Title, Description, Type of waypoint)
• We could add a "Messages Broadcast" feed that would allow Linesman to send messages to anyone at X Track or X Section: Weather Warning / Warnings about Track Problems / Updates, example: "we've had reports of X problem at Y location. Please can riders on SECTION z check It out?"

Any more ideas about this? We would also need to design this new screen.

Community Generated Feed
This would be like a social network feed, where users, could share their moments on the track, a simple photo with location, that you could ONLY post if the app ACTUALLY detected that you are on the track.
Users of the app could filter this feed by country.

The only weird thing about this is that since we are not taking user data, there's no accounts, so once you submit your post there's no way for you to edit or delete it, the picture/text/location is submitted and is now property of the TET and only TET Admins can approve / disapprove / delete it.

Additional Needs

• We also need to create the TET Linesman page where they can log-in and access the statistics, send the broadcast messages, and check reported track problems (with option to approve them and make them public or not).
• And it would be cool to create a public page where users can also get real-time access to statistics, news feed, track problems, broadcast messages.

And that's it!

[ndias666]

Hi,
about the notifications for track updates, we could send a popup message to the user once he hits "download Track" saying "The app will store the file in your memory device and we will send notifications with possible track updates. Are you sure you want to download?" "Yes" or "No, I don't want to store the track in my device" answers (something like this). From that point on, the user knows that the file is stored in the device. And he knows he'll need to have notifications on to see the track updates.

[johnkeel-thork]

Sounds good, although I feel like we should make some changes to the track country list. I will make some drawings and testing.

[yunusde]

I think downloading the track and sending the notification confirmations should be different, for example I would want to download the track but don't want to get notification about the updates?

[johnkeel-thork]

Also, after you guys read the goals, let's start from the beginning, which should be the Buttons that show in the first app screen. How are we organising the app?
Currently it's like this:

So how do we organize this?

Example:
Tracks / Signed In Track
News Feed / Community Links

What's your opinion?

[ndias666]

Is navigation planned too? Or just view/download the track and then the user needs a navigation tool to navigate the file?

[johnkeel-thork]

We been having many requests like navigation, but here's the issue. Navigation is a BEAST to maintain or afford. On one hand the current app uses google maps and adding navigation to the current track preview is basically adding one line of code that would allow it to follow you current location. But then we are talking about a 50K+ user base, and google maps requests are VERY expensive and also only work online.
I develop Drive Mode Dashboard and I could in theory use our offline navigation engine, but, that's my living, my work, it makes no sense I would just add it for free, that would just be a bad call for our small business. And we want to keep the TET App free. We could also use any open source offline navigation engine, but then again, not only it's A LOT of work but also we would need a dedicated server to feed the Offline Maps to 50K users.
So, I´m willing to offer my server and a small amount of google maps requests, and a considerable amount of my personal time, BUT, we must keep the app in a way that it is:

• Free to the community
• Doesn't need a maintenance level which would basically be a full time job
• And also not make it dependent on either proprietary software or anything that will cost money.

[ndias666]

It's not worth it, there is many navigation apps, you are right. You can say people could buy yours if they want :) ahah

[johnkeel-thork]

I updated the initial post with a last feature to which im temporary calling "Community Feed". It's basically a feed of moments on track captured by riders. Read about the idea on the initial post.

[jj-lucas]

Heya!
Developer from Denmark here (and TET rider!), looking forward to see if I can somehow contribute with the mountain of work ahead! :D

At the moment there is a DB in my server and a simple API
The app uses a simple API to fetch or send data (using JSON format).

First Question: I been using this for this type of small projects: https://getcockpit.com/ but should we keep it? What are the cool kids using these days?

What is the scope of the changes you are planning to implement?
Is this a full on rewrite for future-proofing the whole thing, or are you "just" planning to add features to an existing architecture?
Before to get religious into arguing pro/against any technology/tool, it would be nice to get a bit more context about the project, to see if we should picture the "biggest bang for the buck" scenario, the "extensible and future proof" scenario, the "least effort" scenario, and everything in between :)

tries to resist urge to answer the question above while lacking the context :D

[ndias666]

I think it looks nice. @johnkeel-thork I think you can start with these icons and then when there's more functionalities we can change it. Any plan when a first beta will be available?