gtg "stealth"
Reorganization with new business objectives in mind.
Skookum Digital Works
JavaScript Team
June 2013
existing implementation obstacles
- Tight coupling between UI and realtime data stream
- No unified API client-side interface
- View and Model locked into framework
- "Ball of mud" or "archeological dig" organization
1. tight coupling to realtime data
- Limits UI responsiveness (data must be processed NOW)
- Experimenting with UI => complex and expensive
- Difficult to build automated tests without UI
2. no unified client-side api interface
- New features must be built once for every client
- Increased chance of data structure mismatch
- No drop-in libraries for 3rd parties
3. model-view framework cohabitation
- Sacrifices flexibility for initial development speed
- Harder to 'change with the times'
- Can't replace view without also changing model
4. ball of mud / archeological dig
- Changes to one feature may break unrelated features
- Difficult to test isolated functionality
- Longer ramp-up time for new developers
old vs new business objectives
- Rapid, simultaneous development
- Realtime as core focus
- Feature addition, growth
vs.
- Testability, maintainability, reliability
- Freedom to experiment
- Core value proposition, refinement
- Predictability of resources
- Integration, white labels, partnerships
the vision
- Unified, open-source Status4 API client library
- "Headless" view-independent user agent
- Reusable view component library, multiple thin views
- Native wrapper, possible native versions (eg iPad)
1. unified api client library
2. view-independent user agent
3. reusable view components
4. native wrapper
new capabilities
- Dead-simple API integration for us and 3rd parties
- Thin clients for iPad and other devices
-
Automated tests at every level of the application
- Ability to automate server performance tests
- Test sandboxes for all UI components
- Match new look-and-feel
- Vastly increased performance, reliability
-
Global feeds for the whole Status4 universe
-
Event-based feeds for each event
- Use GPS to find nearby courses
-
In-event messaging between players
-
Individualized scorecards
- Choose your own follow list for scoring and scorecards
- Faster, cheaper, component-based evolution
tradeoffs
- Greater reliability and maintainability in the long term; more upfront planning and platform development in the short term.
- Non-linear development speed: slow at first, faster once components exist (opposite of the current situation).
- To increase UI responsiveness, we will limit update speeds to sub-realtime 10-30 second intervals.
- Slower moving between sections of the app (home, score, create event, find event). Faster moving within sections.
- Unit tests take time upfront but save time when changing or adding features.
mobile mini-apps and their views
- Home (friends feed)
- Event list (upcoming & past)
- Account / Profile (register & login & view & edit)
- Create / edit event (find course & select tee)
- Invite players (email & friends & current list)
- Find / join event (code & GPS nearby)
- Score (score & hole select & stats & latest event feed)
- Leaderboard
- Event feed (feed list & chat box)
- Individual player scorecard
effort
- ~24 independent UI components
- ~12 view controllers
- ~12 non-UI components
- Automated test suites for all 48 mini projects
- Test sandboxes for all UI components
Some of these may come nearly for free - for example, omnego integration, routing, some of the similar UI components - but we're estimating as if everything must be built independently in order to remain conservative.
development estimate
Platform, 6 weeks
(client, agent, components, tests, sandboxes)
Home app, 2 weeks
Score app, 2 weeks
Create app, 1 week
Join app, 1 week
(plus or minus 25%)
Total of 8 - 16 weeks for a single developer. Includes all new features; feature matching is approximately 80-90% of effort.
feedback
After presenting this to various stakeholders,
we've received some great feedback and questions.
We've documented major points of that discussion below.
evolving technology
How will we manage the risk of using evolving technology like angular.js?
The performance and flexibility of the UI layer remains the largest risk of this project. One of our motivations behind separating the mobile app into separate concerns is to isolate that risk into a smaller area that's easier to manage and, potentially, replace. In a worst-case scenario, angular.js fails to provide expected performance and we replace the thin UI layer with one of its competitors, leaving the API Client and Agent business logic in place.
We began our design concept by building angular.js-based views and testing them on real devices, vetting the technology as early as possible. So far it has demonstrated both high performance and rapid development iterations.
backbone vs "pojso" models
Why roll our own API client instead of using a framework like Backbone.js?
We tried building the models around backbone and discovered that the problems backbone solves are not the real challenges of this project. In fact, the models and business logic can be represented much more simply outside of backbone.
Similarly, one of our primary motivations is easy integration. Requiring partners to include both underscore and backbone in order to integrate doesn't align with that goal.
A case study on writing a non-trivial application in both angular and backbone:
html5 vs native
Why build a single HTML5 app instead of multiple native apps?
First, an HTML5-based app isn't mutually exclusive with targeted, native apps. We considered the following before concluding that we should start with a hybrid:
- The API client and agent functionalities are required to support web apps. The native wrapper already exists. That represents 3 / 4 of the ingredients for a hybrid app.
- Our testing has shown that golfers use a broad array of Blackberries, Androids, and iPhones. Keeping three separate teams in lock-step is both expensive and complex.
- Iteration can be done faster in HTML5, especially with the custom controls and views that best represent golfing data.
avenues for roi
How can we leverage our work 'componentizing' the software stack in future endeavors?
By investing in our own building blocks, we're able to be more agile and flexible - testing and polishing interfaces by mixing existing components together and actually using them.
Beyond their use in the Status4 Golfing app, many of these components can provide immediate value and accelerated development for broader Status4 ventures (tennis, disc golf, baseball... or an iPad event management app, or more targeted mini-platforms).
One of our goals is to make Status4 a platform, and building a library of common Status4 components (s4.touch) aligns well with that goal.
gtg stealth
By hunterloftis
