robluscouting / roblutodo Goto Github PK
View Code? Open in Web Editor NEWA central location for feature requests, proposed designs, and discussion regarding the future of Roblu.
A central location for feature requests, proposed designs, and discussion regarding the future of Roblu.
Manually backup/restore events to a file.
Redesign Roblu Logo for all platforms.
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 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?
Redesign roblu.net. Possibly get some more designs as well.
Assignments tab for master to tweak assignments in real time & view what they currently are.
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?
MailChimp for newsletters.
@roblu.net emails for help, support, etc.
Support Roblu on Linux, Windows, and macOS
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:
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.
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.
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.
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.
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.
Design the basic layout for the team viewer & match viewer.
The team viewer should list:
The match viewer should list:
Roblu support for mobile platforms on Google Play, the App Store, and the Amazon App Store.
Design syncing protocol that is platform agnostic.
Syncing protocol should consider:
Syncing must also consider what to sync:
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.
Logging/crashalytics for Dart code
Design of how data is structed in events.
For a flexible system, the following should be supported:
Make sure to also track who won the event. Team profiles should have links to TBA & team website.
Support USB as a sync method. USB would work between two phones/tablets, or a phone and a laptop.
Support for web browsers, desktop and mobile.
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.
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.
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.
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.
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.
Create or scan barcodes/qr codes.
Is this something people would use?
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.
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.
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:
Javascript engine for doing stuff with Roblu data in PC/browser
Support QR codes as a sync method. Possibly look into animated QR codes for larger content (file, image, doodle) transfer.
api.roblu.net, or roblu.net/api and associated docs
Allows teams to build custom stuff on our system.
Allows users to share events with the world (or specific other teams). Users could:
We should come up with FRC number verification as well to display a verified checkmark.
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.
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.
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.
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).
Support Internet as sync method.
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.
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?
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.
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.
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.