Mobile has arrived so start building those apps!


Presenters     Agenda
Terence Fugazzi Terence Fugazzi
Director of Marketing NA
  • Mobile by the Numbers - Why make the investment now
  • Architecture Choices - Pay me now or pay forever
  • Tools to Help - From frameworks to model driven development
  • How to Get Started - Practical tips to start building mobile apps fast
Rodrigo Coutinho Rodrigo Coutinho
Senior Product Marketing Manager
Duration 00:41:42 min  



Video Transcription

Terence: Okay. Hello, and welcome to the OutSystems' webinar. Mobile has arrived, so start building those apps.

Today's webinar is presented by me, Terence Fugazzi, Director of Marketing for North America, and Rodrigo Coutinho, who is one of the founding members of the OutSystems team, and is currently the Senior Product Marketing Manager.

Today, we're going to talk about how mobile has arrived for the enterprise, what choices you have, and show you one way that you can very quickly start building mobile apps for your business. On today's webinar, if you'd like to ask a question please use the chat window in WebEx and send it to all panelists.

We'll answer each question individually via chat, and also we'll select a few to broadcast and answer live at the end of the webinar.

Why mobile for the enterprise? I just think by being on this webinar today, you might have already had a hunch that the times has arrived, and either you need a new way to build mobile apps or you're preparing to kick it off. There's some very interesting statistics that show that your hunch is spot on.

First of all, Forrester did a survey, Forrester Research, and found that 75% of decision makers say that deploying mobile apps increases productivity. These weren't just people that thought about this, these are people who already deployed mobile apps in their business.

65% of these same decision makers said that going mobile has increased their decision making speed. It seems kind of obvious to me that having information with you at all times would increase your speed, but it's nice to see that the numbers prove it out.

Here's another fact. According to IBC, 72% of the enterprise workforce is mobile in some form or another. Of these people, 94% of them are equipped with smartphones. So the base is already there for mobile apps.

The reason more and more executives also can't live without their smartphones, and they're demanding them from their business units and demanding that they have access to systems and data in their enterprise from their devices. According to Forbes and Google, 82% of these executives already have smartphones. Seeing as these guys probably control my paycheck, if this isn't a reason to go mobile, I don't know what would be.

You already know it's time to go mobile for your business, and now you see that the data clearly backs it up. Everyone is bringing their own favorite devices to work, you see it everywhere. They're expecting them to work with your internal systems.

This is actually quite an interesting phenomenon, because this is the employees that are moving this forward. It's not an IT initiative, per se. They're expecting you to have these apps working for their particular devices.

There's big challenges when you go mobile. For one, all these employees are bringing in different devices, as I said, they expect them all to work. In the old world, IT would force certain devices on the workforce, but it's been shown that people are much more productive when they use their own device.

There's also a huge skills gap in IT when it comes to building out mobile apps. There's different languages, design skills to create UIs, testing, all these things are different for mobile in general. It can be different for each device, should you decide to go native.

Now, you might not know what that is, but Rodrigo's going to touch on that point in a minute.

Another key thing is that your business wants to go mobile yesterday. They want to already be there. The executives, the heads of the business units see that the benefits are laid out and they want to get there as soon as possible. They know those devices are out there. They want to have access to all those internal systems, or they want their customers to have access to their data.

Right now I'm going to hand it over to Rodrigo. He's going to show you what choices you have when you go mobile, what ways you can build the apps, and also show you one way that will make it much simpler and easier to deploy those mobile apps for your enterprise.

Now I'm going to hand it off to Rodrigo. Rodrigo?

Rodrigo: Thanks, Terence. I'm going to talk a little bit about the choices you have for going mobile. Before I do, just a reminder for those that got in late. If you have any questions, please type them in the chat window and send them to all panelists, so we make sure one of us can handle your question and we can reply on the chat window.

We'll select some questions to answer live after the event is done.

Okay. Three choices you have for going mobile. The first one is going native. Native applications are applications that are built specifically for a given operating system for a given hardware, and for a given device.

The other option you have is going mobile web. What you do here is you build an application that runs on a browser that in turn runs on a mobile device.

The third option is going hybrid. This a mix of the two, so you have a mobile web application and then you have a thin shell around it that allows you to put the application in the app store, and allows you to access some features of the phone.

I'm going to go into a bit more detail with each of these. Let's start with native.

