openSAP

Building Mobile Applications with SAP Screen

Personas
Week 1 Unit 1

00:00:07 Hello and welcome to week one, unit one, of our openSAP course,
00:00:11 Building Mobile Applications with SAP Screen Personas. My name is Sebastian Steinhauer

00:00:15 and I am the Vice President for SAP's UX Engineering team responsible for SAP Screen
Personas.
00:00:21 Throughout this course, you will learn how to use SAP Screen Personas
00:00:24 and the Slipstream Engine to quickly and easily create and deploy
00:00:28 low-code mobile applications. While SAP Screen Personas and the Slipstream Engine
00:00:33 work great on desktop devices, in this course we will focus only on the mobile aspect.
00:00:39 To get a more solid understanding of SAP Screen Personas, I encourage you to also check
out our other openSAP courses.
00:00:47 After taking this course, you should be able to use SAP Screen Personas
00:00:51 and its flavor editor to create mobile applications targeted at your company-specific use
cases,
00:00:56 that are ready to render on your mobile devices using the Slipstream Engine,
00:01:01 our SAPUI5-based rendering engine. The material in this course targets several different
roles:
00:01:07 business analysts, developers, enterprise architects, and designers.
00:01:11 We will cover different aspects related to each of the roles.
00:01:14 For example, as an architect, you will learn how SAP Screen Personas works.
00:01:19 As a developer, you will see how you can write scripts that access native device features
00:01:24 when running in the Fiori client. As a designer, you will get valuable insights
00:01:28 into flavor design for mobile devices. And as a business analyst,
00:01:32 you will learn how to create flavors and execute SAP Screen Personas projects
successfully.
00:01:38 In contrast to previous openSAP courses on SAP Screen Personas,
00:01:42 this course will follow a simple mobile project from initial user requirements to successful
rollout,
00:01:49 and it touches many of the latest features and developments in SAP Screen Personas and
the Slipstream Engine.
00:01:55 We will continue week one with an introduction to the Slipstream Engine
00:01:58 and planning a mobile project. In week two we'll focus on
00:02:02 how to break down complex scenarios for mobile devices, specifically considering screen
real estate
00:02:08 and mobile network performance. In week three we'll discuss
00:02:11 how to roll out the mobilized SAP scenario to your end users.
00:02:15 With that as a high-level overview of this course, let's talk about what you are going to learn
this week.
00:02:21 Today, we'll talk about low-code development platforms. In the next unit, we'll provide you
00:02:26 with a solid understanding of the Slipstream Engine as the underpinning technology used in
this course.
00:02:32 In unit three, we'll discuss the scenario that guides the course and how to learn from end-
user interactions
00:02:38 early in the development process. Unit four will introduce you
00:02:41 to the principles of mobile application design. And in unit five,
00:02:46 we'll get started with using SAP Screen Personas to design the mobile application.
00:02:51 At this point, I have mentioned the term "low-code" a few times.
00:02:56 It's about time we make sure we have the same understanding of it.
00:02:59 Low-code development platforms allow you to create applications predominantly through
00:03:04 graphical interaction and configuration, instead of traditional programming languages.
00:03:10 While the concept is not new, the term "low-code" started to emerge around 2014.
00:03:15 It's important to note that the term "low-code" is coined very carefully
00:03:19 to indicate that these platforms reduce, but do not necessary eliminate the need for hand-
coding.
00:03:27 The fundamental idea of a low-code development platform is that a wider range of people
can contribute actively
00:03:34 to application development, and that their target audience is not limited to formal
developers.
00:03:40 Low-code development platforms emerged to allow for quick creation and deployment of
applications
00:03:46 that can address the specific needs of a business organization,
00:03:49 while side-stepping the formal software development process. SAP Screen Personas with
the Slipstream Engine
00:03:55 is a low-code platform designed specifically to create mobile applications
00:04:00 on top of existing SAP functionality. Fundamentally it allows you to take
00:04:06 any classic SAP transaction as a starting point and rapidly create a mobile application.
00:04:12 This is done by removing unnecessary elements, adding new elements,
00:04:17 and the use of a "what you see is what you get" editor to create a mobile experience.
00:04:21 We also provide an integrated and easy-to-use scripting environment, and several tools
00:04:26 to ensure a smooth rollout in your company. As you can see, we designed SAP Screen
Personas
00:04:33 to combine the flexibility of an easy-to-use graphical programming environment
00:04:38 with the functional richness of SAP to bridge the between quick solutions required by
business organizations
00:04:45 and the need for a centralized system of record with a controlled staging and rollout.
00:04:51 Today we talked about the general structure of the course and the different target audiences
for SAP Screen Personas
00:04:57 as a low-code development platform. In the next unit, Tobias Queck, our Chief Architect,
00:05:04 will cover the inner workings of the Slipstream Engine and why it's a fundamental departure

