The overwhelming trend in mobile device adoption has changed the way a law firm's stakeholders expect to consume content. This exclusive one-hour webinar will provide an in-depth look, with case studies, at the advantages and disadvantages of engineering custom native apps, web-based apps, ebooks, microsites and responsively designed websites.

A conversation with:

Jaron Rubenstein, Founder and President
Rubenstein Technology Group

George Sanchez, Director of Business Development
Rubenstein Technology Group

Send questions or comments via twitter to @RubensteinTech and #RubyLaw before, during, and after the webinar.

Video Transcription

Jaron: Thank you for participating today. We have a great presentation planned, lots of hands-on demos and some actual case studies to show you some of the options available to you in the mobile space, in the mobile technology space. Now there will be an overview of the hour we have planned for today, we're gonna start with just a few slides on the "Growth in Mobile." I think it's pretty clear to everyone that mobile is on the rise, we'll show you some specific charts that relate to that. We're gonna talk about "Types of Mobile Initiatives." This will be the lion's share of the presentation today, to talk about a number of different web technologies from native apps, to responsive web design to ebooks and everything in-between to really give you that introduction to, "What are the options out there?"

That's really the goal of today, of the webinar today, is really to show where we are with mobile utilization growth, what technologies are out there, pros and cons of each and how to think about a mobile project going forward. That's a question we're asked most frequently by our clients and prospects. We'll talk a little bit about what the actual process is, we've got a few slides on that, I think it's important to start thinking about it from the right perspective, and we'll go through that, and then perhaps in the future we'll delve into that further in a future webinar. And then we'll hopefully have some time at the end for questions and discussion, so all along, if you have any questions, please send them via the WebEx chat to George Sanchez. Don't send them to me, send them to George, he'll be reviewing them and he'll chime in throughout the presentation as necessary or we'll save some of the more in-depth questions for the end. So that's what he have planned for the day today.

Growth in mobile

So we'll start with "Growth in Mobile." What's going on in mobile space and where are we? So the current, some of you remember the PalmPilot era, but there was a bit of a dip after that and the current mobile environment really started in 2007, I think it was July 2007 with the launch of the App Store for iPhone. The iPhone came out earlier that year and that's really when the market heated up for apps. We've been involved since that day, we actually had an App in the original App Store. I think there was something like a thousand Apps in July 2012 and we had one of them. And then over the years we've basically been, obviously, continuing to evolve and stick with the landscape, moving from iPhone to iPad to Android and everything in-between.

So "Growth in Mobile," and what we have here is a chart, which is "World-wide Smartphone Sales." And as you can see from this chart, this is really showing the era from 2007 to today, you have the early adopters and really around 2010, when Android came out on the market you saw an even greater spike. Nowadays the corporate executives typically have at least one smartphone, often they have two, and these days iOS and Android are by far at the head of that pack, you can see that from that chart. And these are world-wide sales, so of course some people have multiple devices, some people have been upgrading etc. The source of this is a Gartner report. And then what also happened is, as the platforms have taken off and as the device makers have evolved their offerings you'll see that really the market share these days is owned primarily by Samsung, which is Android devices, and Apple, which are iOS devices. Nokia and RIM have more or less been casualties to that innovation and while there's obviously lots of RIM devices out there, but in terms of market share it's really gone down quite a bit over the past two years in particular.

The state of Apps today

And then of course the next most important factor to consider is Apps. So what's going on with Apps out there? And this is a great chart because it doesn't just talk about iOS or Android, it's really all mobile App downloads from all stores. And you can see that over 2011, 2012, those numbers were pretty high, I mean, I think it was somewhere around 20 billion in 2011, on up to 50 in 2012 and then it's approaching 100 in 2013. And then the rest are projections through the rest of 2013 and into the next few years. So you'll also see that the lion's share of Apps are still free downloads. There's still free Apps that are available to anyone, no cost involved. And that's an interesting aspect of the process as well. If you start to break down, we're not gonna show any more charts to this regard because this really isn't a data analysis call, but if you start to dig into it you may have heard that iOS users are by far the more lucrative users on mobile platforms, so they're more likely to spend a lot more on Apps over the course of the year than other users, than Android users certainly, I think it's something like a 2:1 or 3:1 ratio. And you see that essentially the market is primarily Apps for these two devices.

Everybody has a Blackberry

The next thing I want to talk about is what I'm calling today, "EHABB Syndrome: Everybody Has A BlackBerry." So the first thing that everyone thinks about when they think about mobile is, all of the attorneys at our firm have BlackBerrys, General Counsel and our clients have BlackBerrys, everyone's on BlackBerry in corporate America. And fortunately or unfortunately, that's true. You saw that chart on RIM's market share as of late but by and large people do have BlackBerrys, but I think it's important to note a couple of really important things related to that, and the reason that there aren't very many Apps on the BlackBerry.

The first is that corporate devices usually block App installations, so most firms that we speak to, clients and prospects, their IT departments lock down those BlackBerrys so that Apps can't be installed because it's a security risk to them, it's a concern for the security of the devices that they're allowing their employees. And there's also some concern about, you know, employees downloading inappropriate Apps or Apps that are for leisure and not work etc. So most corporate devices are actually locked down, don't allow Apps.

Bring your own device

The other factor which is even more prevalent of the past couple of years is, "Bring Your Own Device" or BYOD. And this is, if you do a Google search for BYOD you'll get just a ton of very interesting articles written by everyone from CIOs on down about how prevalent this is. It's a real challenge for most IT departments but most IT departments don't really have a choice because users are bringing the devices anyway. What this means is that many corporate employees have both a BlackBerry that's company issued and an iPhone or an Android. Many, many attorneys and many firms have iPads. I don't have an exact stat but some of the numbers that we've heard from our clients are approaching 50% or more of their partners will have iPads. And so the devices are out there, they're being used, they're being brought in whether it's in a firm or in your client firms. Client organizations, it's out there, it's being used. 82% of companies are planning to allow or have or are planning to allow some or all workers to use employee-owned devices. And that's actually, I think, from an Intel research study earlier this year.

