Offline Apps Series: Blog 2 Design

Blog 2: Design

In this blog, I go into more detail on the Design and Build process of your apps.

Look at the priorities you have assigned from the discovery phase and start working on one or maybe two of them to begin with.

Keep in mind that the cost of changes later in the project grow exponentially. Therefore, make sure to spend enough time to design the app and to name the features it must have.

Create a strawman

Be creative. Use paper and pencil to design the look and feel of the app! There is nothing like a visual representation to allow a free flow of thoughts. For me this also provides the quickest way to visualise and reflect to managers and end-users what the app would be like.

Do it in a workshop with the right people:

• You need a careful selection of the people who will use the app – to make sure it works for them
• And you need managers or supervisors in the room – to make sure it will capture the business value they are hoping for.

Play through some the important test scenarios, “day in a life of …”:

• Collect ideas and feature requirements
• Class them as must-have, should-have, nice-to-have.

In the follow-up of the meeting

• Estimate the cost of each feature!
• Play back the features and decide “in or out”?
• Document the outcome and decisions.

Refine your strawman design if needed, but do it at least once or twice.

Usability challenges in SAP

As you create the strawman, bear in mind and learn from the design errors which were made in the SAP GUI transaction and do not repeat them. Allow end-users to feed their experience into the workshop and listen to them! Address them when designing the app.

Below are listed a few of the typical challenges in the user experience with SAP and the resulting inefficiencies in the business.

Design Guidelines

Use following guidelines when designing the app and validate if you are breaching them:

• Show only what is needed, do not show what has the potential to confuse the user.
• Hide or deactivate buttons and fields based on context. If a button doesn’t make sense in each situation, why not hide it or deactivate it?
• Design the screen layout intuitively.In the western culture books are read from top-left to bottom-right. Organise the screen flow in the same direction, e.g.
  • Selections and filters belong on the top of the screen or list being displayed
  • The most used button like “save data” belongs to the bottom right.
  • Provide a consistent design. Do not have the same button placed in various places on screens, e.g., the back button should be always in the same place.
  • The fewer clicks or taps, the better. SAP’s search helps are notorious with popups which ask the user more questions they can bear.
  • Google search helps.If drop downs or work lists have a lot of entries, provide Google searches for it. Let the user enter only a few letters and provide a responsive hit list as the user continues to type. This works wonders when entering cost centres or G/L account numbers in purchase and finance apps! Combine key fields and description fields in those searches to allow for flexibility to enter the G/L account number or description.
  • One process step should be a simple “1-2-3-done”. If it takes more than 2 minutes, consider simplifying it further. Go back to drawing board and consider more design options and turn the process “upside-down” to gain new perspective of how to make the process simpler.
  • Consider device integration, can barcode, camera or GPS provide a better process if used in the right way? Further thoughts on device integration are provided in the Infrastructurechapter further below.
  • Provide understandable errors and warnings. Show them where the user can see them – not at the bottom, but right in the middle of the screen. Make them understandable for a layman if possible, avoid SAP terminology.
  • Validate all user entries. Give immediate feedback for entries if it would cause a problem in SAP. Think about which fields are mandatory and optional or shouldn’t be entered in circumstances.
  • Personalise drop-downs. Only show drop down entries which the user is allowed for in SAP, i.e., the user has appropriate SAP authorisation! For example, do not show drop downs for plants or company codes the user can’t process in SAP anyway. More so, only show drop down entries which make sense in the circumstance, e.g., based on a system status of the data which is processed.
  • Personalise work lists.  Filter + Sort are great, but ideally a personalised work list only shows me what I need to do – not somebody else’s work or work I have already completed. Don’t show work items to the user which they are not expected to process. A work item typically has a natural responsible person who must do the next step. Further, for lists with a lot of columns allow for the end-user to personalise the fields he wants to see, the sequence, the sort criteria etc. and store that for the next time the app is used
  • Red – Amber – Green.  Work lists have a colour-coded process status like new, processed, closed, error which tell the user quickly what he is expected to work on.

Wire-frame

Once we have gathered all the ideas and included them into the scope, create a wire-frame of the app in a tool of your choice. SAP provides www.build.me as a toolkit which includes the major UI objects of SAPUI5. That will give you the closest look and feel of what the new app may look like for the user.

Run it by the user again with your test cases and validate and refine it further and finalise your functional specification with it.

Specification