Here you can see an example of a native app. This is the address book for the iPhone, and it's actually a pretty good example of a native app. It's distributed with the operating system, and it has two interesting characteristics. For one, it is on the iPhone, so every iPhone has one of these.

The interesting thing about this app is that the data it handles is shared across all other applications. This is a characteristic for native apps, they can share data.

Also, it has both an online and an offline mode. If you guys use exchange, for instance, all the contacts are downloaded for your address book, and you can either access it when you're offline or when you're connected to an exchange. There's some synchronization there.

These native apps are usually known for being rich in features and in terms of user hardware, so people usually think of more interactive stuff when they think native. Here's another example. We have an augmented reality application, and this is an application that makes use of a bunch of the phone's features.

You can see it uses the camera, it uses the GPS, it uses the compass, the gyroscope. This native app uses everything, so highly interactive application.

And of course, our favorite kind of application, games. These are applications that have sound, that are very interactive, that have heavy graphics. Sometimes even 3D graphics. Of course, you probably notice that all my screenshots are from the iPhone. The only reason is because they're easier to do. You can apply this to Windows Phone 7, to the Android, whatever.

Native apps are extremely cool, as you can see. Obviously they have their place; you just have to look at the success of the app store and the millions of apps that were already downloaded. They sure have their place, but they have some problems, especially when you can see they're enterprise applications. That will be the main focus on this session, enterprise applications.

For one, these applications are hard to build. You have specialized tools to build these applications. You have new SDKs, development platforms. Sometimes you even have to learn a new programming language just to be able to build an application to go native.

Also, you have the app store approval process. If you want your application to be on the app store, you have to submit it for approval, and that can take a long time. It can take weeks to do that.

You have to worry about manual updates, because even though the app store makes this stuff easier for users, they still have to go there and push the button. They have to decide they want to update your application, they have to go to the app store, and click the upgrade button.

By definition, native applications run on a particular device. The thing is, like Terence already mentioned, people bring their own device to work. People like to use their particular device, and actually there are studies that tell that people are more productive when they use a device of choice.

Building for each of these devices is extremely expensive, and it's actually a maintenance nightmare down the line. So what's the alternative? Well, one alternative is mobile web applications.

Here you can see an example. This is Gmail on the browser; this runs on the browser. It is prepared for mobile, so it has some ready buttons, the buttons are big. That's ready. The only way you can see it's running on the browser is the bottom bar.

Actually, this one doesn't even look that much native, but if you look at these enterprise apps . . . this is a mobile sales app, and I'll be showing this in more detail later. You can see that it looks almost native. The only tell is really that bar down there.

Again, this is touch ready and thumb ready, and I'll show you in more detail in a bit.

We truly believe that this type of application, mobile web applications, are the best way to go, especially for enterprise applications. Here's the thing. You can leverage what you already know. When you're building a mobile web application, all the knowledge you have from the web, you can re-use it.

Of course, there are some challenges around the form factor. Just like the browsers on the desktop, there are a few differences between the way they behave in each of the devices. Compared to building a native app, it's a very small step. It's not like a huge leap that you need to do to have a native app.

Also, you don't have to worry about approval process. You just publish the application to your server, and it's ready for your users to go and access it.

Of course you have automatic upgrades. It's running on your servers; it's not on the device.

You can build applications that are immediately ready for a bunch of devices. If you building using standard technologies like HTML5, you'll have an application that's ready for the iPhone, for Android, for Windows Phone. You basically develop once and have it running on a bunch of devices.

Finally, because you don't have this approval process, you get to be agile. You decide when you deploy the application. There is no two week waiting period to get it approved. You can release it every week if you want to, it's your call.

Now, at this point, people usually get the value of mobile web applications for the enterprise when compared with native. But there are a few objections that usually appear, and I'm going to go through the major ones that people usually ask me for.

One of them is that, by building a mobile web application, they don't have access to all the phone features. This is true, but the fact of the matter is that HTML5 is evolving. So while we don't have access, for instance to the camera on the mobile device, you do have access to geo location. We are expecting HTML5 to evolve, and we're hoping that pretty soon you'll have access to a lot more phone capabilities.

Another thing people mention is that, well, native apps are much more interactive than mobile web applications. Again, this is also true, but the fact of the matter is that there are great things being made with HTML files. The other day I saw a game, a touch-based game, built with HTML5 and with CSS3. These things are evolving and are growing.

Again, we are talking about enterprise apps. They don't need as much interactivity as a game or a consumer app.

