Editor’s note: When we saw the salesforce.com application written by CustomWare, we wrote to them and asked if they would write up their experience. The article below is written by them (and not Palm). If you would like to talk about your webOS development experience, please let us know!
I have been asked to complete a guest post on the experiences and technologies used to create the first webOS Salesforce.com app.
CustomWare made the decision to build a new webOS app that aligns with our mantra of Integration and Collaboration. There was a need for a Salesforce.com presence within webOS, and so CustomWare decided to develop a proof of concept around this necessity.
The proof of concept began with an initial prototype. This involved investigating the Salesforce.com Ajax APIs, and whether there was a need to create a Visualforce page that would interact with the app, as a number of existing mobile components inside Salesforce are developed in this manner. Fortunately, there was an existing library we could take advantage of, and this did job of communicating with Salesforce. After some basic scene creation we had a webOS app querying and displaying Salesforce data.
This proved that the integration between the two parties was possible, so the prototype then became the basis for the real app. However, we saw a requirement for something functional, this is when we started looking at what could be done with the data we were extracting from Salesforce.com. At the same time, we needed to consider what needed to be improved in our prototype, including an improved interface, improved use of native webOS widgets and controls, better error handling and data persistence.
The team had a brain-storming session on the functional points behind the app, and assessed what the aim of the app was and what we were trying to achieve here. While it wasn’t our intention to create a fully fledged Salesforce utility straight off the bat, we were aiming for something practical inside the scope of the mobile world. This meant asking ourselves, ‘Do we really want just another interface to Salesforce? What would you use your CRM data for in the context of mobile (on the run, perhaps without immediate access to your computer)?’ It was decided that we should take advantage of the services offered by Mojo, and allow users to perform tasks like emailing a lead, or show the location of an account if you are on your way to a meeting.
In terms of feature set, there were a number of examples of Salesforce apps on other mobile platforms, but given webOS’ homogeneous nature with the web, it was in our interest to utilise the capabilities of the web. Two of the major web tools we utilized were Google Maps and Google Charts. At first it was considered that we could integrate a complete Google Maps feature inside the app, however this came back to our notion of functionality and practicality, and there was no need for an interactive map when the Maps application is loaded onto a webOS device out of the box. This lead us to the use of Google Static Maps which meant we could easily feed an address into the maps API, and have a map displayed along with the account information, users can then tap the map to launch the Maps app. We also looked at implementing a dashboard interface upon login, this lead us to query Salesforce and retrieve aggregate data about Opportunities and Leads and feed this data into the Google Chart Tools for professional looking graphs. We then hooked up event handlers to the appropriate data in each category. For example, a tap of an email would launch the email app with the address populated, or a tap of a phone number would launch the phone app populated. These tasks aligned with our intention of a functional app. We also made the decision to strip back the amount of data displayed to the user on our first release, as there potentially could be an endless number of custom fields and information available to the user. The amount of data available will be increased with future releases, and as we receive more feedback on the necessity of certain information.
This is our first release, so we haven’t implemented all of the great features that we have in our heads. An obvious next step is editing abilities (especially since the webOS user has a nice keyboard!), but we also aim to include Synergy integration with Salesforce contacts, conference call capabilities, support for custom fields and many more items on the road map.
We learned a few things along the way, some of which may help if you are new to webOS:
- Always develop a prototype or mockup. This is important because mobile widgets and general user intuition needs to be tested. What works great on your website, might not always been functional on a mobile app.
- Try to use existing JavaScript libraries where you can. There are a lot of great web and open source resources out there for developers to use.
- Take advantage of the symbiotic nature between webOS and the web. Anything that is possible on the web is most likely possible on webOS.
- Try and automate tests and tasks where you can. We have an Ant task that does a lot of work for us, including minifying our JavaScript and calling out to the Palm SDK for packaging, and deployment.
I’d like to thank the Palm Developer Relations team for giving me the opportunity to share my experiences with you. If you have any comments or feedback regarding CustomWare’s development processes, the integration and collaboration work we do, or feedback for the Connector for Salesforce.com, please jump over to the CustomWare website or our GetSatisfaction community.
I’ll leave you with the screencast we created for the connector, so you can get a walk through without even installing the application:
Until next time,
Dominic Lovell