00:05:08 from the classic SAP approach to Dynpro rendering. I hope you'll enjoy the remainder of this
course.
00:05:14 Have a great day.

2
Week 1 Unit 2

00:00:07 Hello and welcome to week one, unit two, of our openSAP course, Building Mobile
Applications with SAP Screen Personas.
00:00:14 My name is Tobias Queck and I am the Chief Architect responsible for SAP Screen
Personas
00:00:18 and the Slipstream Engine. Last time, Sebastian introduced the course
00:00:22 and today we will be talking about the architecture of the Slipstream Engine.
00:00:26 We will focus on the added flexibility in consuming flavors, as well as the simplified
maintenance.
00:00:32 Before going into the architecture of the Slipstream Engine, let's quickly have a look
00:00:36 at the inner workings of SAP Screen Personas when used with the SAP GUI for HTML.
00:00:42 At a high level you have three layers on the server side. On top, you have the business
applications
00:00:46 that are unaffected. The next layer, your SAP S/4HANA or SAP NetWeaver,
00:00:51 is where SAP Screen Personas is installed as an add-on and it interacts with the core
components
00:00:56 of the ABAP program execution. The add-on not only contains the back-end logic
00:01:00 but also the client sources that are executed when using client-side Personas features.
00:01:05 As the lowest layer, you have the SAP NetWeaver Kernel containing the Internet
Transaction Server, ITS.
00:01:11 The ITS is responsible for generating the HTML representing the transactional screens,
00:01:16 as well as applying your changes defined in SAP Screen Personas flavors.
00:01:21 And, of course, to consume a flavor, a supported desktop browser is required for your end
users.
00:01:27 From a business perspective, the most important architectural change
00:01:30 is that we are using the SAPUI5 libraries for the Slipstream Engine,
00:01:34 allowing us to support desktops as well as mobile browsers. The SAPUI5-based files
required to render your screens
00:01:42 are bundled together with the existing SAP Screen Personas sources, so that you as a
customer
00:01:47 get the latest and greatest version as part of the SAP Screen Personas client note.
00:01:52 As a result, it is no longer necessary to update the kernel for corrections of the renderer.
00:01:57 We also switched from a server-side rendering to a purely client-side rendering and
applying of flavors,
00:02:03 simplifying the requirements and dependencies for the kernel even further.
00:02:07 Finally, less data needs to be exchanged between the front end and back end,
00:02:11 because the back end does not send fully rendered screens but only the data model
required to render these screens.
00:02:17 This approach has a positive performance impact and is similar to the communication
00:02:20 between the back end and the SAP GUI for Windows. Independent of the Slipstream
Engine,
00:02:25 your SAP Screen Personas flavors will still work with the classic GUIs,
00:02:29 and you should always choose the consumption channel that fits your requirements.
00:02:34 There are scenarios where the SAP GUI, even with a limited feature set, is the best choice.

00:02:38 In other cases, perhaps a homogeneous user experience needs to be delivered

00:02:42 using the SAP Fiori launchpad. While the Slipstream Engine has been developed

3
00:02:47 with the focus on being used with mobile devices, it also is an alternative for desktop
browsers.
00:02:53 Especially when using the SAP Fiori launchpad, the Slipstream Engine is an interesting
option
00:02:58 because it is bundled like an SAP Fiori app, and can therefore be embedded into your
launchpad.
00:03:04 Additionally, we provide a launchpad plugin, making the integration smoother and simpler.
00:03:10 As previously mentioned, our goal was and is to deliver a rendering engine
00:03:14 that allows you to mobilize your SAP transactions. Not only does the Slipstream Engine
00:03:19 allow you to run SAP transactions in mobile browsers, it also enables access to native
device features
00:03:25 like the camera, when being used together with the SAP Fiori Client.
00:03:31 Delivering mobile access to your SAP transaction not only requires support for mobile
devices
00:03:35 but also the possibility that you might access your screens from the public Internet.
00:03:40 As a result, we made sure that you can expose the Slipstream Engine
00:03:43 using the SAP Web Dispatcher, or in combination with the SAP Cloud Platform and the SAP
Cloud connector.
00:03:50 So from an architectural perspective, there is nothing stopping you from mobilizing your
SAP transactions.
00:03:56 In this unit, you got an overview of the architectural changes
00:03:59 introduced by the Slipstream Engine. We showed you how it reduces maintenance effort
00:04:04 while also allowing you to consume your flavors where, when, and how you need them.
00:04:09 Next, we will talk about the planning of your mobile application project.
00:04:14 Thank you.

