Tag: migrate

6 myths on migrating from web to mobile

If you have a public facing website today, then it should be mobile enabled. Period. In this post when I say mobile I’m referring to both native and web mobile. There are an endless variety of articles discussing the benefits of moving from web to mobile, however there are very few articles on the internet that discuss the costs of migrating from a traditional web software development environment to mobile. And, yes, in 2013 there are still some major and not-so major companies that haven’t migrated to mobile. I think the best way to start talking about costs is to expose some common myths.

These myths are more about discussing the impact of not “going mobile” and adjusting to an increasingly mobile-friendly world. Consider your users to be the experts on what the mobile experience should or shouldn’t be like. Remember, building mobile web sites and apps in 2013/2014 is about accommodating usage patterns that many, many users have already adopted and are intimately familiar with. This is okay, but you’ll need to play by the rules already established by thousands of other companies and organizations that have already built mobile apps.  Don’t play and it could mean lost customers and slower business growth.

Myth #1 – Mobile, we don’t need no stinkin’ mobile. The sheer number of mobile devices in circulation is a hard, cold fact. There’s hundreds of millions of them. And rest assured these devices are well loved and used constantly 24 x 7 by their adoring owners. Smartphone and tablet sales worldwide have finally started to outnumber desktop sales. Along with the shift to mobile, the use cases have changed in a significant way. Think about this: desktop use cases only apply when you are sitting at your desk or crack open a laptop. In comparison, mobile devices go with us wherever we go and we can access them anytime and almost anywhere: such as standing in line at the grocery store, waiting for dinner at a restaurant, getting real-time driving directions and the list goes on and on. The very nature of having a device with you all the time, even when you go to bed, lends to its ease-of-access.

Myth #2 – Squeeze existing content onto a smaller screen. Don’t do it. It can lead to awful and sometimes nearly unusable navigation and surfing experiences. Users who spend many hours a day looking at their mobile devices and visiting dozens or hundreds of sites and apps that are mobile-ready will absolutely expect your content to be mobile compliant.  For this reason major phone OS vendors have spent a lot of time and money to publish user interface guidelines.

Myth #3 – Continue to use long development cycles. The mobile world changes fast. Prototyping should occur in hours, days or weeks rather than months or years. Full release cycles are  often measured in months. To get an idea of the pace of change check out how fast updates occur to the Android operating system. I’ve gotten feedback on some companies with mobile development cycles being planned for up to 1.5 years from design to delivery of v1.0. In today’s fast paced world that can be a sure bet for problems and increased risk of project failure.

Myth #4 – Recreate complex workflows on smaller screens. Mobile device workflows call for simplified, intuitive workflows with fewer steps. If you have what I’ll call an enterprise web app with dozens of menus and pullouts, pulldowns and multiple pages then you’ll need to do some homework along side a good user interface designer to figure out how to make it work on mobile. Chances are your app will have to be sliced and diced into smaller and more digestible chunks.

Myth #5 – Reuse existing security measures on mobile. Mobile security is vastly different than desktop security and applying desktop security patterns to mobile can be a recipe for disaster.  People carry their devices everywhere and they tend to download many different apps, and some people don’t even use their screen lock. We’ve all heard stories of devices being left unattended in public places or left behind at airport security screening.  So, there are many more ways for potentially serious security breaches to happen via mobile devices than your typical laptop.

Myth #6 – Users won’t like change. If you have a public facing web site today that’s not mobile compliant, chances are you’ll have a significant portion of your mobile users who aren’t happy. The best way to find out: survey. Ask your users what they think…don’t leave it to guesswork and opinions. Get the facts from the people who matter most: your customers. And, I’m going to go out on a limb and say that the majority of users would jump at the chance to use a mobile version of your website.

References

iOS Version History
Android Version History
WindowsPhone Version History
iOS User Interface Guidelines
Andriod User Interface Guidelines

Migrating from Desktop to Mobile: 6 steps for success

If you have only one web site that is built for desktop browsers then you definately need to read this post. The one-size website-fits-all days are gone along with the AMC Gremlin. Mobile is a much different world than desktop and your visitors, users and customers will know that. This post is based on a presentation that I did at GIS in the Rockies 2012, and another blog post I wrote called 3 Steps for Determining if Your Website is Mobile Ready.

The presentation mentions GIS, or Geographic Information Systems, however it applies to anyone considering mobile.

Why care about mobile? For once the internet analyst firms are clear on one thing: mobile device sales have  surpassed desktop sales world-wide, yep I mean not just in the good ol’ U.S.A, around January’ish 2012. There are more than 835 million mobile users now, and studies show that people are spending the majority of their free time using their devices. And the patterns they use to interact with the devices are becoming ingrained and, for better or for worse, expected. And that expectation has reached a fervored pitch as the iPhone fanboys (and fangirls) demonstrated when the iPhone 5 launched. Everyone wants the latest and greatest even if it’s not all that different.