So BlackBerry, while it's prevalent, it's not the most functional device, and we're not gonna talk much about BlackBerry Apps today, although some of the solutions that we're talking about will actually work on BlackBerry and we have done BlackBerry compatible solutions, so you should be aware of that. Alright, so let's get into the mobile technologies. This is really the target of the day today, and it's where we're gonna spend a lion's share of the time, so I'm gonna jump right in. The three technologies we're gonna talk about are Apps, websites for mobile users and eBooks. I didn't say mobile websites because that kind of confuses things, but we'll talk a little bit about what that means and why there's a difference.

Where are apps found?

So Apps, where are we with Apps and what are Apps? When someone talks about an App, the two definitions is that it's really a compiled software application, it's usually distributed via the App Store and there are a lot of different App Stores out there, so when people say "the App Store" they're often referring to the Apple iTunes App Store, but Android has an App store called Google Play, Amazon have an App store for Android called the Amazon App store for Android, and there are lots of other App stores out there.

Android has a more open ecosystem as you may have heard, so Google Play has their own Google-based Android App store but then there's Amazon and others as well. So there's different choices there. So you've got iTunes, you've got the Android App stores and then the other devices have App stores as well, so Microsoft has an App store, BlackBerry has an App store etc.

The idea is to be, the point of the App stores is that it's a central repository for these Apps. In the case of Apple, the only place you can get an iOS App is via the App Store, for a public user. There are enterprise options, for enterprise distribution, but when I'm talking about the general public you have to go to the App Store. With Android you can actually get emailed an App, you don't actually need to go to an App store to get an App, so it's a slight differentiation there on those two platforms. The benefits of that, that there is this repository, there's this place where users are going on a daily basis looking for Apps. Maybe they're in the middle of a commute, maybe they're looking for a specific resource, maybe a friend told them about the App. There's a hundred ways the marketing is happening but the gist is that there's a centralized place you can go to find Apps, to look for Apps, and that's a big benefit.

In the early days when there were less Apps in the App Store it was actually a real bonus for firms because if you put an App up there was a pretty good chance that someone would stumble upon it, these days it's a lot less likely and you really need to promote it. We'll talk a little bit about that later. But you can do public distribution, which means the entire general public can access the App. You can do limited enterprise distribution which essentially means that you're somehow restricting it to just the users of your enterprise. We're not gonna get into the complexities and drawbacks and pros and cons of that today but just know that there are those two options for distribution.

Also know there's free and paid distribution models, so what that means is you can make your Apps available for free download or you can charge for them. For marketing purposes, typically speaking, most firms are providing Apps for free because obviously they want that user engagement with the mobile users. But if you've got some specialized content where there's a significant value there, you can charge 99 cents, you can charge $10, you can charge $200 for an App if it's appropriate to your user base so just something to keep in mind depending on what you're trying to publish.

So App dev tools, this is as technical we're gonna get in this presentation today in terms of actual coding and technology. But it's just good for you to know that in iOS the native coding stack is Xcode which is really written in Objective-C as the programming language. Android's a completely different SDK, completely different language, it's called the Android SDK, and the language that Android Apps are generally written in is Java for native Apps. There's also a concept of multi-platform Apps and those are Apps that are really written by other technologies other than those two above.

So often those technologies might be the Ruby program language, it might be JavaScript, it might be a proprietary language specific to the platform. But there are several other multi-platform Apps that provide that level of cross-platform support while not requiring you to necessarily know Objective-C or Java or drill down to those engines. And those all have pros and cons and we'll talk a little bit about that in the coming slides.

So what are the benefits of an App? These days there's a lot of different kinds of methods we're gonna talk about, native Apps are by far the most complex to build and so there needs to be a justification. Why are we spending additional time and effort and budget to develop a real native App? These are the main reasons why you need a native App. So the first is offline access and data storage. Meaning, if you have an App that has some sort of content in it and you want that content to be accessible when there's no internet access. In other words when there's no 3G signal or there's a weak cell signal or the user's on a plane without WiFi or underground in a subway etc. If you want that content available in that offline fashion, you pretty much need an App because an App is able to store content locally on the device. Very key part of an App functionality.

The second is notifications, so many of you have social media Apps and other Apps that have notifications associated with them. So for example, if you were signed into Facebook or LinkedIn you'll get social media updates. Almost looks like a text message on most of those devices, and those are really called notifications and in order to get notifications you actually have to have an App that registers for those notifications, accepts the privileges and then receives them when they're sent from a server. So if you want notifications you need an App.

Background processing, another one. Most of the content-based Apps that we're building for the B2B market don't really have a need for background processing but if you have an App where it has to do something when you're not using it, in other words you think your phone's off and you're using something else but the Apps gotta go and fetch updates or do something in the background, you need an App for that. If you want to access things like contacts in the address book or photos in the photo stream, you need an App. If you wanna use hardware, low level aspects of the hardware device like the Accelerometer or GeoLocation GPS that kind of thing, there are methods that you can do that without an App these days but more or less you need an App to get really low level with that.

And then finally a fluid user experience. So with a lot of content-based Apps this is not as big of an issue. If you're building an App that has a more video aspect or a game aspect or that kind of thing where there has to be a very fluid user experience, very polished transitions and animations and that sort of thing, you need to get down to the low level hardware. And at a certain level you can do that without an App, but then you need an App.

So again, many of these options are slowly over time being exposed to non-native Apps. So some of these things are slowly over time becoming less true but it's important to consider these are the main reasons why you use an App. Native App types, as I mentioned before, there's really two divisions of that. You can have a truly native App which is what we were talking about before in Java or Objective-C and that's separate code for each target platform. And then you can have a multi-platform App which is essentially, so you have a single codebase but multiple targets. It's better for ongoing maintenance and efficiency.

