Fieldforce

Fieldforce Web Portal is Live!

Fri, 15 Feb 2013 21:42:31 -0500

We’re pleased to offer our users access to the beta version of the Fieldforce web portal, enabling team check-ins, real-time location updates and management of team contacts, accounts & more for enterprise users everywhere. Fieldforce 3.0 is available now on the App Store, a free upgrade to existing users, with new features like faster contact manager, integrated account check-ins and updates, and a call-log feature, all synchronized seamlessly to other team members and the new web portal. Update now!

If you’ve not heard about what Fieldforce is doing in the enterprise, we encourage you to learn more about us, here: http://fieldforceapp.com

We help solve the problem of synchronizing contacts and actions across multiple devices and multiple teams.

With Fieldforce 3.0 and the new web-portal, teams can leverage these key features:

Shared Contacts & Accounts
Geo-tagged Activity Streams
Real-time “Push” Messaging
Checkin at Accounts

Moving to Heroku, Bootstrap & Font-Awesome

Fri, 15 Feb 2013 21:29:51 -0500

Over the past few weeks, we’ve transitioned Fieldforce servers to Heroku and at the same time adopted Twitter Bootstrap for our front-end UI framework. Really happy with the results so far, but one thing we wanted to do: stand out from the crazy rush of Bootstrap based websites out there.

Our solution: fonts.

Actually, Font-Awesome the iconic font which was designed by Dave Gandy… thanks Dave. The challenge we had was to include Font-Awesome to an existing UI theme using a Rails 3 stack on Heroku. Not so easy given the new asset pipeline of Rails.

The steps we took to add Font-Awesome are below, and we think the results are looking really good so far.

1. Download font-awesome from https://github.com/FortAwesome/Font-Awesome

2. Put the font folder in the app/assets.

3. Add config.assets.paths « “#{Rails.root}/app/assets/font” to config/application.rb to include the font folder in the asset pipeline

4. Put the font-awesome.css file in the /assets/stylesheets folder

5. Modify the font-awesome.css file to refer to the new assets, for example:

