Adam is one of our main developers here at Lively, which means he makes our app look and feel good, makes our site work, and puts up with a thousand emails from everyone saying, “HOW DOES CLICKING WORK?!”
Today he got to share his work with a lot of other, very smart people at the HTML 5 Developer Conference in San Francisco, where he spoke on a panel about his work with Lively. I wanted to be able to explain all of this, but I know my limits. In lieu of my stumbling explanations, Adam has taken some time to write about his experience with the Lively app, so you can get to know the deeper side of what he does and what we do to bring Lively into the world.
Take it away, Adam!
Here at Lively, we are firm believers in the web, trying our best to provide near native experiences. Keeping things light weight and as “plugin-less” as possible has been a successful model for developing our application. We noticed other projects in the market place that pull in big libraries to do one or two actions. That just wasn’t us.
Like our founder Dean Graziano said, quoted in a recent article on New Music Seminar, “Each live show is such a unique performance and an individual experience for each fan; we just saw the need for a better way to capture the experience. We take care of everything for the concert-goer, so they can just relax and enjoy the show.” Or as I heard at a show the other night, “put the phones down, and your hands up.”
We know that this is not what the user wants to experience.
The app itself runs across iOS, Android, and Windows Phone 8.
Our app is a media consumption app, so our native needs are in DRM and media playback, while our web needs are all UI related. Choices in architecture ripple outward from this starting point. We bring in only one native library, Facebook. This lets us ask the native Facebook app for authentication.
Frameworks like Intel’s XDK and PhoneGap end up bring extra KB’s that we don’t need. The XDK and PhoneGap also don’t help with media DRM either, nor should they. So it’s not that we don’t like web wrapper helper frameworks, we just wanted to use the right tool for the job. You don’t need a machine gun to kill mosquitoes.
From the user experience side, our code tries to compliment this lightweight approach. In our web views, we’re just presenting images, video, and lists of shows. We have code to tear down and create views, where CSS handles the transitions for pages.
We want fewer libraries and frameworks in our app so that we can control the environment; we’re serving as few files as we need. Audio and video is handed off to the native media player instead of trying to be played in the Web View. The process is much simpler this way, and performs better.
Our tooling for building the app is an IDE of our personal choice, Chrome, Firefox, Safari, Androids, and iPhones. We like to test right on device, it’s the only way to get an accurate reading of the painting and performance. We also have few tools in between the browser and our IDE’s, like Jade, Stylus, and SCSS. Then the whole environment of our app, is controlled by a Vagrant instance, so my local machine can emulate the production server exactly.
Then, while all of these tools are rocking and rolling, we use the Chrome Dev Tools heavily, as well as mobile browser debuggers. We watch the charts from the dev tools, and monitor the health of our app that way. If something new is introduced, and paint or render times go way up, we don’t have to go back through our code to find it, we know it was our most recent Git pull or recent change we made ourselves. This is powerful, and in our opinion, the best way to go about building an app for mobile, with 60 fps as a goal.
We’re trying to help everyone who is interested and crazy about live performances. We do that with our successful and simple approach to hosting a light weight application.