Another big thing people talk about is the lack of ability to work offline. I was thinking about this, and the fact of the matter is, if you want to build a native application that works both online and offline, you've got a lot of work to do.

The whole syncing between the clients and the servers when you're offline, and then you need to make sure the data is consistent, that piece of code is extremely hard to do. It's a huge investment, something that's very expensive.

If you think about it, even some native apps assume that you're always connected. Since 3G is so wide spread, applications like for instance the Maps application that you get on your iPhone, assume that you're always on. Again, I don't believe that this is a huge problem.

It's all a matter of analyzing if the total cost of ownership of a native application, remember you have to support multiple devices, so the cost is huge, is worth going native or not. Fact of the matter is most companies are now going mobile web.

I can think of two examples. We have a customer that's building everything in mobile web; they dropped native. And you have the Financial Times example. They were using a native application, and right now they've stopped supporting that app and they only do it via mobile web.

Again, sometimes you really, really need to build a native, either because you need to access a feature on your phone like the address book or the camera. Or because your marketing department really needs the application on the app store for some reason. My advice in this situation is to go hybrid.

Hybrid application is basically a mobile web application, and in this example you can see that all this center stage that you're seeing is mobile. This is an application that we built for one of our events. Then you put a very thin shell around it that's native.

What's the advantage? Well, you get all the advantages from going mobile web, but you can still access stuff like for instance the camera. In this particular application, we wanted to use the camera, and you can do it via this shell. The application in the end allows people to post pictures.

Again, that center stage is a mobile web application. If I want to change it, it's very easy to do.

Okay. By now, I'm hoping you're all convinced that going mobile web apps is the best way to go for the enterprise. The question is, how do you build a mobile web application?

Now I'm going to go a bit toward the things that we've been doing in our product. OutSystems is the provider of the Agile Platform. That's the platform that we use to build enterprise web and mobile applications. We have had an initiative this year, so we've been doing this platform for ten years, and this year we decided to go mobile.

The idea is to make the mobile web as fast and easy as possible. We looked at the current environment in terms of devices, and there are a bunch of devices, and we looked at how people developed mobile web applications for these devices. We saw there were a few libraries and so on. Some better at some stuff, some better at other.

What we did is we removed all this complexity, and we allow publishing mobile web applications with only one click.

For you guys out there that never heard about the Agile Platform, I'm just going to give a quick introduction before I show it. The Agile Platform is something that allows you to manage the full application life cycle.

What this means is that you can use the Agile Platform not only to build your mobile or your web applications, but also to do your integrations, to do all the monitoring, to build deployment obviously, and to do change, which is one of the most important components we have. Once you have an application running, you want to change it.

The Agile Platform is made up of a few components. One of them, and this is the thing you'll see the most today, is Service Studio, which is kind of like the development platform of the Agile Platform. Then you have the server, and this is a server that enables you to publish applications, and it translates the applications into standard, .NET or Java applications.

You actually won't see this one, because we're going to create a server in the cloud. Finally, we have a monitoring console that allows you to manage all these applications and your users and your environment and so on.

Finally, we have something on the side, which I'm also going to show you, which are the apps. These are examples for you to see what you can build with the Agile Platform and to learn from it. So you can go there and look at the code and learn from it.

Let me just show you what you can do with the Agile Platform, and how a mobile web application behaves. Now I'm going to share my desktop. Now you're going to see my computer, and hopefully you're seeing Service Studio. What you see right here is Service Studio, and this is the screen you see once you download it from our website.

There's a free download. You can go to our website and download the Service Studio. What it allows you to do is actually to create your own server in the cloud. What I'm going to do is, I'm going to create a new server for me so I can show you this working.

I'm just going to put in my name and an email address. Right now, we at OutSystems are building a server that you can use to build your applications, to install applications that we provide for free, and you can use this server for 15 days to do what you need.

Right now I'm connecting to that server. What you guys are seeing here is my server tab. This is the things I have installed on my personal server, running in the cloud. There's nothing there yet, so what I'm going to do is I'm going to go to the OutSystems tab, and I'm going to install an application. Because this webinar is all about mobile, I'm going to install the mobile sales application.

Just click on it, and it will start the installation. Now, because the mobile sales application runs on top of the sales, both of them will be installed. In fact what I'm doing here is installing both the web application that manages sales, and the mobile web application.

There. It's done. The application is installed in my server in the cloud.

