The Time-to-Market Advantage in Mobile Application Development

As a visit to Damnoen Saduak Floating Market of Thailand will confirm, time-to-market and distance-to-customer are distinct advantages in business. 

It is difficult to know which came first: the customers with their curiosity and pocketbooks or the merchants with their bamboo and palm hats and colorful produce, but they are certainly mutually drawn to one another. People do not come here because the prices are cheaper but rather because the produce is fresh, accessible and sold in a convenient and interesting way. In bygone days, the vendors would paddle their boats on the waterways buying, selling and trading fruits, vegetables and other goods all across Bangkok’s canal system.  The canals were convenient, the boats efficient and the coverage of the canals was pervasive across all of the city. Where am I going with this?

Today’s mobile networks are pervasive, mobile apps are interesting and they can get to customers first, right where they are.

When it comes time to build mobile apps that can reach customers, time-to-market has more to do with the ability to develop mobile apps that run on multiple device operating systems and integrate to back-end business transaction systems in an efficient and agile manner. Distance-to-customer is the advantage that mobile apps have because they reduce the transaction distance between you and your customer to zero. Your ability to sell to customers is no further than the palm of your customers’ hand.

But quite frankly time-to-market is often a disadvantage of mobile apps because of the long lead times required to develop mobile apps using native platform development tools. That’s why when we see a platform that claims to marry the advantages of rapid development techniques, pre-built integration solutions and a capability for cross-platform mobile smartphone and tablet deployment, we have to pay close attention. Faster time-to-market for mobile apps requires a smarter application platform.

 Most development approaches fall prey to the time-quality-cost triangle and suggest that you can choose only two of the three beneficial qualities: less time and more quality or less time and less money or more quality and less money. The prevailing wisdom suggests that you cannot have all three. But frankly this popular dilemma is based on the preconceived notion that all approaches require a fixed effort.

What Magic Software initiated in the 1980s with the notion of a rapid prototyping platform for creating business applications carries forward today into some fairly slick and sophisticated technology that still gets overlooked far too often by the mainstream computer programming community. The benefits of an application platform can be found in the fact that it breaks through the problem of fixed effort. Platforms have built-in solutions. They allow for very rapid results by leveraging common application development requirements in an underlying solution set or platform.

Daniel Coyle, author of The Talent Code says: “Baby steps are the royal road to skill.” As I have said before: “Regardless of whether you use agile or scrum project management methodologies, early and frequent results are essential. Too many projects are cancelled midstream simply because their progress is shrouded in mystery.” An application platform gets you to those early victories and propels you to frequent wins that will keep executive sponsors engaged to completion and asking for more.

Native development suffers in comparison to Magic xpa application platform development for a number of reasons. First. More tools are needed. This is not opinion, this is fact. With native development you need a server-side language and deployment methodology and a client-side language. Furthermore, the client-side languages are different: Objective-C, J2ME, J2SE, etc. Because of the extra effort required by these tools, more programmers are assigned to a mobile app development project. While  environmental complexity increases with native mobile development, the Magic paradigm of platform based metadata development remains constant: one tool for all requirements – server-side and multiple OS clients.

To understand the absolute significance of this, one needs to consider the COCOMO II Model of software estimation perfected at the USC Center for Software Engineering. (Go Trojans!) The COCOMO II model can be simplified as follows:

                      Effort = (Team) x (Tools) × (Complexity)(Process)

As you increase the number of programming languages needed (tools), effort increases. The concept is fairly simple. As you increase the number of developers (team), effort increases. And as you increase the functional requirements of the application to be delivered (Complexity), effort increases. The relationship between these three components of effort is factorial.

Those restaurants along the canals of the Damnoen Saduak Floating Market want their vegetables really fresh. For really fresh mobile apps, consider the Magic xpa Application Platform.

Developer’s Guide to Mobile Order Tracking Apps

Developing Mobile Order Tracking apps for deployment across multiple mobile platforms? When designing your app it is important to keep in mind the differences between order tracking and simple shipment tracking.

With a shipment tracking app we start with a tracking number and have a simple question in mind: where’s my package? These apps are very easy to build because you can simply pass the tracking number to the shipping company web service as a request and receive back shipment information from the shipping company web service. For a company like FedEx that ships 9 billion packages per day, there’s a lot of big data integration taking place behind the scenes of that simple Web Service request, but as the mobile app developer, you don’t need to worry about that.

As the developer of an order tracking app, you suddenly have taken on a much more complex task. Order tracking differs from shipment tracking in the following ways:

Multiple Shippers.  In many businesses, an order may be shipped by a variety of different carriers. Not only FedEx, UPS, DHL, USPS and other well known small package delivery companies, each of which offers Web Services for package delivery and tracking information, but also other carriers such as CEVA Logistics, DAMCO, and literally thousands of trucking, common carriers, sea cargo, air cargo, rail, freight and freight forwarding companies.