4
Week 1 Unit 3

00:00:07 Hello and welcome to week one, unit three, of our openSAP course, Building Mobile
Applications
00:00:12 Building Mobile Applications with SAP Screen Personas. My name is Sylvia Barnard.
00:00:20 Last time, we wanted to give you an understanding of the architecture behind Slipstream
Engine:
00:00:26 where things are stored, processed, and so on. Today we will focus on the planning
00:00:33 of your mobile application. Customers, your business process manager,
00:00:40 or your users might come to you and request a mobile app for a SAP GUI transaction that
was developed
00:00:48 for desktop usage, without having a clear picture of what that means or knowing exactly
what they want.
00:00:56 So before jumping on a mobile project, your first step should be to determine whether
00:01:02 it makes sense to create a mobile app out of an existing SAP GUI transaction.
00:01:09 Some transactions are so complicated with large lists, lots of tabs, and mandatory input
fields
00:01:16 that they are not well suited to being turned into a mobile app. In those cases, it would be
better to see if you can modify
00:01:26 an existing SAP Fiori app or create your own custom app. But, if you believe your
transaction is a good candidate
00:01:36 for a mobile app, it's time to get a better understanding of your project.
00:01:41 To get started, ask your stakeholders and future users the following questions to get the big
picture:
00:01:50 Why do they need this specific transaction simplified in such a way that it will run on a
mobile device?
00:01:58 Will users be working in countries or in areas where there is no online access?
00:02:05 In which case, SAP Screen Personas is currently not suitable.
00:02:10 What does the work environment look like? Who will be the users or the user groups?
00:02:16 How are they currently doing their job? What problem would the mobile app solve?
00:02:23 How many users will be using it and how often will they use it?
00:02:29 What are their preferred mobile devices? What is your timeframe?
00:02:34 Who are your stakeholders? What budget and skills do you need to access
00:02:41 This is not a one-person project that can be done on the side.
00:02:46 Of course, your questions may be different, but this list is intended to point you in the right
direction.
00:02:55 Once you have a better understanding of your project, it's time to put together your team.
00:03:02 A typical SAP Screen Personas project needs to be staffed with a business project expert,

00:03:09 and this is someone who knows how that transaction works in detail, where mandatory
fields need to be filled out, and so on.
00:03:18 Then you need an SAP Screen Personas expert. And this is someone who knows their way
around
00:03:24 SAP Screen Personas, and who can build screens and write scripts with JavaScript.
00:03:30 And then you need a user researcher or a design expert. And this is someone who can help
with understanding
00:03:37 users' needs, create wireframes, and drive the visual and interaction design of the screens.

00:03:44 Now that you have your project outline and a team, where do you get started?

5
00:03:52 Using design thinking is always a good starting point. This will allow you to guide your team

00:03:59 through the whole project. We covered design thinking within the context
00:04:05 of SAP Screen Personas in our introductory course, so I will not go through every single
design thinking step here,
00:04:14 but I will show you how to factor it into your mobile application project.
00:04:20 If you want to refresh your knowledge on design thinking, please take a look at our previous
openSAP course, called:
00:04:29 Introduction to SAP Screen Personas. To make some of the design thinking steps more
tangible for you,
00:04:37 we have created a hypothetical use case to illustrate some of its concepts.
00:04:44 We will maintain this scenario through the remainder of the course.
00:04:49 In our case, we will be looking at workers in a typical office environment, who occasionally
come across items
00:04:57 that are broken and need the attention of the facilities or IT teams.
00:05:04 For example, an employee wants to report a malfunctioning printer, broken toilet flusher, a
dead lightbulb,
00:05:12 and so on. The expectation is that there is an easy way of reporting
00:05:19 things that need repairing - so how about providing a mobile app where you can do just
that?
00:05:27 Create a repair notification right on the spot, rather than having to walk back to your desk
00:05:34 and open a message on your laptop. This prevents you from forgetting the room number,
00:05:40 the device name, or other relevant information. So, how to get started.
00:05:48 Get an understanding of the existing desktop application. Be familiar with how it works and
its limitations.
00:05:56 This is your basis for everything. From there, get your users and stakeholders involved.
00:06:03 Talk to the employees that will be using the app, as well as IT and facilities colleagues
00:06:10 that will be interacting with the tickets. Ask and observe how users create a message
00:06:17 in the current system, understand how IT or facilities work on it, distribute it to a technician,

