Over the last couple of years, software companies and online brands have had to make decisions about how to provide rich experiences for users on tablets and smartphones. Much has been said about the tradeoffs between platform-specific apps versus browser-based web apps (including recent reflections by Mark Zuckerberg on Facebook’s position against HTML5-based mobile apps).
But even limiting the discussion to browser-based implementations, there is still a fork in the road. You can build two web experiences—one for desktop and one for mobile—or you can build a single site/app that senses screen size, orientation, and color depth, and renders itself accordingly. The latter approach, generally referred to as responsive design, is the approach we’ve taken.
As we build new web applications for consumers and business users, we assume a significant portion of those users will be on smartphones and tablets. We have a pragmatic objective to simplify the codebase we maintain, and we want to avoid separate point-solutions for different presentation environments, as each of those point solutions will incur separate upfront development and ongoing maintenance costs.
We’re trying to get the most out of the frameworks and libraries we use, so we can benefit from some economy of scale across our tech stack, and allow our team more fluency to work across products. Code consistency across applications is always a challenge, and when very separate solutions are developed to address different computing environments (mobile and desktop), consistency sometimes runs counter to “using the right tools for the job.” Consistency in such an environment requires constant vigilance, as separate point solutions tend to evolve independently, like finches on separate islands.
Rather than establish separate teams for desktop and mobile, each with its own set of technologies and frameworks, we have decided that every web application we build is essentially a mobile application. The technology stack we chose is informed by this reality, as is the overall architecture of our system.
We have established a platform layer that embodies the principal entities in the Get Satisfaction system, where their attributes, relationships, and access control are implemented. These entities, at this level of abstraction, are entirely independent of the presentation layer and device-specific constraints.
**This post is the second in our Mobile Manifesto series. Interested to learn more about our mobile strategy? Read last week’s post, then check back in next Thursday to read the next blog in the series!