Multiple Shipment Methods. In addition to tracking multiple shippers, an order being tracked may have a variety of different shipment methods associated to it. In addition to common designations such as same day, next day, 2-day air, etc. you may also have alternate methods such as will call, in-store pickup, download, digital delivery, license keys and hold for further instructions.

Order Information. In a simple shipment tracking app, all you have is the tracking number and perhaps weight and dimensional information. You don’t necessarily have any information about the order itself: quantity, item number, name, description, price, etc. An order tracking app will typically have all of this information available as well. From an app design standpoint this becomes problematic because you obviously don’t have the screen real estate for all of this information. So even though your app spans a broader range of related information regarding the order information, you’ll want that information on a separate tab.

Multiple Orders and Order Status. Since you may be tracking multiple orders, you’ll want an easy way to find and display orders, usually by order number, date, or keyword search. The home screen for an order tracking app may indeed be a list of order numbers with most recent open orders first and oldest delivered orders last. Color or bold text on the order number can be used to clearly identify open orders versus closed orders. Partial order logic will need to be considered as well as this is a common scenario in many businesses.

Payment Information. Another tab to track payments related to orders may be desirable as well. As payment methods will vary, so will payment status and the way that payments are applied.  In some businesses, payment methods may fail after an order has placed. Such as a delayed credit card rejection. In these scenarios, you may want to highlight these orders that need payment attention on the home screen and also provide mechanism to the customer and/or salesperson to cancel orders in accordance with your business rules. When customers have terms and make payments after the fact, credit status may affect the status of an order. For example, an order may be accepted but not processed until a payment is made to return the credit status to normal. This is common in many industries and may need to be accommodated in your app as a business rule.

Salesperson’s Tools. Salespeople and sales management may also need mobile order tracking apps, since they deal with multiple customers, they may need to have an ability to see orders in a variety of ways: by date, by product or product type, by customer, by salesperson, etc. From the home screen, the salesperson or sales manager should be able to apply filters so that they see only such orders. User rights for salespeople, sales managers, warehouse and logistics personnel and customers will all vary. Keep role based rights and security in mind when creating your app.

Summary. In summary, an order tracking app will begin with a home screen that allows the user, based on rights, to see relevant orders. Drilling down on an order will normally display the shipment status on the tracking information tab along with the desired shipment tracking details. If information on the order details is desired, clicking on the order number in a shipment status tab will open the order tab containing order details, clicking on the order amount can display the payment/credit status information. Here again, color coding the payment amount green, red, etc. can help identify payment status at a glance without the need to click on the amount to open the tab. Depending on your business rules and user desires, a mobile order tracking app can be developed with any number of options. Fortunately, the Magic xpa Application Platform makes the creation of these apps straightforward and allows you to deploy them across multiplemobile OS including iOS, BlackBerry and Android. Then the Magic xpi IntegrationPlatform can handle back-end enterprise integration to shippers’ Web Services and your own ERP system for up-to-date information.

Maps Fiasco: Is Apple Having A Bad Hair Day?

Apple has faced a firestorm of criticism over its poorly executed introduction of Apple iOS 6 maps as a replacement for Google Maps. Pushing out a friendly competitor is classic Apple behavior reminiscent of their rejection of Adobe Flash. If the maps battle ended today, Google would be the clear winner. But it remains unclear whether Apple or Google will triumph in the map wars in the long run. I anticipate either a long term standoff fueled by Apple’s stubborn unwillingness to see a clearly superior Google technology continue to succeed on their platform or  Apple will find a way to become less proprietary and allow Google maps a role in a future iOS version. For now, there course is fairly well set.

The problems with Apple maps in many consumers’ minds are simply that they are not Google maps. Google’s brand is well respected even among iPhone users. But to compound these problems, the maps are simply being ravaged in the media for a long list of errors, glitches and mis-categorizations.

Meanwhile, Apple has lost a pair of rulings in German court against Samsung and Motorola Mobility in its patent infringement claims. The patent dispute over touch screen technology favoring Motorola Mobility and Samsung could have a ripple effect in several other related cases around the globe.

While all of this is clearly bad news for Apple, one cannot help but wonder if it is nothing more than a bad hair day for Apple. They have survived other fiascos in the past with bad antennas, overheating tablets and the like. One suspects that they will find a way to deal with it.

Google has quite admirably taken the high road, stating that they want to make Google maps available for everyone on all platforms. Although one can’t help but feel that they are gloating over all the negative publicity aimed at Apple.

