2008
10
October

Creating a BlackBerry Version of Your Rails Application (Web-based)

With an application being used by salesmen, the most demanded feature has no doubt been a Blackberry version.

I found a good tutorial on developing for the iPhone but almost nothing on working with Blackberry’s, so I decided to post some notes to help any rails developers creating a Blackberry version of their application.

The goal in creating the mobile version was to:

  • Minimize the size of the application
  • Reduce features to only those necessary when on the road
  • Optimize the UI for the smaller screen

Subdomain

The first step was to set up a subdomain for the site, for example mobile.dmix.ca. I deployed the app using Nginx so I just created a new DNS and vhost following Slicehosts tutorials.

It used to be common practice to automatically redirect mobile phones to the mobile version of the site. But this has recently been deemed bad usability, users should always have the choice. I created an entirely seperate rails app; some people create seperate stylesheets and some variable layout elements depending on the user agent, if thats the path your taking Mobile_fu might help.

Detecting user-agent

Instead of automatically redirecting, I set up a helper to check the user-agent to see if includes the string “BlackBerry”.

#application_helper.rb
def blackberry_user_agent?
  request.env["HTTP_USER_AGENT"] && request.env["HTTP_USER_AGENT"][/(Blackberry)/]
end

#application.html.erb
<% if blackberry_user_agent? -%>
  <div class="message">
  <p>Using a Blackberry?
  <a href="http://mobile.site.ca/">Use the mobile optimized version</a>.</p>
</div>

BlackBerry user agent: “BlackBerry8700/4.1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1”

Phone Simulator

If you want to test the site locally you can download the RIM Smartphone Simulator. Its Windows only so I wasn’t able to run it on OSX (I tried Crossover and can confirm it does not work). If you are running Windows it will probably save you a lot of time not having to redeploy the site to test changes.

The Blackberry Browser

By default the Blackberry Browser is configured to ignore stylesheets, javascript and background colors. To make your life easier as a designer you can turn these on and recommend your users to do the same (configuration is in the options inside the browser). This is much easier to do if an IT department controls your users phones, but to be safe always test with it off.

The HTML/CSS support varies depending on the version of the phone, it has been pretty consistent on any phone released in the last 3 years with decent support. The newer Bold’s have a much better browser (4.7) with almost full support of CSS/HTML and zooming (still about half of the capabilities of Safari Mobile). I knew my users would be using Blackberry Curves, so I only had to test on the browser version 4.6.

RIM has  HTML/CSS reference guides that explain the support each browser versions has for the languages.

Optimizing UI

A few notes on the UI…

  • Aim for function over form, these are not iPhone’s
  • Fonts are automatically converted to the default typeface and are almost always black unless you specify, it’s probably best to leave it that way for usability.
  • Pages formats to one continuous page, so remove any sidebars and fancy layouts you had in place
  • I kept the navigation at the top of the page and horizontal, and did not repeat it in the footer.
  • Be very strict on limiting the amount of images you use
  • Use clear separators between content (such as hr and background colors) to separate different areas
  • Remember the small screen and constant scrolling makes it difficult for users to become familiar with the layout so be very consistent in design

Optimizing Javascript/CSS

First ask yourself if you really need Javascript on the mobile version. If you use a framework like Prototype, loading an extra 150kb will eat up your users data plans and if you happen to live in Canada, with the second highest data rates in the world, this is a big issue.
There was one section that I needed Prototype and without it I would have had to rewrite the whole section. So I added a check to make sure it only loads on that one action.

<% if current_controller == 'objectives' and current_action == 'new' -%>
  <%= javascript_include_tag 'prototype', 'effects', :cache => true -%>
<% end -%>

For CSS I recommend going through and deleting all the layout code and everything unused, every KB counts. You should also look into Bundle_fu to minimize the HTTP requests and put everything into one file. I also moved all my assets (JS, css, images) to S3 to improve speeds and so that attachment_fu uploads are accessible by both rails deployments (mobile and full version).

Firebug/YSlow Stats

Here is the result of the tweaks done to the mobile version compared to the full:

Mobile
Average total size: 30kb
Average HTTP Requests: 6
YSlow grade: B
Full Version
Average total size: 350kb
HTTP Requests: 19
YSlow Grade: D

I would love to post up screenshots and a demo of the finished product but it will have to wait until the full site goes public.

- By Dan McGrady

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

Additional comments powered by BackType