Manually backup/restore events to a file.

Allows users to share events with the world (or specific other teams). Users could:

• Follow the events of other teams.
• Help scout events for other teams (with permission)
• Fork events from other teams
• Fork forms

We should come up with FRC number verification as well to display a verified checkmark.

A team could use a laptop or Raspberry PI as a sync hub. Sync hubs would be a central computer that all scouters connect and push data to. This sync hub would dump data to Tableau, a data base, or allow opening through a Roblu app. Headless sync hubs may not be necessary if we can just build it into standard syncing on the desktop version.

Support for web browsers, desktop and mobile.

api.roblu.net, or roblu.net/api and associated docs

Allows teams to build custom stuff on our system.

• Create from TBA
• Create manually (allow custom definition of alliances, teams, number of matches, etc)
• Link pit/match/qual forms
• Include start date/end date
• Can't remove TBA event, but can go back and add one.

It is tedious to create a RIOModel for every type that needs to get serialized to the database. A RIOModel for mobile requires a column for each top level field in the model within SQLite. This is very error prone - forgetting to update these when adding a new field is likely. Secondly, some fields can be disabled during shallow loads. A much cleaner solution here is an annotation for the class (like "@RIOPersistable") that will handle mapping all fields into database columns, and another field-level annotation for ("Shallow") meaning the field won't be loaded during a shallow load (or something like that).

A second, less-important issue is that IDs are a little messy as well. Maybe each model should inherit from a superclass or something.

Design syncing protocol that is platform agnostic.

Syncing protocol should consider:

• Compression
• Prioritize transfer items - on limited connections (like QR codes), give the user control over only syncing top priority items.
• Merge conflicts - how to avoid them, or at least handle them if they occur. Merge strategies (smart, manual resolution, ranked off scouter, etc.)
• Leveraging the advantages of each sync method. For example, devices may form a Bluetooth mesh network and discover an online node and will route all traffic through the higher speed internet on this node to reach the master device faster.

Syncing must also consider what to sync:

• Assignments
• Picks
• TBA data (proxy)
• Scouting data (and content files)
• Events and the matches, teams within them

For maximum flexibility, all events should be synced all the time (remove the restriction of one active event). A team may archive an event to stop it from syncing, but it will naturally stop syncing if data is stopped being added to it. This would allow more use cases for teams who'd like to create multiple "Roblu event" objects for an event to separate out data. Maybe they contribute to another event for another team as well.

Further along, we might want to model "syncs" as "pull requests" that can have permissions (needs approval, anyone can merge, etc.). Especially if we want to support public events that anyone can make a "pull request" to.

Additionally, a better improvement to sync over legacy would be to NOT perform merging during the transfer, but to instead ONLY transfer data, close the connection & report sync as success, then merge at the receiver's leisure.

Design of how data is structed in events.

For a flexible system, the following should be supported:

• Matches: A series of teams within alliances (not necessarily 6 teams & not necessarily 2 alliances). The match viewer needs to be rethought from the legacy. The tabbed view (where each tab is a match) is clunky, and with multi-paged forms, this will need to be redesigned.
• Chunk (come up with a better name for this): A chunk is a unique scouting data point. It represents a pairing of a team within a match. Each chunk would ideally support multiple forms. At minimum, a chunk might have a qual and/or match form. However, we'd like to support multiple users filling out the same chunk as well.
• Teams: A user should be able to easily view all the matches a team has been in. Teams should also have good TBA integration. Team profiles should include easy access to robot pictures and past data. Even displaying links towards the teams performance is past events would be huge.

Make sure to also track who won the event. Team profiles should have links to TBA & team website.

Team previews - a quick summary of a team across all matches. This allows users to select the most important metrics and really quickly generate an "at a glance" report for a team.

Design the basic layout for the team viewer & match viewer.

The team viewer should list:

• A short summary of the team
• All the matches the team is in

