Rob Tiffany on Cross-platform tools allow developers to repurpose existing skills to accelerate native, multi-platform #mobile development.
Read More Rob Tiffany on New WebViews with the same performance as #mobile browsers mean web skills are finally viable for building fast, cross-platform hybrid apps.
Read More Rob Tiffany on Replace wasteful, server round-trip Web 1.0 sites built with Cold Fusion, CGI, ASP, Servlets, Perl and Livewire with AJAX empowered #mobile web apps.
Read More Rob Tiffany on Migrate Web 1.0 Intranet apps built for Netscape + Internet Explorer 3 to HTML5, CSS3 & ECMAScript5 for modern #mobile browsers.
Read More Rob Tiffany on Most mobile web browsers render incoming HTML in a virtual window that is typically wider than the screen of the mobile device. This is done so you can view non-mobile websites via panning, pinching and zooming. The negative side effect of this behavior is you often see tiny text, pictures and UI elements that are unusable. As you might imagine, this poor user experience contributes to the notion that mobile apps are superior to the mobile web. You can help correct this misconception by adding the viewport meta tag below inside the head tags of your web page:
<meta name="viewport" content="width=device-width, initial-scale=1">
This tag instructs your mobile browser to adapt the HTML content to the size of your mobile device instead of the width of a desktop browser. In our mobile-first world, one of the keys to success is to start small and target mobile browsers first instead of the other way around.
Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany
Rob Tiffany on Take a look at the latest report from the French analyst house faberNovel, on HTML5 and how to rethink web strategy:
Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany
[mc4wp_form id=”5975″]
Rob Tiffany on I also recognize that you’re likely to get a different strategy from every person you ask. To quickly recap how we got here over the last several years, the rise of BYOD is a result of more compelling devices in the marketplace combined with the move from Corporate-Liable (CL) to Individual-Liable (IL) device ownership policies. Typically, I like to take baby steps on this one because you don’t have to boil the ocean in order to respond to this mega-trend all at once:
Baby Step 1: Oh, it’s too late. This step was already taken while you weren’t looking. Your employees are already bringing their own smartphones and tablets into the enterprise. In an Individual-Liable scenario, they’re using their own data plans to surf the mobile web and use apps. Don’t freak out because you haven’t given them access to anything yet. At worst, you might have employees that are distracted and not giving you their best work since they’re playing Angry Birds. On the other hand, they may already be more productive because they’re using public information on the mobile web to solve corporate problems.
Baby Step 2: Your employees want to get their email on their smartphones and tablets. No surprise here. Since I’m a person that believes CIOs and IT Directors should get more value for their dollar, I won’t ever recommend one-off, point-solutions to satisfy the need of each different mobile platform, because that’s wasteful. During the middle of the last decade, I watched in horror as Microsoft began to license the Exchange ActiveSync (EAS) protocol to all its competitors. At the time, I was worried we were giving away one of Windows Mobile’s competitive advantages. Fast forward to our consumer-driven world of today, EAS is the one thing that every smartphone and tablet has in common.
While not every organization uses Exchange Server, most do. Some are even sidestepping the management of additional servers buy running this in the cloud via Office 365. What this means is that you can instantly give push email, calendar, contacts, and tasks to your employee’s iPads, Android devices, Windows Phones, Symbian smartphones, and iPhones via a single technology that you probably already have. If you’ve ever used Outlook Web Access (OWA), then your organization is already setup to securely deliver this value to most every device over SSL. Okay, at a basic level, your employees can now get elements of their ‘information work’ done anywhere at any time which makes them more productive. They should also be more responsive to your customers as well.
Baby Step 3: Uh oh, someone told you that security could be an issue. You’re now thinking that there’s no free lunch in mobile. While you may not be able to beat the security you get on your heavily-managed Windows laptops and tablets with BitLocker, there is some light-management that you get for free and you probably don’t even know it. Remember the EAS protocol from Baby Step 2? Well, it gives you some light device management in the form of policy enforcement in addition to the email stuff. While there are a lot of great device management packages out there that can give you complete control, when dealing with devices owned by your empowered employees, heavy device management may not be appropriate. The notion of installing a device management agent on each employee-owned device is a huge undertaking. So how does Exchange ActiveSync sidestep this? Well, it’s already installed on their smartphones and tablets and it does things like enforce complex PINs, password expiration, and allows you to remotely wipe a device if it gets lost or stolen. You get this for free and it works the same way across many popular smartphones and tablet. Whew, you now have a basic line of defense in play.
Baby Step 4: Supported device matrix. While EAS provides email, calendar, contacts, tasks, PIN enforcement, and remote wipe to the majority of smartphones and tablets your employees might own, some devices might fall through the cracks.
That’s why it’s important to let your employees know which devices and mobile operating systems meet the minimum EAS standards to create your BYOD baseline. It’s a list that looks similar like this:
As you can see, this covers the majority of devices that consumers are buying today with the exception of the Blackberry, which has its own device management system.
Baby Step 5: Your employees are now asking for enterprise apps so they can perform other elements of their job remotely from their devices. It’s too soon. I know your IT department has been developing desktop apps for decades, but your BYOD baseline isn’t ready for this yet. The heterogeneous mobile diversity created by BYOD makes cross-platform native development inefficient and costly. There are too many programming languages, IDEs, MEAP vendors, app security, and deployment issues for you to think about during this early Baby Step phase. Don’t worry, you’ll get there later. For now, I want you to keep it simple, and follow my theme of using the same technology over and over for every smartphone and tablet to realize training and cost efficiencies while shortening time to market. The Mobile Web is your key to cross-platform success. Today’s devices all have web browsers that support many of the features that comprise HTML5.
By continuing to build web applications like you’ve been doing for your company Intranet since the 90’s, you can target every device via a single code base, through a single engineering effort on the part of your internal or outsourced developers. Since your employees will be accessing your web servers via their device browsers, you’ve effectively sidestepped software deployment and patching issues, blacklisting/whitelisting users and groups, as well as data-at-rest concerns. WebKit, Opera, and Internet Explorer all provide the same SSL-encrypted experience you get on the desktop when you’re doing online banking. Oh, and make sure to use Basic Authentication on your web servers since it’s the only auth method guaranteed to predictably prompt users for credentials and work across all device browsers. To make things more competitive with native apps, the faster JavaScript engines of today’s mobile browsers make business logic and Ajax calls to your backend web services infinitely faster. While your employees will securely get the data they need in the palm of their hand, it doesn’t mean I want them to access internal web servers via the corporate Wi-Fi network. The BYOD baseline I’m creating for you doesn’t include secure CorpNet access because the necessary level of device trust hasn’t been established. Publish your internal web servers out to the Internet using reverse proxy servers or through a public cloud where your employees can access them via their mobile operator’s data network. The HTML5 mobile web is your no-brainer strategy for cross-platform mobile development until further notice.
Bonus Baby Step: Speaking of Wi-Fi, the tidal wave of folks bringing in their consumer-focused, individual-liable devices are facing new caps on their previously-unlimited data plans and they’d like you to help. While I remain firm that you haven’t done enough in your BYOD baseline to trust devices on CorpNet, you can throw your employees a lifeline by giving their devices access to a ‘Guest’ Wi-Fi network that only allows them to go out to the Internet. Many companies have a segmented ‘Guest’ Wi-Fi network for visitors. If you already have something like this in place, consider allowing your BYOD legions to ride on this network using Wi-Fi Protected Access (WPA2) for security. Think of this as a ‘Give-Get’ since you’re publishing corporate HTML5 apps out to the public Internet without accommodating the data usage fees for employees to use them. Now employees can use your mobile web apps from the office without eating into their mobile operator’s monthly data allotment.
Is this everything you need to know? No. But it quickly gets you out of the paralysis of not knowing what to do about this tidal wave of devices flowing into your enterprise. Once you have this BYOD baseline in place, you begin to thoughtfully look at topics like encryption, containerization, wireless security, enforcing a larger list of policies, software distribution, inventory, corporate network access, enterprise apps, data, MEAP, and many more.
Right now, I want you to feel a sense of accomplishment by taking the first Baby Steps towards creating a mobile strategy for your organization.
-Rob
Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany
[mc4wp_form id=”5975″]
Rob Tiffany on Now that I’ve spent the last two articles helping you to get your Metro user experience foundation created with CSS3 and Media Queries, it’s time to jump into one of the features of HTML5. Geolocation is perfectly suited for smartphones because location awareness is something they all have in common. Most people are under the impression that only native mobile apps have the power to reach into the platform APIs and retrieve a device’s current location. Luckily, with modern HTML5 browsers like Internet Explorer 9, web pages can use JavaScript to gather this same information. This API finds your location via the following methods:
Let’s take a look at a simple page containing HTML and JavaScript:
As you can see, I’ve taken our HTML5 + Mobile Web boilerplate and included the Light Metro stylesheet to get started. Beyond that, it’s just a simple button designed to call a JavaScript function via the onclick event. For the sake of this example, I’ve done the unthinkable and have included the JavaScript inside the web page. Please never to this in production.
The onclick event calls the getPosition() function. The first thing you should notice is a bit of defensive coding where I test to see if the navigator.geolocation capability exists. If the target browser allows me to pass that test, I then call the getCurrentPosition() method and pass in a single arguement for the successCallback parameter. Don’t worry, I’ll dive into the other two parameters in the next article.
The displayLocation callback function is called once the device passes the coordinates back to the web page. After that, it’s a simple matter of retrieving the latitude and longitude values.
This first image below shows you what the mobile web page should look like when you run it on Windows Phone 7.5:
You should see the now-familair Light Metro UX. When you click the Get Location button, IE9 will popup a dialog asking your permission to allow the web page to access your location from Windows Phone as shown below:
This should give you comfort in knowing the Big Brother cannot anonymously track you. You can say Yes or No for each Geolocation request and you can check the checkbox to remember your choice for this particular web page. Once you’ve said Yes, the device will give you a lat/long as shown in the image below on the left:
In order to more easily test this on my PC with Visual Studio 2010 running, I used the Windows Phone emulator, plus the additional tools you get with the Windows Phone 7.1 SDK. By clicking on the Location tab, you can then click on the Bing map to get a Pushpin in a particular location. The coordinates for the pushpin are displayed in the Current Location section which should match what you see in the emulator. That’s all there is to it!
Congratulations! You can now get lat/long coordinates without building an app.
Keep coding,
-Rob
Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany
[mc4wp_form id=”5975″]
Rob Tiffany on It just so happened that the style I presented you with was Dark. Since we know that Windows Phone also has a light theme, I think it’s important that your mobile web site have one as well. Below is an enhanced version of the boilerplate HTML5 file that displays many commonly used Form elements:
Here is the Dark CSS file that accompanies the above HTML5 file:
The combination of a mobile-optimized HTML5 page and a Dark Metro CSS3 stylesheet results in a familiar UX designed for AMOLED displays:
But what if you want to display a light mobile website? Luckily, you get to use the same HTML5 page and just point to a new, Light Metro CSS stylesheet as shown below:
So what does this new CSS file look like? A lot like the dark one with some subtle changes:
With the Light Metro stylesheet, you now have a look and feel that’s reminiscent of the Outlook experience on Windows Phone. With the black and white colors reversed, you get the following:
So there you have it! You started with a simple HTML5/CSS3 boilerplate and now you’re building mobile web apps with both a Dark and Light Metro UI. All the touchable elements are large enough for big fingers and the separation between controls ensures that users won’t hit two at the same time. Consider this your foundation for a new HTML5 journey that you’ll be taking with Me, Internet Explorer, and Windows Phone.
Keep coding!
Rob
Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany
[mc4wp_form id=”5975″]
Rob Tiffany on Up until recently, it’s been all about the apps written in Silverlight. With hardware-accelerated video, text rendering, canvas drawing, and the high-speed “Chakra” JavaScript engine, IE9 compiled for ARM processors means business. But diving into HTML5 without considering the differences in characteristics of mobile web browsers is a mistake. Therefore, I’m going to show you some HTML5 and CSS3 that you can use as a starting point for your mobile web apps.
Below, you can see the simplified DOCTYPE, html, charset, and stylesheet tags that are the hallmark of HTML5. In order to be accomodate small screens on Windows Phones, I’ve added the viewport, mobile optimized, and handheld friendly tags to keep the browser from trying to render a desktop web site.
<!DOCTYPE html>
<html lang=”en”>
<head>
<meta charset=”utf-8″/>
<meta name=”viewport” content=”width=device-width, initial-scale=1.0, user-scalable=yes”/>
<meta name=”MobileOptimized” content=”width”/>
<meta name=”HandheldFriendly” content=”true”/>
<link rel=”stylesheet” href=”wp.css”>
<title>Mobile Web Title</title>
</head>
<body>
<h3>Mobile Web</h3>
<script></script>
</body>
</html>
You probably also noticed that I placed the script tags just before the closing body tag instead of inside the head tags. This ensures that the mobile page fully renders in the browser before the JavaScript parsing begins.
Along with this simple HTML goes an equally simple stylesheet that provides a basic, Windows Phone Metro look and feel:
@media screen and (max-width:480px) {
body {
font-family: “Segoe WP”,Tahoma,Geneva,Verdana;
background-color: #000000;
color: #ffffff;
padding: 18px;
}
h1, h2, h3, h4, h5, h6 {
font-family:“Segoe WP Semibold”;
margin-bottom:7px;
}
h1 {
font-size: 48pt;
}
h2 {
font-size: 40pt;
}
h3 {
font-size:32pt;
}
h4 {
font-size:24pt;
}
h5 {
font-size:20pt;
}
h6 {
font-size:18pt;
}
p {
font-size: 14pt;
}
input, select, button {
color: #ffffff;
background-color: #000000;
border: 2px solid white;
vertical-align: baseline;
font-size: 17pt;
min-width: 40px;
min-height: 40px;
}
label {
vertical-align:baseline;
font-size:17pt;
}
input.hasfocus {
background-color:white;
color:black
}
fieldset, legend {
font-family:“Segoe UI Semibold”;
font-size:12pt;
}
fieldset {
padding:12pt;
border: 1px solid white;
}
}
I’ve included a simple media query in the CSS to only apply the style to devices with a maximum width of 480 pixels. Additionally, this will definitely give you the Segoe fonts, black background, and white borders that you’re accustomed to in Windows Phone Silverlight apps. You’ll also notice that I set minimum heights and widths for some of the UI elements to give mobile users a larger hit target.
Good luck with your next HTML5 + CSS3 mobile web site!
Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany
[mc4wp_form id=”5975″]
