Your mobile strategy should facilitate business over advertising it

Everyone is thinking about what they want to do with their mobile strategy these days. Most of the bleeding edge strategy in the arena is coming from the advertising/marketing side of the corporate house though instead of IT. Marketing gurus consider a mobile strategy to be akin to a web site. Just another way to expand your business and get your name out there to the masses. While they are correct, the mistake comes when the comparison is made between the effort to create a static content web site as opposed to the effort to create a functioning mobile application.

Most web sites are just static HTML pages. I like to say “marketing fluff”. They serve a great purpose by legitimizing your business and showing the general public that you are more than a few guys at a kitchen table dreaming up ideas. From a programming perspective, static web content is simple. Most programmers don’t even consider it actual code. A mobile app differs from a static web site in that it should provide users with functionality instead of eye candy. For example, you may accept orders through your mobile app, do estimations or load data from a server to keep the content fresh. All of this is functionality that requires deeper programming expertise than static HTML content. For example, on iPhone and iPads, you need an Objective C programmer and in the Android world you need a Java programmer. Objective C and Java are far more complex than HTML and are true programming languages. So, while the cutting edge thinking in mobile is done in marketing, the implementation of the app fall more into the domain of IT.

Some companies have more than static web sites out there. Take Wal-Mart for example, Wal-Mart is a traditional brick and mortar institution but has a web site that allows you to shop at home. This type of functional web site might have been designed by a marketing department but the functionality was delegated to programmers at some point. The same principal applied to the Wal-Mart web site applies to their mobile app. It facilitate their business first and advertises it second. But if you download the app, you’ll notice that it simplifies the functionality that the web site offers. The main functionality is there to shop but some of the more detailed functions are not present. Another principle of mobile development is to keep it extremely simple. Do not try to put all of your bells and whistles from the web site into the mobile app.

Usability and design are extremely important in a functional web site and they are equally important in your mobile app. It’s probably a good thing if your marketing department is leading the charge for your mobile app. This means that usually graphic designers and usability experts are working on the design and intend to hand it off to programmers for implementation. This strategy works very well and usually results in a fantastic mobile experience for the end user.

Now that I have given you a little background on the differences between a mobile app and a static web site, I would be remiss not to mention cost. Cost is the biggest issue I see when someone starts talking a mobile app. In their mind, they equate the mobile app back to marketing expenses and the cost of their “static” web site. “I paid $10,000 for my web site, so I was going to budget 75% of that for my mobile app” is something I hear quite often. Now, let’s look back at what I have said before. The static content web site took one designer to implement doing just straight HTML. Now you need a designer plus a programmer and let’s face it, designers are no less talented than programmers but programmers are more expensive, usually by another 50-100% more depending on the experience level. So based on this, you can logically deduce that your expense for your mobile app should be around 150% more than it cost to do your web site. So if you spent $10,000 for your web site, I would off the cuff estimate that your mobile app is going to be in the ballpark of $20-25,000. Now keep in mind that there are a lot of variables at play here and take my estimate with a grain of salt. I’m not saying you can’t do a mobile app for 75% of your web site costs but I am going to say with 100% accuracy that if you go that route, you won’t be happy with what you get from a functionality perspective.

I want to throw out another thing I see people rationalizing in their heads. It’s a smartphone, therefore it’s smaller, so it must be cheaper to develop for and take less code. It takes the same amount of code to do a task on the server as it does doing the same task on a smartphone 99.9% of the time. Another mistake I see people make with relation to cost is forgetting the cost of the backend support. You want your mobile app to update from the server to get fresh content and you also want it to store that data and work if the user is without access to an internet connection. This adds great amounts of complexity and multiplies the cost of the project. For one, it takes a greater level of programming expertise to integrate with services and cache/store data for offline use than just simply creating a self contained mobile app. This expertise comes at an increased cost in terms of the resource and the time of the project.

