Implementing a mobile deployment of PeopleSoft has a unique set of challenges and considerations. As we’ve been working with our customers on 4 active mobile implementations, I thought that this would be a topical blog entry to write.
What’s different and Whats’ the Same
When implementing mobile, there are a number of areas to consider as you plan your implementation:
For most organizations, self service is the set of transactions that are initially targeted for implementing. Although Self Service is nothing new from a PeopleSoft perspective, with delivered transactions for students, employees, and managers. However, the challenges created by user expectations on usability, access location, device platforms, and screen real estate size means structuring your project plan to gather end-user feedback on an incremental basis is imperative.
So far, all of our customers have structured their mobile projects as follows:
This allows the project team to gather feedback, manage expectations, and find issues in both infrastructure and usability.
Because much of your testing is going to occur on mobile devices, your PeopleSoft environments need to be accessible to them early in the process. For many organizations that have had a good amount of control over the browsers (devices) and the way that those devices are accessed, this can become a significant wrinkle. Therefore, the first question you need to answer is “how are the mobile devices going to access my PeopleSoft environments at each stage of the release process?”.
This differs from a standard self service model because in self service, you can go through almost the complete release cycle with standard equipment connecting inside your corporate firewall with wired connections before opening things up to the public internet. With Mobile, the devices must either connect using WiFi or using the phone carrier’s network. In both circumstances, your PeopleSoft web servers must be accessible to the segment of the network that the device is accessing which can add complexity to the process very early in the implementation. For our customer implementations, this is generally the first item we discuss to make sure there’s a plan for it (because the security and network team have to be involved in this and approve of the plan).
The solution can fall into 3 categories (note that many organizations will use multiple categories depending on where they are in the implementation process).
Troubleshooting and Problem Reporting
Although the robustness of the environments available on mobile devices has increased dramatically since the earlier smartphones, the process of reporting and troubleshooting issues creates a unique set of challenges. It is imperative that you define a process that allows your end-users to identify and report issues. Because most of the techniques we’re familiar with are related to using the browser on the mobile devices, this section will cover these techniques (as opposed to techniques for native applications on those devices).
As you approach this process, you should identify the following:
Reproducible Test Case
Because the debugging tools available on workstation browser are superior to those on mobile devices, and because it’s easier to share desktops using GoToMeeting or Webex for troubleshooting sessions, we recommend that you ask end-users to reproduce the problem on a workstation with the mobile rendering turned on. If the problem can indeed be reproduced in this manner, it will be much easier to troubleshoot it and even if it can’t be reproduced the developer will know that the problem lies specifically with the browser on the device.
When reporting the issue, the user should capture either the URL for accessing the page or the navigation followed to get to the page, the User used to access the system as well as the data put into the transaction. They should also capture a screenshot and send that on as well. If you have sufficient logging built into your mobile application infrastructure, you can also correlate this information with what’s in the logs.
Troubleshooting data can come from the following sources: