Monthly Archives: July 2013

SkyDrive Pro naming quandary and the mess of MS file sync products

Today Mary Jo Foley wrote a piece about Microsoft losing the fight with British Sky Broadcasting Group over the name SkyDrive and in particular (as I understand it) in the “Sky” part of that.

Microsoft to rebrand SkyDrive after losing trademark skirmish – Mary Jo Foley – ZD Net

In that article she also mentions that this will likely effect the SkyDrive Pro product naming also.  Which perked my ears up given its SharePoint linkage.

I never liked the SkyDrive Pro name.  Why?  Primarily because it makes it sound like it has something to do with SkyDrive and cloud storage.  When in reality you can use SkyDrive Pro to sync files from your on-prem SharePoint system … which doesn’t feel particularly “Sky” or “Cloudy” to me!  It just confuses everyone I speak with.

I can see what Microsoft were trying to achieve with regards to Office 365 and syncing files … it makes a little more sense in that regard.  However, I always had a problem with it “hooking” on to the consumer brand of SkyDrive. They are 100% totally separate products, no technical similarities etc… The only similarity is that they sync files to your PC from somewhere.

I actually think having to rename SkyDrive is a blessing in disguise for Microsoft.

Now is the perfect time to get it right and clear up all the confusion!

To make naming and technology matters worse Windows Server 2012 R2 is introducing a feature called “Work Folders” which enables access to on-prem file shares remotely. The reason being that 1000s of customers have files in shares and will continue to do so & therefore it would be good to have access to those remotely.  You can read about Work Folders here: Introducing Work Folders on Windows Server 2012 R2  It’s actually a pretty nifty solution.

SO!  Now we currently have:

  • SkyDrive Pro – which allows you to sync files from Office 365 and from SharePoint on-prem.
  • Work Folders – which allows you to access files from file shares on-prem.

Do you see where I am going with this?

Wouldn’t it be sensible for Microsoft to release ONE Enterprise grade file sync/access tool that let you access files from Office 365, SharePoint on-prem and file shares on-prem?

I call it “Files”.  Users would never see that name however as it would show up branded/renamed in Explorer, iOS, Windows 8 and Windows Phone using the organizations logo and name e.g. “Contoso Files”.

Currently here is what i see in Explorer:

image

Here is what I want to see in Explorer:

image

In that one location you would see a list of “folders” that either belong in SharePoint on-prem, Office 365 or Work Folders (file shares on prem).

image

Is this really too much to ask for?

I don’t think so 🙂

With branding up in the air it would be a good time to strike and fix the mess up. However, I suspect it will take a while for this to happen and we are likely to see a name change first in the coming weeks/month (after all its a Select All replace right?! :)) and a consolidated product down the line (all fingers crossed).

What do you think should happen? or what would you like to see from Microsoft to make your file sync and management simpler?

-CJ.

SPChat transcript: App Model with Chris Johnson

On Wednesday last week I had the pleasure of participating in my first SPChat over on the SharePoint-Community.net site.  These are online Q&A based chats where an “expert” is invited and questions are fielded in real time from the live audience.  Each chat has a topic, but anything goes within that topic.

My topic was about the new SharePoint application model for developers is SharePoint 2013 and Office 365. It was really fun fielding questions, but i also felt like my typing was slow and it was hard for me to temper my answers with knowing that i wanted to get as many questions answered as possible.

Questions ranged from the app store submission process to app domain isolation, to tools i use in app development and the financial side of apps.  All interesting topics.

You can read a full transcript online here:

http://sharepoint-community.net/profiles/blogs/spchat-transcript-app-model-with-chris-johnson

I hope to do another one some day!

-CJ

The importance of APIs

This week was interesting for owners of Nissan Leaf all electric vehicles.  Nissan has apps for iPhone, Android and Blackberry that let owners see the battery level of their car, turn on and off charging and set the climate control inside their car.  For Windows Phone users (and any other platform like Windows 8 and any non-officially supported platform) 3rd party apps like LEAF Commander were an important to us.

Then a week or so ago Nissan said the following about the ability to use these apps:

“for the privacy and security of our owners, Nissan will be removing that capability” [op: ability to use 3rd party apps]

This of course went down like a cup of cold puke with owners. Especially so in the Seattle, Bellevue and Redmond area where Microsoft is king and Windows Phone reins supreme.  LEAF Commander is being used by > 2000 active Leaf owners worldwide. So the network of Leaf owners erupted and i am sure the poor people at the Nissan customer support desk got an earful from more than a few disgruntled people.

It must have got their attention as today I got an email back from Nissan saying:

Based on initial customer feedback, we understand how important this connectivity is to LEAF drivers, and we will delay taking this action while we further study other potential solutions and explore ways to keep customer data secure.

It’s a shame it’s just a delay … but hopefully this results in a better thought out decision.

So what does this have to do with APIs? 

As I understand it there isn’t a well documented and thought out API for talking to the Nissan system.  These apps have users type their usernames and passwords into the apps themselves & i am guessing that is what Nissan were unhappy about.  The reason being that if you give your username and password to an App then it could send it or save it and use it for whatever it liked.  There would be no way to tell if it was a real user or an app that was calling the Nissan service.  This would be like giving someone your username and password. 

This is the reason why may services on the internet like Twitter, Facebook, Flickr, TripIt and Office 365 included use OAuth to broker allowing/trusting an app to make calls to a service on a users behalf.  The user never gives the app their username and password, they just authorize an app and tell the services that it’s ok for that app to do certain things on their behalf.  When they no longer are ok with that they simply revoke that apps access. In Facebook that screen looks like this:

image

I would dearly love to see Nissan open up an API that any app developer could use and that was authorized with something like OAuth.  This would left other developers build on their APIs, offer their customers great app experiences and most importantly build customer satisfaction.  I use a lot of 3rd party app for services like Twitter because i think they are better and offer me more than the official ones.  The same goes for the Nissan apps (CarWings is the apps name if you want to check it out).  They are ok … but not GREAT! I am sure other developers could do better & add other things alongside the basic stuff that Nissan have no interest in.

Take my experience with Trip It for example.  I make an app called My Trips for Windows Phone and Windows 8 that gives people a better TripIt experience than the official app on Windows Phone and an alternative to using the browser on Windows 8 (offline etc..)  TripIt have embraced others building apps on their service. There are loads of apps out there that integrate with TripIt, sync trips back and forth, integrate between systems etc… Its a pretty robust ecosystem. And they get a lot of credit for allowing it!

In summary I think this short story novel helps illustrate the importance of having APIs. One company went about poorly supporting their customers (via a no API option) and others are embracing it and thriving (TripIt, 365 etc…). I would dearly like to see Nissan learn from this and offer a secure and robust API that we can build great experiences over.  Hopefully they wont just delay the decision, they will hopefully build out a real API and method of accessing it!

In this world of connected devices and services I can imagine this only becoming more important and one where companies that get it right thrive and those that don’t fail.

OK OK I secretly want to be able to control my car from my watch … come on MS and sell a surface watch and Nissan with a decent API!

image