The match viewer should list:

• Match information
• All teams and alliances within the match, and who won the match.

Assignments tab for master to tweak assignments in real time & view what they currently are.

Powerful TBA integration is essential for a powerful scouting platform. The TBA metric at a baseline is included within each match form. TBA values should integrate fully into the form builder. Users should be able to select which values to display. These values should be referenceable in expressions an analytics as well. Should the TBA feed by one metric? Should it be one metric for each TBA value?

Support Roblu on Linux, Windows, and macOS

Instead of not observed metrics, it's probably a lot better to just not have forms show up until they've been scouted. So instead of not observed, just have data physically not present.

Would it be worthwhile to display "sync events" within some sort of "sync history" page within Roblu?

Each sync item would list items affected by the sync, i.e. what is included in the sync & from whom.

Update: This is just the pull requests screen.

• Move cloud sync to background service
• Option to not transfer content
• Actually delete deleted items
• Archive support
• Better resistance to any problems from failing mid sync

Support internal team chat, direct messages, and event chat.

Chat would flow together with assignments & data analysis.

Resources in Roblu (like forms, events, matches, etc.) could be linked directly in chat.

Provide a chat service that allows teams to discuss data and pin useful information. Event level chat would let teams meet other teams, easily share or follow data, and more.

The stat form is a new type of form that enables "statistical metrics". These metrics take "series" as inputs. In other words, a stat form works at a team level. Stats forms can take data points across all matches for that team and display them as a computed value or graphs. Also allow stats to work for a single match (or multiple) to compare teams. Like a mode where a user can select a list of teams to include and analyze. Another idea would be to set filters which define what is included in a graph or stat metric.

Some stats metrics:

• Bar graph
• Histogram
• Scatter plot
• Pie chart
• Avg, stddev, etc.
• min(), max(), minNonZeros(), and avgNonZeros()

Pick lists help a team organize their top choices for teammates based off scouting data they've collected.

To aid teams in making team picks, an automated pick list system could allow a team to set important data points or metrics that picks could be derived from.

Automated pick lists could come in several flavors:

• A user sets an expression or integer score within pit/match/qual forms. Automated picks will then rank teams by these metrics. Essentially - users select which metrics they care about, and picks are generated based off the best performing teams in these metrics.
• Machine learning could be mixed in to balance important metrics, past performance, available TBA factors, and other important details in order to make pick recommendations.

Create a demo mode with a range of different configurations and some prefilled data. This would aid in training and onboarding. The Demo mode should be isolated from the regular mode to prevent accidentally damaging data.

Should this mode preserve the state between restarts?

Integrate with robot driver software to pull diagnostics and data from robots directly.

Also another good reason to allow syncing multiple events at once. It might be nice to logically separate this from other events. Or at least have a way to separate it within the same event.

Support Internet as sync method.

The database connector would allow teams to bring their own database and have Roblu Cloud automatically push data to it via webhooks (or something else).

MailChimp for newsletters.

@roblu.net emails for help, support, etc.

Support Bluetooth as sync method. Investigate Bluetooth Low Energy connection that can upgrade to a full connection during a transfer. Improve stability over legacy Bluetooth sync.

These webhooks and triggers work at the team level. Webhooks and triggers allow teams to setup all sort of rules and conditions that can fire webhooks that can integrate with other services. For example, when a scouter submits data, this could fire a webhook that allows teams to validate data or rank it using a custom program.

Portal to sign up for Roblu
Should create RAccount in the background, handle subscription, and user account setup. Possibly an easy account setup tool - email spreadsheets to send out links or emails or something.

Conditional metrics allow users to attach an expression to any metric. This expression must be true for the metric to be visible within the form.

Also support "virtual metrics", this is just a metric with the expression set to "false", but can still be referenced in other computations.

Searching and sorting is a powerful feature to allow teams to drill down into their scouting data. This feature enables users to ask questions like "which teams have the highest value for metric X where metric Y is also checked?" or "what percentage of teams have metric X set to Y"