Some of the benefits of native Apps, and you're gonna see slides like this for each of the types of mobile technologies we're gonna talk about today, so you can get a real top level view of what the benefits and drawbacks are of the Apps or of the options. So the benefits, I talked about the App Store, I talked about that low level hardware access, talked about the speed of the user interface, the speed of the experience, that can be important to some designs. The offline access and the data storage are two big ones as well. So the one thing I didn't mention about data storage is that you could have an App that you want to record notes related to news stories or you want to have the user to be able to flag the lawyers at your firm that they're working with and add them to a group that's somehow specialized within the App. So things like that require an App as well.

But there's a benefit because you can store lots and lots of data, lots of content, videos etc. all offline. The drawbacks are that each platform must be supported separately, unless you go with a multi-platform app, you're talking about having a completely separate codebase for Android, completely separate codebase for iOS, so if you do wanna support multiple platforms you have to kind of keep that in mind, there's a good amount of effort involved in doing that.

You have to worry about the App store management submission process, this is always the top concern from clients that are planning to launch an App, is they want to know what's the process, how long is it going to take, that sort of thing. If you're not familiar with this, the concept is that in order to put your App in the Apple iTunes App Store it needs to be submitted for review and approval. Apple actually opens, they use the app, they confirm that it doesn't violate any of their many many many guidelines. Then they will reject it and they often do reject if it violates any of that and so very important that if you're doing an App, you work with an experienced developer that's actually done this before, that's dealt with both the acceptances and the rejections, that knows what Apple's looking for, it's going to streamline the process.

Equally as important is the concept that Apple takes anywhere from a few days to two weeks, generally speaking, to perform that review. So you need to account for that in your timeline for your project, you need to know that at the end you've got two weeks where the App has to be completely done, before it goes live Apple has to review and then approve it. If they reject for whatever reason, you have to go back, make whatever changes they requested and then re-submit and go through another process which can take another few days to a couple of weeks.

So it's just important that if you're doing something, if you're doing media buys around an App or advertising or any of that sort of thing, you need to build that into your timeline. The same thing goes for updates and fixes, so if you have an update for an App, let's say there's a bug that was found or there's an update that you wanna add some functionality, it has to go back through that review process. The update review process seems to be a little bit quicker than the initial submission, but we still encourage clients to allow for two weeks for that process to go through.

And then finally, this is real software, a native App is a real application, just like Microsoft Word on your desktop and Outlook are real applications, an App is a real software App and so there's a software lifecycle behind that. You have to consider ongoing maintenance, you have to consider the long-term. So, you launch the App today, next month Android 7 comes out and iOS 8 comes out, you need to support that. You know, Samsung releases yet another device with another form factor, this one's six feet by seven feet in dimension and you need to update your App to support that. And it's not usually a quick process, it could be a week of work, could be a couple of weeks of work, and then you've gotta go back through the release cycle. So something to keep in mind is that long-term prospect.

First multi-function app for an Am 100 Law firm

We're gonna show you a case study real quick to get off the slides for a second. We're actually gonna show you a couple of screenshots of the MoFo2Go app. The MoFo2Go App was launched a few years ago now. It was the first multi-function App deployed for an Am Law 100 firm and it was the winner of the B2B magazine award for Best Branded App that year that it launched. And it's backed by the RubyLaw Content Management System, so just something to keep in mind is that a lot of these Apps that are content-heavy may have a CMS behind them, they may have a content management system where a marketing team, a non-technical team can go in and actually edit content, update stories, add videos, things like that.

So MoFo2Go features that, I'm going to just show you... a couple of quick slides here of the MoFo2Go app. OK. So originally it was launched iPhone only, and then about a year later we did a version two that supports iPad as well, so what you see here is the major functions of this App are People, News, Locations, Events, Video and Play. The App is available on the App Store and if you have an iPhone or iPad I definitely encourage you to download it and check it out. And this is something that gets some great experience to... Again, it was really, in a lot of ways it set the bar for what a firm-wide App should be and should look like and how it should function. I'm just gonna show you a couple of screens of the App today, 'cause again you can download and check it out on your own, but this is an example of the news section, you can see a MoFo tech article which is Morrison & Foerster's tech publication, award-winning tech publication I should mention. And the App allows you to actually have as many MoFo tech articles as you want. Those all get managed by the CMS system and you can see these synopsis, these updates... previews or abstracts about the content and then you can actually click to see the full article via an in-App browser.

So it essentially allows you to experience the content, to search for it, sort it, you can make notes on it, that's actually another interesting feature of this App, is those little notes buttons, you can add and edit notes on a particular alert or case study or any kind of news update you get within the App. The other features are Locations, it integrates with the mapping system and with the GPS so that you can actually geolocate to the nearest MoFo office, you can find points of interest around that office, so for example, hotels and restaurants, transportation options that sort of thing. And all that content is, again, managed via the CMS. A lot of the content on the App is actually pulled dynamically from their legacy website CMS which is not a RubyLaw system and it's important to note that that's another feature of a lot of these Apps, is that they can pull content and re-purpose it and publish it in a new way without necessarily requiring marketing resources to do that. So that's all automated, it happens automatically via the system, via the CMS integration and it's really an amazing opportunity to publish content in a new medium for users who are on mobile and really give them an optimized experience. And then finally, MoFo2Go features a game, MoFo Maze. And this is another example of something that we did that required hardware integration, why this had to be an App. So MoFo Maze is a labyrinth kind of game where you can actually use the device and you can tilt it to the left and to the right and the marble will roll around that screen. So it uses the Accelerometer based into the iOS devices, iPhones and iPads. And it's an interesting game, it's a fun challenge there's a number of boards, they get harder as they go.

Why would a law firm need an app?

