Transcript

[00:00:00.00]

Let’s take a look at how we put a site together in SharePoint that’s optimized for consumption by the iPad.

First we just start with a regular Team Site. The site at first has nothing that special about it, which is great because we can start with something we already know.

We’ve created a couple reports in this report library.

[00:00:30.11]

This first report is a report built on US Government data that dealt with “Cash for Clunkers” trade-ins. This is built with SQL Server Reporting Services using ReportBuilder. The data set is partially Analysis Services (cubes), and partially SQL Server relational data.

What this report is telling us is state-by-state how may cars were traded in under the program. We can see 76,740 cars in California; 36,835 in New York and only 592 in Wyoming. There’s a chart on the bottom that shows by brand what kind of car the person who traded in a car actually purchased.

We can see Toyota is #1, while Chevrolet and Ford were close to second (along with Honda).

[00:01:27.24]

This report also has a drill-through capability using a linked report. As we click on Illinois, we drill through and see county-by-county what the trade-ins were in Illinois, and within the state of Illinois what brands were most popular.

This format isn’t that great for an iPad, because we have all this navigation, which is really hard to hit with a finger, as are the bread crumbs.

[00:02:03.19]

To make this experience work better for the iPad we’ve created a web part page that we embedded the report in. The user doesn’t have to go to a document library and drill-through; he can just click on a link on the menu at the top. But we also have scrolling that we’ll take care of in a moment.

[00:02:25.27]

This looks a little better. Still we have ribbons that aren’t going to work well on an iPad anyway, so to clean this up and make the overall experience look more like what an iPad user is accustomed to, we’ve created a custom master page. Now a master page in SharePoint (if you’re not familiar with it) is just a template that defines layout: what the fonts are, what the colors are, where the ribbons are placed and so on.

[00:03:00.28]

Normally when you’re working with SharePoint out of the box you don’t really know that much about Master Pages. But if you want to customize the UI, you have to develop your own master page. We’ve done that already for this solution, and I’ll just show you briefly what it looks like in SharePoint Designer.

[00:03:20.20]

Here I’m looking at the “Demo Sites” site collection where I put the master page. If I look at the catalogs folder in the Master Page Gallery, I have an iPad master page here.

A master page is a lot like a .NET page if you’ve ever edited that kind of thing. If I bring this up you can see this looks like a combination of HTML tags as well as CSS and .NET tags. This master page was created by modifying a standard one.

What we’ve done with this page is to add CSS to change paddings and colors and sizes to make the master page more usable by a finger. We also eliminated some of the “stuff” that’s on a standard master page.

One tip with master pages is you cannot delete anything in terms of placeholders. As you get rid of the content within placeholders, the placeholders need to stay. Typically we throw the empty placeholders into a hidden panel at the bottom of the page.

[00:04:42.27]

This is probably the most complex part of this solution, but it makes the output look a heck of a lot better for the iPad. To apply this master page to the site, go to Site Settings, into Master Page under Look and Feel, and change the system master page to the iPad template. This will apply this template to most of the pages in the site.

[00:05:26.25]

Then as I look at this CARS site, you can see that the look and feel is a lot like the iPad. It’s cohesive, it fits within the 1024×786 standard iPad dimensions. But everything works the same way. We didn’t’ have to customize the reports. We did customize the web part page to hide everything in the reporting services toolbar except for the “back” button.

The “back” button provides the iPad user a way to get in and out of the linked report.

[00:05:59.29]

That’s what it looks like on the desktop. Let’s see what it looks like on the iPad.

[00:06:11.21]

Within the iPad emulator we’re going to test how this site looks on an iPad device. After clicking the link on the iPad desktop to launch the site, we’ll be prompted for our username and password. This is my username and password within Active Directory.

After authenticating, we come to the site, and it looks the same as it did on the desktop. We can see it behaves just like any web site. And in fact we could interact with any part of the SharePoint site. The links get a little small, though, and that’s why we made this custom master page so when the user is dropped into the application (which should probably be the home page for this app), we can see that the presentation is sized appropriately; the links are the right size for fingers; and we’ve really gotten away from the concept of using a mouse, and we’re really tuning this for fingers.

[00:07:08.15]

So we can tap on a state, run the linked report, and look at what the count was in California, which is predominately Toyota, Honda and Nissan.

Then we can use the back button with our finger and go back to the top-level National map, and once were here tap on a state that might have a little more domestic consumption (Michigan).

[00:07:45.10]

So that’s how we build a SharePoint site using Reporting Services that looks and feels like an iPad. We haven’t used any very specific mobile skills; we’ve just paid attention to the design of how we layout master pages and reports and assets so that it makes sense and “feels” like an iPad application.

Category:

Mobile BI

2 Comments

  • Can we apply an ipad view only for selected reports? or having 1 report and 2 different views, one view for desktop and one view for ipad viewer – so two links in SharePoint with different view settings?

    • I’m not aware of an easy way to do this using SharePoint settings. I suppose you probably could use javascript to detect the client browser or resolution and manipulate the DOM directly, but it would be painful.

Comments are closed.