00:06:24 and then close it. Ask your users what works well and what doesn't
00:06:29 in the current process - what information they would need, but is missing; what data on the
screen is never used.
00:06:38 It is essential to know the straightforward scenario, what functionality and information is
required
00:06:46 to provide sufficient data for 80% of the notifications, orders, and so on, entered into your
system.
00:06:57 This ensures that all parties involved can proceed without needing to request further
information
00:07:04 the majority of the time. So don't start with your edge cases,
00:07:09 focus more on your average use case. In our example, we want to report a broken
00:07:17 or malfunctioning item in a certain location. The facilities and IT team in our scenario require

00:07:25 location, floor, room, device type, device number, maybe a description of the issue, and the
priority level.
00:07:35 You will get an understanding of your 80% scenario during your research.
00:07:42 Be sure to actually confirm the required data with all of your users. Now that you have
observed, interviewed,
00:07:51 and found your typical scenario, the user research aspect of this project is complete.

6
00:08:00 Next is analyzing the data from your interviews and observations, and looking for patterns.
00:08:07 You can use the results of this analysis to create a rough design on a whiteboard with your
project team.
00:08:16 You should only focus on the data that needs to be on that screen.
00:08:23 So from your data analysis, you know exactly which fields users require on the screen:
00:08:29 the location, the building, the floor, the room, the equipment, a problem description, the
priority, the status, et cetera.
00:08:39 So, why don't you list that on the whiteboard? So that would be, for example, the location,
00:08:46 the building, the floor, the room, now the equipment, a description,
00:09:01 the priority, and the status. And then you need a save, or the submit button,
00:09:11 depending on your guidelines, and also a cancel. Now one thing that the interviewees
possibly
00:09:17 did not say because they did not know, is that you can add a "Scan equipment" button to
the screen
00:09:25 with SAP Screen Personas, where the reporter of an issue simply scans the QR code of the
broken machine
00:09:33 and most of the data listed here gets pre-filled automatically after scanning.
00:09:39 So I will add here now the "Scan QR code" to the list. And when you scan that, all this here

00:09:51 gets pre-filled automatically. So this is why you might not want to start with the location,
00:09:59 the building, the room, but more likely with the equipment, and the problem description, the
priority and the status.
00:10:06 So that would be this here. So this is the first, this is the second,
00:10:12 and this would be the third on the screen. And underneath, then, the data will get filled,
00:10:21 and you can show the precise location after scanning it to get a confirmation
00:10:26 that this is the right machine. So, the next would be to put all this
00:10:33 into a very first rough first sketch. So start with a phone frame, and this could look like this.

00:10:43 It doesn't have to be too pretty, but you get a feeling. Then you start with your scan QR
code.
00:10:52 So that is here your Scan button. The you have the equipment that gets shown here.
00:10:58 Then you add the description. And here you need an input field where you can type in the
stuff.
00:11:05 You add the priority, and the status, and the location will get pre-filled automatically
00:11:14 when you scan the QR code. So now you add the Save or the Submit button, and a Cancel.

00:11:22 So this is what your very rough sketch could look like. Use those initial sketches to create a
mock-up
00:11:30 with wireframes, where you include a rough visual design in addition to the data needed.
00:11:37 After you have done your first sketches, test your wireframes with your user group
00:11:42 and stakeholders, and iterate based on their feedback. Keep testing it until you get it right,

00:11:49 as this will be the basis for the next step: the building of your flavors with the final design.
00:11:58 We won't show that here, since we will build the flavors throughout the other units of this
course.
00:12:06 Once you have built your flavors, roll them out to your test group and let them try it out.
00:12:13 Again, continue to include your users' feedback as you iterate and reiterate the flavor.
00:12:22 Once you have a flavor that successfully incorporates your users' feedback, it's time for the
official rollout.

