Description: This presentation will cover the lessons learned from a web project that targeted the Android default browser. We will discuss gesture and device limitations and approaches for screen size fragmentation.
About me: Mitch Hunt has been developing software since the 80's for both government and private industry. Since 2006 he has been involved in multiple web projects at places like NASA and AT&T.
Below is my initial pass of items of "lessons learned" from my recent android html5 project for AT&T. The project could probably be categorized as a very rapid prototype except that we were going into production (to the public) with it. Most of the items are things which gave us some trouble. I guess the theme of the talk would be "Here are some things which gave us problems, our solution, and a recommendation".
- ground rules
- a high profile proje= ct looking to go into production on a very aggressive schedule
- designed for android devices
- run in native browser using html5, css3
- no view fragmentation (no media queries)
- Urchin
- Rails, Mong= oDB, capistrano, puppet, nginx, phusion, solr (lucene)
- Agile
- dev team in Atl, StLouis, Dallas, Huston, India
- test team in = Redmond
- customers in Redmond, Plano, Atl
- development environme= nt
- Macs - trouble free
- Windows - unbelievably difficult= (rmagic created by mac fans to torture windows users... minimagic is great= )
- Ubuntu32 - ran in VMs on Win7-32 boxes (db difficulties)
- Re= dhat64 (in production)
- RubyMine, Sublime
- git -> svn<= /li>
- Rackspace -> corp network
- MongoDB - on the whole, it= performed well.=A0 replication is still a touchy area
- devices
- different screen sizes, very difficult to= keep things looking good everywhere
- slow connection speeds
- html5 lessons
- css3 lessons
- browsers customized by the manufacturer
- limited processing power (just amazing ho= w well angry birds works)
- load css then html then js
- testing
- clear c= ache frequently
- reboot frequently (minimum of daily)
- test w= ith more than one device (a small, medium and a large is best)
- chrome is best then firefox > safari > opera > ie
- adb is better than nothing but chrome is preferred (it is like you intr= oduced yet another device called 'adb' into the mix)
- screen= shot trick
- hard back vs. browser back
- keeping page size= small is extremely important
- behavior
- orientation
- gestures (swipes)
- hidi= ng the addr bar
- agile
- almost everyone on the team was new to= agile
- 2 week iteration
- 15 min stand-up
- story e= stimation
- updating the underlying utils (ruby, jQuery, etc)
- praise for new features, none for fixing problems
- face= book
- mobile is still immature
- minimal to no support
- difficulties of "like"ing something behind a firewall
- developer accounts are difficult
- lessons learned
- penny-wise and pound-foolish
- <= li>dev machines
- phone devices
- networking (wireless access f= or testing devices)
- svn -> git -> svn
- expensive = consultants
- their advice is hard to remove (paid a lot for it, so it must be go= od)
- off-shore consultants
- language and cultural ba= rriers
- timezone differences
- no ruby or rails experience
- a fair bit of js experience
- very difficult to effectively task = (maybe my limitation)
- use something like phonegap or trigger.io
- do not b= e afraid of jQuery Mobile
- media queries
- a fast moving project does not allow for much tim= e to "come up to speed"
- just like editors, agile is not a= one size fits all
- penny-wise and pound-foolish
Comments