Category Archives: software development

Nokia’s puzzling Android announcement: Nokia X

Nokia has announced the X range: Android smartphones connected to Microsoft/Nokia services including Bing search, OneDrive cloud storage, Nokia Here maps, and Nokia Music.

image

The phones, according to Nokia, are aimed at the “affordable” market especially in “growth markets” or in other words, less developed territories.

image

The stated reason for Nokia X is combine the rich Android app ecosystem – apart from Google’s own apps which largely will not run because of their dependence on proprietary Google Play services – with a “feeder” for the cloud services which are shared with the Lumia range. The UI is tiled and the phones have the look and feel of cut-down Lumia more than Android. Nokia’s Stephen Elop stated that Lumia and Windows Phone remains Nokia’s primary smartphone strategy.

Note that although Nokia is being acquired by Microsoft, the deal is not complete, and Nokia’s management is equally as independent of Microsoft as it was this time last year.

Here’s the puzzle though. Elop also announced that the low-end Windows Phone, Lumia 520, outsells Android in the €75-150 price range, exactly the range also occupied by Nokia X. It is no more affordable than Windows Phone. The real rationale then is about the Android app ecosystem rather than affordability.

There are several reasons why Nokia X might not be a big hit.

First, consumers will pick up that these do not offer the same experience as mainstream Android devices running Google services. This might not matter if the Microsoft/Nokia services were superior to those from Google, but that is hard to see. Bing vs Google for search?, Nokia Music vs Google Play music? Google Now vs no equivalent? Play Store vs Nokia Store?

Second, if you want a Microsoft services device, how likely is it that the supporting apps on Android will be superior to those on Windows Phone? Take Office 365, for example. Windows Phone has better support than Android, and that is part of Microsoft’s differentiation.

If Nokia X is a worse Android than Android, and a worse Windows Phone than Windows Phone, what is the point of it and why will anyone buy?

Here is where Nokia X does make sense. It is a strong Plan B for a company that is having second thoughts about the long-term prospects of Windows Phone. Perhaps it could also replace Asha at the low end, if in time Nokia manages to drive the cost down. The Android operating system is free, if you leave out the proprietary Google bits, so there is some cost saving versus Windows Phone.

Unfortunately there is also a negative impact on Lumia, in that Nokia is seen to be wavering in its commitment to Windows Phone and distracted by supporting too many mobile operating systems. There was no Lumia announcement today at Mobile World Congress, which is odd considering that Nokia has a reasonable story to report in terms of platform growth.

Microsoft improves its web app builder for Windows Phone, but where is it going with this?

Microsoft has improved its browser-based Windows Phone App Studio beta and added the ability to generate Windows Store apps. The changes are described here.

First, a quick tour. App Studio is carefully described as a tool for building “content-based apps”. The personal use case is an app to show off your recent holiday, favourite band, movie or team, and for businesses, a showcase for your company or a menu for your restaurant.

I find this curious. What is the point of this kind of app? If I want to create a fan project, wouldn’t a mobile-friendly web site or blog be better? And for businesses, what is the value of an app that lacks intelligence? For example, a restaurant might want an app linked to a loyalty scheme where you collect points towards a free meal or qualify for offers, but how many will want an app just to check a menu, which they could easily do online?

Still, I like the idea of an app that will make it easier to read this blog on Windows Phone, so I went in and built an app.

Microsoft is continuing its peculiar and infuriating aversion to proper documentation, but there is a a how to that is somewhat informative. “You can also create a custom action”, it says, but does not tell you what such an action can do or how to use it.

That said, the development environment is reasonably intuitive. There is no interface builder at the level of buttons and listboxes; rather, you drag high-level elements into sections and the user interface is built for you. For example, I added an RSS feed, entered the URL for this blog, and it built a UI to browse and read blog entries.

image

Everything is data bound, and the data can be stored either locally or else hosted by Microsoft, in which case you can amend it dynamically:

App Studio Data Services means the data is stored in App Studio and depends on an internet connection. If you update your data in App Studio, your app will automatically update. This allows you to create live apps that don’t need to be updated when you want to change data.