Essentially, sorting, filtering, and searching for teams. The best way to visualize this would be an Excel table with each row representing a metric for a team in a match.

Pick lists contain a ranked list of teams — teams can be added, removed, or reordered. Teams on pick lists have comment sections.

Users can create multiple pick lists, and pick lists are synced.

Create or scan barcodes/qr codes.

Is this something people would use?

• BLE: Better packet design / streaming protocol / compression?
• Smarter sync of content
• Maximum content size
• Concurrent/batching of requests where possible
• Checksums?
• Background syncing?
• Redis on the server end?
• Prioritized syncs?
• Smarter tag resolving - can we avoid pulling child tags (run the hash on the client side instead?)
• Are built in doodle backgrounds getting transferred?
  -BLE congestion control
• Put WiFi sync in a service

• Can move robot around field
• Various "mini-events" that the user can trigger - either counts or events, timestamped
• Region locks/region notifications

Redesign roblu.net. Possibly get some more designs as well.

Support USB as a sync method. USB would work between two phones/tablets, or a phone and a laptop.

A container exists within 1 form page. Containers can be expanded and collapsed, and can have expressions tied to them for whether they are visible or not.

Is this something that is needed? Or are pages powerful enough already to handle this.

Right now, users have to page through the data for each team separately. A match preview would should values side by side on the same page for each team in the match.

Onboarding encompasses easily getting users onto Roblu.

An ideal onboarding setup would allow a scouting lead to start a team account, handle subscription fees, and then help them easily rollout Roblu to all scouters, getting scouters signed in quickly, and rolling out a Roblu version for whatever platform they're using.

Javascript engine for doing stuff with Roblu data in PC/browser

An event is a collection of matches, with multiple teams and alliances in each match that need to be scouted, possibly with multiple forms (qual or match). Assignments aims to be an intuitive way for teams to manage who should scout what by distributing work using various strategies. Some strategies include:

• By device: "Device A" receives Team 1, Blue alliance, etc for each match
• By user: "John" gets assigned a list of matches to scout. Admins could configure rules for this based off scouter ability. Some users could be on Pit form duty, others on match duty.
• By availability: Users could claim matches as they come. Once a match is claimed it is marked as taken and others couldn't use it.
• Overlapping: admins could have multiple users scout the same match twice to have multiple points of reference, especially for training in new scouts, or that sort of thing.

This feature encompasses coming up for a clean and flexible design for assignments, while designing for sync connections that may not always be instantaneous.

Additionally, assignments could have permissions levels. Users could be locked to only be allowed to scout assigned matches and need permission to override this.

Additionally, tie this in with scheduling. Could be useful to have assignments pick the "6 most available scouters who aren't busy" for scouting the next up match. Push notifications to tell users they've got a match coming up. Possibly accept/decline as well.

Redesign Roblu Logo for all platforms.

Team accounts, lead accounts, scouter accounts. Avoid passwords at all costs. The gold standard would be getting 30 scouter accounts created and signed in in under 10 minutes.

Support roles & permissions. This will "scope" the app. App conforms to the role of the user using it: lead, scouter, viewing only, etc.

Roblu support for mobile platforms on Google Play, the App Store, and the Amazon App Store.

Some thought needs to be put into how chunks are displayed to scouters. How should scouting data appear an how should assignments tie into this?

• Continuous integration for App store, Amazon app store, Google play store, and Azure servers
• Automated testing and code quality

Export to Tableau and Excel.

Either come up with a fixed format, or allow teams to implement their own.

Especially allow continuous exporting. If we can do it, it'd be nice to not even have to close & reopen Tableau, it would just refresh as new data comes in.

Logging/crashalytics for Dart code

Support QR codes as a sync method. Possibly look into animated QR codes for larger content (file, image, doodle) transfer.