Creating a Mobile Customer Service or Help Desk App with Magic xpa Application Platform

Writing a basic Magic xpa Customer Service or Help Desk app for a mobile device could make a great weekend mobile app development project for a Magic xpa developer.

Magic xpa does a good job of making it easy to handle the huge variety of data types, by insulating you from the details of the implementation.  Magic xpa reduces the number of data attributes (often referred to as data types in many programming languages) that you will need to work with -- alpha, numeric, date, time, BLOB, logical, etc. are the most common. The Magic xpa programmer also does not need to specify how those variables are actually stored in memory or in a database as the application platform itself manages these repetitive and inconsequential details for the developer.

To create a mobile app for customer service or an employee help desk, a few tables that might typically be required are the user table, the ticket table, the solution table and the solution response table. Many other variations are possible, of course, depending on the complexity of service/help app required. We’ll take the time to detail the fields used in the user table and the ticket table. But keep in mind that the tables will all have relationships.

For the sake of efficiency both in data storage and application performance, you should avoid creating duplicate data. So if, for example, the solution proposed relates to a specific ticket, there is no need to store all the ticket details in the solution table. You can simply point to the unique identifier of the ticket table. This is the principle of data inheritance. The data inheritance or data model relationships in our example are shown here:

Now let’s look at the User Table and Ticket Table.

Typical Customer Service App fields – User Table

Field name*	Field attribute	Field description
PrimaryID	Numeric	The unique identifier for the record.
UserFirstName	Alpha	The first name for the record
UserLastName	Alpha	The Last Name for the record
UserEmail	Alpha	The Email for the record
UserMobilePhone	Alpha	The mobile phone number of the user or device.
UserEmployeeID	Numeric	An integer value containing the employee ID for this record
DepartmentID	Numeric	An integer value containing the department ID for this record

Typical Customer Service App fields – Ticket Table

Field name*	Field attribute	Field description
TicketID	Numeric	The unique identifier for the record.
Status	Alpha	The status of the service ticket, for example, this could appear to the user as a drop down list offering open, closed, pending, overdue, etc.
Severity	Alpha	The status of the service ticket, for example, this could appear to the user as a drop down list offering open, closed, pending, overdue, etc.
Subject	Alpha	Brief subject of the problem described in the record.
Description	BLOB	A detailed description of the service issue.
CreateDate	Date	Date record was created.
CreateTime	Time	Time record was created.

* The developer can use any name for these fields, the field names here are just examples. In addition to the above, you’ll want to think about tables that contain the problem, description, and BLOBs containing the communications between the service rep and the user (the solution and response table), as well as tables containing service rep information, etc.

