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.