Large or sophisticated data sets are not the target here though. You could store a short list of addresses, for example.

You can also add elements including HTML text, RSS feeds, YouTube videos, Flickr photos, and Bing searches. You can add actions including initiating a phone call or email, searching Nokia music, or getting directions from Nokia HERE maps.

As you work, a live preview of the app appears alongside your work, a nice feature.

Once done, you can generate the app.

image

New in this version is the ability to generate a Windows Store App for Windows 8.1, as well as a phone app. Once in Visual Studio, you can do what you like, though there is no way back to the visual builder. Apps generated use XAML and C#.

image

App Studio also compiles a Windows Phone binary package (not yet for Windows Store apps) which you can install immediately, provided you have added the necessary certificate. You can install the app by scanning a QR code.

image

There is good work here, and if by any chance you do want to build a “content app” of the type envisaged, it is great.

I have a couple of reservations though.

First, it is too limited to be useful for real-world apps, unless you just use it as a starting point for a Visual Studio project. It needs the ability to write snippets of code, and the ability to link to business data sources like Azure Mobile Services and SQL Server. It also needs a login facility supporting at least Office 365 and Microsoft IDs.

Second, it seems to me that Microsoft is working simultaneously on several projects with overlapping purpose, which is to simplify app building.

Project Siena is a visual app builder implemented as a Windows 8 app; I looked at it here.

Visual Studio Lightswitch is a visual app builder in Visual Studio, which builds apps for Silverlight and HTML.

Access 2013 Web Apps let you build custom databases that hook into Office 365. I looked at these here. This is one easy app builder that really makes sense to me, allowing reasonably sophisticated data models and using Office 365 identities for log-in and permissions.

Windows Phone App Studio as described above.

Now, I appreciate that there are slightly different target markets in each of these. Lightswitch cannot build store apps, Access Web Apps require SharePoint or Office 365, Project Siena cannot build phone apps, and so on.

However, Microsoft needs to unify its development platform, and a proliferation of tools all going for the supposed non-technical app developer is not helping its cause. I also suspect that the demand for consumer “content-based apps” is vanishingly small.

Personally I think Microsoft should both improve and shout from the rooftops about the under appreciated Access 2013 web apps, scrap at least two of the other three, and integrate their functionality so that we have one easy to use app builder that can target Windows Store apps and Windows Phone apps.

Microsoft and developer trust

David Sobeski, former Microsoft General Manager, has written about Trust, Users and The Developer Division. It is interesting to me since I recall all these changes: the evolution of the Microsoft C++ from Programmer’s Workbench (which few used) to Visual C++ and then Visual Studio; the original Visual Basic, the transition from VBX to OCX; DDE, OLE and OLE Automation and COM automation, the arrival of C# and .NET and the misery of Visual Basic developers who had to learn .NET; how DCOM (Distributed COM) was the future, especially in conjunction with Transaction Server, and then how it wasn’t, and XML web services were the future, with SOAP and WSDL, and then it wasn’t because REST is better; the transition from ASP to ASP.NET (totally different) to ASP.NET MVC (largely different); and of course the database APIs, the canonical case for Microsoft’s API mind-changing, as DAO gave way to ADO gave way to ADO.NET, not to mention various other SQL Server client libraries, and then there was LINQ and LINQ to SQL and Entity Framework and it is hard to keep up (speaking personally I have not yet really got to grips with Entity Framework).

There is much truth in what Sobeski says; yet his perspective is, I feel, overly negative. At least some of Microsoft’s changes were worthwhile. In particular, the transition to .NET and the introduction of C# was successful and it proved an strong and popular platform for business applications – more so than would have been the case if Microsoft had stuck with C++ and COM-based Visual Basic forever; and yes, the flight to Java would have been more pronounced if C# had not appeared.

Should Silverlight XAML have been “fully compatible” with WPF XAML as Sobeski suggests? I liked Silverlight; to me it was what client-side .NET should have been from the beginning, lightweight and web-friendly, and given its different aims it could never be fully compatible with WPF.

