Active Product Development
8 Posts tagged with the development tag
We launched our iPhone app last week and it was greeted with less than stellar reviews. One reviewer complained of bugs, another about the lack of saving tab order, another about sluggishness. I wanted to explain the non-traditional approach we took when developing this app and what we're doing to improve the experience for those less-than-satisfied customers.
We built this app using a new tool called Titanium. It was created by Appcelerator as a way to write iPhone apps without using XCode, Objective-C or Cocoa. You write your apps using Javascript and several libraries they make available to add the same functionality as if you had written a native app--UI controls, the camera, a local database, and lots more. A very ambitious project that looks like it's off to a good start. Unfortunately, being an early adopter means you're going to run into more bugs and unexpected behavior than with a well-established toolkit. We wanted to get the app out to people quickly and our internal testing didn't show any of these bugs that are popping up in the wild so we felt we were ready to go.
We wrote the first version of ActiveReader against a beta release of Titanium--0.8.3. Development of Titanium itself was happening very rapidly and new SDKs were being released every few weeks. Documentation was okay, but they had a thriving community which the developers participated in regularly. If you had a problem you could usually get it answered within a couple of hours. However lots of functionality was still missing from the API, and bugs were being found on a daily basis.
Titanium is now in 1.0.0 (as of two weeks ago) and the API has changed quite a bit. They are now doing as much as possible in "native" iPhone views rather than everything being a "webView." While webViews are easier to code using their Javascript/HTML/CSS paradigm, they are really, really slow (one of the major complaints about the current version of ActiveReader). They (Appcelerator) neglected to mention this prior to their decision to overhaul the API. The apps that the new version of Titanium creates *are* much faster. Appcelerator has also announced their business model for Titanium--charge for premium support and access to analytics about your app. What this means the thriving community is now almost purely supported by the users themselves. The devs don't appear as often and I can only assume this is to encourage us to upgrade to premium. Also, the documentation is even spottier than it was for the beta release. So for now help is being provided only by other users who are also confused and picking their way through the code just like you.
So, what have we done to get the app more stable? We were able to migrate the app from the 0.8.3 framework to the 1.0.0 framework over the past week and it is currently being reviewed by Apple to be added to the app store. We expect that to happen early next week at the latest. The loading times for the app are orders of magnitude faster. Previously you would be staring at the splash page for 10 seconds or more while waiting for articles to come down from the cloud. Now the loading screen is up for 1-2 seconds and you see a list of articles immediately. Viewing an article is faster as well.
We also removed offline access to articles for the time being. This is another of the major performance problems with the current version and we want to revisit the database storage issue in-depth. We felt that lack of offline access wasn't a deal-killer to getting this new version out the door in the hopes that it addresses most people's concerns.
It may turn out in the end that Titanium just won't fit our needs as a rapid iPhone application development environment. The Light Engineering Group's mission is to find new technologies that help us get to the market faster than ever and we hoped Titanium would be another way to do this. While it's true that we are able to develop apps quickly, it may not be worth the tradeoff of stability and lack of support. We may end up going back to the drawing board and instead build the app out from scratch using the good old fashioned tools that Apple intended for us to use in the first place. Time will tell!
We appreciate everyone that's downloaded the app so far and given great feedback on Facebook and Twitter. We won't leave you guys hanging -- we'll get you a great reader one way or another!
New advertiser, and a "fun" new way to feature them on the site. We built a Gaiam "skin" for our Mind and Body channel.
I think it's a nice way to strongly brand the page without being obtrusive and getting in the way of the content that the user has come to the site to find. It's also not the most difficult implementation ever - which is nice. The trickiest part was getting the logo on the background image to be clickable. It took an anchor tag being blocked and relatively positioned to make that happen. Of course the hardest part of that was - and isn't everything - dealing with cross-browser DOM/box model inconsistencies.
results.active.com is our hub for communicating race results to people. We train event timers on how to use the backend portion of the system, and after a given race is completed the timers upload results, making them available to the world at large.
We typically see a lot of traffic on results.active.com after large events, such as the Marine Corps Marathon or the Chicago Marathon. And to be fair, results.active.com hasn't had an exemplary performance record when it comes to handling the volume spikes we get on the Monday after major events.
We've just released a major update to results.active.com adding 3X the scalability we had before. We've also made tweaks to the architecture so that we can add additional servers to the load-balancer should we get any unanticipated increases in volume.
So if you see any issues with site responsiveness please let me know (here on this blog) and I'll look to it personally and immediately.
Predominantly people use our site to find events to participate in. Events like the or the Turkey Trot in Cartersville, GA. We have over 300,000 relevant events in our system. And by relevant I mean things that have recently happened or will be happening in the near future. Past events are archived and are a lot harder to find in our system, but we're working to fix this.
For example, the San Diego Rock 'n' Roll Marathon happens every year. Yet if you search through our system you'll only find next year's event (and possibly last year's). But what did people say about the event in 2004? Was it well run by the event organizer? What was the weather like?
Linking data from past events is one of the projects we're working on in our Directory Initiative. You'll be able to understand what people have said about previous occurrences of an event and can make a better decision about whether or not you'll participate this year.
Oh yeah and we're also working to make our event details pages load faster. Right now we receive a YSlow score of 'F', which we're not proud of. But I can say things are in the works in our prototype environment that will give us a better score. Changes will be rolled out incrementally, as we're touching several areas to "lighten the payload".
On the Product Development side here at Active we haven't done a great job of communicating with our audience. We're hoping to change that now.
I'm a Development Manager with the Participants side of the Active Media Properties (AMP), the team responsible for www.active.com, results.active.com and community.active.com (we also have a few services/widgets we develop and support behind the scenes). We are distributed, with some people working from China, others in Michigan and even others in LA. But the bulk of us work out of the San Diego office.
I worked for a long while as a Management Consultant implementing waterfall-based projects with various Fortune 1000 companies. Consulting companies love waterfall. Changes in scope = more dollars in the pocket. But I've always been troubled by the inefficiencies that are inherent to waterfall and to the disconnectedness it brings to the parties involved in delivering a project. So I was keen to implement Agile software development with my team here. Agile is hard with remote resources I quickly discovered. But I digress.
But then came our "Directory Initiative". In simple terms, we use the word "Directory" to describe search.active.com and the mechanism through which we submit information to it. Active is a network (my company is actually called "The Active Network"), and we are a conglomerate having acquired multiple companies throughout the years. Each of these companies have interesting artifacts (or "nouns"), such as classes, campgrounds, marathons, training plans etc., and search.active.com aggregates these making them discoverable to our consumers.
Directory is the core of what we do here within AMP. And we've recently launched a major program, the "Directory Initiative", to enhance and harden those features on our properties that are related to it. To do this we've split the team into smaller teams and have aligned each with a Product Manager. Although we've only just begun, organizing our resources in this way has already paid off (at least with internal demos). So, while we may not be fully Agile, the hybrid model we've adopted is promising.
More to come.
Facebook
MySpace
YouTube
Twitter