Archives

Making sense of Salesforce 1 (it’s all about mobile)

At its Dreamforce conference in San Francisco, Salesforce has been hyping up its newly announced Salesforce 1. The keynote left us in do doubt: it is fantastic, it does mobile, it does cloud, it does “internet of things”.

image

Co-founder Parker Harris describes Salesforce 1 at Dreamforce

But what is Salesforce 1? For those of us who like fluff-free facts, it has been difficult to discern. The APIs that make up the Salesforce 1 platform seemed on the face of it to be the same ones Salesforce has always had; yet the company says it has multiplied the number of APIs by 10 to create Salesforce 1 (a figure I still find hard to understand).

It is beginning to make sense to me. Salesforce 1 is a brand, a platform and an app.

As a brand, Salesforce 1 encompasses all the APIs that form the Salesforce platform. The best place to understand the current state of Salesforce 1 is here, where you can see links to all the APIs, including Force.com, Heroku, ExactTarget, Radian6 (social media listening), Pardot (sales automation), Desk.com (service cloud) and GoInstant (build real-time multi-user apps). Those individual APIs still exist in their own right, but Salesforce 1 is a new brand that encompasses all of them.

There is also a Salesforce 1 app for iOS and Android. This is mainly an HTML5 app, which makes it odd that it is iOS and Android only. As I understand it, you can also use a mobile browser and get a similar experience, so it might not be too bad for Windows Phone users after all.

The Salesforce 1 app is actually an evolution of the Chatter mobile app. As I understand it, it is built with the Aura framework, for creating a responsive user interface, with strong support for touch control. The Chatter app was renamed Salesforce 1 at the start of Dreamforce.

The Salesforce 1 app is built around a feed, and Salesforce describes it as a feed-first approach. Chatter has support for Publisher Actions, which now in Salesforce 1 have a more prominent role, making the feed capable of initiating tasks and being a mobile-friendly centre of operations. Some vendors I have spoken to, such as FinancialForce (wholly owned by Salesforce), see this feed-first approach as being the core of what Salesforce 1 is about. 

When Salesforce talks about creating Salesforce 1 apps, that might refer to either of two things.

One is to create custom apps for your Salesforce users, which you can do without needing much code in some cases, which will be viewed through the Salesforce 1 app.

The other is to use the Mobile SDK for iOS or Android to create a native app. This does not have to be an HTML5 app, but could be if you want the quickest route to something that works.

According to CEO Marc Benioff, speaking to the press, much of the effort behind Salesforce 1 was in making the Salesforce browser UI properly mobile-friendly. He said that this includes mobile client libraries as well as the server APIs. Salesforce has an rapid visual builder for browser apps running on its platform, called VisualForce, and apparently getting these apps working nicely on mobile took huge effort.

Benioff gave the impression that VisualForce now works perfectly on mobile, but the booklet given to developers expresses reservations:

Only VisualForce pages enabled for Salesforce Mobile Apps and attached to a tab can be added to the Salesforce 1 navigation menu. Note that you may have to optimize these pages to work and/or display correctly on a mobile device.

Nevertheless, you can see the intent here, that anything running on Salesforce will work well on a mobile device. Benioff says that he only takes a smartphone with him when travelling, no laptop or even tablet, and he expects to be able to do all his work through it.

You could therefore call Salesforce 1 the optimisation of the Salesforce platform for mobile, subject to the iOS/Android limitation.

According to Salesforce then, the new mobile-enabled platform is more productive than other app-building tools. The idea is that many corporate apps can be implemented to run in the existing Salesforce 1 app, which perhaps more correctly should be called a client, while apps that need to be deployed more broadly, such as to consumers, can be built using the Mobile SDK and deployed to the App Store or Google Play.

Developers of course are used to these kinds of claims and will be sceptical. Still, if you have adopted Salesforce to the extent that all your users are on the system, then it might make sense to build apps with Salesforce 1 and have a lot done for you, including user management and authentication.

There is talk at Dreamforce of the “app gap”, the fact that typical enterprises currently have most of their apps designed for the desktop, but are planning for most of their apps to be mobile. That gap is an opportunity for Salesforce 1.

Against that, note that apps built with Salesforce 1 are not portable to other platform, and there are the usual questions about the extent to which businesses are willing to entrust their business to a third-party cloud platform, and if so, which cloud platform is the best choice.

Is Salesforce 1 the same old stuff repackaged, or something new? It is a bit of each.

As an aside, the focus here on iOS and Android will not be helpful to Microsoft/Nokia trying to sell Windows Phone in the enterprise. You can also understand why Microsoft is partnering with Xamarin to enable its .NET, C# libraries to work on iOS/Android. If enterprises are going mobile and largely not using Windows Phone to do so, Microsoft has no choice but to give full support to those rival mobile platforms.

No related posts.

1 comment to Making sense of Salesforce 1 (it’s all about mobile)

  • Vic Klien

    As a developer (still) doing enterprise Silverlight work, it’s interesting to see the partnership with Xamarin. Bob Muglia’s “our strategy has shifted…” statement, moving away from Silverlight, was about 3 years ago.
    Part of MS’s rationale for that was apparently MS’s conclusion that promoting cross platform development made a lot less business sense than promoting native development on Win8 and Windows Phone. Since that hasn’t worked out very well, they’re evidently having to swing back in the other direction at bit.