7
00:12:32 Two very important factors in this rollout are the communication with the users
00:12:38 and the change management process that is needed for all processes that will be different
than before.
00:12:46 If your end users do not know what's coming, what is happening, if they feel excluded,
00:12:53 or think that this is just another transaction or change being flung at them,
00:13:00 your project will possibly fail and users will not use it. Do marketing for your project and the
resulting application.
00:13:10 There are plenty of ideas on how to get users involved through the interviews, the testing,
find-the-bug- program,
00:13:19 little video snippets - you name it - then do it! With all of that, you now have, in theory, an
outline
00:13:30 of the project setup, and how to achieve the desired design of the app.
00:13:38 Today we talked about the planning you need to do for your mobile application project.
00:13:45 You learned the important questions you need to answer before you start your project:
00:13:51 does it make sense to rework and simplify an existing SAP GUI transaction for a mobile
device?
00:13:59 What transaction will you simplify? Who needs this mobile app?
00:14:03 Why do they need it? What is their work environment?
00:14:08 Do users need offline access? And so on.
00:14:13 We discussed the required members of your project team, then we touched on how to
integrate design thinking
00:14:21 into your project, as well as how to address change management and the outcome of the
project is a rolled-out mobile app
00:14:31 that will make people's lives run better. Next time, we will talk about the considerations you
need to make
00:14:41 when designing mobile apps. Thanks for watching!

8
Week 1 Unit 4

00:00:07 Hello and welcome to week one, unit four, of our openSAP course, Building Mobile
Applications with SAP Screen Personas.
00:00:15 My name is Peter Spielvogel. Last time, we talked about the role design thinking plays
00:00:20 in planning your mobile application project and how to capture customer requirements
00:00:24 to create a rough outline of your app. We also introduced the business scenario
00:00:29 for which we will build our mobile app during this course and the general skill sets you
should have on your team.
00:00:36 Today we will focus on the unique design requirements for mobile applications,
00:00:41 which are somewhat different than for desktop flavors, as you have much less screen real
estate to work with.
00:00:47 The smaller form factor of mobile apps determines how they look and behave,
00:00:52 and really forces you to prioritize what you want your app to do.
00:00:57 One common element for designing any app, whether desktop or mobile,
00:01:02 is that you must start with the user and think about how they will interact with the
application.
00:01:07 In the last unit, we talked about the role designers play in understanding user requirements.

00:01:14 As with most job functions, there are several different types of designers.
00:01:18 For a successful SAP Screen Personas project, you should have both interaction
00:01:23 and visual designers on your team, as they play key and complementary roles.
00:01:30 Interaction designers focus on the overall business scenario and workflows.
00:01:35 They produce wireframe diagrams that illustrate how people
00:01:39 will flow through the application. They ensure the app will make sense when people use it.
00:01:45 Visual designers help you design an aesthetically pleasing app. This is often the role that
people think of
00:01:52 when they hear the term "designer". Visual designers focus on following
00:01:56 your corporate standards and aligning the colors, fonts, and layouts with your corporate
guidelines.
00:02:02 Without a competent visual designer, it's unlikely you will end up with a good-looking
00:02:08 You should have a basic understanding of design to work effectively with your business
users and designers.
00:02:14 The most fundamental thing to consider when building a mobile app is that screens are
small,
00:02:19 so you'll need to prioritize what you want the app to do and then focus the user on a single
task.
00:02:25 Maybe two closely related tasks, at most. This may require breaking a single transaction
00:02:31 into smaller chunks. Don't try to replicate the full functionality
00:02:35 of an SAP GUI transaction that runs on the desktop. Either the development effort or the
resulting screen
00:02:42 will be too complex to be useful or maintainable. Instead, create a flavor
00:02:48 that focuses on the one or two tasks you have in mind. To optimize the limited screen real
estate,
00:02:54 decide if your users will consume the app on a tablet or phone or both.
00:02:59 Then, build dedicated screens for the devices that will run your apps.
00:03:03 This will likely require different versions of the for each screen size,
00:03:08 perhaps even landscape and portrait versions. For the app that people will use

9
00:03:13 to report broken items around the office, we will certainly need a phone version.
00:03:18 Most people carry their phones around with them, so they will have the tool they need
00:03:23 to create repair notifications, wherever they are. Many people also use tablets and carry
them to meetings,
00:03:30 as they are much more useful for taking notes, since the keyboard is larger and easier to
use.
00:03:36 So, we should plan on building both tablet and phone versions of our notification app.
00:03:43 SAP Screen Personas makes it easy to build flavors once and reuse your logic.
00:03:48 We call this "adaptive flavors". This functionality automatically switches flavors
00:03:54 based on the screen size available. Just build your main flavor, which could be on a
desktop,
00:04:00 then create flavors for each device or form factor and tell SAP Screen Personas
00:04:06 what size to switch to the next one. We will show you exactly how to do this
00:04:11 in the second week of the course. When building screens for mobile devices,
00:04:16 there are a few other items to keep in mind. Don't overwhelm the user with too many
choices.
00:04:22 A simple app that does one or two things really is much better than a more complex mobile
app
00:04:27 that's hard to use. If it doesn't work quickly and easily,
00:04:31 people won't use it. You probably have at least
00:04:34 a few examples of these on your own phone. For example, instead of providing every option