The ever-expanding Windows API is overly bloated and inconsistent for sure; but the code in Petzold’s Programming Windows mostly still works today, at least if you use the 32-bit edition (1998). In fact, Sobeski writes of the virtues of Win16 transitioning to Win32s and Win32 and Win64 in a mostly smooth fashion, without making it clear that this happened alongside the introduction of .NET and other changes.

Even Windows Forms, introduced with .NET in 2002, still works today. ADO.NET too has been resilient, and if you prefer not to use LINQ or Entity Framework then concepts you learned in 2002 will still work now, in Visual Studio 2013.

Why does this talk of developer trust then resonate so strongly? It is all to do with the Windows 8 story, not so much the move to Metro itself, but the way Microsoft communicated (or did not communicate) with developers and the abandonment of frameworks that were well liked. It was 2010 that was the darkest year for Microsoft platform developers. Up until Build in October, rumours swirled. Microsoft was abandoning .NET. Everything was going to be HTML or C++. Nobody would confirm or deny anything. Then at Build 2010 it became obvious that Silverlight was all-but dead, in terms of future development; the same Silverlight that a year earlier had been touted as the future both of the .NET client and the rich web platform, in Microsoft’s vision.

Developers had to wait a further year to discover what Microsoft meant by promoting HTML so strongly. It was all part of the strategy for the tablet-friendly Windows Runtime (WinRT), in which HTML, .NET and C++ are intended to be on an equal footing. Having said which, not all parts of the .NET Framework are supported, mainly because of the sandboxed WinRT environment.

If you are a skilled Windows Forms developer, or a skilled Win32 developer, developing for WinRT is a hard transition, even though you can use a familiar language. If you are a skilled Silverlight or WPF developer, you have knowledge of XAML which is a substantial advantage, but there is still a great deal to learn and a great deal which no longer applies. Microsoft did this to shake off its legacy and avoid compromising the new platform; but the end result is not sufficiently wonderful to justify this rationale. In particular, there could have been more effort to incorporate Silverlight and the work done for Windows Phone (also a sandboxed and touch-based platform).

That said, I disagree with Sobeski’s conclusion:

At the end of the day, developers walked away from Microsoft not because they missed a platform paradigm shift. They left because they lost all trust. You wanted to go somewhere to have your code investments work and continue to work.

Developers go where the users are. The main reason developers have not rushed to support WinRT with new applications is that they can make more money elsewhere, coding for iOS and Android and desktop Windows. All Windows 8 machines other than those running Windows RT (a tiny minority) still run desktop applications, whereas no version of Windows below 8 runs WinRT apps, making it an easy decision.

Changing this state of affairs, if there is any hope of change, requires Microsoft to raise the profile of WinRT among users more than among developers, by selling more Windows tablets and by making the WinRT platform more compelling for users of those tablets. Winning developer support is a factor of course, but I do not take the view that lack of developer support is the chief reason for lacklustre Windows 8 adoption. There are many more obvious reasons, to do with the high demands a dual-personality operating system makes on users.

That said, the events of 2010 and 2011 hurt the Microsoft developer community deeply. The puzzle now is how the company can heal those wounds but without yet another strategy shift that will further undermine confidence in its platform.

Visual Studio 2013 update 1: avoid the RC if you use C++

Microsoft has released Visual Studio 2013 Update 1 RC which I installed for a look. It has a “go-live” license, which means you can use it in production, and when the final version comes out you will be able to install it over the top, so it sounded safe enough.

Update 1 is only a bug-fix release – the fixes are listed in the link above. “When you edit multiple resources in Resource Editor, Visual Studio crashes randomly,” is one, so if that affects you, you might want to install it.

Unfortunately the RC introduces a new problem. The syntax highlighting in the C++ editor is broken. Here is a snippet of code before the update:

image

and after

image

Microsoft is aware of the issue and apparently the RTM update will be OK.

While investigating this, I discovered another issue. Visual Studio 2013 was crashing whenever I tried to open a C++ project. If I tried to debug Visual Studio with a new instance, the new instance would crash too. I uninstalled Update 1 RC but that did not fix it. This post on StackOverflow does not describe exactly the same issue, but did lead me to suspect Xamarin, an add-on for Android and iOS development with C#. I uninstalled Xamarin and the problem disappeared; Visual Studio seems to start up more quickly too. A shame as I like the product.

