Over the last 3-4 months I have been on a project that involved setting up of a SAP Mobile Card utilising SAP Mobile Services within SAP Cloud Platform. Overall, it was a great project to be involved with and over this time I have been spruiking from the tallest mountain how great SAP Mobile Cards really are. They are brilliant if you already have OData services active in your environment but want to improve the User experience of daily activities such as Leave request approvals, Purchase Order approvals - as the templates on offer allow innovation at lightning speed! I know SAP Mobile Cards can be utilised in a multitude of other situations but I've yet to delve into these...watch this space for future blogs!
I did run a DEV garage session internally with my colleagues which allowed them to set up their own mobile card (you can read it here) and also recently presented SAP Mobile Cards at the SAP Tech Night held here in Melbourne. Having carried out all of these things I thought I would provide a blog that focused on the learning lessons from the project so that others can learn from my experience. I will try and add to this blog if I think of any others so make sure you [Follow] this blog to get the future updates!
I will describe each major learning lesson below.
When people look at a mobile card I suspect most would say - "What do you mean you need a UX Designer for this" but I can triple confirm that this is a naive statement. I have written countless blogs over the years about how important design is when designing and building applications within SAP Cloud Platform (or on any platform for that matter) and just because there may be less fields, or the real estate is smaller does not mean skimping on critical design activities. In fact this is even more reason to get a skillful UX designer involved. There is no doubt this will save time overall and ensure the mobile card user experience is nailed.
Additionally, here are some key reasons why UX Design is critical with SAP Mobile Cards.
A backend developer could also assist in some of the above activities so also important that the UX Designer, SAP Architect and Backend Developers work closely to get the best and quickest outcome.
This is a real key learning lesson for me. Spending time up front thinking about the applications that lend themselves to SAP Mobile Cards will alleviate headaches down the track. While all OData services could be set up and implemented within a SAP Mobile Card they don't always lend themselves to the wallet style application that SAP Mobile Cards provides. Why? Because there simply may be too many cards for users to process.
During the project the application which was being selected was changed a couple of times - mainly due to the revelation that there would be too many. Initially Approve Timesheets was chosen as the SAP Mobile card to implement however we quickly determined that there would be hundreds of cards rendered for most of the key users. This was going to be difficult to manage and the executive staff the Mobile cards project were aimed at would not receive this well. We then looked for other applications and found the Approve Leave Request application the best fit. The number of cards that would need to be approved or rejected was a much more manageable number.
Thinking about this prior to the project starting is a must. Key thought: how many mobile card instances will be generated? If hundreds then it is probably not a good fit to the SAP Mobile Cards application.
Determining the devices to be utilised when implementing SAP Mobile cards is really important. The applications on each OS are very different so selecting the device type up front will allow the full set of activities to be known and the type of onboarding processes that need to be included. Ideally, if possible, a single device type or OS should be selected as this makes the overall project alot easier to implement. You will start to understand this from the next learning lesson ;-).
The next key learning I had was around onboarding of new users - basically getting them started on SAP Mobile Cards. This is an area SAP are working hard on improving as I had mixed results especially on Android - and I am not saying this because I am an iPhone user. 🙂 Generally, we had different requirements for onboarding on Android than the Apple devices - this is a fact. Key learning is to make sure you spend enough time working through the entire onboarding process as it may take some time to confirm all of the steps. Additionally, a small video of the process or a user guide detailing the steps may be helpful. We did both on the project and these were well received. Another tip is to also test on a number of different devices - especially the various Android devices that are out there as they may all have different onboarding experiences.
For iOS I simply use the camera to scan the QR code and it then requests to open the SAP Mobile Cards application - so really easy onboarding process.
For Android, different devices provided different outcomes. Advice from SAP was to use Google Lens to scan the QR code to then execute the SAP Mobile Cards application however on a Samsung device this did not work at all and some did not have Google Lens (Note 10). Google Pixel devices sort of worked via Google Lens but not as easy as the iOS onboarding process. The last ditch effort was to download a QR code reader on an Android device and see if this worked but had no luck with this either. Since then I do believe this has improved so try it yourself and provide some feedback to the blog in the comments so that this knowledge can assist others.
Another option would be to use the Cloud Build option (within Mobile services) to build an apk file to then load on devices however this is definitely more work to onboard users and if there are hundreds of users then it may not be that feasible.
If multiple devices are to be used then I would recommend that the navigation options on iOS and Android are understood and detailed in advance. Users of each different device will need to know where to find the various operations that can be performed on the SAP Mobile cards. This differs between the various devices. While the layout of the card itself is similar on the iOS and Android devices the functionality within Mobile cards is found in different places. One example of this is the Activity Logs. This is shown in the below diagrams.
Figure:1 Android SAP Mobile Card layout - Activity Log
Figure:2 iOS SAP Mobile Card layout - Activity Log
You can see that in the Android device the Activity Log can be found by clicking on the 3 vertical dots and then choosing [Activity Log]. On the iOS device you need to select the top left icon to get to the Activity Logs. Knowing the differences in navigating and finding information between the different devices will make it easier for users down the track.
The actions themselves are in the same place (bottom left) however the icon that describes them is different. The same goes for the card flip from Front to Back. These are all very intuitive but to the uninitiated it can be quite tricky at the start to find everything so documenting them and communicating them to users is one key item to assist with a successful implementation.
In most cases there may be no backend OData service changes required to implement the application as a SAP Mobile Card however I would make sure some development time is included in the project just in case it is required. In the project I was involved in, I did need the assistance of a backend developer to provide more SAP Mobile Card friendly fields such as showing the Leave hours in 2 decimal places. While this can be performed using a script in the mobile card I much preferred the data coming directly from the backend. In this case, the on-premise Fiori application formatted the data however the OData service results retrieved the hours in 4 decimal places which looks odd on the SAP Mobile Card for the actual leave request. A number of fields had the same issue so the backend developer was utilised to include some additional fields in the OData service specifically to send the fields through as 2 d.p. Ideally I would try and limit complex formatting inside the SAP Mobile Card - while some of this can be done I would look more to the backend to supply exactly what needs to be rendered in the card. This is also better from a support and maintenance perspective.
Just because I hit the Approve action in the SAP Mobile Cards for a leave request does not necessarily mean the action is performed in the backend. 🙂 If the leave request is removed from the worklist then yes - it makes sense that in most cases this should have performed the approval successfully. HOWEVER, make sure backend objects are checked to make sure the actions are being performed successfully. Again, like the first point states - just because it is a SAP Mobile Card does not mean things will simply work. This is an application like any other so needs to be adequately tested!
A good option for testing that I found was to compare the SAP Mobile Card information to the existing application. The project I was involved in had an on-premise Fiori Launchpad and on-premise applications running however this SAP Mobile Card project was utilising SAP Cloud Platform and so I wanted to test with a standard SAP application in the cloud as a further check. To do this I simply enabled the cloud application (as I had already completed backend connectivity) as detailed in my blog. This worked really well and sped up the testing process overall as I did not have to log into VPN to access the on-premise FLP which was a godsend!
If you do hit snags during the testing process then the best thing to do is utilise the Network Trace functionality within Mobile services. Actions can be quite tricky to get right so at the start it makes sense to run a network trace to make sure the leave request action is performed, and successfully.
New updates were delivered by SAP a couple of weeks prior to the start of this project and one of those major updates included the ability to create a mobile card application from the SAP Web IDE Full Stack service. This involve creating an application from a new template type that was offered. The new template is called [Mobile Cards Kit Micro App].
Figure:3 SAP Web IDE Full-Stack - Mobile Cards Kit Micro App template
I did find the maintenance of the mobile card much easier in SAP Web IDE however once I had published to mobile services I then carried out any additional configuration in there directly. SAP Web IDE overall had more real estate to work with, especially when updating the html or css files themselves so made the development activity more efficient and of course easier.
I have noticed a recent update that allows you to link back to SAP Web IDE from the mobile card itself - I have not checked this out as yet but looks like a really good feature! Will update here when I know more.
Overall, the project was a success and delivered Approve Leave requests functionality via the SAP Mobile Cards wallet style application. It also covered the following main items:
Figure:4 SAP Mobile Card notification on Apple Watch
There are still a large amount of features for SAP Mobile Cards that I have not utilised including the Full-Text search options, the use of SAP Fiori elements annotations and widget support for Android. I look forward to trying out these options in the near future and reporting back to the SAP Community.
Lastly, like to shout out mark.wright5 and matt.carrier for their assistance throughout this project.
As always thanks for reading and hope the learning lessons covered in this help you - should you be part of a future project involving SAP Mobile Cards. Feel free to leave comments and Like this blog.
I did run a DEV garage session internally with my colleagues which allowed them to set up their own mobile card (you can read it here) and also recently presented SAP Mobile Cards at the SAP Tech Night held here in Melbourne. Having carried out all of these things I thought I would provide a blog that focused on the learning lessons from the project so that others can learn from my experience. I will try and add to this blog if I think of any others so make sure you [Follow] this blog to get the future updates!
I will describe each major learning lesson below.
UX Design Matters
When people look at a mobile card I suspect most would say - "What do you mean you need a UX Designer for this" but I can triple confirm that this is a naive statement. I have written countless blogs over the years about how important design is when designing and building applications within SAP Cloud Platform (or on any platform for that matter) and just because there may be less fields, or the real estate is smaller does not mean skimping on critical design activities. In fact this is even more reason to get a skillful UX designer involved. There is no doubt this will save time overall and ensure the mobile card user experience is nailed.
Additionally, here are some key reasons why UX Design is critical with SAP Mobile Cards.
- Screen real estate is limited so it is extremely important to show users exactly what they need to see to be able to perform the necessary actions on the specific cards rendered in the application. Due to the real estate limitations it is also important on laying out the fields in a meaningful way not just include all fields from the OData service.
- What actions are required on the Mobile card? UX research could be used here to make sure the necessary actions are captured and built into the application. This is even more important if several mobile cards are being implemented as they could potentially all have different action requirements. Knowing this detail prior to development is a key for success.
- There are multiple sides to the mobile card so sorting out which information belongs in the Front card and what information should be moved to the Back card needs to be determined and prior to development commencing.
- Other field requirements. During the design activity there may be additional field requirements not currently included in the OData service thereby requiring code changes in the backend. Identifying these up front are a plus and will save development costs over the course of the project.
- Card numbers. Additional UX research on exactly how many approvals/rejections are typically carried out by the various personas will provide valuable input into the applications that can be utilised as SAP Mobile Cards. This fits nicely into the next learning lesson.
A backend developer could also assist in some of the above activities so also important that the UX Designer, SAP Architect and Backend Developers work closely to get the best and quickest outcome.
Choose the Correct Application
This is a real key learning lesson for me. Spending time up front thinking about the applications that lend themselves to SAP Mobile Cards will alleviate headaches down the track. While all OData services could be set up and implemented within a SAP Mobile Card they don't always lend themselves to the wallet style application that SAP Mobile Cards provides. Why? Because there simply may be too many cards for users to process.
During the project the application which was being selected was changed a couple of times - mainly due to the revelation that there would be too many. Initially Approve Timesheets was chosen as the SAP Mobile card to implement however we quickly determined that there would be hundreds of cards rendered for most of the key users. This was going to be difficult to manage and the executive staff the Mobile cards project were aimed at would not receive this well. We then looked for other applications and found the Approve Leave Request application the best fit. The number of cards that would need to be approved or rejected was a much more manageable number.
Thinking about this prior to the project starting is a must. Key thought: how many mobile card instances will be generated? If hundreds then it is probably not a good fit to the SAP Mobile Cards application.
Device Determination
Determining the devices to be utilised when implementing SAP Mobile cards is really important. The applications on each OS are very different so selecting the device type up front will allow the full set of activities to be known and the type of onboarding processes that need to be included. Ideally, if possible, a single device type or OS should be selected as this makes the overall project alot easier to implement. You will start to understand this from the next learning lesson ;-).
Onboarding Users
The next key learning I had was around onboarding of new users - basically getting them started on SAP Mobile Cards. This is an area SAP are working hard on improving as I had mixed results especially on Android - and I am not saying this because I am an iPhone user. 🙂 Generally, we had different requirements for onboarding on Android than the Apple devices - this is a fact. Key learning is to make sure you spend enough time working through the entire onboarding process as it may take some time to confirm all of the steps. Additionally, a small video of the process or a user guide detailing the steps may be helpful. We did both on the project and these were well received. Another tip is to also test on a number of different devices - especially the various Android devices that are out there as they may all have different onboarding experiences.
For iOS I simply use the camera to scan the QR code and it then requests to open the SAP Mobile Cards application - so really easy onboarding process.
For Android, different devices provided different outcomes. Advice from SAP was to use Google Lens to scan the QR code to then execute the SAP Mobile Cards application however on a Samsung device this did not work at all and some did not have Google Lens (Note 10). Google Pixel devices sort of worked via Google Lens but not as easy as the iOS onboarding process. The last ditch effort was to download a QR code reader on an Android device and see if this worked but had no luck with this either. Since then I do believe this has improved so try it yourself and provide some feedback to the blog in the comments so that this knowledge can assist others.
Another option would be to use the Cloud Build option (within Mobile services) to build an apk file to then load on devices however this is definitely more work to onboard users and if there are hundreds of users then it may not be that feasible.
Card Operations
If multiple devices are to be used then I would recommend that the navigation options on iOS and Android are understood and detailed in advance. Users of each different device will need to know where to find the various operations that can be performed on the SAP Mobile cards. This differs between the various devices. While the layout of the card itself is similar on the iOS and Android devices the functionality within Mobile cards is found in different places. One example of this is the Activity Logs. This is shown in the below diagrams.
Figure:1 Android SAP Mobile Card layout - Activity Log
Figure:2 iOS SAP Mobile Card layout - Activity Log
You can see that in the Android device the Activity Log can be found by clicking on the 3 vertical dots and then choosing [Activity Log]. On the iOS device you need to select the top left icon to get to the Activity Logs. Knowing the differences in navigating and finding information between the different devices will make it easier for users down the track.
The actions themselves are in the same place (bottom left) however the icon that describes them is different. The same goes for the card flip from Front to Back. These are all very intuitive but to the uninitiated it can be quite tricky at the start to find everything so documenting them and communicating them to users is one key item to assist with a successful implementation.
Support for Backend Changes
In most cases there may be no backend OData service changes required to implement the application as a SAP Mobile Card however I would make sure some development time is included in the project just in case it is required. In the project I was involved in, I did need the assistance of a backend developer to provide more SAP Mobile Card friendly fields such as showing the Leave hours in 2 decimal places. While this can be performed using a script in the mobile card I much preferred the data coming directly from the backend. In this case, the on-premise Fiori application formatted the data however the OData service results retrieved the hours in 4 decimal places which looks odd on the SAP Mobile Card for the actual leave request. A number of fields had the same issue so the backend developer was utilised to include some additional fields in the OData service specifically to send the fields through as 2 d.p. Ideally I would try and limit complex formatting inside the SAP Mobile Card - while some of this can be done I would look more to the backend to supply exactly what needs to be rendered in the card. This is also better from a support and maintenance perspective.
Testing
Just because I hit the Approve action in the SAP Mobile Cards for a leave request does not necessarily mean the action is performed in the backend. 🙂 If the leave request is removed from the worklist then yes - it makes sense that in most cases this should have performed the approval successfully. HOWEVER, make sure backend objects are checked to make sure the actions are being performed successfully. Again, like the first point states - just because it is a SAP Mobile Card does not mean things will simply work. This is an application like any other so needs to be adequately tested!
A good option for testing that I found was to compare the SAP Mobile Card information to the existing application. The project I was involved in had an on-premise Fiori Launchpad and on-premise applications running however this SAP Mobile Card project was utilising SAP Cloud Platform and so I wanted to test with a standard SAP application in the cloud as a further check. To do this I simply enabled the cloud application (as I had already completed backend connectivity) as detailed in my blog. This worked really well and sped up the testing process overall as I did not have to log into VPN to access the on-premise FLP which was a godsend!
If you do hit snags during the testing process then the best thing to do is utilise the Network Trace functionality within Mobile services. Actions can be quite tricky to get right so at the start it makes sense to run a network trace to make sure the leave request action is performed, and successfully.
Development Process
New updates were delivered by SAP a couple of weeks prior to the start of this project and one of those major updates included the ability to create a mobile card application from the SAP Web IDE Full Stack service. This involve creating an application from a new template type that was offered. The new template is called [Mobile Cards Kit Micro App].
Figure:3 SAP Web IDE Full-Stack - Mobile Cards Kit Micro App template
I did find the maintenance of the mobile card much easier in SAP Web IDE however once I had published to mobile services I then carried out any additional configuration in there directly. SAP Web IDE overall had more real estate to work with, especially when updating the html or css files themselves so made the development activity more efficient and of course easier.
I have noticed a recent update that allows you to link back to SAP Web IDE from the mobile card itself - I have not checked this out as yet but looks like a really good feature! Will update here when I know more.
Summary
Overall, the project was a success and delivered Approve Leave requests functionality via the SAP Mobile Cards wallet style application. It also covered the following main items:
- Offline capabilities. This was seriously cool and when it states offline - it really offers this functionality. In the Actions Log you will see an All Actions and Pending Actions and in the latter any approvals/rejections performed while offline will be detailed until such time as the device is back online. I tested this a number of times and all was successful.
- Backend sample data. A really nice feature that was available included retrieving information from the backend OData service to see how the card looked with actual data. I have noticed this area being enhanced over the last few months so lookout for some changes in this space in the near future.
- Notifications. At the start this was a little hit and miss but by the end of the project this had improved immensely (guessing updates?) - including the appearance of notifications on my Apple Watch! Yes - this really did happen! The ability to Approve and Reject leave requests on my Apple Watch is HUGE and I can confirm that this functionality works. The reminders for each of the notifications I also found handy and so now I have set up the card to notify me on my Apple Watch nightly! 🙂 Hey - I did this for the SAP Tech Night and forgot to remove it :-).
Figure:4 SAP Mobile Card notification on Apple Watch
There are still a large amount of features for SAP Mobile Cards that I have not utilised including the Full-Text search options, the use of SAP Fiori elements annotations and widget support for Android. I look forward to trying out these options in the near future and reporting back to the SAP Community.
Lastly, like to shout out mark.wright5 and matt.carrier for their assistance throughout this project.
As always thanks for reading and hope the learning lessons covered in this help you - should you be part of a future project involving SAP Mobile Cards. Feel free to leave comments and Like this blog.
- SAP Managed Tags:
5 Comments