With the business agreement in place on how the app should work, write up the results into a specification document.

Understand, that we are building an application from scratch. There a couple of topics to address:

As we are essentially creating a new application from scratch we have to describe the flow of information “light” enough for a business user to approve it and “detailed” enough for a SAP developer to understand how to implement it.

• Describe the screens and the screen flow, i.e., what menus you will have once you build your complete suite of apps – this is important so you can design the launch pads with the final look and feel for the end users. Describe the high-level flow how you navigate from one screen to another one. Yet again the build.me wireframe is a good tool to do so.

• Describe the data flow, i.e., name the affected SAP business objects. Align the app screens with the business objects and where and how they are used. Name the used fields in list and screens. Be clear if the user wants to see the key field or description, e.g., do we need to show the vendor number or name or both?
• Describe the buttons and events, i.e., describe what buttons are on the screen and what happens if the user clicks/taps on it or a field or a row or column?
• Describe the SAP integration functions, i.e., Name the read SAP tables or function modules and the posting functions for each business object, ideally name the BAPI function module name which should be used for each posting. Align the read and posting functions to the buttons, events or clicks and taps down on the screens.

Specific considerations for offline apps include:

• Name which data is stored locally on the app and what it is used for?
• Name all search helps and drop downs the user will need – otherwise we can’t validate them once we are offline with the app!
• Think about status management of any offline work list, was it processed, but not yet synchronised with SAP?
• Consider error management. A typical one is locking problems. What happens if the object is locked by another user in SAP when I synchronise my data? Hence, using BAPIs is the recommended approach for posting any change via a mobile app to SAP, because it uses the SAP locking mechanism correctly.
• Design an outbox. Best practice is to design address error and lock problems is that all postings are queued into an “outbox”, similar from what we know from our e-mail client. We can write emails whilst travelling on a plane and just store them in the outbox until the time I am back online and then synchronise them. Then, when any posting error occurs, the messages returned from the BAPI can be stored alongside the entry in the outbox and the user can read them and take appropriate course of action – in the simplest case of a lock problem, you would just attempt to “resend” the posting to SAP later.
• Be also clear on target devices, security aspect and user authentication, see chapter Infrastructurechapter next for more thoughts on that.

Have a plan

Bring it all together and build an implementation plan covering the app development and deploying the infrastructure, see next chapters.

The plan as such follows standard SAP project activities covering:

• Build
  • Application build
  • Any required amendments to SAP configuration and data transformation
  • Mobile app build and deployment
  • Security and Certificates
  • Unit testing
  • Test
    • Deploy to test system
    • Business acceptance testing
    • Deploy
      • Preparing go live

A note on training which should be easy since your app should be intuitive to begin with!

• Deploy to production
• Go-live, Hypercare and handover

Secure resources

Allocate or secure the resources you need:

• The design consultant – an authority who understands the business end-user, but also knows how to simplify their day by knowing app design
• The functional consultant – involve the person responsible for the SAP module. Often, you the new app requires some simple adjustments in the SAP process already in place.
• The ABAP developer – You will need someone who understands the underlying database in SAP and how to code that correctly.
• The SAPUI5 app developer – app development is a new skill, requiring design skills with HTML5 (on which SAPUI5 is based) and new language skills JavaScript. — That said, with Neptune you can extremely simplify the app development process since you basically just upskill your ABAP developer to do the SAPUI5 at the same time! Get two developers for one.
• The basis consultant – you need a good communication to the SAP technical team to put authorisation in place and getting access to the app to begin with. This is also your line of communication to your resources in the wider corporate network
• The wider IS team – Identify who is responsible to deliver other activities like source, deploy and provide access to a mobile MDM system, providing security certificates, or who can sign up to other cloud services like Apple enterprise developer program and Adobe Phonegap.

And include the wider project team

• Business representatives – for testing activities and feedback. Involve them as much as possible in the process to hit the expectations. Allow for cosmetic changes in the plan, but be firm on features which can be covered in later project phases or your BAU process.

Get a formal development estimate from your developer now for the app design and the data integration into SAP and seek formal approval from the business process owner now to proceed.

Note, that for the first project also the technical infrastructure must be put in place, but the business justification should consider that the payoff for it is across all targeted business use cases, not just the first one!

Outlook

In the third blog, I will explore the technical and security aspects I need to consider when building a mobile app.

Contact us to discuss your specific needs or for more information.