All, this being said, I want to just put a few tips out there to help you evaluate your mobile strategy so that you can make an informed decision when you get to that point.

  • Don’t do a mobile app for the sake of doing a mobile app
  • Make sure that you can’t just get by with a mobile web site strategy instead native mobile functionality
  • Remember the cost will be greater than you expect always
  • Remember that you need a programmer and a designer at least
  • Keep the functionality simpler than your web site
  • Try to plan to feed the app from the same data sources as your web site
  • Do not use an advertising firm to write your mobile app. This is the greatest advice I can give. By all means, contract them to design it and create mockups, but have it reviewed and implemented by an experienced mobile developer or architect. Most advertising firms outsource the implementation to a contractor anyway.
  • Do not exclude your IT organization from your strategy. IT and marketing should collaborate on mobile strategy





External Tablet keyboards are not necessary

To me the keyboard of a computer comes as natural as wearing a belt with my jeans. It just seems like they should go hand in hand, but reality all I need is likely tighter jeans at the waist to eliminate the need for said belt.

Something I have noticed since the dawn of the iPad for business is that employees of companies who are not power users are more comfortable with using an iPad over a Laptop. It’s not just that, but most of them are also comfortable without using an external keyboard and don’t really complain that they don’t have one. Within a few days, they are using the virtual keyboard like a boss. This is much harder for those of us who have used a keyboard for years. We whine like a baby who just had our favorite pacifier taken away.

I am convinced that the external keyboard should go away and I am also convinced that the virtual keyboard can become just as productive. To prove my point, I have written this post with just my virtual keyboard. I have used my Marware case to have the iPad angled in a position that represents a keyboard angle so that everything aligns into the correct placements so
I won’t aggravate any tendinitis in my wrists. I have used this setup for simple things before but never for something as long as a blog post before. To my surprise, after a few little mishaps along the way, I am using the keyboard just as well as I use an external one.

We all know the old idiom that states you can’t teach an old dog new tricks. While the idiom itself itself is not true, it speaks to the stubbornness of beings to accept change. I admit that I thought it was not possible to get accustom to the keyboard because of the physical limitations, but as it turns out, the limitations are purely mental. It’s more about breaking habits, much like the habits we had to break when we went from typewriters to keyboards, for those of you who actually are old enough to have used a typewriter that is.

I’ve also noticed something quite amazing about the younger generation of kids using tablets and smartphones. They don’t feel the need for an external keyboard. The main demographics for external keyboard purchases for iPad are middle to later age men who have used a computer for many years. Middle-aged women are also more adaptive to the virtual keyboards and don’t feel the necessity to have an external one as much as men do.

An external keyboard also defeats the purpose of the tablet as well. Tablets were meant to be a tween device that bridges smartphones to computers, but as it turns out, tablets are just replacing both in many cases. Adding a external keyboard to a tablet makes it more like a laptop, which makes the perception and usage of a tablet klunky because the tendency of users is to try to mimic habits they have from the computer, leading to a poor tablet experience.

I see that external keyboards are here to stay, at least until a younger generation comes up through the ranks and more traditional PC users retire or adapt and while companies are making a nice profit by selling them, they will always be out there.

My suggestion is to give the virtual keyboard one week. Just try to go tabula rasa and see how well you do. Remember that you have been using a keyboard for 10-20 years in some cases and you didn’t learn to use it overnight.

What can the cloud do for your business or your mobile presence?

The “cloud” is really not a new concept in the lower rungs of software development. For the most part, enterprise architecture has been pushing everything back to a server for many years, but in the consumer space, the cloud is indeed a bright and shiny new toy.

Several years ago, I embarked on the journey to get all of my data stored onto someone else’s server instead of having said data always on my laptop or on a backup drive. In the event of a catastrophe, I wanted to make sure everything was safe and sound just in case my laptop were to crash or get stolen. I enlisted the services of Mint, TurboTax, Google Docs, DropBox, etc., all are wonderful cloud-based services.