00:04:40 to create a service notification, choose the path that people take most of the time.
00:04:46 Generally there's an 80 or 90% path that people usually follow.
00:04:52 Don't add complexity to your app that will slow everyone down by forcing additional clicks
00:04:57 for the sake of covering scenarios that occur only 10 or 20% of the time.
00:05:02 If you must cover them in your mobile app, have a fast path and a separate route
00:05:08 or maybe even another app for the more complex cases. On a similar note,
00:05:14 good mobile apps follow a principle called progressive disclosure.
00:05:18 This means you present the minimum amount of information required for a task,
00:05:22 while allowing users to access more details, if required. Not only does this keep the screen
design simple,
00:05:29 it usually also improves performance as you're retrieving less information from the back
end.
00:05:35 This is especially important for mobile apps as they often have slower connections
00:05:40 than in an office environment. You can use progressive disclosure in the example above
00:05:46 regarding creating a service notification. Allow people to enter the minimum information
required
00:05:52 and then add more details, if they need to. We have a new feature in SAP Screen Personas
called Viewports,
00:05:59 which is especially useful for breaking complex screens into simpler units.
00:06:03 We'll cover this next week. There are a few other design tips
00:06:07 that will make your mobile app more usable. Try to minimize scrolling in the vertical direction

00:06:13 and keep all or most of the key buttons and information on the initial screen.
00:06:19 This will be easier on larger devices, so you will probably want to consider
00:06:23 simpler functionality for phones when compared to your tablet application.

10
00:06:29 In all cases, you should eliminate any horizontal scrolling, as it is difficult to maintain the
context on the screen
00:06:36 if it's moving in two dimensions rather than just Think about how people will be viewing your
screen.
00:06:43 If you shrink a desktop screen to a phone's dimensions, the text will likely be too small for
most users to read.
00:06:50 When designing your app, consider the font size and even the font choice.
00:06:55 Some typefaces are much easier to read than others. Similarly for buttons on the screen,
00:07:02 ensure they're large enough to click easily, with enough space
00:07:05 so your user does not inadvertently hit the wrong The best rule of thumb for readability
00:07:11 is to test with a variety of users across different age groups.
00:07:15 You can then ensure that all the people who work in your office
00:07:18 are able to use the app. Another factor to consider
00:07:22 is how people will interact with the screen. For tablets, it could be similar to how people use
a desktop system,
00:07:28 if the tablet is sitting on a flat surface giving the users full access to the keyboard.
00:07:34 Or, they might be carrying the tablet with one and typing with the other.
00:07:39 For phones, some people hold them in one hand and type with the other.
00:07:43 Another possibility is that someone might operate the phone with one hand.
00:07:48 For the one-handed operation category, consider putting the action buttons
00:07:53 on the bottom to facilitate one-hand operation. Again, watch how your users interact
00:07:59 with prototypes of your app to determine how to fine-tune
00:08:02 the locations of controls on the screen. Navigation often plays a major role
00:08:08 in how usable an application is. If your app has several steps,
00:08:13 each building on the previous one, a person could lose their context.
00:08:17 For example, if you're creating a service notification, you might need to enter a description
of the broken item,
00:08:23 its location, and the symptoms of the problem. If you're doing this on the phone,
00:08:28 it's likely you'll need to do this on separate screens for space reasons.
00:08:33 So, always allow easy navigation, whether it's breadcrumbs on the top of the screen
00:08:38 to indicate where someone is or an easy way to jump back to the home screen
00:08:43 if they get lost in the application. Today we talked about Designing Mobile Applications
00:08:48 and how to make the most of a phone or tablet screen. We covered the differences
00:08:53 between interaction designers and visual designers, why both roles play critical parts in your
project team.
00:09:01 We talked about the importance of looking at all the functionality of a SAP GUI transaction

00:09:05 and determining how to break it into individual apps. We discussed various factors to
consider
00:09:11 when designing a mobile app, such as progressive disclosure, typography, button layout,
and navigation.
00:09:19 Next time, we will talk about Using the SAP Screen Personas Editor in the Slipstream
Engine,
00:09:24 where you'll have a chance to put the theory we have talked about so far into action
00:09:29 by starting to build a mobile app with SAP Screen Personas. Thank you.

