This is a series describing various architectures I have worked with in the last two decades and some of their benefits and issues. The table of contents of the series is here.

Vive had a single product: a wellness coaching system designed for both individuals and groups. I was interested and partially ‘won’ the interview process because I could help game-ify the product.

Major System Aspects

When I joined Vive, the system was implemented in Flash and Microsoft .Net on proprietary servers. This had a couple big issues:

• It was meant to be mobile, and especially iPhone
• The server code was not really functional

So the first architectural change was to move to an iPhone compatible front-end and a Linux based backend. If the backend code had been better, the second part wouldn’t have been done, but given it was a restart, staying in the Linux stack was a significant benefit, especially on cloud computing.

After doing a Rails project with FooMojo and a couple other ones on my own, I was pretty comfortable with Rails and liked the productivity improvements it provided from being so opinionated. At this point the Grails technology was mature enough to be stable, so I leveraged that to make Vive. After evaluating a number of front-end technologies, the team and I picked YUI as being sophisticated enough for the kind of user interfaces we needed (or thought we needed).

Although the product was meant to support iPhones, it was also meant to be ‘SMS compatible’ and most of the messaging was expected to be through SMS vs. through email and web capabilities.

A couple more system aspects that ‘came later’ or were proposed included:

• A Unity or similar interactive game environment
• Connecting to devices like FitBits

AA-1 : Unifying SMS and a Web UI

AA-2 : The curse of the UI, especially for mobile

The UI on small-screen form factors is very constrained and with a platform like iOS, quite opinionated. Unless your design team is experienced and skilled at this, it can cause a lot of issues and thrash.

Vive was at the very beginning of WebApps for mobile devices. Technically, everything was correct:

• The payload was manifest-based, so updates happened correctly and behind the scenes
• There was some amount of client detection to make sure features would work (including on a BlackBerry)
• The layout was simple and widgets were large enough to interact with.
• And a number of other mobile-oriented aspects

Unfortunately there was a core problem of ‘fancy’, ‘complex’, ‘changing’, and ‘confused’ for the requirements with the mobile UI and its relation to the desktop UI. Week upon week a slightly different approach was used that might be ‘better’ and needed to be tested out. The functionality was always the same: it wasn’t much more than the SMS interface provided, except you could see what was happening better. This continuous thrash was a significant overhead to development, slowing work in other functional areas.

AA-3 : Gamification

The game-enabling of Vive was important to me: I wanted a race-like environment, or a treasure hunt, or something similar.
The technologies behind FooMojo (Unity and similar) made this possible, but the prototypes were never moved forward with. The one gamification that did make it in was that distance competitions (say first team to 100 miles combined) were plotted out on a map that was a windy course and potentially had realistic terrain (there was a collection of maps, some of which were terrain-based and others simply geometric)

AA-4 : Connected devices

Vive never decided to productize it, but architectural work was done on using connected devices for input. The market was still early but Garmin and others had some devices that you could pull data from.

AA-5 : Grails

Although not fully capable at the time, Grails was a great productivity booster and made it easy to transition the code to someone else by simply saying “It uses Grails, augmented by this”.