So what exactly does “cloud” mean? Simply, it is storing your data somewhere else via the internet. Let’s not get into Platform as a Service, Big Data, Cloud server distribution or all that other nomenclature other than to say that there are degrees by which you “buy into” the cloud. How does it benefit you as the consumer? It mostly means that your data is persisted somewhere you can always get back to it from any device whether it is mobile device, laptop computer or desktop PC. The major advantages are convenience and piece of mind that your data is safe. With this comes a trade off. Your data is no longer really your own. It is less secure by virtue of just being transmitted back and forth and available to millions of people who might be able to get at it in a worse case scenario.

From a mobile perspective, the cloud strategy makes perfect sense. In the purist sense a cloud strategy might involve a simple web-based user interface that supports all browsers on all platforms, but with the current “app craze”, it makes more sense to go beyond this and also provide native apps running directly on mobile devices to interact with these cloud services. The reasons to have a native mobile app go far beyond having and app just for the sake of having one. A native app gets you coverage in an app store whether it is the Apple or Chrome app store, so a side-effect is market presence. A native app gives a far richer user experience than any web-based app can offer. A native app means that you have the ability to function in an offline mode and still give the user a way to accomplish their tasks and sync up with the cloud later.

Creating a native app and interacting with the cloud is no different than interacting with the cloud via your web interface, or for that matter, a native desktop application that accesses your data via the same cloud services. Think about your user interfaces as you would a mask. You have a different mask every Halloween, but your face is still the same and really that is the important thing. After all, buying a new mask is far cheaper than paying a plastic surgeon for  a new face. In terms of cloud services, most businesses already have some infrastructure for supporting multiple interfaces back to the same services anyway, it is just a matter of exposing those as something that native apps can consume.

From the perspective of business, the cloud takes on a whole new meaning as opposed to how a consumer would see it. Corporations are switching to cloud-based services to offload their once internal applications to a software-as-a-service provider. Here are some good examples of how businesses have taken to the cloud, Github for source code control, Google Docs instead of Microsoft Office, Google Business Services instead of having a traditional “in-house” mail server like Microsoft Exchange and Sugar or Bullhorn for CRM Solutions. By utilizing these cloud services, companies that could not afford an IT presence, now have the tools much larger companies have enjoyed for years on a tighter budget. Also, if we go back to those degrees of cloudiness I mentioned, you see that even maintenance costs that were once incurred to you directly would be an inherent benefit if you chose a Platform as a Service (PAAS) in the cloud. PaaS allows you to forget worrying about scaling servers, managing backups, handling server security, blah, blah blah… the things that do not deal with your core application logic.

Now that more businesses have progressed into the cloud, not only have they reduced their costs, but they have also instantly enabled a mobile presence in their business. Businesses that use Google Docs, example or Google Business now have automatic access via several great mobile applications. Employees with these companies now can enjoy greater flexibility on where and when they can work using their mobile devices and the cloud enables that data to be available no matter what interface they sit down in front of or what internet connection they use. With more and more companies offering remote work, telecommuting and co-working opportunities to remain competitive, it has given validity to the cloud as a viable mechanism for enabling businesses to function.

Cloud-based service adoption has flourished among newer more agile companies and on the consumer front. The larger corporate machines are just starting to see the value and determining how they can make a go of it. While all this is going on cloud-based service companies and mobile tech leaders are reaping the rewards of such a fantastic approach to how we do business in this new age.

How do you handle mobile security?

There’s been lot of hubbub related to mobile security over the past year and how to accomplish it. The biggest reason that this is an issue is that most companies are opting to allow their employees to connect their mobile devices to their corporate networks instead of providing them with a device. While this is a great cost cutter and it gives you a happier, more productive employee, it begs the question of how to handle security when you don’t control the device. Larger corporate networks that are supplying the mobile device are using Mobile Device Management solutions to solve the problem for them. Much in the way that a domain policy controls PCs, the MDM controls the iPad or iPhone. Still the security issues of the personal devices are still out there, but it’s not as big a deal as you might think.

At the present time I am writing this, I will say that I do not believe that it is possible to secure an Android device owned by an individual in any manner that would meet any type of rigid security requirements. Android users are usually more technically savvy and they tend to unlock and root their phones and when you couple that with the ability of applications to have services running in the background and the larger issue of malware, it’s just not safe right now. Hopefully, this will change in the near future as Google addresses security on the platform. BlackBerry is an almost perfect example of security, although data communication goes back to Blackberry servers and when they go down, everyone is a sitting around twiddling their thumbs.

iOS on iPhone or iPad is a much better example of a secure platform due to the closed architecture and the limitations Apple imposes on the applications that run on the platform. Please note that we are not talking about jailbroken iPhones.  Myself, I usually insert a bit of code in my apps that prevents my apps from running on jailbroken devices. iOS apps run sandboxed so that another app cannot interact with the app or it’s data. iOS app data is also encrypted with data protection so long as the passcode or passphrase is set and providing the developer didn’t make some cardinal sins with regards to how they are storing the data.

By far the biggest offense made by developers is forgetting the sensitivity of the data they are managing. Often security is the last thing on a mobile developer’s mind as they have their blinders set on creating the perfect user experience. Even worse, lack of experience in securing data is also another factor in most newer developers. Dealing with financial data and healthcare data all my career data has made security one of the foremost things at the top of my mind when I do a mobile project.

So let’s look at some ways that can give you piece of mind with regards to securing personal mobile devices.

  • Secure your app with a User name and password that authenticates to the server.
  • Don’t store any personal data onto the device file system (This is rarely an answer as your app most likely needs to run sans connection)
  • Have the user establish a lock code for your app that you then store inside the keychain
  • Make the user responsible for security breaches that are a result of negligence.

By far one of the easiest things to do is the latter. Most of the time, the user of the device is your internal employee and by making them responsible for the lost device, you can prevent a lot of silly mishaps that could have been prevented by some accountability.

An iOS device is far more secure than a Windows PC… Let me repeat that if you didn’t catch it. An iOS device is far more secure than a Windows PC. The reason for this are pretty simple.

  • Instances of malware, viruses and such are virtually nonexistent on iOS platform (yes, this is still true)
  • iOS is a closed source system. Open Source is a wonderful thing when you are building software but an open system is a different animal entirely. Think of it like you just build a tank and then you publicly posted the blueprints of said tank for the enemy to analyze and look for weaknesses at their leisure.
  • iOS Apps are sandboxed and cannot access data of another app
  • iOS users tend to have their data encrypted without knowing it because they have set a passphrase or unlock code

Of course, whether or not you allow employees to user their personal devices at work is a judgment call you have to make based on the type of business you are in. A good strategy for solving the contention is to write logic into the app that doesn’t allow local storage of data for a personal device. So basically, without a secure connection to the server, the app would be useless and devices provided by the enterprise would have the additional feature of being able to store data encrypted locally. There are many options, but remember it is unforgivable to have a data security violation because you were careless in the application and monitoring of security policies with regards to mobile devices.

Services are the key to choosing an enterprise mobile developer

There are more gotchas in software than in professional politics unfortunately. Some are a lot more serious than others and some are downright unforgivable. I’ve found the lynchpin for mobile development to be not in the app itself, but in the supporting services.

Not all apps require services to communicate back to the server, but in a corporate environment 99% of the time they do. This is where the problems arise. Most mobile developers are so focused on user experience and they have blinders to anything that exists other than their app…. it’s the only thing in their ecosystem as far as their concerned. In reality, the mobile app is just the tip of the iceberg. It’s an old analogy but think about a corporate system being one large iceberg with many points that stick out of the water. At the surface, it could appear to be multiple icebergs moving freely, but underneath, it’s all the same mass.

The average mobile developer has discipline in only one thing… mobile user interface design. To develop a corporate app, it is important that you look at the complete package of a system from the perspective of an architect. This is where a background in software architecture and a lot of experience comes into play. The mobile developer is just another developer under the umbrella of software engineering, a cog in the machine. When starting a mobile project, it is important to hash out the supporting web services first, not to design the app and drive the services from the app. Services should be based on solid use cases and user stories and the app will come. A matter of fact, doing it this way makes it simpler to add on different mobile devices or web clients later on.