A lot of people ask, well why is there an App in a law firm App? And the reason is that, there's a number of reasons, but the main one is really that we were looking for a way to engage users in the brand, to let them experience the MoFo brand and to keep them coming back to the App for a number of different reasons. So the App has alerts where if a new news story gets posted, you get a little red bubble and the number increases on the App so they'll come back to view a news story. Maybe they like the game and they wanna come back and check out the game and while they're there, they take a look at intellectual property, attorneys at the firm etc. So it was really just a way to get people to come back to the App and to provide additional value for users, to get them over the download hump and we'll talk about that in a little bit.

Back to the presentation, next we're gonna talk about multi-platform Apps. Multi-platform Apps are really native Apps that share common codebase across multiple target platforms. Most Apps these days that are going to support multiple devices, in other words you're planning on supporting iPhone and Android, are built as multi-platform Apps because it allows you to use a more flexible development methodology that allows you to support those Apps much better. They're often a combination of native code and HTML5 technologies. They typically have a more generic user interface or design and that's really because, generally speaking, budgets don't allow for creating two separate designs. So you're not gonna create an iPhone specific design and an Android specific design, you're gonna create one design that's really gonna work well for users on both platforms. So it's a little less Apple focused or a little less Android design focused and a little more brand oriented, and that's actually an opportunity for a firm to further their own branding efforts. Again, it's really sort of a hybrid between native and WebApps, we'll talk about WebApps in a little bit. And they're common for B2B content-based apps because most content-based Apps don't need more deeper hardware integration than a multi-platform App can provide.

And so again the benefits here are that you get most of the benefits of native development, it certainly more easily supports both iOS and Android at the same time so you don't have to have two different projects, two different codebases in two different languages, you can use one system to support both. And because of that there's a reduced development effort to support multiple devices, multiple platforms. The drawbacks are, that the hardware access is a little bit limited, again, not really an issue for most content-based apps. You do still have to go through the submission process, it is still an App, it does live in the App store, you still have to submit it to Google Play and to iTunes. Just a quick side note I didn't mention earlier, but the Google Play App submission process is much much quicker, it generally takes a couple of hours. We tell clients to allow for 24 to 48 hours at the most. There's no review process, it's really just submitting it and then it needs to get distributed to the store. So it's a little bit different than the App Store for Apple.

And finally the drawbacks are, you are still dealing with multi-platform software development, so you do still have to test on all those devices. Something to keep in mind, those of you who do a lot of work on the web know that something can work absolutely perfectly beautifully in Internet Explorer 8 and not work at all in IE9 or not work at all for Safari users or Chrome users or Firefox users. So the problems on the mobile area are even greater, I mean, you have the scenario where you might have something that works really fine on half of the Android devices on version 4 but not on version 3, it doesn't work on version 2.3, Android comes out with a new operating system and things break. The other thing to keep in mind is iPhone, you now have six or eight different devices you need to consider supporting, depending on how far back you want to go. With Android the number's more like 60. There's so many different devices, device sizes, device manufacturers, versions of Android. So there's a lot of testing that needs to happen and you do need to keep that in mind if you're going to have an App that supports multiple platforms.

Case studies, this, I'm actually going to show you just really quickly another App we did for Morrison & Foerster, they've really been on the edge of mobile development over the past few years. It's an App called the MoFo Sexual Harassment Workplace Bullying Guide or Advance@Work. It supports iPhone and iPad at this point and there is Android support possible in the future. The idea behind this App was really that there was content available in this area and one of the partners in the firm, this is really another good example also of a practice specific App, in that, sorry just give me a second here, it's a practice specific App in that it really focuses on a particular practice at Morrison & Foerster. Really niche or focused on sexual harassment in the workplace, bullying training, and this App features quite a few things in it.

The main thing is the main menu allows you to view content about sexual harassment training for the federal government, for each of the states. All of this content is backed by the RubyLaw CMS, it gets updated as it gets updated by the constituencies so that you really can use this App as a reference for the most current information about sexual harassment training requirements. There's also a section on workplace bullying which talks again about some specific areas of the law and provides some interviews and related information about that topic which is obviously very hot now in HR and finance companies. It features also videos, I'm not going to go too far into this but this has support for video as well so you can actually see selected videos that this partner has created. You can view them in the App and view a number of different videos on the iPhone and iPad.

George: Surveys. Oh sorry, do you want to talk surveys? You can also do surveys.

Jaron: And finally yeah, there are a few surveys that are featured in the App. So this is actually version two, the first version of this App launched about a year ago. Version two supports a number of things that the first version didn't, video is one of them and also surveys. So you can actually, they featured a number of surveys that the firm is promoting as ways to just basically gather information about workplace bullying and also job burnout. And those are two surveys that are available through the App that you can take and help them to gather this information, they'll be providing some very useful reporting around those things in the future. There's information about the partner, the partner bio for Sharon Parella as well as information about the firm MoFo. And this App is also on the App Store, it's a public App, it's a free App and I encourage you to go onto the iTunes App Store if you have an iPhone or an iPad and download it and check it out yourself. And then just finally one last thing is that there's also a Twitter feed that's integrated in the App, so they recently moved to social media for this campaign and that Twitter feed is always present in the App as well. So it's another feature that allows them to promote the App and it's also to engage their users and provide a useful reference to those in this space. And then there's another App that we're working on for a firm that we can't show yet, it hasn't launched yet, but the key there is alerts functionality.

So I mentioned before, the fact that if you have a native App or a multi-platform App, you can access the notifications part of the system. So the idea here is that it's a very hot area of legal action, there's constantly being updates that are happening and there are some key decisions that are going to be occurring in the coming months in this industry and they really want to set up a channel for engaging their distant clients and prospects that are working in this area of the financial services sector. So what we've done is, we worked with them to come up with a solution where it has a lot of the same content that I shared with the Morrison & Foerster Advance@Work App, but it essentially also incorporates the ability to send alerts, so when an alert that's relevant to the industry is created in the CMS system, it can get pushed up and pushed out through the RubyLaw solution to all of those users. So anyone who has the App will get an alert, it looks like an SMS message, it'll alert them to what just happened, what regulation passed, what major ruling came down and then they can click to open the App and see the actual detail. So that's something that you don't get with a website. E-mail is an old school medium for handling that, not every client's on Twitter, but a lot of them have iPhones and iPads, especially in the sector that this particular App is focusing on. So it's a great example of how they've leveraged that hardware and that technology and really technology strategy along with marketing strategy to figure out how to promote that.

