Modern society is spoiled. Any time you sit in a café, myriad mobile devices are visible around you, and these represent only a small percentage of the numerous models of smartphones, tablets, laptops, etc. which are currently available on the market. Nowadays, everyone expects to be able to access the data they require at any time or place.
What people often don’t realize is that the mobile applications they have downloaded or the websites they access from their mobile device often require a complex back-end data system. A successful user experience ensures that the complexity of the back-end data system is completely invisible.
Mainframes have long been the preferred option for any company creating a data program which expects to deal in large volumes of data transactions, e.g. insurance companies, banks etc. Many of these programs were developed more than 20 years ago and are still in use. They were developed at a time when the UI technology available for data input was much more restricted than now. Combo boxes, context menus, carousels, sliding techniques…these were never even thought of.
But now we all want to be able to do our banking using our mobile phone, to look up our insurance policy details from our tablet, to check our mobile phone subscription information from our mobile.
These services are usually provided by a custom ‘app’ developed by your specific bank, insurance company or mobile provider. The creation of these apps to expose the background mainframe applications to your mobile devices is affected by a number of decisions:
- Destination device screen size
- How many controls can fit on the screen effectively?
- Any images included in the application should be scaled appropriately for the destination device
- Network access
- How will the application operate in offline mode
- Will 3G/4G/LTE versus WiFi access be sufficient for performance?
- Application management
- Efficient mainframe access is measured according to Million Service Units (MSUs), with possible needs to restrict number of application instances with access to the mainframe
- Ability to restrict application access to specific user group
- Revoke of application permissions
- Execution platform
- Web (typically HTML5 so viewable anywhere but no access to device sensors e.g. GPS)
- Native (access to device sensors but requires device specific code)
- Hybrid (mixture of the two–more complex to develop)
And once you have finalized how you want to create your app, you then need to decide how you will test it. Most popular browsers offer in-built device simulators which are very useful for quickly testing how the app appears on different devices. But the simulators cannot replace a real device experience. But how do you test your app on each physical device? The number of models available is extended daily, so you can never cope with all variations.
A typical approach is to have one physical tablet and one physical mobile phone available in the test lab, running the following OS variants:
This will allow general verification for the major mobile platforms. For more information regarding the complexity of testing mobile applications see https://www.keynote.com/resources/white-papers/testing-strategies-tactics-for-mobile-applications
Further verification is possible using a cloud device test service, and it’s possible to pay for a service in the cloud which will allow you to test your application on a vast number of device models.
Do you have experience in the mobile app development space? Please share your views on how the design/development phase can be simplified.