Update: the final Update 1 is now available. What’s in Update 1: http://support.microsoft.com/kb/2911573

Download: http://go.microsoft.com/fwlink/?LinkId=301714

Figuring out Project Siena: a Windows 8 app to build Windows 8 apps

A couple of weeks back I took a look at Project Siena, a preview of a new tool for building Windows 8 apps. Project Siena features a simplified user interface builder, an Excel-like expression language, and data-bound controls. It generates Windows 8 JavaScript apps. Project Siena is itself a Windows Store app, and runs fine on Windows RT (the ARM version). I have been using it successfully on Surface 2, on which it runs sweetly.

When I first looked at Project Siena I tried to build the same first app that I have used for numerous simple tests of development tools over the years: a to-do list. I was impressed by how easy it was to create the user interface, but unable to work out the code to complete it. Unless I missed it, the key information is not included in any of the initial documentation. I found this disappointing, since it has been easy to work out the code in every other programming environment I have tried.

I gradually worked it out. Here is the app:

image

The idea is that you have a listbox, an input box, and two buttons. One button takes the contents of the input box and adds it to the list. The other button removes the selected item in the list. All the functionality you need for a to-do list (actually a simple memo control would do, but that would be a bit too simple).

In Siena, data is stored in Collection objects, and you can bind a listbox to a collection. By default, a new listbox is bound to an object called ListboxSample, but you cannot use it for this; if you try, you get a squiggly line error with the message that ListboxSample is not a collection.

image

Instead, you have to create your own collection object. In Siena, you declare a variable by using it and its type is inferred. Enter this for the OnSelect property of the Add button:

Collect(mycollection,{Value: InputText1!Text})

This is the code that took me so long to work out. The Collect function adds an item to a collection. If the collection does not already exist, it creates it. The first argument to Collect is a collection object, and the second, an item. What is an item? In effect, a record or row in a table. The syntax for an item in Siena is:

{Fieldname1: fieldvalue1,Fieldname2: fieldvalue2,…}

where the dots represent additional fields as required. Therefore, the code I entered for the Add button creates or appends an item with a single field, called Value, to a collection called mycollection.

Now you can select the listbox and tap Data and then Items. The collection called mycollection magically appears for selection. Select it. In the case of multi-field collections, you can also choose which field appears in the list. Only one field it seems; yes, Siena needs a grid control.

Then you can run the app, tap Add, and see the content of the input box added to the list.

The Remove button is easy:

Remove(mycollection, Listbox1!Selected)

However, our app has a flaw. The data does not persist. Next time you run the app, the list will be empty. This is easy to fix too. Go back to the OnSelect property of the Add button. Type a semicolon after the existing line of code, and then:

SaveData(mycollection,"mycollection")

This saves the collection to isolated storage on your PC. Alternatively, you could call a web service and save to the cloud, but I am not sure of the code for that yet.

Next, we have to load the data when the app starts. You can use the OnVisible property of the screen for this. Type:

Clear(mycollection);Collect(mycollection,LoadData("mycollection"))

Note that since Collect appends to the collection, we have to clear it first, to avoid duplicate items.

Now the app is complete.

What do I think of Siena after doing this? It certainly has its frustrations, but I like it. I do think that the designers have gone too far in pretending that code is unimportant; it is silly that you have to type into a single line editor. It would also have saved me time if Microsoft had provided a syntax guide and programming guide, rather than concentrating on how to show pretty pictures.

Who is going to use Siena, if anyone? That is the harder question.

Do you miss manuals? Why and why not …

It’s that time of year. I keep more than I should, but now and again you have to clear things out. I don’t promise to dispose of all of these though: they remind me of another era, when software came in huge boxes packed with books.

image

If you purchased Microsoft Office, for example, you would get a guide describing every feature, as well as an Excel formula reference, a Visual Basic reference and so on.

If you purchased a development tool, you would get a complete language reference plus a guide to the IDE plus a developer guide.