11
Week 1 Unit 5

00:00:06 Hello, and welcome to week one, unit five, of our openSAP course,
00:00:10 Building Mobile Applications with SAP Screen Personas. My name is Vandana Deep.
00:00:15 Last time, we talked about some best practices for designing mobile applications using SAP
Screen Personas.
00:00:22 Today, we will focus on building a flavor designed for a mobile device using
00:00:26 SAP Screen Personas editor in Slipstream Engine. Let's take a look at the create
notification transaction, IW21.
00:00:35 Here, I'm going to provide the notification type "m2", and hit enter.
00:00:40 This gets me to the transaction screen. Now, on a tablet device, this is too much
information.
00:00:46 So, basically we're looking for the workers to be able to quickly log a report
00:00:52 for malfunctioning equipment. The screen elements that may be of importance to them
00:00:57 are the functional location from the Notification tab, the equipment details, and of course the

00:01:03 description and the subject long text. In addition, the worker would need to provide
00:01:10 the malfunction start date and time, and whether it's a breakdown or not.
00:01:17 The other pieces of information that need to be surfaced up on the tablet device
00:01:22 are from the location data. In the location data, we have the maintenance plant,
00:01:28 the location, the room, the plant section, and the work center.
00:01:33 Let's take a look at how this transaction works. So I switch to the Notification tab.
00:01:43 I specify the equipment. Maybe I pick up the gearbox over here.
00:01:52 I specify what's wrong with the gearbox. And then I click on Save.
00:02:04 This saves the notification. Once you have captured the key user requirements for a mobile
app,
00:02:11 you are ready to build it using the Flavor Editor in Slipstream Engine.
00:02:15 It's important to note that flavors can only be created and edited on the desktop using the
editor.
00:02:21 Once created, the flavors can be rendered on the targeted mobile device.
00:02:26 So let's get started creating this flavor for the transaction.
00:02:31 Let's start by creating a copy of this original, unmodified transaction.
00:02:37 Let's call it: "SPS4 Notification W1U5".
00:02:55 The first thing I want to do is skip this screen because I'm going to provide the default
notification type.
00:03:01 The way we will do this is by using scripting. So let's save the flavor here.
00:03:09 Let's switch to the script editor. Now I'm going to use Start Recording for the script
00:03:20 to provide a script for the default value for the notification type. Let me create a script.
00:03:35 Now let's start recording. I'm going to provide a default value, "m2", here...
00:03:47 and hit enter. Let's stop recording.
00:03:52 You should be able to quickly change the script if it's required over here.
00:03:57 Otherwise, the script is ready to go. We have set the focus on the field.
00:04:01 We specified the default value and hit enter. Now once I'm in the flavor, I need to specify
00:04:11 this script as the onload script for the flavor. The way I do this is by bringing the flavor in the
edit mode.
00:04:18 I go into the Insert tab. And in the screen event I will specify the onLoad script,
00:04:24 which is the default notification type. Now we are done with this screen and we'll save

12
00:04:32 Now, let's make sure this works properly. I will switch to the original view.
00:04:40 And I will mark this particular flavor as my default flavor for this transaction.
00:04:45 Now that we are in the second screen for the transaction, let's start modifying the
transaction screen
00:04:51 for the tablet device. Let's bring this flavor into edit mode.
00:05:01 The first thing we want to do is to change the title of the flavor.
00:05:08 We'll call it Malfunction Report. Now we want to hide the tree control.
00:05:15 So we select the tree control here. Click on Hide.
00:05:22 We want to also hide the GUI toolbar. Now the notification section is already defaulting to
"m2", over here,
00:05:33 so we can completely hide this section also. Now, let's move this tab strip a little below so