Mobile websites

We'll talk a little bit about mobile websites, and essentially there's three types of mobile websites that we're gonna talk about. We're gonna talk about compatible versus optimized, we'll talk about responsive web design and we're gonna talk about Web Apps. First of all, compatible vs optimized, so most firms these days have a mobile compatible website, meaning if you open up the site, it works on the iPhone, it works on the iPad, it works on the Android. It looks just like it does on the web. It might be a little small, it might be a little hard to navigate, you might have to pinch and zoom, and that kind of thing but it's functional. And that's what we talk about when we talk about mobile compatible. When we talk about mobile optimized, what we're really talking about is a site that is optimized for that size screen, it's optimized for that user experience.

So it might have a completely different layout, it might have completely different buttons, there might be just really focused information, I know for a while some firms were providing a mobile optimized site that only provided information about their offices. with the idea that most users are probably just looking for their office information via mobile phone. So there's different ways you can optimize for that experience.

A mobile compatible App is multi-platform, it generally has the full site content visible and usable on most mobile devices. And it really uses common technologies and experience, so users are used to this now, it's been three, four or five years since most sites have become mobile compatible, not really a big thing. It used to be the table stakes for any amount of websites, it's not any longer but it used to be, a year ago, we were telling clients, maybe two years ago, telling clients, you gotta at least be compatible, you can't build a site that's not mobile compatible. The drawbacks are, you do have a diminished user experience, because that might require pinching and zooming, it might not be optimal, but at least it works. And it does require internet access unlike a native App.

A couple of quick case studies are, I'm actually gonna show you Akin Gump, which is a site that we launched just earlier this year and essentially it is fully functional and what I'm showing you here is an iOS simulator, so this is actually the version of the iPad that you would see if you were using an iPad in front of you. So it's a software application that simulates the iPad and iPhone. So what we're looking at here is this what the Akin Gump site looks like on the iPad. I'm not gonna actually go into the iPhone as well but it just is that you can zoom and you can pinch, you can do that sort of thing, but essentially it works, it's very functional, it's user friendly and we can actually see content here. Sorry my demo isn't working right now, you can click and actually see what a page would look like, but it's not necessarily fully structured for that device. OK. I'm gonna move on because we're running a little late on schedule here.

So mobile optimized is really the next step, so next step is it's basically multi-platform, its full site content is visible and usable on most devices and it's a common technology experience but it's really optimized for those experiences. The drawbacks are, historically, a poor responsive web design which is typically implemented as a separate user experience or separate layouts, so there was a mobile site, mobile version of the user site. It's really no longer the best practice, unless it's responsive and it does require internet access, so that's something else to keep in mind. And just really quickly I am going to show you an example of that and CNN is actually a great example of that.

So this is what CNN looks like on the iPad, it's very similar to what you see on the desktop, but on the iPhone, now I've switched to emulated iPhone mode so you can see what that looks like, you'll see that... the CNN site actually changed to a completely different layout than what you see on a desktop. So you see it's just showing latest news, showing a few key links in the US etc. and you can scroll but it's a completely different design than what you saw on the homepage and this is a great example of mobile optimization in the way that they've done that. So CNN and then Facebook's another one, I'm not going to go through that but some of you have probably used Facebook on your mobile browser versus Facebook the App. They have both and many sites do, CNN has an App as well as a mobile optimized site. So the Facebook experience on the iPhone is another example of a mobile optimized experience. Responsive web design is really the, it's the relatively new kid on the block, but it's really what most firms are considering table stakes for their initiatives, whether it be a website or a new blog or a new microsite.

The idea is that all visitors, whether they're on desktop or a tablet or a phone, a mobile device, get the same content and code, they get HTML and they get CSS, the same HTML and CSS that the desktop users get. But that design and that technology is designed to adapt to the visitor's view. So if their browser's 1024 pixels wide or if it's 480 pixels wide or 768 pixels wide, whatever the width or height of the browser window are, the content will automatically adapt to that view. Maybe the text gets larger, maybe unnecessary content like a slide show drops off on a mobile device but you still see the top news stories, that sort of thing. It really targets the screen  size, not the OS device and because of that it allows you to adapt to future devices and screens. So for example, today there's a set of devices that we know about that are out in the marketplace but we don't know what's going to come out  two years from now. So a responsive web design helps to ensure that all these future devices can be supported and targeted in an effective way. Just some of the benefits are, it is mobile optimized, it's often multi-platform, it's really the best strategy for future device support and it allows for single sourced content. So a lot of mobile optimized sites have a separate CMS or a separate section of their CMS to support that mobile content, with a responsive web design site, you generally have one set of content you're supporting, one set of content you're updating and it works across everything.

The drawbacks are, it does require developer experience and extensive testing, so because responsive is so new, the experience out there for the teams that have done it is not that widespread. So you really should work with a team that has done it before, done it a number of times before, because there's a lot of lessons to be learned as far as how to manage it most appropriately across the devices and associated with that is extensive testing. So like I was saying before, if you have a... If you're supporting iPhone and Android and BlackBerry and Windows phone, you need to test that on all those devices. You test on all the versions you're gonna support, you need to test on all the sizes you're going to  support etc. So it can be time and budget intensive because of that. It's generally a sizable chunk to a based on web project. It really must be designed, you really are best with a designer that's done a responsive design before because of the way these layouts have to adapt from template to template and screen size to screen size, it takes a lot of design thinking as well. And it requires internet access unlike an App, it is really just a website.

