How to design/organize/architect the development of mobile web within a Rails application?

Question

I'm going to do my best to phrase this as an answerable question and less as the start of a discussion.

The essence of my question is, in your experience, is it better to develop a mobile web version of your website as a separate app that uses your website as an API or to develop from within the same Rails app that serves up your website?

I'm currently planning how we're going to implement it and here are the upsides/downsides for each as I seem them.

Separate application for mobile web

• Upsides
  • Performance: less overhead from existing website = better performance
  • Smaller footprint: easier to organize and cleaner app to work/develop on
  • De-coupled: would force us to architect services for desktop/mobile
• Downsides
  • Subdomain: would have to use m.thredup.com so mobile traffic could be routed to the separate app
  • Session management: would have to deal with authentication on multiple apps/domains
  • Local development is harder: another service to maintain for developing locally
  • Branch management: new code requires separate branches for web app + mobile app

Same application for mobile web

• Upsides
  • URL Scheming: able to use same URLs for desktop + mobile (easier for sharing)
  • Session management: able to use existing user sessions
  • Quicker implementation: shorter project timeline as all back-end logic is already in place
• Downside
  • Code bloat: more code for our already large Rails web app

If we were to develop mobile web within our existing app, here's the approach we would take for rendering mobile views - http://scottwb.com/blog/2012/02/23/a-better-way-to-add-mobile-pages-to-a-rails-site/

Any insights would be greatly appreciated.

Answer 1

You will 9 times out of 10 be better off if you design the site so that you can use the same codebase for any device, so that it adapts intelligently to your device, and so that it renders the most important/useful content/functionality for each device based on stylesheets or runtime choices of rendering/non-rendering. Remember that, unlike 6 years ago, your primary concern with mobile devices today isn't lack of processing power, but rather a different screen size and different input.

Generally, mobile users do not want to be seeing a crippled or stripped version of your site. They want to see a usable version of your site. What Usable means varies, but it often means that the most frequent functions are very easy to access, while the more obscure options are buried a little bit lower or perhaps not quite as optimized. Usable might mean that you give them exactly the same functionality as on a desktop, but styled to present better on the mobile. Or that you cut out things that make no sense on a mobile. But you'll be making it much harder for yourself if you set it up so that you have to maintain two code streams, or one code stream that branches very early on, or a fundamentally different application. It's a lot more testing, a lot more coding, and a lot more likelihood of breakage.

We follow this approach, and it works well for our very small development team -- we've successfully used it so that we can use the same codebase to run two different implementations for different customers -- one a very complex desktop-first UI as well as a very streamlined mobile-first app:

• assume that all devices will access the same URL
• assume that 90% of device optimizations will be done using CSS media queries, 7% will be done using jQuery hacks, and 3% will be done using browser detection very early on
• build your application so that the individual UI components or modules can be easily enabled/disabled through code (logic in ApplicationController? Rack Midleware?). We do this by putting our individual "widgets" in partials that are wrapped with checks for enablement of the widget (either in Rails.config or as an instance variable in side ApplicationController) so that we can turn off whether we return the corresponding HTML back to the browser
• use CSS media queries not only to style fonts and widths but also to rearrange menus/functions and other UI items so that they work on the different form factors you require

Generally, the API-for-mobile approach will be of most use to you if you're going to be building a compiled app for a mobile device and are going to be doing the heavy lifting on the UI using the device's UI libraries rather than HTML generated on the server. Then again, if you choose to use an approach such as Backbone.js or Angular.js to handle your front-end display, then going with an API-only approach MIGHT be also a good architecture for you to follow. But then you're stepping outside of Rails a lot more.

Answer 2

It seems to me that the one piece of essential information is "why?" and you need to consider your budget and timescales and deadlines for the job.

Providing you use a liquid layout similar to the awesome layouts by Matthew James Taylor that will resize according to the available screen size The only reason I can see for needing mobile specific templates is in order to provide specific css styling to make you views look more like a mobile app.

I don't see performance as being an issue. If you have performance overhead from an existing website and you are designing these performance issues out for mobile then why not also design these issues out for the non mobile. i.e. design a mobile site with a liquid layout and make it work for desktop/tablet viewing as well. It could be an good opportunity to redesign the whole site to be more performant.

I see that you really have two options depending on budget and time scales

1) Design a totally new set of templates at the same time designing out performance issues using a liquid layout with a view to switching over existing layouts to the new layouts over time

2) Redesign existing templates and functionality to make a mobile friendly website.

Either way your desktop and tablet users will get the benefit but how far you go with this is down to your deadlines and budget with option 1 being the cheaper and faster way in the short term and option 2 being the cheaper and faster way in the long term. The way I see it is that by not providing the same templates for both mobile users AND desktop/tablet users you are disadvantaging someone so provide the best possible experiene for all users.

This is really a decision for your project managers.

UPDATE - Based on comments

In which case I would go for developing a separate mobile only app. I would even consider looking at using alternative technologies for live streaming the updated data. There is a good comparison between Rails Live Streaming and Node.js.

Whether you choose to introduce new technologies or not, by providing a separate app for mobile users you will provide the ultimate mobile experience and be able to totally focus on that.

I don't see different domain names being too big an issue with regards to SEO. You should be able to take advantage of existing visibility from the main site and with a separate domain for mobile you may well increase your SEO rankings without having to do much additional promotion.

I guess you have kinda already come to your own conclusions as to the best way forward and the best advice I can give you is to tell you to just give yourself a little more thinking time and to allow your chosen solution to firm up and I'm sure if it's the right one it will just "feel" right to you.

No one knows your business better than you and it's really impossible, without being involved with the project and the business, to say what is ultimately the best option.