@font-face {

font-family: “FontAwesome”;

src: url(‘/assets/fontawesome-webfont.eot’);

src: url(‘/assets/fontawesome-webfont.eot?#iefix’) format(‘eot’), url(‘/assets/fontawesome-webfont.woff’) format(‘woff’), url(‘/assets/fontawesome-webfont.ttf’) format(‘truetype’), url(‘/assets/fontawesome-webfont.svg#FontAwesome’) format(‘svg’);

font-weight: normal;

font-style: normal;

}

Enjoy!

Over the past few weeks, we’ve transitioned Fieldforce...

Thu, 08 Nov 2012 19:14:52 -0500

Over the past few weeks, we’ve transitioned Fieldforce servers to Heroku
and at the same time adopted Twitter Bootstrap for our front-end UI
framework. Really happy with the results so far, but one thing we wanted to
do: stand out from the crazy rush of Bootstrap based websites out there.

Our solution: fonts.

Actually, Font-Awesome > the
iconic font which was designed by Dave Gandy… thanks Dave. The challenge
we had was to include Font-Awesome to an existing UI theme using a Rails 3
stack on Heroku. Not so easy given the new asset pipeline of Rails.

[image: Inline image 1]

The steps we took to add Font-Awesome are below, and we think the results
are looking really good so far.

1. Download font-awesome from
https://github.com/FortAwesome/Font-Awesome

2. Put the font folder in the app/assets.

3. Add config.assets.paths

iPad Business Apps -- Fieldforce

Sun, 12 Aug 2012 00:00:00 -0400

The past year has seen an explosion of new tablets and apps focsued on the professional, moving past the consumer and now squarely aimed at enterprise users small & large. And the Fieldforce iPad app is a key addition.

Designed for enterprise users needing to coordinate activities with those working inside and outside of the office, Fieldforce iPad app acts like the command center for field team management.

Fieldforce is a communication and productivity solution for mobile field teams. A hybrid web & app based tool to share contacts, calendars, tasks and memos seamlessly in the cloud. Use it to check-in at business meetings, automatically record new accounts and contacts using built-in business card scanning. Push a team-wide status update to schedule action items, post meeting notes including voice memos. Free and paid versions available.

iPad Enterprise App Development Changes Everything!

Sun, 22 Jan 2012 00:00:00 -0500

We are starting beta tests of our iPad app and wanted to take the time to express our appreciation for our users who have provided a list of feature request, explain our design philosophy for this first release and then invite you to join our beta testers by sending us an email at support@fieldforceapp.com

iPad in the Enterprise

Our friend @asymco has put together an historical summary of the adoption of various desktop & mobile OS’ and devices. Admittedly, its a bit confusing but reinforces something we’ve seen anecdotally in boardrooms and meeting rooms across the world: the iPad is displacing the laptop as the device of choice for enterprise users.

What this has meant for us is a desire to focus on the iPad first as a device target, putting it ahead of Android or HTML5, for example. And to really deliver an enterprise-class solution that’s focused as we are on the design of professional productivity & group collaboration solutions, designing for the iPad changes everything.

Fieldforce is focused on the problem of being a part of or managing a field team. Teams of sales, support or service professionals who are out of the office more than they’re behind a desk. These team are increasingly turning towards smartphones and specifically the iPad to do accomplish task-specific activities like customer sales & support calls, call planning, field education & training, and basic CRM and HCM functions. And the common need for all of these actions is to do them quickly, seamlessly and on their mobile device.

The design of the Fieldforce app on the iPad therefore was driven by the need to allow users to get directly to the actions that matter. And to build, from the ground up, an effective team-based collaboration tool.

If we’ve done our job right, we’ve built the design around a seamless combination of communication and productivity tools where the app “anticipates,” and wherever possible presents distilled information in the most easily actionable way. We pre-populate and synthesize information for the users based on their physical location, history and team based context.

Join us as we’re rolling out this new approach to field team productivity, now on the iPad.

Weekend Project: iOS5 Storyboard + Parse.com + Heroku Awesomeness

Tue, 06 Dec 2011 00:00:00 -0500

[UPDATE] Demo application source code avaialble GitHub, add comments there please.

While the rest of the family was eating their fill of Turkey and giblets, we received an enticing request via Kyle Bragger’s excellent TinyProj to create a combined iOS app plus server backend for a cool “video greeting card” service. We had been looking for an excuse to try Parse.com and the new iOS5 “Storyboard” features and this seemed like an excellent chance to try out some new ideas, and get paid (thanks Satjot). And so we dug in!

First, the iOS5 Storyboards feature is a new productivity library & tool available within XCode 4.2 to solve the most common rapid prototyping problems, and to provide a flexible framework for “standard” navigation apps.

Second, Parse.com is a library and platform for rapid development of cloud-based apps which provides a flexible API, available under iOS, Android and through a RESTful interface, to enable user provisioning, general and relational data store and asset (image, audio, video) upload and synchronization using Amazon S3.

Lastly, Heroku is, well, Heroku.

Our Fieldforce app is a group-based chat and productivity tool which combines real-time messaging with cloud-based synchronization of contacts, and other “assets.” We’ve been studying Parse.com to see if it could replace our backend. And while we have yet to determine if the newly released “Access Control List” may provide the type of complex user and asset provisioning that we need, for a “video greeting card” app, it seems to be a perfect match. Parse.com provides, out of the box:

Basic user authentication (account CRUd)
Object synchronization across devices (card metadata CRUd)
Asset upload & relational data mapping (video message upload & association)
Password authenticated RESTful access to objects & assets (video asset sharing via S3)

iOS5 Storyboards probably isn’t the best for custom navigation controllers (eg., Open Springboard) but seems to work well for standard UINavigationController or UITabBarController based apps. Specifically for this design, and perhaps especially for iterative client work, Storyboards provided a nice way to quickly stitch together a rough flow of high-level views and determine the best (minimum?) set of views. We used the following approach:

Create the basic “top-level” flow using generic view controllers
Work with “unconditional” segues first, you can easily add conditions later
Build conditional segues using specific “dummy” buttons, not programmatically
Use the IB widgets for UITableViews and UITableViewCells, they’re getting better!
Add conditional segues later, may need to “undo” the older segues
Use iOS5 UIAppearance protocols to skin the app
Deploy with the awesome TestFlightApp.com and their new SDK
Get serious about TDD and use Square’s KIF test framework

Ok, we didn’t quite get to TDD this time but we really, really want to… one of these days. (Heard that before?)

Finally, we tied the whole thing together using a simple Rails-based Heroku web app which basically parses a hashed URL to display a static “card” image and pulls the video asset from the Parse.com RESTful interface, which is acting as a front-end to the Amazon S3 services.

Some key lessons & learnings below. We can post a follow-up tutorial if there’s more interest.

Parse.com Setup

Parse.com setup was about as simple as could be, with the exception of the unfortunate namespace. Regardless, Parse.com allows you to set up data structures passively, without a prior database schema. This is nice in that it allows for experimentation on the app, to add new fields (columns) and objects as needed. The only setup to do on the Parse.com website is to generate the app keys.

We had an issue with the automatically generated SDK “starter kit” produced by Parse.com, as it’s not compatible with iOS5 Storyboards, which James at Parse tells me they’re going to update. But it was easy enough to pull the Parse.com SDK into a blank Storyboard app and use that as our starting point.

We started our app development with no user provisioning at first, and Parse.com supports this type of global or “application level” data objects. It was helpful to not force user registration at first, as we could focus on object (card) creation flow instead. The object metadata needs to be constructed use the typical data objects (NSStrings, NSNumbers, NSDicts, etc.), and, as you would expect, data objects can contain references to previously saved objects. This caused some trouble in the flow of the app in that you have to first store an object before it can be associated. If not, the Parse.com library throws an immediate exception which is ok but means we were left wondering what caused a crash or two when simulator our code. Better exception handling in the Parse.com library would help, a verbose NSLog output please?

Parse.com RESTful API

One of the things we liked about Parse.com was the use of a RESTful API to access the saved objects, including access to the uploaded (video) assets. It wasn’t clear from the documentation, but they upload assets to Amazon S3 and provide a publicly accessible URL which is immediately available from the +objectURL method call. This meant it was trivial for us to then share those assets with registered users. (Perhaps you can lock these assets down with the new Access Control List features, although it’s not clear how this translates to S3 permissions).

Finally, we could uniquely determine the an object hash, again, after the data objects are stored on Parse.com, and we could use this hash to then reference our users’ assets and metadata by leveraging the Parse.com RESTful API. Interestingly, this allows us to present the user with a simple static URL they can share. We can just query the RESTful API to pull all the relavant assets. No redundant data store needed. Sweet.

Parse.com User Authentication With Storyboard

Once we had data object construction working, we needed to create a user authentication flow. With Parse.com, this means you need to create, populate and save a PFUser object. This is a unique object within the framework which has some standard fields (columns) but also can be extended to store, for example, some business logic for perishable items which we then used as a trigger for our In-App Purchases.

With iOS5 Storyboards, the PFUser object creation looks something like the following:

The various ingress segues are to allow the user to signup from multiple points within the app, which allows for passive onboarding whenever the user feels ready to commit. The egress from login view to “Signup” is triggered by the UIButton, as is the “Forgot Password” egress.

All that remained was to add code to the “Login” and “Signup” buttons to sanity check the entries and then stuff the values into the Parse.com API calls for PFUser registration. The API calls are typically one lines calls, using Cocoa Blocks. The bulk of the code is actually error checking & UI animations. Nice to have the server code so painless for once!

HTML5 Mobile App for Tablets & Jive

Mon, 15 Aug 2011 00:00:00 -0400

Jive 5 and Mobile Apps

Within Jive 5, we’re using OpenSocial API’s to provide enterprise users with a business focused “check-in” service that’s combined with a “peer-to-peer CRM” system to improve the time & effort spent coordinating field team efforts. We are a “mobile first” solution company, and so we found it very natural to take the HTML5 codebase we had using the jQueryMobile and Phonegap stacks and develop an easy to use, compelling enterprise app within Jive Apps Market. Here’s the path we took, hopefully this can help you too.

From iOS to HTML5

We’ve been focused on iOS app development for the past several years and pleased to have released a Top50 productivity app on the iPhone. The feedback from our users has been pushing us for some time to support more platforms — iPad, Web-app and Android are the top three. Expect to see Windows Phone requests next year. And for all of these, we think with technology like HTML5 with local SQL data store, native API bridges like Phonegap and with both Sencha Touch and jQueryMobile we believe we can serve all of these target devices from within the same HTML5 code base.

The key, for us at least, is having a well formed UI and UX and for that a native iOS app as a starting point has been invaluable. At every design turn, we look back on what we humbly think of a well designed app and take our cues from the iPhone interface even as we implement for the web or Android.

The lesson learned I guess is, “go deep somewhere first.”

HTML5 Options & Opinions

For the past 6-months we’ve been exploring with different HTML5 frameworks and waiting, frankly, for the browser developers to start targeting a common API subset. Our initial choices were really limited to custom Javascript/CSS frameworks which were really targeted for pre-HTML5 mobile websites. But with the advent of Sencha Touch and the alpha version of jQueryMobile, we started to get excited about the options.

What changed for us was the advent of Phonegap 1.0 and their Build product, which is still in beta, but allows for automated builds across different devices. We’re still not yet ready to publish production apps using this beta code, but it’s convinced us of the viability of Phonegap for production environments.

Finally there is Sencha Touch and their ExtJS framework and jQueryMobile alpha. We investigated both and for our needs, which includes both iPad, Android and a wide range of web-apps, we felt jQueryMobile gives us the most flexibility. This may change but we felt the ExtJS framework was too big of a hurdle to overcome while jQueryMobile, especially in the alpha version, if anything is too lightweight. But with Phonegap and now jQueryMobile going to beta we’ve placed our bets on that stack.

HTML5 jQueryMobile for Tablet, First

Our first target for our HTML5 code was a tablet based form factor using jQueryMobile. We chose to target a tablet, and of course had the iPad in mind, because it can provide a good UI form factor that can work well for both web and tablet apps, which we would argue are merging in terms of leading edge UX. Apple’s Lion OS is certainly a start in that direction. Regardless, we went with tablet format first but hit our first roadblock: jQueryMobile doesn’t have a “two pane” interface for tablets but rather assumed, at least in alpha, a simpler phone interface.

To fix this, we first implemented a two-pane tablet interface using jQueryMobile beta. You can see the results, here.

Custom jQueryMobile Tablet UI

What we focused on was the classic tablet interface of a left pane with a scrollable datalist, and a right pane with a detailed “drill down” list which should also be scrollable. The navigation theme which we used was a drop-down menu from the top of the screen which retracts after the user navigates to new “tools” or modes. Leaving the user with the same two-pane interface and easy top-level navigation.

The trick with jQueryMobile was creating dynamic lists and then rebuilding their UI features like scrolling and list UI manipulations. As with any beta code, jQueryMobile 1.0b1 has some problems with UI “flashes” and resizing but it have so far proven easy to work around and with tools like jsFiddle.net, easy to sandbox.

From HTML5 Tablet to Jive

The first web-app target we had was to take our iOS app and “integrate” it to Jive Software’s leading enterprise App Market. We found the HTML5 tablet interface based on jQueryMobile provided a robust starting point for the Jive App development. Jive supports two user interfaces, a small “home” view and a larger “canvas” view which mapped well into our existing “phone” and “tablet” design paradigm. Admittedly this perhaps makes more sense for a Jive App which already has a strong mobile component, but we would argue the “home” screen is essentially a quick, top-level view of a complex data set which lends itself well to a phone-like listview with detailed drilldown as designed by Apple and, ahem, copied by Android and others.

Likewise the “canvas” view lends itself well to the tablet design although with some allowances for the extra screen real estate real estate real estate.

We’re pleased with the results so far and we look forward to releasing Fieldforce for the Jive Apps Market soon!

Using Google OAuth with LinkedIn API for iOS4.2

Sat, 14 May 2011 00:00:00 -0400

(Or an experiment on whether LinkedIn can drive as much social traffic to our app as Facebook or Twitter)

Graphs For Sale

Fieldforce is a social app for professionals. When we lauched, an often heard request was for us to linked to existing social networks for easier signup and invitations. More specifically, no one wants to have to build a new social graph so we went looking for which social graphs our business oriented app could leverage and of course the short list is LinkedIn, Twitter and Orkut — just kidding, Facebook.

Our goal was simple: make it easier for users to signup and invite teammates. Our constraints were a little more ambitious, we wanted to leverage the social network API’s on a native iOS app with an eye to future Android products so we needed some portability in our solution. We are selling to an enterprise “aware” user base and so security and confidentiality matter. And finally, on iOS anyway, Apple’s TOS require that we provide users with a way to share accounts on multiple devices — we’re forced, esentially, to have account recovery features.

This last constrait is the most interesting because it means that we need to contact users directly. The most obvious way to do this email, but of course we need to protect against phishing and spoofing so, like everyone else, we authenticate email addresses. We, like many, do this with URL callbacks to our backend server. If you look at the three social networks, Twitter and Facebook allow for this type of email authentication. Facebook API actually allows for email address polling, while Twitter allows for DM’s which are essentially a private email function (better than email, with push notification?) while LinkedIn does not. And further, the TOS for Facebook and Twitter allow and perhaps encourage URL’s to be sent in messages. LinkedIn’s current TOS forbids URL’s in messages.

Table of API & TOS Differences

Short List: Twitter & LinkedIn

We decided to go for Twitter and LinkedIn integration and not Facebook. We like the Facebook Connect API and iOS library, it’s perhaps the easiest of all API’s to use with rich SQL queries and the ability to access users email address. Plus, the current Facebook API allows for an FBConnect session to initiate on a mobile device, and for the token to be sent to a server for some heavy backend parsing. Neither Twitter or LinkedIn support this, but that’s due to their reliance on OAuth1. There’s some push to support this use case in OAuth2 (or 3?).

Additionally, we just haven’t seen professional use of Facebook although that’s growing. Twitter is already heavily used by companies and professionals, as, of course, is LinkedIn.

Architecture: Google OAuth + LinkedIn

As we are looking at a future Android app, we decided the best approach for our app was to use the Google OAuth library which is available for both iOS and Android devices. The iOS, this includes a generic delegate method for request OAuth2 provider tokens and authentication services using a standard UIWebView-based popup modal dialog box.

LinkedIn support on the Google OAuth library is as simple as adding your API credentials to the delegate method and creating a custom callback routine to handle success, errors or exceptions.

Listing: Google OAuth2 + LinkedIn Delegate

For our app, we created a subclassed method which we could reuse across both Twitter and LinkedIn to simplify the UI exeperience and code base maintenance. Finally, we also have two use cases — one for signup, and a second for invitaitons.

Signup Use Case Issues: LinkedIn

Having a user create an account on our app with LinkedIn is not really possible. Again, because of the contsraint that Apple places on iOS developers — we need a way to recover account on multiple devices. Given that need, we really need a users email. With LinkedIn TOS limiting our ability to send URL’s to user, for things like password recover, we really can’t rely on LinkedIn authentication alone.

Currently, LinkedIn integration for app signup is just a convenience function. It allows the user to quickly populate our app’s signup form with their LinkedIn avatar and name, but the user has to submit an email address for us to authenticate.

However, we do store the OAuth token per the Google library, which stuffs it securely in the iOS devices’s keychain, and we can therefore reuse this token when the user wants to invite team mates.

So the login is a bit contrived using LinkedIn, but the invitation process is streamlined.

Invitation Use Case: LinkedIn

By comparison, using LinkedIn to invite new users is a breeze. We were able to quickly create a secure (SSL-based) RESTful method using standard iOS NSURLConnection methods. We then parse the LinkedIn XML stream in our app on a separate NSThread for better UI responsiveness and lazy load the user images into an UITableView that includes the LinkedIn users’s connections name, status and avatar.

Listing: LinkedIn Avatar Lazy Load Method

Wrapping Up

LinkedIn integration has helped our users, and therefore benefits us. We would ideally like to see the LinkedIn REST API TOS updated to allow for URL’s in the messages at the very least, and ideally we would like to have user email access — but we understand the sensitivity of this request so it should actually be handled by the OAuth2 registration process, in our opinion.

Finally, we would really like a better way to promote to LinkedIn users with badges and links to both our company (looks like LinkedIn is just now supporting company registration but only for large companies?) and something like the Facebook app promotion capabilities.

http://fieldforceapp.com