So just a couple of case studies, I'm only going to show you the first one now, UBS Neo is a project that we did for UBS, it's essentially a microsite about a product they have called Neo and you can check that out on your own but essentially it's a responsive website, responsive web design for a microsite. I'm gonna show you Winston & Strawn because that's a site that we launched just a couple of months ago now. And it is a fully responsive website, it supports iPhone, iPad, Android, large scale, small scale devices. What you're seeing here is this is how the site looks on an iPhone, so you can see that you can actually scroll it, you can keep scrolling, it has animation built-in, it basically resizes that screen and makes it functional on an iPhone device. I'm just gonna flip over here and show you in the browser, this is what it actually looks like in a browser. So you'll see that it's a lot more spacious, a lot more built  out, the layout's are a little bit different, you'll see that there's a search, there's an animation, these circles here in this design are actually horizontally orientated but if you look back at that iPhone version you'll see that they've actually stacked up on each other. So there's a lot of ways that you basically re-layout content and adjust the content to have most of the same content in an effective way that really works and is readable on an iPhone. You don't have to pinch and zoom, you don't have to play around with it, it just works and it's an optimized experience. And that's really what responsive is all about and that's why most sites these days are moving towards that design.

WebApps

And now WebApps, so no discussion of Apps would be complete without talking a little bit about WebApps. And a WebApp is really a browser-based App that's built using HTML 5 and JavaScript technologies. So it's really a hybrid between a website and an App. It's not native, it's often multi-platform but it's not always multi-platform and it's not an App-per-se, which means that it's not in the App Store. You can't create a WebApp and release it to the App Store. You can't tell clients to go to the App Store and search for your firm or search for your practice name and have it show up, because it's not gonna be in the App Store. What you have to do is send them to a URL, to a WebApp address, "So you go to this address and you'll have our WebApp."

So it's a slightly diminished marketing message, but the capabilities of a WebApp are much greater in that they're a lot more flexible, you can still have an icon on the Home or Menu screen if the user creates one and it's hosted on a web server so that it is a more flexible environment, it's using technologies that a lot of teams are much more experienced with. It's a lot more like a website than a native App. Again, it's multi-platform, it's generally faster and easier to develop and maintain. There's no App Store bureaucracy because you don't have to submit anything to the App Store. It is difficult, this should actually be a drawback, it's in the wrong column, it's difficult to charge WebApp visitors, so what that means is if you have content that you do want to charge for, it's a website so you have to start asking them for credit cards and things like that, and that can get clunky and the barrier to entry is pretty high for most users for that. But it can be secured internally or externally via authentication, that's definitely a benefit if you have content that you don't want the whole world to have access to, if you want it to be limited to selected clients, to a selected industry or just within the firm, you can secure it in a way that Apps don't make as easy.

Again the drawbacks are that it's not in App Store, there's no long-term storage, you have very limited access to device hardware. There's no DRM, digital rights management, this is more of a concern for some CIOs than anyone else, but it's a whole other conversation. And it does require internet access, generally speaking, meaning there are ways to cache things in a WebApp but generally speaking you really need to have internet access to access it. And what I'm gonna do is I'm just gonna show you really quickly a Financial Times App, and I'm gonna show you a couple of screens from a partner App that we worked on. So... the Financial Times App is actually a great example of a WebApp, it actually has an icon which I created ahead of the webinar today, you can click it and you'll see when I first load it, remember I'm on the iPhone version now, you saw it loaded a little bit. It requires internet access, it's actually going off on the internet and it's showing me content. It really feels like an App. It looks like an App, it feels like an App, there's buttons down the bottom, I can click into Sections and look at different sections of Financial Times but this is actually all web-based. And it's an important differentiation from a technical perspective, there are some pros and cons to that approach but it is another way for you to develop an App and launch it with technologies that are possibly available to you already.

And then the next I'm going to show you is a Partner Meeting App that we built for a firm. This is actually... So what we're showing here is... just a couple of screens from a Partner Meeting App we built for a firm, it had been white-labeled for the presentation, this isn't something that we're allowed to share publicly, with specific firm data because there's some proprietary information involved. But the idea is that essentially the firm came to us to build an App for their annual Partner Meeting and that's what we've done in this demo. What you're seeing here is just essentially the screens for, this is the iPad version, what it would look like on the iPad, it works for both orientations, so it automatically reorients itself when you're looking at a horizontal view. You can see lots of great content, great visuals, it was really engaging for the partners at the firm when they got this App and it got really record reviews for the usability and the efficiency of the App.

In order to make it more valuable we also built it as a responsive web design WebApp which means that it's equally functional on a desktop as it is on the iPad and iPhone and Android. So what you're seeing here is just the desktop version on a monitor. It works on the iPhone as well, it automatically reorients itself and basically provides that content in an optimal fashion no mater what device you're using. And it scrolls, so what we're showing you here is if you scroll down you'd see the content below. This is a landscape version of that same content. You'll see that for this particular App, there's a meeting schedule so if you look in the design and the user interface you'll see it really looks like an App, it's really built like an App, it functions like an App. And you tap on things so they slide around and they animate and they reorient and that's the point of a good WebApp. There's a "Year In Review" we did for them here, you can actually track the partners that you met at the firm and have sort of a live social media, etc. So I'm gonna move on but that's another example of a great WebApp and what you can do with that technology, it looks like an App, it feels like an App, but it's really a website.

The important aspect of that WebApp that I didn't mention is that because it's got proprietary content, they were able to secure it in a way that only partners in that firm could access that App. It's not in the App Store, the public can't have access to it, it was only distributed to those partners, they were authenticated and they had very restricted access to it. So it's a great way for them to share proprietary information with members of the firm without divulging any confidential information.

eBooks

And finally it brings us to eBooks, the last technology we're gonna talk about today. eBooks are based on an open eBook standard called EPUB. When people think about eBooks, sometimes they think about PDFs and that's a common way to distribute content on the web but for mobile devices EPUB is actually the format that is optimal. And it's optimal because the content itself can be posted in an App store. Every user can get an EPUB Reader for their device, it works on just about every supported device from a Windows phone to BlackBerry to iPhones or iPads, Androids, Android tablet, to etc. etc., and there's desktop readers as well. The content is downloadable from the App store and all the functionality of that reader, you get for free. Meaning you just have to provide the content, the reader provides functionality like bookmarking, search, highlighting, things like that. It automatically repaginates for supported devices and eBooks that you provide can be free or they can be paid. So you can distribute them as free informational resources or you can actually charge for them in the App stores.