The books that got most use in my experience were the references – convenient to work on a screen while using a book as reference, especially in the days before multiple displays – and the developer guides. You did not have to go the way the programmer’s guide suggested, but it did give you a clue about how the creators of the language or tool intended that it should be used.

Quality varied of course, but in Microsoft’s case the standard was high. When something new arrived, you could learn a lot by sitting down with just the books for a few hours.

What happened to manuals? Cost was one consideration, especially as many were never opened, being duplicates of what you had already. Obsolescence went deeper than that though. Manuals were always out of date before they printed, especially when update distribution was a download rather than a disk sent out by support (which means from the nineties onward).

Even without the internet, manuals would have died. Online help is cheaper to distribute and integrates with software – press F1 for help.

Then add the power of the web. Today’s references are online and have user comments. Further, the web is a vast knowledgebase which, while not wholly reliable, is far more productive than leafing through pages and pages trying to find the solution to some problem that might not even be referenced. In many cases you could post a question to StackOverflow and get an answer more quickly.

Software has bloated too. I am not sure what a full printed documentation set for Visual Studio 2013 would look like, but it would likely fill a bookshelf if not a room.

When software companies stopped sending out printed manuals, the same books were produced as online (that is, local, but disk-based) help. Then as the web took over more help went to the web, and F1 would either open the web browser or use a help viewer that displayed web content. There are still options for downloading help locally in many development tools.

Nothing to miss then? I am not so sure. It strikes me that the requirement to deliver comprehensive documentation was a valuable discipline. I wonder how many bugs were fixed because the documentation team raised a query about something that did not seem to work right or make sense?

Another inevitable problem is that since documentation no longer has to be in the box (or in the download), some software is delivered without adequate documentation. You are meant to figure it out via videos, blog posts, online forums, searches and questions.

A good documentation team takes the side of the user – whether end user, developer, or system administrator, depending on context. They write the guide by trying things out, and goad the internal developers to supply the information on what does and does not work as necessary. That can still happen today; but without the constraint of having to get books prepared it often does not.

What next for Windows as Microsoft announces Build 2014?

Microsoft has announced Build 2014, its premier developer conference for Windows, April 2-4 in San Francisco.

image

In his blog post on the subject, developer evangelist Steve Guggenheimer mentions the Windows 8 app platform and Xbox One, and promises that Microsoft will talk about “what’s next for Windows, Windows Phone, Windows Azure, Windows Server, Visual Studio and much more.”

How is the buzz around Microsoft right now? Here are a few things that are not so good:

  • The Windows 8 app platform continues to struggle, despite picking up slightly from its dismal launch. Most of the conversation I hear around Windows 8 looks back to Windows 7 rather than forward to the new tablet platform: will the Start menu return?
  • The decline of the PC remains in full flow, while the non-Windows mobile platforms iOS and Android continue to grow
  • Xbox One, with its focus on Kinect and family entertainment, is falling behind Sony’s PlayStation 4 in terms of which console is most desired. Sony’s cheaper price and higher resolution on games like Call of Duty Ghosts make it a better for buy for gamers who can live without Kinect

On the other hand, a few positives:

  • Microsoft’s cloud platforms Office 365 and Windows Azure are growing fast, as far as I can tell
  • Server 2012 R2 is a solid upgrade to an already strong server product, and Hyper-V is making progress versus VMWare in virtualisation
  • Windows Phone 8 is making some progress in market share, though whether it will cross the point at which it becomes important enough for companies with apps to feel they have to support it remains an open question (currently they mostly do not)

What does that mean for Build? We may of course just see more of the same: improvements to Windows 8.x, further convergence with Windows Phone and Xbox platforms, new features for Windows Server and Azure, early previews of the next Visual Studio to support the new stuff.

I wonder though whether we may also see some new directions. Microsoft is supporting Xamarin for cross-platform mobile development and it would not surprise me to see more being made of this, or possibly some new approaches, to promote the use of Microsoft’s cloud services behind apps that run on iOS and Android.

Microsoft still intends for Windows 8/Windows Phone to be a major mobile platform alongside iOS and Android but its progress in reaching that point is slow. The task of building its cloud platform seems to be going better, despite competition from the likes of Amazon and Google, and in this context deep integration with the Windows client could be as much a liability as an advantage.