So what’s all the fuss about? One of the most humorous mistakes is an Irish rural estate named “airfield” that has been represented by apple on the map with an airplane icon to indicate an airport. This prompted the Irish Justice Minister Alan Shatter to comment: “I know on occasion mistakes can be made and I am surprised to discover that Airfield, which is in the centre of my constituency in Dundrum, has, in Apple’s new operating system iOS 6 maps application, been designated with the image of an aircraft.”

Aside from the errors, which are just comical, the Apple maps lack some of Google Maps most popular features, such as public transit directions, useful traffic data and street level view images.

What is an app developer to make of all this brouhaha? My takeaway is that the competition between Android and Apple is likely to continue long into the future. As a result, the apps market will remain fragmented between these two giants as well as Windows and BlackBerry. Multi-platform mobile apps development solutions are going to be needed for a long time. Apple doesn’t have any problems that can’t be cured with a good comb. 

How does mobile app design differ from design for desktop and web apps?

Designing business applications for mobile smartphones and tablets is often described simply in terms of screen size. While it is a factor, this is only one of the important differences to keep in mind when designing mobile apps. I’ve developed an acronym to help mobile app developers think about best practice when designing for mobile apps: P.O.O.D.L.E.

By considering the differences in context between desktop or web applications and mobile apps, we can begin to see the outlines of best practice design considerations. Consider these six dimensions of mobile app design when developing new smartphone and tablet applications whether with a Mobile Enterprise Application Platform or through more tedious native development tools:

Pressed-for-time.  The mobile user is typically in a time crunch when compared to their desktop computing counterparts. Attention spans are shorter, the need for extensive information and data is far less. In fact, thoroughness of data and information will often be viewed as a negative an a mobile app. Mobile users want just the pertinent facts and procedures because they are pressed for time. They are often in the midst of doing something else and the use of the mobile app is literally an interruption to their current task. Pressed-for-time means apps need to be aware of the multi-tasking being done by the user. The app needs to allow the user to get in, get out and be done. POODLE Rule-of-thumb:  Mobile apps should typically involve no more than 2-3 screens.

On-the-spot. Mobile apps are usually at their best when they are location sensitive. Accessing the GPS for location allows the application to lookup relevant data, display locations on a map and so on. Geocoding requires developers to think in new ways about data relationships. From a design standpoint a mashup of Google Maps or other geocoded information can be especially useful to mobile app users. POODLE Rule-of-thumb: Limit initial application scope based on where the user is currently or most recently located.

On-the-go. Keep in mind that the current location of the device is not always the location the mobile user is concerned about. A mobile user is often thinking about “where to go next” and not simply where they are. For this reason a mix of GPS, server-side geocoded data and user entry about desired locations will need to be a part of the application. POODLE Rule-of-thumb: Allow the user to easily indicate an alternate, more relevant location from where they are currently located.

Device-specific. Not only are mobile screens smaller and the interface method different (no mouse and usually no physical keyboard) but the devices vary drastically from model to model. Size, screen resolution, camera resolution, battery life can all make a difference. Poor application design that constantly drains a battery through GPS use or radio use can become a real issue. If a company has to program in different languages for BlackBerry, Apple iOS, Android and Windows Phone, this can be extremely resource costly. Consider a Mobile Enterprise Application Platform (MEAP) suchas Magic’s application platform to overcome these duplicate efforts. POODLE Rule-of-thumb: MEAP Platforms Reduce Development by 35-90%.

Leveraged-Data. When designing business apps, it is essential that the apps leverage backend data and business processes so that the mobile user is fully connected to the business without having to interact directly with enterprise IT systems. An enterprise mobile mashup will allow the business app designer to leverage data and processes for the most effective user experience. POODLE Rule-of-thumb: Enterprise mobile mashups increase app acceptance by 35%.

Expressly-Personal. With traditional business software, the user learns to navigate a series of screens and interfaces to accomplish their tasks. With a mobile app, user navigation is resource intensive and regarded as a waste of time. Mobile apps should learn the preferences of the user to personalize the interaction without the user having to set preferences and options. If I press the same three navigation buttons every time I use the app, shouldn’t that become my start page?  

Mobile applications should be expressly personal experiences allowing the user to interact when, where and how they want to. Apps should be limited in scope so as to be more intimate and personal to the specific need of the user at that moment. Other apps can accomplish other tasks for other users. POODLE Rule-of-thumb: Tailor applications on-the-fly in a way that lets the user know you have been paying attention to their preferences.

What’s all the POODLE about? It’s just a way to organize a few ideas about mobile app development and how it needs to be approached differently than the development of traditional desktop and web applications. I’m sure we could extend the acronym further to POODLES and discuss security and other important issues. But for now, we'll let sleeping apps lie.

Additional important concepts:

What is a mobile app?

What is a mobile enterprise?

What is a mobile enterprise application platform (MEAP)?

How do mobile enterprise application platforms (MEAP) differ?

How can I make money as a mobile app developer?