So just quickly some of the benefits are, that they are optimized for reading a large amount of text on most any device. This is really important, if you what you really want to  do is publish 100 pages of proceedings or 100 pages of content, however important or unimportant it is, it's really content-heavy, it's not images, it's not interactive, it's not dynamic, an eBook may be the best venue for that. It supports the widest array of devices and you can actually not only distribute it via the App store but you can also distribute it directly, you can e-mail people eBook files for them to install on their devices, depending on devices it can be easy or hard, it's always easier to use the App store, but it's very functional. The drawbacks are, the complexity of the publishing are really tied to the document layout and the complexity of the content that you have. There's no CMS, so it's not ideal for frequent updates, it's really best for content that's only gonna change, you know, annually, if that, maybe less. There is still a complex submission process if you're gonna put it in the App store, plus each store has its own App store's own submission requirements, so you need to submit it to iTunes separately from submitting it to Google Play, separately from submitting it to Amazon Kindle eBook store, separate from the BlackBerry Bookstore or the Barnes & Noble NOOK store. So they all just kind of add up.

And finally, on this, complex content does require multi-platform testing, so if you're gonna support all these different devices you do still need to QA and test it on those devices. And the quick case study that I'm gonna show you today is again from Morrison & Foerster, a Capital Markets FAQ that we helped them to publish as an eBook, So they had an existing book, they were publishing it and sending it out to selected clients and prospects and they actually wanted to create an App but we talked about it and we decided an eBook would really be the better approach.

So if you go to this, this is actually the desktop Kindle version, but if you've never used an eBook I encourage you to check it out either using the bookstore App on iPhone or the appropriate eBook reader on Android or even a Kindle App which works on the Kindle as well as all of the other devices. You can do things on these devices like search and sort, you can see content, you can search for a particular thing, like if I'm looking for information about PIPEs you can see that, PIPEs (Private Investment in Public Equity), you can learn all about it, read about it, you can bookmark it, you can highlight it etc. Just really a functional way to get large amounts of content out. This is a couple hundred pages of content. And MoFo, this is available on all of those App stores I mentioned as an eBook, so you can download it an check it out. There is a small charge for it because of the value of the content but it's probably worth it to download and check out and see what you can do in that regard.

So we're gonna talk a little bit about process, I know we're coming really close to the end of our webinar here, but I want to go through just a couple of key things about process before we round out the call today. So first, what's the process? What do you do when you're looking to develop a mobile App, or a microsite, a responsive web design, any of these things? So really just high level, the first step is to define what you're looking for and we have a slide to talk a little bit about that. Then it needs to be designed, you need to have a designer who has preferably worked on these platforms before they do the actual design. It needs to be built, you need to launch it, and then you need to promote it. And this is really important, because the way people used to think about websites, where if you build it they will come, over time it turned out that they won't come and you need to market it, you need to promote it. And the same thing is true of Apps, so if the goal is to launch an App to get attention, to get marketing, get PR, there's a promotion effort that has to happen if you're gonna get those kinds of results and it's important to consider that in your plan. And then measure, there's lots of different way to measure, we'll talk about a couple of those things on the next slide.

So where do you start, how do you define this? The first most important thing to figure out is who your audience is. Are they internal or external? What are their demographics, what country are they in? What are their socioeconomic factors? What age are they most likely to be? What devices are they likely to have? Which you can usually figure out from those earlier questions. Are they going to  be reading your content on the train, on a plane, on a desk or on a golf course or all of the above? And again that's going to help you choose which of the prior technologies we talked about are good for that.

You want to think about your content, you really want to think through some use cases of how users are actually going to use the App and what content they're gonna read, what content they're gonna get and where they're gonna go with it. So think about that, you want to think about this, what's success for the project? So success can vary quite a bit from project to project and client to client. Success might be a number of downloads, it might be a number of active users, it might be press attention, it might be business leads and opportunities, it could be e-mail subscription sign-ups. It could be a sponsorship, you know, you're sponsoring an event and the App that goes along with the event and it's for their branding for your firm. Whatever it is, you want to define what that success looks like for the project up front.

You need to think about that content and how frequently it needs to be updated. Is it getting updated once a month, once a day, once an hour? That's of course gonna affect which direction you go with the App. You really need to think about value, there's a definite hurdle these days for downloading an App, so as I was saying before, when Apps were new, people would just go and check it out and download it. Now people are a little more hesitant, they need to think, "Oh, what value am I going to get out of this App to make it worth me clicking download?" It's still just a couple of button clicks but there's definitely that hurdle that you need to get over and the way you get over it is really with that perceived value. So you think about what value you can be providing to your user to encourage them to actually click that and download the App.

I mentioned promotion already and how important that is, you definitely wanna make sure that you have a promotional plan, whether it's a PR plan or an advertising plan, it should most definitely be promoted on your site as heavily as you can, etc. And then think about your timeline and budget of course, how long do you have to develop the App and what's a reasonable budget for it from a client? You know, from the business stakeholders in the project. You can do an App for, you can do a mobile initiative I should say, for $5,000, you can do it for $25,000, you can do it for $250,000, it really all depends on things like functionality, the content, which technologies you've choosed, etc. And so it's really important to think about, what is the sort of resources, what's the ballpark that you're thinking about and that can help to decide what technologies are able to deliver your marketing message.

