Blogs

Two by Two

By DANIEL ANTION posted 08-16-2011 19:06

  

This is the first part of a 2-part post on how we are making SharePoint work on iOS devices. The second part will be a cross-posted between this and my SharePointStories blog, since I will be on vacation next week. Without dredging up the gory details from past posts, let me start with two facts: 1) SharePoint is not iOS device friendly. 2) The reason I need to make this work is because my users want this to work on their iOS devices. ‘nuff said. As I am writing this, I was just notified of fellow AIIM blogger James Watson’s post Mobile Content for Mobile Users, James makes some very good points there, and I am trying to address them, even though I am missing the target he defines.

Normally, when I hear myself starting a sentence with “I’m trying…” I think “I am making excuses.” That isn’t the case here; I am trying to address these issues so that my users will understand two things: 1) I appreciate their concerns. 2) I am not going to try to hide behind Microsoft’s poor response. I may not be able to make everything work on our mobile devices the way my mobile users want things to work, but I can meet them half-way. They have shown that they can wait for complete solutions, as long as they see progress – they simply are no longer willing to wait empty-handed. OK, so what am I doing? Well, today and tomorrow, I am solving a problem I didn’t know I had until a week ago.

One of the best solutions we built on SharePoint is a time tracking “system” for our attorneys. We were actually able to replace a fat-client desktop application with a series of related SharePoint lists. The attorneys like it (as much as anybody who has to record time likes a time tracking system). The accountants like it (as much as accountants ever like anything). We like it in IT because it helped prove that SharePoint can be used in a production data collection and reporting process. The problem? Last week, we gave the attorneys iPads. They love the iPads, but the Datasheet view they use doesn’t work on the iPad’s mobile browser. It seems that the “grid” view is one of those pesky things that still require Internet Explorer. We can’t make the Datasheet view work, but we can make an iPad view by using Data View Web Parts, that comes pretty close. Fortunately, we spent some time earlier this summer in the tutelage of Marc Anderson, so we’re no longer afraid of DVWPs.

The solution we came up is simple, but it achieves two key goals: 1) Using this simple web part page, our users are able to enter their time, from their iPad while enjoying almost the same experience they do on their laptop. 2) Building this solution this quickly sends the message that we care. What? Since when does an IT shop have to care? I happen to think that if you don’t care, you won’t be their IT shop for long.

If you can stand one more set of two things, I want to get back to James Watson’s post. He says that mobile access “is not browser-based access from a mobile device.” He’s right, but that gets to be a tricky objective when the content you’re trying to access is in SharePoint. Browser-based certainly should be OK for SharePoint, but I can’t tell my users that “you have to carry your laptop, because SharePoint doesn’t work in a mobile browser.” We are working on a two-pronged attack. The first attack vector is what I’ve talked about here, making SharePoint work in a mobile browser for solutions that have to be in SharePoint. The second vector is building iOS apps. Later this week, we will be distributing our first iPhone app. The functionality of the app could have been built in SharePoint, but the app is a better delivery mechanism. Hopefully, our users get the message.



#sharepoint #mobile #dataviewwebpart #datasheetview #iPad #iOS #SharePoint #iphone
0 comments
109 views