Now, I have two options here. I can either click here, this 'Next' button, and start learning how to use the platform and start learning how to change this application. Or I can navigate to this URL, and I don't know if you guys can see it properly but you actually, if you have a smartphone, can navigate to this URL and see the application running.

Because you guys cannot see my iPhone, what I'm going to do is I'm going to use this simulator to show you the application running. I'm just going to launch Safari, and I'm going to go to the URL that's on that text box:

When I finish typing the address, my iPhone simulator will access that server in the cloud. Oops, I'm having some trouble spelling mobile. Mobile sales...

It will run the application in this simulator. The first thing you'll see is actually a login screen, because all the applications built with the platform have security enabled. I'm going to log in as a sales manager. Of course, in the real application I wouldn't have these links.

You can see that I can actually install these web apps on the home screen of my phone. I'll show you this in a bit. Let me show you how the application responds and so on.

If you see, if I click here, the call Carl, you have the animations, you have the old flow like if it's a native app. There was a big effort on our part to make this look as native as possible.

Then I have the usual stuff I have here. If this wasn't a simulator, I could make a call right now to this phone number. I could send an email to Carl. We really put an effort to have all this interactivity that you would expect from a native, so if I go here and click the check box, it immediately goes to the server, it strikes the name.

This was all done with rich patterns using Ajax and so on. But let me go back to the home screen, because if you follow this advice and you actually go here and add the home screen... I'm just going to call it "mobile sales." You actually get an application that you can just click, and it looks even more native than running on Safari.

Again, I can log in and you can see as I navigate the tabs, all the interface is there, and although it's communicating with the server, all these reach patterns, like if I click here, "All Opportunities," you'll see that the list updates. If I go here to brown desk and decide to close this opportunity, you have exactly the interface you expect from a native application.

For enterprise applications, mobile web is definitely a good bet.

Now, I suppose you're wondering at this point how easy or how hard is it to build an application like this? Again, using the Agile Platform it's actually quite easy. I'm going to give you a quick example. This is not a thorough demo of the platform, it's just for you to have an idea how quickly you can build your application.

To develop a mobile web application, I go here, I click the, "New mobile web application," and again, this is going to create an application in the cloud for me. I have here the help box, so you guys can go here and learn more about the platform. This is the development environment.

Center stage, I have my canvas where I do my UI flows, where I do my business logic, where I do my screen design. I have a few tools on the web. Over here, on the top right, you can see I have everything I need to build my application. I have my data, all the database access, I'll access the database here.

I have my business logic, so any logic I need to build is built here visually. I've got my UI, in this case I'm building an interface for mobile, and I've got business processes. I can model and run businesses processes or workflows, everything from Service Studio.

Now I start by building my data model. Actually, there are a lot of ways you can do this. You can build your data model from scratch. You can integrate with an existing data model, if you already have one. I'm going to go with an Excel file that has information about people in my company.

It's like a directory, spreadsheet. You can see a few filters, I have phone numbers, birthdays and so on. Some colors, value fields and so on. I'm going to use this to build my mobile application.

What I'm going to do is just drag and drop the Excel file on top of Service Studio, and what Service Studio will do is first, it will look into the Excel file and it will build the data file I need. You can see here I have exactly the same info that was on the Excel file.

Next, it builds all the logic needed for the first time I launch that application. It's going to take that Excel file and move all the data to my database. Once this is running, the Excel file will no longer be used. You'll be doing everything in the database.

Now what's missing is the UI. I need to build the screens to manipulate this information. To do that, all I have to do is drag and drop the employee table onto my canvas, and Service Studio automatically builds a list screen for me, with all the features I need from a list screen.

You can see here I have search, I have this show more pattern that's used usually in mobile applications and so on. Notice that this was only an accelerator. I have full freedom to change these screens as I see fit.

Now that we have the list screen, I'm going to just use the same mechanism, we call it Intelliware. When you see the stars, you know Intelliware is working. I'm going to create a show screen. If I go here, to my flow, you can see there is a new show screen.

Finally, I'm going to create also an edit screen so that we can change the employees. If I go here, again, Service Studio builds the whole thing for me but I am free to change it.

That's it, we're done. We built a mobile web application. Now all we have to do is deploy it.

You probably noticed a big green button over here. Oh, let me just change the name of the application; I'm going to call "Am Direct." That's directory.

Now, I'm going to click the big green button on top over here. This button is what we call the one click publish button. If you look at the bottom area . . . I cannot find the annotations, but if you look at the bottom area of Service Studio, what you see is that one click publish over here is going to start and do its work.