What job skills do I need to develop mobile apps?

Metro UI Debate: Planned Obsolescence Ahead

With all the debate suddenly surrounding the Metro design spec introduced by Microsoft as part of Windows 8, one cannot help but wonder whose PR department is whipping up the controversy: Apple’s or Microsoft’s? On the one hand, the discussion can be viewed as an attack on Microsoft by the Apple Dumping Gang while on the other hand it could be a “no publicity is bad publicity” ploy by the MSFT Gang That Can Only Design Straight. In my view the attention ends up helping Microsoft and Android while hurting Apple.

The differences in the UI design and interactivity standards are rather ironic. Microsoft has generated literally billions of dollars in revenue by releasing successive generations of its operating systems and driving their adoption by pushing user expectations towards increasingly complex and interactive design standards. Early windows design looked very gray, gradually became more colorful, then beveled, then shaded, then ray traced, then transparent, then animated. Each time the clear intent was to create a graphical case for the latest coolest operating system version and a feeling that applications using the older design standards were passé. It was plainly and simply a form of planned obsolescence little different from design trends in the fashion, automotive and consumer packaged goods industries.

With mobile devices, Microsoft correctly identified a conundrum. If you bring today’s highly sophisticated desktop design standards over to mobile devices then there isn’t really much of a look and feel upgrade path left. Planned obsolescence becomes difficult when your design trends have reached their logical plateau. And this plateau was evident on the desktop as well. The solution: bring the desktop and mobile UI standards down together to a simpler level and yet one which is so clean and crisp as to feel modern and chic.

Metro is not nearly as bad as most of its critics make it out to be. Sure, it is simple. But there are plenty of Swedish designers who will tell you that design simplicity is a value to be upheld. If you think they are wrong, take a visit to your local IKEA store. I disagree that Metro is classic or retro in any way, it is quintessentially modern and sleek. In this sense, I do not disagree that Metro is a workable and pleasant design and interface standard. Whether or not it is a superior standard is a bit of a subjective argument in my view. I disagree with the Metro advocates who suggest that it is the only effective GUI. It is an effective GUI and it can beat chaos design in side-by-side comparison tests. So what? Is Microsoft really going to enforce Metro UI principles with police-state like efficiency? No. As a result, design creep and chaos will eventually eliminate the consistency that is currently Metro’s primary advantage in UI metric comparisons. Once you eliminate its newness and therefore its consistency, the Metro UI will compare similarly to any other well conceived GUI.

Call me a cynic on this one, but I see the graphical aspects of Metro as a well-designed platform for planned obsolescence. Time will tell. In the meantime, designing apps for any platform, any device, any time leads me to Magic.

Mobile Enterprise Application Platform: Any App...

Enterprise mobility is in part a decision about “how to” develop and deploy mobile applications but it also involves serious questions about “what” applications to deploy. The fact that a good mobile enterprise application platform can make core enterprise software systems accessible remotely by a handheld device does not necessarily mean that all data and functionality should be exposed. Serious decisions need to be made about which data is accessible and which business functions are to be mobile-enabled. In this regard, it is important that you have all the tools in place to allow you to selectively integrate enterprise applications rather than simply providing wholesale access to your back end systems and processes.

With the announcement of Magic Software’s Mobile Offering yesterday, a new discussion of the importance of complex mobile business process and workflow was begun. See for example, the article in Dr. Dobbs Journal subtitled: “complex workflow support for mobile deployment of enterprise apps.”

Magic Software offers the mobile enterprise application platform you need to develop and deploy mobile apps and it provides the integration platform that enables connectivity and data interchange with your existing enterprise applications. Rather than engaging in extensive retooling of an existing application, you can use Magic Software’s iBOLT integration platform to automate the orchestration of data transformations, business transactions and application messaging with backend systems.

This automated approach to integration is the first step in reducing the effort required to mobilize any application. We then return our consideration to the mobile enterprise application platform itself. As a metadata engine, Magic Software’s uniPaaS application platform is a ready‐made business application engine containing pre‐written technical and administrative functions and services. It frees the developer to bypass the intensive technical code‐writing stage of application development and move quickly and efficiently to deployment.

The easiest way to grasp this concept is to see uniPaaS in action. The uniPaaS development environment is really a visual representation of application ‘assets’ and business rules stored in XML based ‘metadata’. This metadata business structure can be easily transferred from one deployment scenario to another (for example, Windows Mobile to BlackBerry) with minimal effort. And as discussed in our previous entry, it isn’t a matter of developing one core application and force fitting it onto various devices. Applications designed for iPhone and Android should have the unique look and feel of those devices. Instead, Magic Software’s Mobile offering allows you to customize your core business application for each device without having to refactor your core business logic or data structures.

For more information, please click here to download Magic Software’s Mobile Offering FAQ.