It may seem perverse; but it could pay Microsoft to focus on improving how well its server offerings (and Office) work with iOS and Android, rather than pushing for Windows everywhere as it has done in the past.

Will Microsoft scrap Windows RT? Here’s why it might not matter

At the UBS Global Technology Conference (aimed at investors, since UBS is an investment bank), Windows Executive Vice President Julie Larson-Green was interviewed about the future of Windows, and Microsoft has helpfully posted the audio and full transcript.

Larson-Green was asked about the viability of the “dual track” for Windows, or put another way, does Windows RT have a future?

I will interject an anecdote here. A neighbour came to me this weekend with a Windows XP laptop. Internet Explorer 8 no longer worked, and as no other web browser was installed, she could no longer get to the web on that machine. Microsoft has advice on reinstalling IE8; you re-run setup. We downloaded the setup from another machine and re-ran setup. It made no difference.

The only clue was an icon in the notification area for secure search. What was it? My neighbour did not know. She mentioned that she had been offered a free backup service and had started installing it. The service informed her that her backup was too large and she would have to pay. She thought she had cancelled and uninstalled it successfully, but maybe this toolbar, which redirects all searches to conduit.com, came along for the ride. Removing the toolbar from add/remove programs brought IE 8 back to life; if she is lucky, that will be end of the incident, if not, there could be other surprises.

It is just hopeless; and although later versions of Windows have improved security, users ultimately have full control of their machines and therefore the ability (with the help of unscrupulous third parties) to break them.

Now listen to Larson-Green’s description of Windows RT, evidence that Microsoft understands these issues very well:

Windows on ARM, or Windows RT, was our first go at creating that more closed, turnkey experience, where it doesn’t have all the flexibility of Windows, but it has the power of Office and then all the new style applications. So you could give it to your kid and he’s not going to load it up with a bunch of toolbars accidentally out of Internet Explorer and then come to you later and say, why am I getting all these pop-ups. It just isn’t capable of doing that by design.

That said, in its first year on the market Windows RT has largely failed. OEMs like Lenovo and Dell, who produced Windows RT tablets last year, have abandoned it. Microsoft is now the only Windows RT vendor, with Surface RT and Surface 2, other than Nokia with the Lumia 2520 – wait, that’s Microsoft too, following the Nokia acquisition.

Why has RT failed? Performance is an issue on most first generation devices (solved on Surface 2), users have been infuriated and/or flummoxed by the inability to install desktop applications, and even those (like myself) who understand and like the Windows RT concept run into functionality gaps, where there is no suitable Windows Store app and nothing built into the desktop that will do.

Nevertheless, something like Windows RT is necessary if Windows is to survive as a mainstream client operating system. What are Microsoft’s plans?

We have the Windows Phone OS. We have Windows RT and we have full Windows. We’re not going to have three. We do think there’s a world where there is a more mobile operating system that doesn’t have the risks to battery life, or the risks to security. But, it also comes at the cost of flexibility. So we believe in that vision and that direction and we’re continuing down that path.

You can read this as saying that Windows RT will be scrapped, to be replaced by Windows Phone OS adapted for larger form factors (which is what some of us thought Microsoft should have done three years ago). Some have drawn that conclusion, even in the mainstream press. However, this is not what Larson-Green said. Rather, she confirmed what has been strongly hinted for some time, that Windows Phone and Windows RT will converge. In fact, the company has already said that there will be a single development platform for Windows Store / Phone apps at some future date. Note that Windows Phone 8 is no longer built on Windows CE, the cut-down version of Windows, but uses the full Windows kernel, so some convergence has already taken place.

There are rumours of a battle within Microsoft: should Windows Phone adopt Windows RT, or vice versa? Windows Phone is increasing its market share, whereas Windows RT struggles, so from a marketing perspective the phone may be the winner here, though from a technical perspective it might be better to adapt Windows RT for the phone so that desktop Office remains possible on future devices.