First, it starts by storing this version of the application in the server. So we do version control, you don't have to worry about that. Each time you publish a version of the application, it's in source control. If you make a mistake, you can roll back.

Then, it is building everything that is required to build a standard .NET or Java application. In this case, I'm using a .NET environment, so it's building a .NET application. Finally, it's deploying everything it needs in the database, in the application server, in this case in the Internet information services and so on. And we're done, the application is ready.

Again, I don't know if you guys can see the URL, but if you can, you can access it via your mobile web browsers. I'm going to access it here via the simulator. The URL is the same, because the server is the same, and I'm going to access the M directory.

I think I spelled that right. Just let me show you the application working.

You can see, I have here, my application build can just take a few clicks, a few drags and drops, and you can see I have here the usual mobile pattern. For instance, I have here the "Show more." In order not to load the entire list in one go, we have this "Show more." When I click it, the list updates.

I can obviously navigate to my contacts and see the information. Just like the sales application, I can make a call or send an email. Let me just show you here the ability to edit, because Service Studio was smart enough to set up these fields using HTML5 tags.

For instance, we have here a custom input, that's the date, but here you have an email. We set this to be an email field, which is something new from HTML5. Which means that if you click it, you have a special keyboard where you have the @ symbol and the dot to help you type in the email address.

If you compare it here with the department, that bit is replaced with a big spacebar, which is the usual keyboard for typing text. Again, I have to do nothing manually. This was all done automatically.

Of course, I could do each of the steps by hand, even in Service Studio if I wanted to, but this really helps getting your first mobile web applications running in no time.

Now, one thing I want to highlight is that what I built here in these few minutes was a very simple application. Don't get the wrong idea. The Agile Platform is not for toy applications, it's for real enterprise applications. We've scaled both in terms of application size, we actually have a very large insurance claim handling client that has an application which is bigger than most ERPs, all built with the Agile Platform.

We can also scale to millions of users. If you guys go to, for instance, this is a website that has millions of hits per month. It's running on top of the Agile Platform. So don't get the wrong idea, this is just a small demo of what we can do in terms of mobile.

Let's go back to the presentation. I'm going to stop sharing that stuff, so I'm going to go back to the presentation, just to recap. From this webinar, what we just spoke about, mobile has definitely proven benefits.

Like Terence mentioned, 75% of the inquiries that implemented mobile applications came to the conclusion that it improved developer productivity. Definitely mobile has benefits. Mobile is here, right now. Either you want it or not, everybody is bringing their mobile device to the enterprise.

People want the applications to work with their own devices.

Mobile web apps are definitely the way to go for the enterprise, okay? Native apps have their place, but in terms of the enterprise applications, mobile web apps are the way to go.

They are actually the most effective way to make sure you can handle change, because as soon as your application is in production, the business is going to want to change it.

The question is, how do you get started? Okay, you want to go mobile, that's great. How to get started? Here are a few tips on how you can do this. The first one is, start small. Don't go for the big initiative that will never end. Start with a small project, learn how mobile works, test the user reactions and so on.

Always think of universal apps. Here, "universal app" lately is being used for iPad plus iPhone, but I'm thinking also of the desktops. For instance, the sales application that I showed you running on a mobile device, we also have a version for the web. Don't forget the desktop. These need to be synchronized. Desktop is still important.

You need to be sure that whatever platform you pick, it's easy to change. Your application is going to change. It always does, there are always new requirements and things to add to the application.

Just to give you a couple of ideas on projects that you might use to start your mobile strategy, one of them is you can take a look at the system you have internally, and build a mobile front end on top of it. Because sometimes there are internal systems that could really benefit from being accessed on the road.

This is a good way to start. Of course, you need to be sure you pick a platform that makes integration easy, and of course change in mobile, but you need to focus on integration if you build for the mobile front end.

Another idea is to pick an existing mobile app, like the sales mobile app I just showed you, and customize it to your needs. These are two ways you can start really easy.

Of course, we obviously believe that the best way to go mobile is by using the Agile Platform. I'm having some trouble here with WebEx, so Terence could you please advance the slide.

We welcome you guys to test the Agile Platform, because it's super easy to try. That process that you saw here, where I just type in my name and my email and it built an instance in the cloud for you, you guys can do that on your own.