Over the past three years, I’ve seen a lot of examples of mobile projects that have failed. The failures came for a lot of reasons. The main reason was money. Most folks have an unrealistic expectation of what a mobile app should cost and there is the misconception that because it is smaller, it takes less code to accomplish a task or that since the app is simple, it should be easy. Simplicity on the front end doesn’t always equal less complexity on the backend. The second reason they fail is a lack of experience in overall system architecture. For example, a company hires a developer who has a nice shiny portfolio or self-contained apps with no backend in the app store with the intention of building a corporate app. The developer is immediately in over their head since they have no experience dealing with web services or complex corporate integrations. The developer is usually the cause of this failure because almost always the cost of the app is underestimated to the client at the beginning, this leading to problem #1.

There isn’t anything wrong with being an enthusiastic young developer and loving mobile and almost every mobile developer these days are in their early to late 20s and have no software experience outside of maybe web site design. Don’t get me wrong, I’d hire a smart mobile developer just like this in my enterprise, I just wouldn’t put them to designing an enterprise system of doing the requirements gathering and estimation all by themselves.

Here are some tips to help you choose a mobile developer if you plan on finding someone to do an end to end mobile solution for you.

  • Ask the mobile developer for a resume (Seems like a no brainer, but some people don’t ask)
  • Ask the mobile developer about apps they have done for corporate clients. (If they don’t have any, you might want to pass)
  • Ask them for examples or a demo of their current work. (In particular, apps that maybe resemble the types of functionality you want in yours, for example, offline capability, data storage and service communication)
  • Look at who they have done work for
  • Beware the gamers and 3D junkies. The type of developer that is focused on writing games and likes integrating 3D features in an app, usually isn’t the right fit for an enterprise application. This pairing usually ends in deep frustration.
  • Look at how many apps they have submitted to the app store and what each app does. If the body of work is mostly app store submissions with apps that don’t require an internet connection, then you might just have someone who may  not be a good fit for a doing enterprise level work.
  • Ask for timelines it took to develop some of their apps and then ask for a ball park estimate at a high level for what you want to do. If the number seems to good to be true… it is.
By no means are these tips absolute but they are good starters to get yourself acquainted with a candidate.

A good enterprise mobile design should be flexible. It should have the ability to interchange mobile interfaces or web interfaces without having to change the back end. This is the essence of interface-drive design. The backend code should be written by someone seasoned with plenty of experience in service design. Proper expectations should also be set from the start. Having a great mobile developer with a talent for interface design is important, but keep in mind, it is merely one of those little points of the iceberg sticking up out of the water.

Using the “chessboard exercise” to extract user requirements

 Chess is a game of strategy…you need to be thinking about the next 3 moves after the one you are about to make and one “misstep” by your opponent and then you have to radically replan your strategy. Designing software is really not much different. Collecting software requirements is much like the board and the pieces in chess and the game makes a great analogy to get a stakeholder to thinking about what a user should and should not be able to do in a software design. I call it the “chessboard exercise”.

For starters, the chess board is your playing field or your “clean slate” for your software solution. The pieces represent your user roles. The rules by which pieces can move are your user stories. Let’s look at an imaginary sales application.

  • King – Sales Director
  • Queen – Assistant Sales Director
  • Knight – Technical Sales Support
  • Bishop – System Admin
  • Pawn- Salesmen
  • Rook – Local Sales Manager

Note that we don’t necessarily need to use all the pieces of a chessboard and if we have more roles than a chessboard has pieces, then that doesn’t matter either because we are simply trying to illustrate each role. Sometimes a user can also represent a background process in the software. For example, we could have created a new chess piece called a “squire” that represents a background process in our system that might batch some data off to another system nightly.

We have our players, we have our field, but we need some rules. If our new solution allowed everyone to do everything, then we could illustrate our software simply as one piece on our board, but life is rarely that simple.

  • King – Creates referrals, approves referrals, view and create reports
  • Queen – Creates referrals, approves referrals, view and create reports, assign sales managers to followups
  • Knight – Create referrals, view reports
  • Bishop – Creates users in system, read only view of referrals
  • Pawn – Create referrals, view reports
  • Rook – Create referrals, view reports, assign salesmen to followups
We have oversimplified a referral system but you should get the idea. On a chessboard a Knight only moves in an “L” shape on the board. In much the same way as chess rules, we have said our knight, the technical sales manager, can only create referrals and view reports in our sales system. Even for someone who knows nothing about chess, a 5 minute introduction with this exercise and they can be illustrating user stories for each of the roles in a software system. This process is important because when you are meeting with stakeholders, you need to extract role requirements quickly and efficiently. The chess analogy is the perfect vehicle to keep users from getting too far off in the “weeds”.
Aside from user role requirements, you can also use the chess board to illustrate goals and risk. For instance, any pawn that reaches the back row of the opposite side can be exchanged for another piece by “promotion”, so a assistant sales director achieves his promotion by overseeing 1000 referrals. Risk is also well-known to a chess player…expose your King and your opponent could have checkmate in 2 moves and game over. Think of the opposing side of the chess board as your competition’s software, process or staff. You need to match them piece for piece, move for move but you may also want to add something they don’t have or create efficiencies they lack to give you the advantage. Again, the creation of the “squire” piece might be such an advantage.
If you also look at a chess board, it represents a hierarchy in much the same way your organization does. 1 King, 1 Queen, 2 of knight, bishop, rook and a row of pawns. Use this relationship to extract user numbers for the application from you stakeholders.
A chess board has some complex rules as well, in other words conditional rules. For example, a pawn can move forward by two spaces on initial move, one thereafter, and diagonal to capture another piece. This is a perfect way to think of user stories. Maybe a salesman can only claim a 5k bonus on his first sale exceeding 20k. Users are rarely one-dimensional. (Think of three-dimensional chess in Star Trek… maybe that was a bit too far down the geek path.)
Castling is where a rook and the King can switch places under certain circumstances. In software, think of this as the “oh crap what are we going to do now?” issue. Under an emergency situation, rook may need to act as a salesmen in the system or better yet, in the case the system is down, paper forms are carried with the salesmen for just such and emergency. Castling is a perfect example of a “gotcha” in software design. Software is normally developed for 95% of cases and the other 5% are outliers but you can capture the other 5% during the requirements process by using the castling example as part of the exercise.
We have our rules, now we can run “scenarios”. These are paths of execution in the software that can be followed. We know in a game of chess that there are thousands of strategies that are followed to move pieces with the ultimate endgame of checkmate. Software, in this case, is less complex … well most of the time. Think of documenting each scenario as documenting a strategy. Each strategy can start from the beginning or build off another strategy. For example, think of the many ways a referral can travel through the system. Each of those are scenarios or strategies. In software these are finite and normally easy to document.
As an exercise during a requirements phase, a the “chessboard exercise” can be a valuable tool to extract user requirements and someone might very well learn to love a wonderful game of strategy in the process.

Best Pick Reports now live on App Store

Give the Ebsco Best Pick Reports or Home Reports App a try today

Only the 3rd App I have ever submitted to the App Store but it is by far the most complex. This app was done for Ebsco Research in Atlanta and they service cities in the US with a publication of contractors and this app is a companion that those publications… Try your Zip Code today to see if Ebsco services your area. If you are in Atlanta, the branding will be Home Reports but if you are in other cities, the branding will change to Best Pick Reports.

The Ebsco Research app was complex for all of the offline capabilities. Core Data techniques were used to cache and store data that is retrieved from the server. Also, this was the first app that I have used Story boards with instead of individual NIB files. The storyboards turned out to be easier in some respects but harder in others. This app was extremely conducive to storyboards though since it has a logic flow from one screen to the next. There were some gotchas where I had to control the segues but for the most part, I managed to keep it pretty sane. For this reason and some others, the app is confined to iPhones running iOS 5.

While I mostly do corporate internal applications, it never fails to excite me when I get something in the app store.