And what else should you consider in that process? So I think it's really important to definitely think about your target audience. So you want to think about what operating systems you might need to support, what form factors? Are you supporting only smartphones, are you supporting tablets, are you supporting desktops? And even what devices, you know, I didn't talk about Retina at all today, but the Retina is the high resolution iPhone and iPad devices that are out there now. Do you need to support that for any reason, is that a consideration? You may not be able to answer these questions on your own, you may need a technology partner to help you figure, navigate some of this, but it's good to just start thinking about it in the the realm of, "What are we looking to do on mobile?"

What special features are you going to consider is important too, you really need something that's gonna give that App the unique value that cause users to return to it, tell their colleagues about it, spread it on social media etc. What's your team's appetite for complexity and really what are your resources for upkeep? And I mentioned before that there's a way that you can do an App which has current information that gets pulled off your website, it doesn't require additional work to support. So if you are going to develop an App like that, then that's great. If you have a team of marketers that are able to help update custom content for the mobile audience on a regular basis and your audience requires that or would benefit from that then that's something you should plan for and consider when you're considering what the options are in mobile. So that's really the key considerations there at this stage in the game.

So finally, I wanna share a couple of final thoughts before we go into Q&A and I know we're right about at the time here but the real concept is, the future is here, mobile is overtaking the desktop. I didn't show you that chart but you've probably seen it elsewhere. There's no shortage of mobile users and really the whole idea of content, marketing in general and content marketing these days has to do with, how do you you provide the content that your users are looking for in the mode that they prefer to receive it in? And mobile happens to be a growing mode that clients and prospective clients and clients of the firm perceive it in.

An "App" is often the question, it's usually the question, usually clients or prospects will come to us asking for an App, but it's really not always the answer. And that's why we wanted to show you all these other options out there because there's a lot of different ways that you can approach a mobile initiative. Keep in mind that mobile development is not web development. It's very very different, you definitely want to work with designers and developers and teams that know the mobile space and have worked it in before that have the devices ready to QA and test on and that have that experience, whoever you work with, because it's definitely a critical part of a successful project.

And just keep in mind that really every mobile initiative starts with a conversation and that's really because of the complexity, the inherent  complexity, in all of these options out there. So you may be thinking based on this presentation that a eBook is right for you, or a WebApp is right for you, but then upon further conversation there may be some reason that another choice is better, maybe a native App really was the best choice or maybe a multi-platform App is the best choice. So just something to consider, that really it's always a conversation, there's always some back and forth.

This is not the kind of thing that you can write a one page RFP on and get a proposal and have your App in a month. It's really something that needs to be thought through and worked on with a partner that's experienced in the process. So we're right about out of time now but we do have some time for Q&A if anyone's able to stay on the call, we'll keep going for any particular questions or anything that, if anyone has, you can post them to the WebEx or..

George: Or chat, you can chat to George Sanchez if you have a question, we'll give it 30 seconds or so, if not, we'll finish up.

Jaron: Alright.

George: I've got a question for you Jaron.

Jaron: Yeah sure.

George: What's the involvement, in terms of dealing with IT versus marketing, what are the questions that the IT department would ask the marketing department in terms of moving forward on something like this?

Jaron: Oh that's a great question. So on the... The answer to that depends on whether you're building an internal App, an App that's facing the internal audience, the lawyers of your firm or the public or prospect clients etc. For an internal App, IT is absolutely going to want to get involved, they're going to  want to know things like what are the security concerns of the content? What content are we publishing in the App? How are we encrypting it or securing it so that it's not accessible to anyone outside the firm? Etcetera, etcetera, etcetera. And so it's definitely important to involve IT in an internal App conversation. Maybe not at the very beginning, maybe it's like secondary, but yeah. For a public App, you know, IT is certainly gonna want to know what's going on but they don't necessarily have to be involved from the get-go because there's really nothing that a public App can do to affect internal systems or infrastructure or the technology side of an IT project. So I think they will want to  be involved sometimes, in some of the projects that we've worked on they've been consulted to make sure that... We'll have conversations with them to make sure that the approach we're taking passes their muster. I mean, they want to  make sure that it makes sense to them technically and they're going to  obviously be able to provide that level of expertise. But usually for these publicly facing Apps, it's more of a marketing initiative and that's where the drive comes from.

George: Wait, we do have another question. One of the attendees want to know, do we know of any ethics considerations with the alerts functionality? They're thinking specifically of "opting out," so can a mobile App user opt-out of receiving push messages from a firm while still keeping the App on the device?

Jaron: Yeah, that's a great question. So yeah absolutely, the answer is yes. You can opt-out of those notifications. So the... Whether it's an iPhone or an iPad or an Android, if you're going to send the device notifications, you may have seen this in some of your Apps before, you'll immediately get a pop-up, the pop-up will say, "So and so App would like "permission to send you notifications, allow, don't allow?"

George: Yep.

Jaron: Every App has to do that, it's a part of the basic platform and it's a part of the guidelines. If you don't do it, Apple won't approve your App, So it's a requirement, so yes, every user will get that prompt when they first load the App and they can allow it or deny it. And then while you're past that point, three months down the line you decide, "I do not want any more notifications from this App," there are settings options where you can always turn that off and opt-out, so yeah, absolutely, it's a possibility. You'd still be able to access the rest of the App, just not the alerts functionality.

George: Great, thank you for that. I think with that we'll wrap up the webinar. I want to thank Jaron for taking the time to put the presentation together and the content was really comprehensive. I learned a ton, I didn't know how really expansive the mobile space could be and the options out there, so I thank you very much Jaron and if anybody wants to engage us, please give us a shout. We're happy to talk, and keep conversation going, and we will be posting a recording of the webinar up on our website, inclusive of the slides. So I want to thank everybody again for joining and stay tuned for the next one.

Jaron: Yeah, thanks very much. And just one last note I want to say is, we welcome your feedback on this. So this is the second webinar in our series, we have some really exciting things planned for 2014 and we definitely want to hear from you. What was good and what was bad about this, from your perspective, what was helpful? What ah-ha moments did you have? What information was just not necessary or too detailed or not detailed enough? Whatever feedback you can provide we'd appreciate it.

George: Great. Thank you!