It has a great free mobile application. The sales application is open source, and it's free. You can download it, go through the code, change it, sell it, do whatever you want. The application is totally free of intellectual property and it's open source.

Finally, you can do it in the cloud or on the premises. If you guys have a very strong integration scenario and you want to have this in house, you can do it. If you guys don't want to waste time provisioning servers and so on, you can put this in the cloud.

My advice to you is, go to Check the information on the website, check out the apps, because you can try the applications on the website, and download for free today.

That's basically it. Thank you very much for your attention. I'm now going to ask Terence, who's been collecting your questions in the chat window, to go through the most asked questions. Thank you.

Terence: Thanks, Rodrigo. That was a great presentation.

We do have a few questions here. The first question says, "Your platform looks to be some GUI driven app-builder thing. Is this just some sort of RAD tool, or what?"

Rodrigo: Like I was mentioning earlier, this is not a RAD tool in the sense that we don't focus on code generation only. The Agile Platform handles the full life-cycle of the application, which means you get to do your integration.

You in fact have a rapid application development environment to build your application, but on top of it you have the one click publish feature, you have all the monitoring and the control that you can do on the application, and you have a very strong support for change.

We do use RAD technologies to make sure you can build and change your app as fast and as clean as possible, but then we have everything around it to make sure that everything is integrated, and that should support the full life-cycle of the application.

Terence: Okay. Great. The next question: "You talked about hybrid apps, but from what I could see, the application that you published is web only. How do I make it hybrid?"

Rodrigo: There are actually frameworks available to help you to do this. The example I gave you of the hybrid app was actually built with a framework called PhoneGap. This is an open source framework, and you can use it for free.

By using PhoneGap, we were able to quickly build a very thin shell for the mobile web app. The good thing is that this shell runs on both Android and the iPhone, so we were able to put that application on both stores. You can go and check it. If you look for NeXTSTEP, you can download the app, I think it's available yet.

Really, aside from the delays we had on the approval process, because I think for the app store for the iPhone, they took almost a couple of weeks to answer, and they only approved it the day before the event, the process was okay. If you go to our blog, so, we have a video that shows an example of how to take a mobile web app and integrate with, I think it's the address book.

You can go there and check that video. It shows how to use this PhoneGap.

Terence: Excellent. Excellent. We've got time for a couple more questions. Next one says, "I see how a mobile web architecture makes sense for many of my business employee apps. But for my customer facing stuff, what are the alternatives? Are there examples of companies that are not using app stores to distribute their apps?"

Rodrigo: We see a few businesses that are actually using their websites to promote their content. Instead of putting it on the app store, they are actually linking from their website to the mobile web application. Or they are using those QR codes, those square codes that go to the URL, on fliers and stuff like that.

What they're using to announce what they have is simply point the users to a URL, and they can see the mobile web applications that they have available.

I was just thinking, because we actually have a customer who decided to put everything customer-related on mobile web. This is a big insurance company that did just that. Instead of having a native app, all the customer facing things, they have a customer portal built as a mobile web.

Or the example I gave earlier. The Financial Times, they had a native app for the iPhone and iPad, I think. They just discontinued that. They are not developing that one anymore. They are asking all of their subscribers to move to their new mobile website.

It's much easier for them to deliver new features and keep it up to date. Even in BTC, you have room for mobile web, definitely.

Terence: Excellent. Excellent. I think we have time for one more question. "You spoke about HTML5. I thought HTML5 was still in its very early stages. Is it ready for prime time?"

Rodrigo: Well, HTML5 is still being developed, but I wouldn't say it's in its early stages. Particularly in terms of mobile devices. Both Google and Apple have a very vested interest on this, and they strongly support the standard. Androids and iPhones, they behave very well with HTML5.

The main problems you have with HTML5 is when you go to the desktop. The browsers on the desktop have some issues with HTML5. Still, the fact that HTML5 isn't done yet and is evolving is very exciting for us.

I'm looking forward for the upcoming development in this area. In particular, the ability to accept extra features from the phone, like the camera or the address book or the gyroscope. I think in terms of mobile, you can go HTML5, no problem.

Terence: Excellent. I think that'll be it for our questions right now.

I really want to thank everybody for coming online and joining us for this webinar. I do encourage you to go out to There's plenty of resources out there for you to learn more about the Agile Platform, about developing mobile apps.

You can go download and try many of our apps from our app store, and I do encourage you to go out and check it all out. Thanks again for coming to our webinar. We hope you have a great day.

contact pricing