What about mobile user expectations? Mobile users have significantly different expectations on performance, look-and-feel, and capabilities. There are also differences between devices, for example as you may already know an Android user interface is fairly different from iPhone. Catering to those needs will boost your chances of success. So, here’s just a sampling:

  • Many different screen sizes. Typically smaller screen sizes and a wide vareity of screen pixel densities.
  • The mouse is gone. Navigation is done using fingers for gestures such as pinch and swipe. Greasy, french fry picking fingers are much less precise than any computer mouse.
  • Less memory. Phones have less memory and they can be slower than your high-powered laptop.
  • Poor internet connection. There are no gaurantees on a mobile internet connection, unless you happen to be dragging a CAT6 ethernet cable with you everwhere you go. Connections can be spotty and 4G connections can be inconsistent.
  • Battery life is awful. If you are at a conference, for example, using the phone heavily may kill the battery in  4 – 5 hours. Tablets are typically a bit better. In comparison, desktop computers are always plugged in.
  • Not all mobile devices are the same. iPhone and iPad run a different operating system from Android. Not only are the platforms completely different underneath, but users have different expectations of each platform. You can’t share the same code between iOS and Android, or even Windows Phone.

How about those six steps you mentioned? It’s these differences that really drive the six migration steps. And, these suggestions apply to all the different approaches to mobile whether you are building for mobile web, hybrid, native or responsive*:

  1. Start prototyping today. Let your developers loose to start playing and to get an idea the capabilities of different devices and operating systems. Have them use your existing web site content.
  2. Analyze your existing website usage. Use analytics tools such as Google Analytics to analyze what browser and operating systems your visitors are using. Look to see if there are any trends related to mobile usage. If you don’t use online analytics, there are also tools that can examine your existing web site logs.
  3. Reevalute all use cases and workflows. Mobile is so different from desktop. Refresh your approach on how to work your magic in that enviroment by taking into account how people use their smartphone everyday.
  4. Expect that you will need to rewrite code. Don’t try to make the code fit if it doesn’t meet the requirements. Besides, sometimes it’s a good thing to rebuild so that you clean house and bring a fresh perspective.
  5. Buy as many devices as possible. Since all devices are different, the more you can test on the better. For example, have as many types of Android and iOS devices running different OS versions on several different cell providers.
  6. Dig deep into browser differences. All browsers are different, especially mobile browsers. Check out caniuse.com as your next new best friend.

* A short note on Responsive websites. These use CSS3 media queries to detect and control what HTML content is visible to certain devices. CSS3 is generally considered to be one of the three technologies that together make up HTML5. Those three components are HTML (version 5) + Cascading Style Sheets (version 3) +  some new JavaScript APIs. NOTE: all three of these technologies are built into the browser by the browser vendors such as Google, Mozilla, Microsoft and Apple.

Migrating from SQL Server 2005 to SQL Server 2008

Basically, I needed to migrate a fairly simple database from SQL Server 2005 to SQL Server 2008 for a project I’m working on. The database has six tables, dozens of columns, properties and unique keys. There was also a stored procedure and a trigger just to spice things up.

I was quite happy with how easy and fast the migration went. I’ve had seemingly simple database tasks go sideways before and take hours to resolve. From beginning to end, this whole operation took about five minutes.

Here are the steps I used, although yours may vary slightly.

  1. Launch SQL Server Management Studio on your SQL Server 2005 machine
  2. Right click on the actual database then click Tasks > Detach. This step insures there are no active processes accessing the database.
  3. Since my SQL Server 2008 database was locked down, I copied the .mdf and .log files from the SQL Server 2005 machine over to the corresponding directory on the SQL Server 2008 machine via Remote Desktop. SQL Server does have an option to copy from one database directly into another. However, that involves opening ports in firewalls to allow access between the server, and I didn’t have that luxury for security reasons. 

    4. Note 1:  Make double sure you don’t overwrite an active database of the same name on the destination server!

    Note 2:  the default installation directory for these files on SQL Server 2008 is here: C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA

  4. Launch SQL Server Management Studio on your SQL Server 2008 machine.
  5. Right click on “Databases” then select “Attach”.
  6. This will launch the Attach Databases window. Select “Add” and navigate to the correct .mdf file that you just copied over.
  7. Follow any additional prompts.  I didn’t have any full-text catalogs so I just clicked “OK” when that pop-up window appeared.  For me , SQL Server 2008 automatically converted the old SQL Server 2005 database into SQL Server 2008.

If you follow these steps, and if there were no errors, you are almost done. Before you pop champagne and celebrate make sure you can access the database from SQL Server Management Studio. Open the tables and run a quick test query just to make sure. If you have a more complex database you might want to run multiple test queries, and run your application, just to make sure everything moved over properly.  If you have a migration story please share it here.