The challenge in creating a mobile help desk or customer service app for end users is that screen space is very limited on most mobile smartphone devices. The user information should be entered once, and then it need not appear to the user again unless they request to change it, for example, the user may need to change their phone number or email address. If you wanted to pre-populate the UserMobilePhone field, in theory this can be queried using a user defined function such as  ClientOSEnvGet ('device_udf| UIDevice currentDevice’) on iOS, for example, or the user can simply enter their mobile phone number.

Once the user identity is established, the home screen for the mobile app should be the list of tickets with open tickets bolded or listed in red at top in order from most recent to oldest. Only two columns are needed, Ticket and Subject. The user can select a ticket and then the detailed ticket tab opens with the ability to scroll down through solutions and responses. On an iPhone, these could be displayed as colored speech/conversation bubbles whereas on the android you may choose to display in the more conventional android style.

I think its fair to say that creating a Mobile Customer Service or Help Desk App with Magic xpa Application Platform makes for a great intermediate level programming project. What will set the good CS apps apart from the bad ones? Creative features such as customer self service knowledge bases could create real differentiation. When the type of service involves parts and repairs, location information of the device becomes even more relevant. How might you utilize location knowledge in your app to locate parts? to locate service centers?  

What sets the great mobile enterprise application platforms (MEAP) apart from the others? Integration, unified development approach, enterprise-class scalability, security and reliability. 

Magic Application Platform: “Take Me to Your Developer!”

Just when you thought you would never like a cross-platform mobile development platform, Magic Software has introduced a MEAP platform that makes sense. Previous MEAPs were either frustratingly uniform in their approach to user interface design or overly limiting in the way a native app could be designed for iOS.  The Magic xpa Application Platform iOS client has finally landed and the news is very, very good. It may seem like it was a long way coming, like an alien from a distant planet but “We’re Here!” and we are saying loud and clear: “Take Me To Your Developer!”

The Magic iOS client is a native device OS RIA application designed to take advantage of iOS mobile device capabilities, while being connected to a scalable, robust enterprise server. For those familiar with the Magic Application Platform, the Magic iOS client implements a subset of the capabilities of the Magic RIA client for .NET Desktop, as they are applicable on an iPhone or iPad device.

And you get loads of native device capabilities.

Let’s Play “Where’s Waldo?” er, “Where’s Waldo’s Phone?”

With the Magic Application Platform  the developer can create applications for the Magic iOS Client that leverage the devices' GPS. The ClientOSEnvGetfunction can be used to query the current device location using the internal or connected GPS device. Function syntax in the Magic Application Platform is selected in an intuitive table driven development wizard interface. So for example,  

ClientOSEnvGet (‘device_location’) will return the current device location, using available location options such as GPS or Network. The result is a string in the following format: “OK|Latitude|Longitude”, where OK is a fixed part for testing if a result was returned, and Latitude and Longitude are the coordinates of the current location. If a location could not be obtained, for any reason, an error message will be returned.

Is a Picture Worth a Thousand Words?

The applications you create can also use the camera in the iOS client using the Magic Application Platform’s  ClientFileOpenDlg function. Be sure to specify the path as camera, so that the camera will be opened.  This will enable the user to take a picture and select it. The full path name of the picture will be returned from the function. It is then possible to upload this picture to the server using the ClientFileToServer function, or by loading it into a BLOB variable.

Developing Apps that Access Miscellaneous iOS capabilities on iPhones and iPads

In situations where it is possible to use device capabilities such as calling a phone number, sending an SMS, sending an email and opening a browser, the developer can create app capabilities for that. On the Magic Application Platform the developer can leverage iOS device capabilities by using the Invoke OS command with the URL of the required command.

All of the following examples would be valid parameters for the Invoke OS command:

          tel:1-408-555-5555

          sms:1-408-555-1212

          mailto:chunkylover53@aol.com

          mailto:?to=tcook@apple.com

          http://magicsoftware.com

More than Window Dressing for iOS

Of course the Magic xpa Application Platform delivers more than just window dressing for the iOS Client. Your developers can now build Magic mobile apps that run in a native iOS client and perform important business transactions. These apps are also easily targeted to Android, BlackBerry, etc. Regardless of which mobile client is connected, they can all access the same backend Magic Enterprise Server. So your boss can use your app on his iPhone, your colleagues can strut your apps on their BlackBerry devices and you can run it on your guilty-pleasure Android.

OK, now that you have taken the Magic xpa Application Platform to your developer, take it to your leader and get the mobile apps you need today!

Hurdling Barriers to Enterprise Mobility

Have you ever tried running hurdles?  It takes practice. In the beginning, you’re so focused on jumping that you forget about running. Even experienced hurdlers can become so focused on hurdling mechanics that they forget the importance of sprinting mechanics.

A similar problem exists in enterprise mobility. We can become so focused on pushing enterprise data to mobile apps that we forget that the apps are mobile. The context of the interaction changes the functional requirements of the entire app. The danger is that we overload the mobile user with screens and data so that they need to scroll, tab and search until they are frustrated. Usage rates fall off, adoption fails and our app fails to become the solution it needs to be. But the issue isn’t just form factor, screen size or input method. It’s the context of the interaction. Mobile app users are typically remoteand on the move.

Context Shift. To hurdle the most important barrier to enterprise mobility, we need to design applications that are aware of this context shift. In the past, the context of most computer automated enterprise business processes was within the confines of a data center, network, or office. The web extended reach to remote locations such as customer sites, home offices and laptops. But smartphones and tablets reflect an even more dramatic context shift.

When a business user chooses to interact with enterprise IT via a mobile device instead of their traditional laptops and desktops there is a reason: they are not simply remote, they are either on the move or so location and time constrained that accessing a traditional enterprise device is impractical. They might be dining with friends or family at the exact moment they are accessing your app to approve a purchase order.  They might even be engaging directly with a customer on-site at the exact moment they are accessing the sales order entry app on a tablet. Interaction with an enterprise mobile app needs to be direct, unequivocal and brief.  Designing apps that reflect the mobile paradigm is all about good business analysis, application architecture and interface design. These issues become even more accentuated with consumer facing branded apps.

BYOD. Bring-Your-Own-Device (BYOD) policies present another barrier to enterprise mobility. BYOD often means some users have BlackBerry, others Android, still others iOS phones and tablets. Each of these devices has an operating system that requires a unique development language and compiler.  With different user devices, comes a different culture of app interaction. An app designed for BlackBerry keyboard control and one designed for an iPad Retina touchscreen are obviously going to be quite different or at least they should be. Some businesses are making the mistake of using HTML5 to sidestep the native development challenge but they end up with unusable apps that are bland, unattractive or simply not functioning properly on certain devices. Overcome this barrier by using a Mobile Enterprise Application Platform (MEAP). A good MEAP will allow you to tailor your app to any mobile device without requiring you to create a uniform app or making you resort to several different programming languages to finish the job.

Backend Integration. Enterprise mobile apps don’t exist in a vacuum. Very few businesses are run with an IT system that is entirely run on mobile devices. No business of any size is. You have backend systems whose processes and data are usually determinative. The mobile app is supplemental. Your MEAP platform needs to be closely tied to an integration server that can automate integration and business process orchestration with large enterprise systems such as ERP, CRM, Field Service Management and other systems. Information from your eCommerce website, employee SharePoint portal or email server may be equally vital to the overall process. Only an end-to-end view as documented in a well designed use case analysis by your business analysts will get you to where you need to be in terms of required integration processes for mobile apps. And then you need to make sure you have the proper enterprise integration platform to facilitate easy integration of backend systems based on your business rules.

Customization.  A lot of business “apps” are being foisted onto mobile devices by using a technique known as screen scraping where there is a one-to-one correspondence with backend screens in an HTML browser on the mobile device. The more sophisticated ones break the big screen and its multiple fields into several tabs and allow you to scroll down a long list of poorly aligned fields. This approach is not simply ugly, it is foolhardy to think any real long-term adoption will take place. These stopgap measures fail.

Furthermore, the new “mobile apps” from large ERP and CRM vendors are simply too generic. Their one size fits all approach does not accommodate your customizations and it the templates are completely constraining. Cookie cutters are fine for making cookies, but what if your business is not a bakery? Mobile apps need to be customized to deliver the proprietary differentiation your employees and customers need for you to stand out in the marketplace in terms of performance and customer experience. Here again, you business analysts and app developers should take extra care to create apps that reflect the true nature of your industry and your company. A MEAP platform will allow you to create integrated apps that are customized to your business requirements to outperform the competition and deliver outstanding customer experiences.

The barriers to enterprise mobility can be overcome. To do this, create mobile apps that are both enterprise connected and mobile aware.

The Benefits of Metadata Driven Development

Eyal Pfeifel, Magic Software’s Chief Technology Officer, recently sat down to discuss metadata driven development. In the video, he provides a useful definition of metadata driven development: “Metadata driven development means developers build business applications using metadata and not using code. Metadata is a high level definition of business objects like forms, dialogs, validations and other things that are part of a business process that build a business application.”

Eyal Pfeifel contrasts metadata driven development with traditional coding or manual programming. “Unlike code which is tied to a specific platform or operating system, metadata is a high level definition and theoretically can run on any platform or operating system. Given that you have the appropriate runtime engine, you can build an application built using metadata on any kind of a device, server or client,” says Pfeifel.  

As Chief Technology Officer for Magic Software, Pfeifel certainly knows what he is talking about when it comes to traditional programming languages. Magic Software uses these more difficult third-generation languages (3GL’s) to create the metadata driven platform that is integral to Magic Software’s higher level and more intuitive application platforms. For this reason, he is keen to recognize the benefits of the metadata paradigm over traditional programming. “One of the main benefits of working with a metadata driven development paradigm is that since metadata objects are high level business objects it is possible to build a complete business application in a much shorter time than it would take when using code.  And the same business logic that you can construct one time very easily is relevant for multiple platform and operating systems like desktops, servers and even mobile devices.”

As Magic Software introduces its impressively expanding capabilities as a mobile enterprise application platform provider, Pfeifel has found himself commenting a lot recently on one of his favorite subjects: mobile application development.  “Using a metadata driven platform it is very easy to extend an enterprise application that originally started on a desktop or on a server into mobile devices because once you have the runtime engine running on a mobile device, it can theoretically run any type of application that you built on a desktop,” Says Pfeifel.  “And you can extend your business processes into a mobile device without needing to rewrite the application from scratch and with minimal adjustments just to cater for the smaller screen size or different form factor of the mobile device.”

Magic Software has a strong reputation for providing expertise that can future-proof your application development investments. As one can see by sitting down with Eyal Pfeifel, Magic Software's future-proof expertise is based on extensive customer feedback, strong R&D investment and the mindset to continually think ahead. To learn more about the Magic application platform, visit magicsoftware.com.

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.