00:05:46 we have more room to start building our tablet screen. Now, let's start selecting the screen
elements
00:05:52 for the functional location and equipment, and move it to the flavor.
00:06:07 Next, we are going to move the description and the description long text...
00:06:30 Now we are done with the Notification tab. Now before we move to the Malfunction tab,
00:06:35 let me show you a quick took which will help you align the screen controls properly.
00:06:44 Let's go into the Design tab. We have these Helper Lines.
00:06:48 So if you have multiple screen elements that you want to align and space properly,
00:06:54 you can leverage this particular tool. I can select a different color for the helper lines,
00:06:59 enable the helper lines, and also enable the Snap Mode. This allows for better control in
00:07:06 positioning and spacing of the elements. So let's switch to the Malfunction tab.
00:07:12 And from here we want the malfunction start date, time, and the checkbox for the
breakdown.
00:07:30 Now that we are done with the Malfunction tab, let's switch to the "Location data".
00:07:36 Now here there are quite a few fields that we want to drag into the transaction screen.
00:07:41 So we are going to use the lasso tool. And on my Mac I will use the function shift key
00:07:48 to multiple-select these elements. Now that we have all the data from these tabs,
00:08:05 we can just hide the tab strip. Let's save the flavor.
00:08:10 Now one last thing - we are preparing this flavor for a tablet device,
00:08:15 so we want to do is specify the width for the flavor. We'll go into the Release tab.
00:08:21 And in the width field here we are going to specify 1000 units.
00:08:27 This gray area on the flavor indicates where the flavor gets cut off if the device being used
00:08:33 to render this flavor is 1000 width. So it provides you with a marker on how to
00:08:40 adjust the screen elements so that they lie within the width of the device.
00:08:49 Now that our flavor looks okay with regards to the placement of controls
00:08:53 and the controls we need on the flavor, let's define the behavior of the Save button.
00:08:59 We want some basic screen validation to ensure that the value of the equipment, the
description field,
00:09:09 and the malfunction start date is specified before the user hits on Submit.
00:09:14 So we'll have to create a script for save notification, which does this basic validation.
00:09:21 Before I do that, let me adjust the screen element alignments
00:09:24 for the description field here. Let's launch the script editor.
00:09:38 Let's create a script for the save notification, which will get executed when the Save button
is clicked.

13
00:09:43 For this, we're going to create a script first. As indicated, we need to check if the equipment,

00:09:53 description, and the malfunction start date have a value specified.
00:10:03 We can do this by the object selector. We're going to select the equipment field...
00:10:25 and check for the text value here. Similarly, we're going to check for the text value
00:10:31 for the description and the malfunction fields. Now if the user has not specified a value in
any of these fields,
00:10:55 we want an option dialog to show up for the user which prompts a user to specify a value
00:11:00 for these required fields, and then click on Submit. I already have a call here for the session

00:11:08 .utils.showOptionDialog, which prompts the user to specify the required values,
00:11:15 and also has a callback for the OptionDialogClose. I'll just define the callback function.
00:11:26 Now my "if" condition is complete, I also want to make sure that if the user has specified all
these values,
00:11:34 then in the "else" case we hit on Submit. So if all these values are specified,
00:11:46 then we just need to save the notification. Now we are done with this script.
00:11:56 The last thing we need to do is to hide the Save button and create a Script Button which
calls our script.
00:12:27 Let's switch to the edit mode for the flavor. And under the Release tab we have a Device
Preview.
00:12:36 So we're going to click on that. Now since we are building this flavor for a tablet,
00:12:42 we just want to make sure that the flavor renders properly for a tablet device.
00:12:47 In my case I have an iPad, so I'm going to click on Tablet, over here,
00:12:53 and select the Apple iPad. Here.
00:12:57 This gives me a good layout of how the flavor would look on a tablet device.
00:13:03 I can change the orientation of the device to see how it would look in a landscape versus a
portrait mode.
00:13:09 Notice that we can also select the "Show all devices" and filter down the devices
00:13:15 that are available for the preview. Now that I'm satisfied with the way
00:13:20 the flavor looks on the tablet, I will close my preview,
00:13:25 and I'm ready to test this flavor on a tablet device. Let's select our equipment.
00:13:39 With the equipment specified, all I need to do is specify the description for the notification.
00:13:53 Now I've specified the description and I'm ready to save the notification.
00:13:58 That brings us to the end of the unit today. Today we showed you how to create
00:14:04 a flavor for a mobile device, and preview it for the targeted screen size
00:14:08 using the editor in Slipstream Engine. Since this is the last unit of our week,
00:14:13 let's sum up what we've learned this week. This week we gave you an introduction to
00:14:18 building low-code mobile applications using SAP Screen Personas Slipstream Engine.
00:14:24 We walked through the Slipstream Engine architecture. And we talked about the best
practices for
00:14:29 planning and building mobile applications, and created a flavor for office workers
00:14:34 to create a notification from their tablet device. Next week, we will talk about designing your
flavors
00:14:41 for the different screen sizes, accessing native device capabilities from
00:14:45 within your mobile flavors, creating templates for the mobile flavors
00:14:49 to achieve a consistent look, building wizards with viewports,
00:14:54 and finally, how to optimize for performance for the mobile flavors.

14
00:14:58 Thank you.

15
www.sap.com/contactsap

© 2018 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from e xpectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark
information and notices.