Created
July 31, 2015 16:58
-
-
Save ronindesign/fe9f82782258f4905145 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cool Idea: | |
* MySAM Stats (stats) | |
- FitBit / Pedometor / HR Monitor Sync with MySAM. Compare / compete with friends based on steps per (game / season), avg steps / heartrate per game, highest overall steps in a single game for a season (top steps) | |
- Allows additional stats-based, competative metrics | |
- Social engagement: points for sharing / promoting your team (this in turn promotes the facility / company, and of course, DASH) | |
* DASH Events (pub-sub) | |
- Implement (even a basic) Event System | |
- Allows different parts of DASH to passively integrate (i.e. without direct call / forcing, non-blocking) | |
- Modules that are expected to react can all do so by subscribing to an event type and triggering when such an event is broadcasted, especially when considering it can be done asynchronously and with multithreading (e.g., http://reactphp.org/) | |
- Example: SIT_Team->addMember() fires a "new member" event. Any DASH modules that have been configured to care (i.e. subscribed) will trigger their "new member" logic. Such as: | |
- SIT_Customer->WelcomeToTeam(SIT_Notification($this)) // Sends notification to newly added customer | |
- SIT_Employee->MemberAdded(SIT_NOtification($this)) // Sends notification to Responsible Employee | |
- Finally, this promotes encapsulation (high cohesion, low coupling) in our classes, and in turn, our models. Will also allow for an easy jump to providing abstract / generalized interfaces for our current controller routes. Instead of all controllers having to define their own unique routes like ?Action=Customer/AddNewCustomer, you can have a set of default routes (e.g. for CRUD actions) and then add unique ones only for the actions which really are unique to a customer. However, this might take a bit more work given the way our current modules / objects interact and how their models are organized. | |
* DASH Live (monitor) | |
- Mulitple sources: Database, UI Events, social / trackbacks | |
- Multiple Views: | |
- Simple X/Y (2-dim) live graphs on any configurable DB metric (limited to useful columns) | |
- Density Map (Item / Module density based on: num purchased, pages viewed, actions taken, $$ paid) | |
- Heatmap (user / module interaction) | |
* DASH Messenger | |
- Why an integrated messenger is better: | |
- Internal and can be opened directly on POS / Kiosk / etc | |
- Easily attach reference/link (Current Page, Screenshot, Report, File, etc) | |
- Extensible to allow for additional interactions: smart phone app/sync, alerts, quick links, stat info | |
- Why it might not be worth it: | |
- People already use external messaging platforms: email, hangouts / skype, etc, so not much value | |
- Won't be as useful for people who aren't actively in DASH | |
* HueHue Upgrade | |
- Add new features to HueHue our slack bot! | |
- Could add fun features like meme generator, weather, dance, famous quote functions. | |
- Or useful util functions like search (repo, php.net, DASH DB :O), syntax / man page lookup, lmgtfy redirects | |
- Even Dash related functions like DB lookups, codebase searches (DOCBlock reference / lookup), DASH database queries / status / stats, etc |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@ronindesign I like the top 3 ideas.. for stats i'd also add the ability for players to assign non roster stats to players. Up to you what you want to R&D on.