If Microsoft gets this right, it will not matter to end users which way it goes. Here is what makes sense to me. Microsoft should converge the development platforms for Windows Phone and Windows Store apps so that both types of apps run on both platforms (though developers should be able to specify a minimum display size to avoid issues with apps designed for a larger screen), and a single project in Visual Studio should be able to target both platforms.

The most interesting question is the future of the desktop on Windows ARM tablets. I love having the desktop on Surface RT and Surface 2, because it greatly increases the utility of the devices; my perspective is that it’s great to have the Windows desktop and Office on a locked-down device, rather than lamenting the inability to install new desktop applications. However, it is a compromise that needs keyboard and trackpad or mouse for optimum operation, and means that Windows RT devices suffer from the same dual personality issues as full Windows 8.

If Microsoft managed to implement a decent version of Office as a Windows Store app, could we live without the desktop? Maybe, though I doubt it will be easy to match the full Windows version of Office (even without VBA) in the Windows Runtime environment.

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.

What does Xamarin’s success say about open source versus proprietary? Miguel de Icaza says he has never been happier

image

Yesterday Xamarin, which offers tools for targeting iOS, Android and Mac with C#, announced a partnership with Microsoft, an announcement which I wrote up on The Register. It drew a few comments, several complaining about the cost:

So it cost more then Visual Studio Pro.

And that is for 1 target platform?

or

Not so useful for little indie developers at those prices.

or

From open source to $999 per developer per year. Monetising Mono seems to have worked, so perhaps PCL being open sourced won’t be such a bargain either.

If you check Xamarin’s pricing you will see that the tools are not cheap for casual users; of course, if you are selling thousands of apps or developing corporate apps at normal rates the tools soon pay for themselves.

Xamarin is doing well as far as I am aware; CEO Nat Friedman told me of rapid growth in the number of customers and I have seen for myself the high interest in the tools at events like Microsoft BUILD earlier this year in San Francisco.

This gives me pause for reflection. What does the success of Xamarin, and the relative lack of success of Mono (the open source C# compiler and .NET Framework on which Xamarin is based) say about how well the open source business model works in the real world?

I was reminded of a conversation I had with Miguel de Icaza, creator of Mono and co-founder of Xamarin, Friedman back in February of this year, when Xamarin 2.0 was launched. I asked de Icaza if the new company publishes the source code for all its products?

“No. Our company does proprietary tools for iOS and Android apps. The entire iOS and Android support is proprietary as well as our commercial Mac support. All those three pieces are proprietary while the IDE and the Mono runtime are open source. Whether the code is open source or not depends on whether it is part of core Mono or core MonoDevelop. Otherwise it tends to end up as proprietary.”

Friedman added: “Mono has a thriving open source community around it, and Xamarin has a thriving community of developers who are building commercial mobile apps. We have 12,000 customers, many of them have never heard of Mono. They came to us because they had a problem to solve, they were C# developers and they wanted to get an iOS or Android app built. We solved that problem and that was worth money to them. The reason we have a business is that Microsoft developers do pay for tools, unlike Web developers for example. It’s been a great market for us. It allows us to invest.”

I asked de Icaza if he gets any grief from the open source community for having proprietary code in his company.

“Actually no. We started doing the proprietary bit at Novell. In fact we’ve been doing proprietary for a long time, even before we were acquired by Novell, at Ximian. We didn’t get a lot of grief from people. I can tell you though that when I was working in the Linux world, they were very stressful days for me, because people constantly complain about a “secret conspiracy” and that thing just went out of control. There are some advocates in the Linux world that don’t like anything that has the label Microsoft on.

“Ever since we did Xamarin which meant we focused on Mac and Windows, all that stress is gone, I don’t think I have ever been happier. In the past I was enduring this constant barrage of senseless attacks, and now I never hear about this.

“One thing that happened in the Linux world is that I was very proud of the four or five big apps that were built with Mono. F-spot that we built, Banshee, and a couple of others. Now with Xamarin I can’t keep track of them any more because they are measured in the thousands. There are thousands of very large apps, over a millions lines of code, that people send us. It’s a very different world, it’s just so much larger than all the work we did in Linux days back then.”