1 2 3 6 Previous Next

User Interface Technology

77 Posts

While listening to the User Experience Keynote of Sam Yen during TechEd 2014 in Las Vegas (http://tinyurl.com/kuwt5jj) with the topic: The Users Strike Back: The Force Behind a New SAP Experience, I was quite surprised by a quick demo of Caroline Welsh about SAP.Drive .


Even though the tool is quite interesting and accessible for everyone with a s-user or scn-account, the demo was just a 3:55 min walk-through.

You can watch the demo as part of Sam Yens keynote here:



Nevertheless, I catched the URL to the tool (it was shown less than 5 s during the whole demo...):



What is Drive.SAP?

The goal of Drive.SAP is to get prompt feedback on your design during an iterative project approach.


Or in SAP words:

Drive.SAP is an award-winning user experience application that enables SAP user researchers, product owners, and anyone working on design artefacts to validate and improve the user experience of SAP products.


Drive.SAP studies are simple to create and an ideal research tool that enables you to gather specific feedback from third parties, such as colleagues or customers, on images of your design artefacts.


The days are over when you sent screenshots in mails or via dropbox to get feedback from your customers end users, businness people or colleagues via mail, phone, chat or as annotated screenshots. At least that is the promise of Drive.SAP.


Let's see if the tools really fullfills this purpose.


How does it work

According to the "award-winning" usability of Drive.SAP, it should not be necessary to create huge how-to documents or videos. Depending on how you define award-winning, the tool at least made it to the category "People’s Choice Honorable Mention" in the UX Awards 2014 Winners list.



Nevertheless, the usability of the tool is really good and intuitive which is important for the participants who just want to provide feedback.


So, how to get started?

First you need to fire up your Chrome or Safari browser since a big annoying popup reminds you that Firefox or other browsers are not working:


On the Help page you can read that IE10 should also work fine. At least on IE11, I got the same popup. We will see what the future brings.


The initial steps are actually quite easy: Create a study and upload your screens you want feedback for.


Using drag and drop, you can re-arrange the screens to  get the final screen flow you want to show to the participants. After that, you can specify for each screen which kind of feedback you want to get and also add a question to it like "Do you want to see the password in plain text?".



Participants can answer in a free-text form or set marking points on the screen to highlight their feedback. After adding questions to EVERY screen, you are able to publish your study.

Attention! Once you have published the study, you will not be able to edit it anymore. So please ensure that you have the right order of the screens and added the right questions.


You can now share the study link to everyone you want feedback from. Unfortunately, there is currently no way to secure the study with a password. So your customer should be aware that everyone knowing the URL is able to see it. Currently, it is not possible to participate in a study without a scn- or s-user.


The good usability is shown especially for the feedback process. Before participating in the actual study, the participant gets a nice popup with some tips and tricks how to use the application.



Depending on the type of answers selected during creation (free-text or marker), the user can add responses to the questions or set four types of markers.


  • Like: simple Like icon + possibilty to add some text to it
  • Issue: yellow sign with an exclamation mark + possibility to add some text to it
  • Speech bubble: add some text
  • Arrow: to mark a position without adding text

That's it for the participant. He or she can decide in the top menu to allow displaying the name or staying anonymous.


The feedback can now be seen by the study creator.

What are the benefits

During the quick check of the tool, I can see the following benefits:

  • A tool with an easy and state-of-the-art user experience just doing its job
  • Easy way to collect feedback from various people gathered through ONE channel
  • It is now fun to provide feedback!


What needs to be improved

  • You need a scn- or s-user
  • No password protection to secure studies
  • Help page is currently clearly written for SAP internal employees including SAP internal links
  • No support address or contact outside of SAP
  • Browser compatibility popup



The purpose of Drive.SAP is very simple but a huge advantage if you can use it in projects with a clear design focus. Good to see that SAP is on the right way to create simple but useful apps. Sure, there is quite some work to do but as SAP is not promoting the tool currently (try to search for Drive.SAP at google and you will find just a few hints...), I expect that they are working on it right now.


Personally, I will try the tool in one of our next user centered projects to see how it works in real life.


What are your thoughts on that? Have you already tried it?

UI5 rules the SAP universe. There is a plethora of new tools and infrastructures provided by SAP (HANA database, HANA Cloud Platform (Java), Server Side Javascript in XS, Core Data Service and much much more). But the actual king for me is UI5. Though it’s not much more than a set of libraries and styles in a technology which has been there for ages. Whether it’s a brilliantly composed infrastructure, I can’t judge – as I don’t really know the alternatives. But it doesn’t matter: UI5 it the user interface technology which is being pushed by SAP intensively and which will surely be highly attractive to millions of SAP GUI-accustomed users out there. Hardly any end user can judge the impact of business logic being executed as a stored procedure inside the HANA database or the flexibility of running an infrastructure on HCP. But everybody can look at a UI5-based simplified user interface he once knew in the SAPGUI and say “that looks fresh – and it even works on my phone. Awesome!”. Therefore, I consider UI5 as the driver for business application renovation for the next years.

It’s not about SAP GUI vs. HTML5

Alright, beautiful new world, here you are. I’m learning JavaScript and will somehow manage to deal with an un-typed programming language. I’ll simply expose my business logic as OData via Gateway, as UI5 is based on this protocol. Should not be a big deal, should it? But slowly, second thoughts creep into minds of those developers who actually implemented transactional applications in the past. Some asked related questions quietly also this year in Berlin. Questions like “what about locking”? This addresses one major change in application development caused by the OData-protocol: Applications are supposed to be stateless. And not having exclusive locks which provide a server-side state about who’s under control of which instance is part of that. It struck me also this year was, how little SAP and the brilliant heads available in the sessions actually seem to care about this change and how easy this questions is answered with “there are only optimistic locks”. And I’m even more surprised by how relaxed the developers having asked this question accept the answer.
For me, this change in paradigm is huge! Let me explain why.

Stateless business applications

In the classical SAP development world (=ABAP, until just recently), applications were stateful: The application server knew about the state of the transaction in process. While saving, the state was committed to the database. Locks were either resolved or a new transaction started immediately based on the last image of the previous “transaction” including its locks. To me, this behavior seems absolutely appropriate for business applications: Multiple persons operating on the same data expect to exclusively work on it once they’ve successfully started to perform operations on the data. In our project, even a late exclusive locking (on first write access, not on clicking the “edit”-button) needed some explanation to the users before they could accept it as a feature (not as a bug). I do not know whether this expectation really is a need for business applications or whether it’s just something (SAP) users got used to throughout the years – I believe it’s both. In addition to resolving concurrency, users expect that a system validates their input. And in some cases, does not only prevent further processing, but also the saving of inconsistent states.

In a mobile world, where connectivity to the application server may not be as stable as in a wired office, this interaction pattern is not appropriate: The server must not hold a state which might be lost after the connection was lost or which leaves objects in a locked state as the transaction cannot be completed. At maximum it is acceptable to read data with some mechanism which informs the client that data which he has read is out-of-date as someone else has changed it (optimistic locks). The OData-protocol, upon which UI5 is based, implies such a stateless behavior. While the actual frontend-developer (those brilliant youngsters juggling with the Javascript) simply can rely on the model to which they bind the UI to be stateless while the grey-haired ABAP-developers who are glad to have mastered ABAP-OO are now confronted to fulfil the provisioning side of the protocol.

And there’s no in-built-support for enabling a stateless application-backend.

Figure 1: Evidence: The youngster with his responsive app and a group of fanboys and the grey-haired frustrated ABAPer - picture taken at TechEd 2014, Berlin

Options for stateless backends

Before I go on, let me say very clearly: I don’t know of any silver-bullet-application-design-pattern. I wanted to sketch some ideas which came to my mind and I want your feedback on them.

Assuming data has been read optimistically on opening the UI, the questions is what happens on write (“save”). I’d expect the optimistic read lock to be promoted to an exclusive one once a PUT or a POST are being transformed into backend modifications. If this locking is successful, other optimistic locks on these instances would be deleted. Thus, on a subsequent change from one of the other sessions, the backend could detect the concurrent change and then…

Dismiss concurrent changes

The most simple of the options surely is to inform the user that changes to the instances he wants to modify have occurred. Whether the current data is re-read automatically or whether the user is given a chance to actively refresh his UI is subject to what’s more acceptable to the user. Depending on the complexity of the operations performed, this interaction pattern can in fact be acceptable. Particularly for one-click actions and data which is actually owned by one user, this seems to be appropriate. No wonder leave-requests is the new “hello world” of the business applications.

Push channel

With a bit more of effort, the backend could provide a mechanism for actively notifying owners of deleted read-locks about changes which have occurred by another user. This limits the frustration as less data entered might be lost, but the mechanism remains: Simply inform the user and afterwards, dismiss his changes.


Knowing that concurrent changes might occur, one could also prepare the model for concurrent updateability: With an active/inactive-mechanism which allows to have multiple inactive versions for different users, the system could basically allow parallel operations on (parts of) the same data. A dedicated interaction with the system (e. g. an action “merge”), the always save-able inactive version of the business data which may even have been modified in several steps by the user could be merged with the active one. During this process, the backend can remember the changes done and include this in the algorithm once another session which has read and modified the original data pushes its changes to the backend. In this pattern, not even an optimistic lock would be required – but the merge-mechanism may be tricky to implement depending on the scenario. I believe that this interaction however would be most acceptable for users being used to stateful applications.

Is ABAP (and Web Dynpro ABAP) dead?

With the new world relying on Javascript in the frontend and the OData-protocol, it’s obvious that neither on the frontend nor on the backend ABAP is required anymore. You can even implement business applications with the UI5-look which are based on a completely non-SAP backend or you could use one of the other weapons SAP has in its technology arsenal for you (Enterprise Java on HCP, server side Javascript with XSJS or simply XSOData). But still, you could stick to good old ABAP and expose the service via Gateway. And from my point of view, there are good reasons to do this: ABAP (not as language, but as infrastructure) offers mature tools needed for business applications: A programming model which has first-level-citizens optimized for tabular data, a sophisticated authorization management integration, a brilliant change and transport system and much more.

I have sketched some options for a stateless backend, but honestly, I believe that still for transactional applications, the exclusive locking of a stateful application and the business transaction which allows to save only consistent data will remain the most required interaction pattern for complex use cases. In addition, connectivity has improved vastly over the past years and will surely be enforced more and more also with high-speed networks. Therefore, I believe that many new business applications will also be stateful at least in the next five to ten years. And if this is the case, the usage of the ABAP-based Floorplan Manager is appealing to me: Personalization capabilities are extremely powerful, the controls are optimized for the needs of business users, a real WYSIWYG editor is available and last but not least, the programming model is well established.

Consequently I guess we’ll have multiple types of applications based on OData and UI5 or FPM to exist side-by-side. Key with respect to user experience will be to provide styles for both the UI-technologies which don’t expose the difference in the application pattern to the user. Based on the use case, either a stateful or a stateless application may be launched without the user noticing any difference.

Importance of frameworks

Whatever your architectural decision looks like: To me it’s obvious that you need an application framework which helps you to implement generic consumers in order to fulfil different contracts. Whether it’s about providing generic feeders for the FPM UIBBs or about exposing the model as OData – having a metamodel in place will help you tremendously. Also these contracts evolve or the consumer (UI5, kapsel container offline plugin) require new aspects of the protocol to be implemented. Want samples: $expand, $top, delta tokens,… With the consumption technology evolving, it’s essential to have a technological foundation which keeps the pace.  From my personal experience, I’d even say it’s not possible to actually implement this from scratch on your own. Luckily, we don’t have to (those who followed my previous posts know what’s coming): With BOPF, SAP provides a framework which has a strong metamodel optimized for the delevopment of business applications. There have been consumers around (the Floorplan Manager BOPF integration (FBI), the Gateway BOPF Integration (GBI), Post Processing Framework, … ) which leveraged the benefits of this model driven approach. However, these components have been established based on the needs of business applications built upon BOPF (majorly SAP Transportation Management). This lead to the sad fact, that these components only supported the set of features needed in the consuming applications, not in support of all features possibly required by the consumption technology (e. g. there is no FBI feeder for the Form Repeater UIBB, $expand is not supported by GBI).

But with SP8, this has changed tremendously: SAP now provides an abstraction layer called SADL, the service adaptation definition language. This runtime artifact consumes various types of metadata and provides generic adaptors to the latest UI-technologies. And what’s best: It’s being developed in close cooperation with the consumer-technologies (FPM, Gateway). Personally, I’ve got huge expectations with respect to SADL really making BOPF timelessly consumable software.

The only thing which I don’t understand at all: Why is an application framework based on well established technology not being promoted at TechEd? Of course, this is not as sexy as showing new UI controls, as integrating IoT-sensor data or as aggregating zillions of BSEG-items within the blink of an eye, but in the end, it (still) is all about business applications. So why not show how to actually enable developers to get this done? Maybe next year, when SAP cares more about actual application development. This year’s keynote was a step into this direction, at least I keep telling this to myself.

Let me tell you about an interesting event organized by Dutch SAP user organization (VNSG) yesterday. The User Experience and the Custom Development focus groups joined forces and set up yesterday’s meeting about Fiori. The idea was to have Dutch customers present their experience, but unfortunately we couldn’t convince any of them to stand up to present. On the other hand, we had Marcel Smits, who is Fiori Factory Lead inside SAP EMEA, to tell what he learned about Fiori implementations at 90 customers.




Marcel introduced Fiori and emphasized the importance of great design, which creates an emotional connection with the end users. He talked about SAP’s goal to unify the UX for all SAP software. This means that the Fiori UX will be rolled out to all solutions. Not the Fiori technology, just the Fiori user experience. His first presentation focused on the Fiori apps roadmap per LoB where planned innovations are listed for the coming half a year and future innovations beyond half a year. Basically SAP releases a new wave of apps in each quarter. What we can notice is that the apps are getting more specific for certain tasks, some of them cover more complex processes, which took SAP more time to simplify. He made an interesting comment about a new WDA app for cost center hierarchy, which was released as WDA, because it was too complicated for the Fiori paradigm. Another interesting detail was about the My Benefits app, which is primarily created for the US market and therefore cannot be implemented “as plug and play” for the Netherlands. Marcel took some time to explain why some apps require HANA, while others don’t. He mentioned various reasons such as the use of HANA search models, use of HANA Live and the case of Fiori apps which require re-written, HANA-optimized backend logic.


Marcel shared his experience in Fiori implementations. He organized it along the 3 phases of UX adoption:

  1. Advise - What is my strategy and roadmap?
  2. Launch - How can I get started with deploying Fiori?
  3. Accelerate - How can I accelerate deployment of Fiori?


This presentation gave a very good overview and gave some very specific details at the same time. He talked extensively about the value of good design and he introduced the UX Value Calculator which can be used to quantify the benefits of great UX, in this case Fiori, and express the value in Euros based on many factors such as time saving of management. He talked about security around Fiori. Most SMEs use reverse proxy and SAP Web Dispatcher and larger organizations with more complex requirements implement SMP and Mocana. We had some conversation about SAP Notes, Marcel suggested to check them weekly, because they bring fixes, but also new functionality – which should be evaluated by customers. His advice was to keep track of all manual installations steps in Dev to speed up the setup of QA and Prod. Regarding project approach, he emphasized the importance of project management and he recommended the agile approach if at least 2 sprints can be defined in a project.

Aviad Rivlin, PM and SAP Mentor from SAP Labs Israel joined us virtually and presented via SAP Connect. He introduced the Fiori Launchad and gave a live demo. He defined FLP as “Intuitive, modern and easy to consume single point of access for bus applications and content”. He explained the 4 deployment options: ABAP (Gateway), JAVA (Enterprise Portal), Cloud (HCP) and HANA. He expects most customer to use the ABAP option, because it supports all Fiori apps. FLP in the portal works the same way, but the underlying technology is the portal and the Fiori apps run on the ABAP Front End Server. In case of HCP, the connectivity to on premise backend systems is provided by the Cloud Connector and the Fiori apps themselves run on HCP. He got questions about the future of FLP in relation to the SAP Portal so he spent quite some time explaining SAP’s UI client convergence plan covering alignment between Portal and FLP.


Wim Snoep and Leo van Hengel presented how to change and create Fiori apps. Wim talked about extensibility on 3 levels: backend (ABAP or HANA XS), Gateway/OData and front-end. He mentioned that modifications can be as simple as styling, but can mean introducing new functionality. He described his project approach consisting of 4 phases:

  1. Mockup
  2. Build services
  3. Build screens
  4. Test



Leo gave a nice live demo of Web IDE running on HCP trial. For many participants it was very interesting, because this was the first time they saw this new tool.

Finally Henny Claessens talked about his experience at AppHaus Heidelberg. This short presentation, more like a pitch, was nice to hear about this SAP initiative. It is basically a creative environment where SAP designers, developers, and customers can work together on new, innovative products in multidisciplinary teams. It aims at merging engineering and art. The Design Thinking workshop where Henny participated was about how to bring design education to SAP customers and partners in the form of DesignEd.




As far as I know this was the first time that students (from Amsterdam University of Applied Sciences) joined a VNSG meeting. We were happy to accept them to learn about Fiori.

You have your UX Strategy in place and now the question is what do we improve?


We already made the point that the topic of UX involves a number of elements that are linked or dependent on each other.  From the front-end interface, connecting to an application that renders a system process, based on a business process, with master and transactional data, to the technology platform and architecture.


It follows that with so many moving parts, we need a methodology to bring all these elements together – we need a Roadmap.  The main driver for a roadmap approach is the fact that any solution requires the availability of UI components.  These components change over time and are influence by other components.  So a solution that is not feasible today may be feasible in a few months due to a change or update to the landscape.


Key Principles


1. Focus on Value


Improving UX for the sake of it does not serve much purpose.  For this reason we believe this should be a targeted effort to identify
the business value opportunities.  In my blog 03 I discuss the balanced scorecard approach to UX value and that applies here.  Business value accrues either from value opportunities – introducing a new capability that adds new value, or by solving UX pain points that have a business impact.


2. Focus on Data


Data is the golden thread to discover the value opportunities.  Data also needs interpretation and understanding so this process also requires interaction with users.  The data helps us to follow a method of prioritisation, so that we consider the whole but find a way to identify the best opportunities.  At the end, the data is what we use to justify as well as to quantify the business value.


3. Transactions, End Users & Landscape


We derive our target value opportunities by focussing on the transactions to prioritise, which end user groups to prioritise as well as what the landscape capability offers.  I want to reiterate the end user again.  We are looking to solve the UX pain points of user groups / roles that offer business value.  We are not looking to change a few transactions within the whole of SAP.


4. Time-boxing


As a principle we recommend that you set a time limit on this exercise to avoid  the ‘paralysis by analysis’ trap.  The resources need to be prepared and available for this exercise.


The Stages


We follow a 3 stage approach: Discover > Assess > Roadmap.  Between the Assessment and Roadmap stages we have a decision point where our recommended solutions require approval before they are planned for user coherence and integration into the SAP roadmap.



UX Roadmap.png




During the Discovery stage the aim is to generate as much information as possible and to evaluate this in a way to drive a prioritisation of transactions in the first instance and then of end users.  We consider multiple types of information for this exercise and in practice this depends on what information is available within a reasonable time.  This stage ends with a consolidated list of transactions and users in scope.


During the assessment stage we assess firstly what ‘Out of the Box’ solutions are available from SAP and then consider the appropriate enablement solutions.  The enablement solutions involve the design and build of the solution for the transaction and the users.

The second part of the process is to validate the initial assessment results.  For this we utilise a basic set of validation criteria: Desirability; Feasibility and Viability.  The result of this stage is a set of recommendations.


We recommend an approval step before proceeding to the last stage.  The UX Roadmap is created firstly by developing a user coherence plan and then creating the UX roadmap that integrates the UX solutions, UI components and end users.


Lastly please note that this methodology requires a cyclical approach that every cycle will target the priority areas and over time will drive a UX transformation of your SAP estate.

On Tuesday of the week before Las Vegas SAP TechEd && d-code it was windy in Sydney. In fact it was very windy. A serious low pressure system was passing over us and bringing winter-like conditions to much of eastern Australia. In parts of the Blue Mountains - just east of Sydney - snow cut roads and railway lines, trees were down everywhere, etc. All this on the second week of October - well into our spring and very unseasonal.


Someone sent out a tweet - sorry I can’t remember who - that drew my attention to http://earth.nullschool.net. This is a site built by Cameron Beccario, @cambecc, that provides a visualisation of global weather conditions, ocean currents and ocean surface temperatures.


On Tuesday 14th October eastern Australia looked like this - except animated of course.

Screen Shot 2014-10-28 at 5.33.59 pm.png


I spent a bit of time playing with the user interface because it was so much fun and so interesting. You can adjust the altitude to see the wind conditions at different levels right up to the jet stream and stratosphere. Move forward and back in time to see changes. Modify the map projection to see the whole world in one page. Etcetera.


Screen Shot 2014-10-28 at 5.39.38 pm.png


As I looked to see how Cameron had built this I was pleasantly surprised to find that he had made the project available on GitHub for anyone who wanted to make use of it under a MIT License. Great - I couldn’t clone it quick enough.


Looking at the code I was amazed. Firstly it was primarily only Javascript and SVG. Wow. Secondly I noted how many other projects and resources Cameron had leveraged to produce his awesome “earth” visualisation.


Javascript libraries included Node, D3, backbone, and when. The mapping data came from Natural Earth, a public domain dataset, weather data from the US National Weather Service, etc.


I knew Clint Vosloo and Chris Rae were planning to enter DemoJam the following week with an entry called Swell Analytics. Swell Analytics used an API supplied by MagicSeaweed that provides Surf conditions from all over the world. I thought Camerons' “earth” visualisation would be a great starting point for the UI which would allow the user to search around the world for a surf spot and then drill down to get the surf conditions in detail.


I added the OpenUI5 library to Camerons’ project and a single Javascript call that triggered my code and passed the selected map coordinates. When my code was called it instantiated an OpenUI5 dialog box that ran as part of the “earth” visualisation but independent from it.


The map coordinates were passed to a web service that returned the nearest Surf Spots monitored by MagicSeaweed. When the user selected one it then called the MagicSeaweed API to get the surf conditions for that spot.


The MagicSeaweed API returns all surf condition reports for the spot over the past few days, including weather charts and forecasts. By moving quickly through these charts I could produce an animation effect that looked pretty cool.



Once completed I handed over the code to Clint & Chris to plug in their components. These included historical analysis of the surf spot and analysis of related social media feeds using HANA.


I had spent less than 2 hours on this - but there is clearly more than two hours work in the result. A true example of collaborative development. I have not met Cameron or the people who worked on D3, or backbone, or Node. I don’t know anyone at the National Weather Service or Natural Earth. But we all worked to produce this outcome and I am deeply grateful to all of them. So are Clint & Chris.


That is why GitHub, and other services like it, are so important to developers today. That is why SAP CodeExchange was so important and why it was so disappointing that it was killed with little notice. For developers to truly collaborate we need a distributed revision control, change control, call it what you will service, and associated tools, to support us. That is also why SAPLink is so important - a great collaborative project totally driven by the community.


Most important of all is the developers who share their work, outcomes, and experience with the rest of the developer community and thereby make the whole greater than the sum of the parts. They allow minnows to stand on the shoulders of giants to produce great outcomes.


If you don’t know what Git is I think it is time you found out.


You can watch a replay of the Swell Analytics Demo here.

Graham Robinson

SAPUI5 === Golf

Posted by Graham Robinson Oct 28, 2014

I was fortunate to be invited to participate in the Blogger Program at SAP TechEd && d-code last week. I had a busy week of meetings and meet-ups, keynotes, briefings, etc. and I also did a couple of presentations on SAPUI5.

Several times I found myself trying to explain to people why this web development stuff is so hard.

My pitch went something like this.

"This SAPUI5, Javascript, oData, Gateway stuff is not as easy as some people make out. It is not just opening up the manual and doing a bit of reading. Neither is it taking a few OpenSAP courses or doing a few tutorials and you will have it covered. Learning the syntax of Javascript is not enough. Learning all the SAPUI5 controls off by heart is not enough. Knowing how to use transaction SEGW to model your Gateway service and then falling back onto good old ABAP to do the heavy lifting is not good enough either."

"All this stuff takes time to learn, time to get experienced with, and requires time to fail. You will not get this right the first time - or the second - or the third. As you learn more you will come up with new, and better, techniques to achieve what you want to achieve. Sometimes these new techniques will be developed because you realise you could have done something better. Sometimes a colleague will share his techniques and you will find pieces of them better than yours. Sometimes you will learn from others sharing via SCN or Stackoverflow."

"Also the underlying technology will change - and you will need to change to adapt to it. For example, the whole way that SAPUI5 does in-app navigation changed in release 1.16 and, while the previous techniques will still work, the new way needs to be absorbed and understood."

"It is all about experience. And the only way to get experience is to do it. Then do it again, and again, and again. Refactor old code to adopt new techniques. Share and learn from others. Always be looking for better ways. Rely on proven design patterns rather than create your own."


You get the idea I hope.


So, I am in this meeting with Sam Yen. Sam is the Global Head of Design and User Experience at SAP. He is largely responsible for SAP’s focus on design, and design thinking, and the end-user. He is a designer - I am a techie. Sam listens to me struggling for several minutes to describe how important I think experience will become with SAPUI5 developers and he sums it up in two words.


“It’s golf”.


Don’t you hate that?



Graham Robinson

SAPUI5 Momentum

Posted by Graham Robinson Oct 27, 2014

I was fortunate to be invited to participate in the Blogger Program at  SAP TechEd && d-code last week. I had a busy week of meetings and meet-ups, keynotes, briefings, etc. and I also did a couple of presentations on SAPUI5.


One of my takeaways from the event was that there is growing recognition amongst the SAP developer community that this SAPUI5 thing might be something of some relevance to them. In my opinion this is a good thing.

Screen Shot 2014-10-27 at 11.00.18 am.png

Technical people, especially Developers, are a pretty sceptical bunch and need time to understand new technology releases and to build trust that they will serve them well. And for SAP UI Developers this is especially so due to many false starts in this area over the past decade. The obvious example is WebDynpro which has never really gained much traction. There are two main contributors to this. The first is that SAP never seemed to get on board themselves - for example the only WebDynpro transaction I recall using much is SOAMANAGER. The second reason is that WebDynpro screens never seemed like the answer the end users' were calling for.


SAP are certainly committed to SAPUI5 - and committed to oData too which is an important thing to be recognised. SAPUI5 is SAP's "go to" technology for building user interfaces across their entire product range. Tangble evidence of this is that the number of available Fiori apps has now passed 500 and this initiative continues to have a strong focus.


And the screens produced with the SAPUI5 libraries do look pretty good. In an area where people can be very subjective it is hard to find anyone who does not like the cool blue Fiori-style. It goes beyond the look of each individual control too. The SDK has tons of examples that shown in the context of a full application. In this way they are also serve as part of a more subtle campaign to guide the developers, who typically aren't great UI designers, in how to combine these fundamental UI components into complete applications with suitable aesthetics. Essentially the demo apps that show how things work also serve as part of more holistic design patterns, thereby encouraging a consistency that would be impossible if every developer went their own way.

Screen Shot 2014-10-27 at 11.22.52 am.png


As mentioned, I twice presented an ASUG session that was designed to help the total newcomer to SAPUI5 understand where it fits in relation to other web technologies as well as the rest of the SAP technology stack. Those who attended the second session got a smoother "user experience" as a self inflicted technical issue disrupted things a little in the first - but in both sessions there were many in the room who realised SAPUI5 was an important technology they needed to add to their skill set.


Don't be fooled by any personal scepticism or jeering from the sidelines. The SAPUI5 libraries are very good and can stack up beside the others popular JavaScript libraries. The data binding stuff is very slick. As John Patterson, whose opinion I highly respect, says - "It just works!". I am also coming to appreciate the way SAP has implemented the MVC design pattern and there is no doubt the library has an extensive set of very sophisticated controls.


So let me suggest a few tips about how you can start on the road to becoming a true SAP Web Developer. Others will have their own suggestions and I encourage them to put them in the comments.


  1. Learn the fundamental web technologies of HTTP, HTML, CSS and especially JavaScript. As you do so consider why HTTP is on this list. Hint - I didn't say find out what these things are, I said "learn".
  2. Learn how to use the debugging tools of your favourite web browser. I recommend Google Chrome but ultimately it is a personal choice. Knowing the purpose of these tools and how they work will help you with Step 1. Not to mention debugging tools can be handy during the development lifecycle - but you knew that right?
  3. Download the OpenUI5 SDK from GitHub, install it, and start reading. There are tons of guides, examples, etc. and all the code is there too.
  4. Setup your own personal development environment on your local machine. Improve it the second time. And the third. Etcetera.
  5. Start building stuff because Steps 1 through 4 won't make you a web developer. It is a skill that requires considerable familiarity before you become even a little bit competent. It takes time, practise, evaluation, etc. and lots and lots of refactoring.


There are of course plenty more things you need to learn and do to successfully add SAP Web Developer to your resume - I have planted some seeds in this article if you look close enough.


And let me close by pointing out how important the right attitude and an inquisitive mind are. Chris Solomon captures this aspect better than I ever could in his recent post My path to learning OpenUI5.....deeper down the rabbit hole and back again!


I am lucky enough to be spending a few days in the Nevada desert at SAP TechEd and d-code 2014 in Las Vegas. Yesterday I sat in on a roundtable/panel discussion hosted by Michael Falk covering UX Strategy Implementation. The participants (including Damean Chen) had some great experiences of implementing a UX strategy at their organisations. In this quick bog post I’d like summarise some of the key points that I took away from the session.


Understand the User Journey

Everyone agreed that this was of paramount importance. There is no substitute to getting to know real users, not proxies, not people who “think” they know what the users want, but real honest to god users of the system. Understand them, understand their needs, wants and hopes, spend time with them and build “a day in the life” scenario and you will be much more successful.


It’s not all about the User Interface

In fact the UI is only one piece of the puzzle albeit an important one. An example of something that greatly effects the UX is Single-Sign-On (SSO). It’s just something that when it works everyone is happy. It’s a bit like the war on terror, get it right and you get no praise but get it wrong and you’ll know about it… fast.


Have a UX Centre of Excellence

Sounds scary eh..? A UX COE… boo! But seriously having somewhere to turn for guidance and direction to make the right choices and provide UX services is the right thing to do. It provides consistency and governance, driving forward your UX strategy.


Be Agile

Oh no, not agile… really. Yes really… in fact it makes perfect sense, being agile means you try stuff out early (on real users) and get their feedback, then you fix stuff and make it better and test it out again (on real users), then rinse and repeat. Duh… simple.


Start Early

Start usability testing with the design (hey this can fit in with being agile… see above). Fixing stuff in the design is much easier than fixing it in the code after User Acceptance Testing just before go live. Do yourself a favour start early.


Expect to have a Cross Functional Team

Good UX is the intersection of Human Values (People), Technology and Business Goals. Guess what to be successful you need to have people from all 3 of these areas in your team - think of them as your 3 musketeers!


Pick something that will have Real Business Impact (credit to Jocelyn Dart for this insight)

It’s tempting to start small and easy (e.g. Leave Request) - do a proof of concept and see what happens hoping it will drive wider adoption. But be careful, you’re better off choosing something that has a real impact on your business, something that matters, improving something that matters, something that people use a lot will give you way more bang for your buck. It may be a bit more risky but hey we’re in Vegas so roll the dice baby.


I’m afraid I had to leave the session before the end due to another commitment I needed to run to so there are no doubt more golden nuggets of wisdom I missed out on. Thanks to everyone on that panel, it was great. Please add your thoughts and comments below

You may by now be well aware that one of the key recommendations for all our customers is to develop your own UX Strategy.

Why do we make this recommendation? 

Let me highlight a few key reasons:

1. Execution of Enterprise Strategy

Your enterprise will have a number of strategies in place that are also in the process of execution.  As a simple example:

  • Enterprise Strategy: How does your enterprise deliver value; Achieving which outcomes?
  • IT Strategy:  How does IT support your enterprise strategy and outcomes?
  • SAP Strategy: How does SAP support the IT Strategy and outcomes?
  • SAP UX Strategy: How does SAP User Experience support the SAP Strategy and outcomes?

There is a hierarchy of strategies in action that all drives towards execution of the enterprise strategy and achieving the defined outcomes.  This leads logically to the primary purpose of the SAP UX Strategy.

2. Business Value

The primary purpose of UX improvement is to deliver Business Value.  Please reference topic 03 in my blog series were I discuss this in more detail. It should be clear that to support delivery of the SAP Strategy, we need to fully determine the appropriate mixture of business values to target within a defined period of time.

3. Assessment Guidance

The SAP UX Strategy should be executed through the process of developing an SAP UX Roadmap and implementing the defined actions.  During the process of developing a UX roadmap we have to make recommendations.  One of the functions of your UX Strategy is therefore to provide guidance during this assessment process.

For example, what is your principle around the topic of remote working?  Do you want to provide your user with offline access to the business application?  Your UX Strategy should incorporate architectural principles to provide guidance for these decisions.

4. Landscape:

UX improvements operate within a technical and landscape context.  For larger enterprises, your enterprise architecture are under governance control to ensure stable and available business applications.  The pace of UX improvements are clearly impacted by the availability of the required technical and landscape components and these can usually not be changed on short notice.

An example here is your internet browser.  This is a UX relevant component for using particular UI technologies.  SAP UI5 is based on html5 and there are compatibility issues with browser versions.  In this case, defining your UX Strategy should help ensure that you have appropriate policies and strategies in place that govern all UX relevant components.

Overview of Strategy

A strategy can be defined as a plan of action designed to achieve future goals.  Any strategy is anchored by two states; where are you now and where do you want to go.  The current state should include an assessment of both the internal and external environments.  The future state sets out a desired future vision.

In between these two states is where the tyre hits the road!  A good strategy sets direction – how do we move from the current state to the future state – and must be actionable.  To be actionable it should therefore describe the practical aspects with sufficient detail so that is actionable.

Customer SAP UX Strategy

In this blog I discuss the topic from an SAP perspective only, but clearly you may require a corporate UX strategy and the SAP strategy will in this case be a specific supporting strategy.

I want to highlight one particular section that I expect to find in your UX Strategy:  End Users.

Ultimately the value of SAP starts by how successful your end users are in their use of SAP applications.  Here the expression GIGO applies = Garbage In Garbage Out.  It is a bit more complex than just this, but I trust you understand the point here.  Let’s consider a few implications.

1. Adoption: At the basic level we need users to use SAP and not use unofficial processes and products.  In this case an enterprise is not able to gain a clear and accurate picture with an audit trail of what is happening in their business.

2. Compliance: We need users to use SAP in accordance with the defined processes and policies.  The business case to invest in SAP is based on assumed use of SAP.  The enterprise and IT strategies are dependent on the execution within a defined framework.

3. Value Add: The above point may sound very rigid.  I want to share two considerations.

(a) A very capable end user should be able to add value through their effective use of SAP by making good business decisions and taking timely action.

(b) We recommend that enterprises actively work on gaining insight into the use of SAP and how this may be improved.  Please note that this is a very wide topic that straddles enterprise policies, business processes, system process, data, information and technology. 

The end user and how they use SAP is where user experience ultimately sticks in your enterprise.  The user does not per se care about which technology they use.  They do care about how easy it is to use and how effective they can full-fill their role.

One last point: If you take this into account it should be clear that UX should be improved through identifying the priority user groups / roles to target with a holistic SAP solution for all their SAP use.

SAP UX Explorer

This is a very good reference source for customers and supports our ‘Experience SAP’ source.  I work regularly with my colleague Juergen Jakowski who has written a section around customer UX strategy which I highly recommend for your consumption:


Also see under the ‘Documents’ section the presentation with notes on the topic.

This is the second blog in a series that will look at the following five perspectives that are changing in the SAP world:



Two years ago, I wrote this blog series during SAP TechEd 2012 that explored which options SAP customers had when looking to improve the user experience of their SAP users.


The good news is that the options have not really changed, but the great news is that SAP has taken what were “technical frameworks” at that point  and incorporated them into products. Specifically, Fiori has gained momentum and, in line with Sam Yen’s UI strategy, it is now being used for all new applications (that I know of) and is being used to renew many more. Beyond this, SAP has continued to invest in SAP Screen Personas, which can be used to simplify or tweak SAPGUI and has removed the dependence on SilverLight – so it’s much easier to deploy.


I have even heard people whispering that this dynamic duo (Fiori/Personas) might become the primary way SAP Users interact with SAP – providing an additional option to classic SAP GUI.


Fiori - LaunchPadPersonas - Select Functional Location



Having said that, SAP GUI 7.40 just shipped, including the “Fiori Style” Blue Crystal Theme, and more interestingly, the 7.40 release that comes bundled with SAP NetWeaver Business Client (NWBC). This blog by my fellow SAP Mentor John Moy highlights the value SAP NetWeaver Business Client can add to classic SAP users. It is also worth remembering that many classic SAP GUI screens have been improved with Web Dynpro ABAP via Enhancement Packages (see this example for Plant Maintenance in EhP 6). Finally, look at Personal Object Worklists (POWL), which can help an SAP user understand which objects in the system need their attention (e.g “Purchase Orders past Goods Receipt Date for My Vendors”).


So we start to see a future where power users might use NWBC (hosting a variety of UI technologies) and casual users access content via Fiori LaunchPad/Fiori and Personas. The icing on the cake is the SAP Web IDE (this was formerly called “SAP River – Rapid Development Environment”) to extend existing applications and develop new ones.




So there are plenty of options - you can browser them all at the SAP UX Explorer.


So where do you start?


First Step:  Understand Your Problems


Plenty of people complain about “using SAP,” but not so many have really done any analysis on where the specific problems exist. So a logical first step is to perform an analysis of what is driving the problems.


I would suggest you start by creating a matrix that maps your user community and rates the level of problems users have. For the top three areas, you can start to assess what could be done to help and start to build the business case for a new user interface (I discussed a framework for doing this in the 2012 blog series).


Second Step:  Understand the Options


The second step, which can run in parallel with the first one, is to understand what the option are. OpenSAP can help here with courses on SAP UX strategy and SAP Fiori. You can also read the SAP UX Strategy and use SCN daily to engage with others who have already started their journey.


Third Step:  Hardware and Software


Depending on what you decide, some options will already be available in your landscape (quick wins), while others will require you to adjust your SAP landscape roadmap.


For proof of concepts, you might look at the Cloud Appliance Library or invest in your own innovation system. HANA Enterprise Cloud and HANA Cloud Platform also offer options for fast and lower-cost deployment options. Find more details in my next Cloud blog later this year.


Fourth Step: Create an Implementation Programme


Finally the rubber needs to hit the road. You need to create an implementation plan!


One good thing about most of the UX solutions is they can be run in parallel (not recommended for long term TCO, though). So you can select the best business case for UX renovation and work from there.




If you go through the above process, I predict two things:


  1. You’ll find a user interface solution you already have, or which could be adopted quickly.
  2. The user experience that most of your users get today will be radically transformed – and at the end of your three-to-five year roadmap, most users will never have heard of SAP GUI (even though some will still use it via NWBC or Personas).

I would like to see every customer of SAP gain a level of user experience with SAP that satisfies their users and
realises real business value. 
This is an ambitious goal and all my experience points to one fact: realising this is a journey and not a destination.  The reasons are simple – user expectations are increasing and what success looks like is evolving.  Underlying this are an number of factors.


External to SAP are a number of mega trends that affects people, organisations and society's expectations, for example the
consumerisation of IT.


Internal to SAP are a number of forces as a result of SAP responding to the external environment and our stated goals:

(1) The SAP Software Portfolio has increased at a pace since the mid 1990's, fuelled by technology evolution of the web and major
acquisitions by SAP.

(2) Innovation by SAP led to the development of the global standard in business applications, powered by in-memory computing, cloud, analytics and mobility.

(3) SAP is fundamentally transforming its User Experience across this vast SAP portfolio and the pace of this change is accelerating.


For our customers there is one particularly important implication.  The future of SAP is business applications in the cloud, on an in-memory based platform, consumed anywhere by all stakeholders.  The key question is when are you planning to switch over?

This decision is integral to your IT and resulting SAP Strategy.  Are you an early adopter or part of the early majority?   At the time of writing we are probably nearing the end of the early adopter stage.  That means if you are not yet planning for such a transition you probably already fall within the late majority segment of customers.


Adoption Curve.png


The reason for including this in the first blog is to make it clear that there is a transition journey for SAP customers and the underlying architecture separates those customers on the high road from those on the low road.  Both are valid, as long as you have defined this
strategy.  If you have not yet then I strongly recommend that this is a top priority for 2015.

When we consider the topic of UX improvement we should also understand where in the lifecycle of the application we operate.


User Experience Lifecycle


The lifecycle of user experience follows the lifecycle of application software.  The classical model remains valid:


1. PLAN: Business Strategy > IT Strategy > SAP Strategy > UX Strategy > SAP (incl. UX) Roadmap with software selection.


During this first stage UX is particularly relevant when it comes to ‘Software Selection’.  Business requirements require you to translate and execute in accordance with your strategy.  This may or may not result in SAP being selected as the recommended software.


2. BUILD: Design/Blueprint > Realise / Configure > Prepare for Go-Live / Test > Go-Live / Deploy


During this stage you have the opportunity to consider the UX of the applications in scope.  The process is similar to that described in RUN below apart from that it needs to integrate into your Implementation Plan with multiple integration points.


3. RUN: Operate and Support the application; Upgrades / Patches; UX Improvements


During the operate stage of applications you plan updates/patches and upgrades to maintain the applications.  The key opportunities during this stage are functional improvements and user experience improvements,


In this context, SAP developed an improvement framework for UX based on an SAP estate in operate mode.


SAP UX Improvement Framework


UX Improvment Framework.png


The improvement framework is divided into 4 phases:


1. Understand & Learn


This phase focuses on 2 components that drive the major outcome of establishing a customer UX Strategy.  Understanding is based on gaining knowledge and insight on multiple topics, specifically SAP information such as our UX Strategy as well as customer strategy details.  Knowledge of the respective sides helps SAP and our customer to formulate an initial customer UX strategy. 


There is no substitute for practical experience of SAP UX solution components in the customer landscape.  This experience validates the principles, values and limitations of User Experience and takes the initial UX Strategy and turns this into a final customer UX Strategy.  Note that the UX Strategy document should be considered a living document and updated on the cyclical basis.


2. Discover & Plan


Now we need to execute on strategy.  The key questions to answer are what should we improve to gain what value, for which user, and with which solutions do we achieve it?


To answer these questions SAP developed the UX Roadmap methodology that (a) Discover the priority transactions, appropriate end users, UX pain points, and Landscape components; (b) Assess the options and make solution recommendations; (c) Develop an outline business case for each solution and submit for approval; and (d) create the SAP UX Roadmap by integrating all UX and UI components in line with the customer SAP Roadmap.


3. Realise & Measure


During this stage we plan and execute the SAP UX Roadmap.  This involved technical activities as well as design and build activities for each solution component.  Part of this plan also involves planning for user coherence based on the recommended UI clients and theming.  The ultimate outcome of this stage is the delivery of UX improvements to end user groups and measuring the effectiveness of these improvements.


4. Sustain


Improving the User experience of SAP will not be a one-off activity for most of our customers.  It is better to view UX Improvements in the same light as you view application and landscape maintenance.  The key question is always to seek business value.


The ability to execute this approach requires a capability from our customer to work across the UX lifecycle.  A capability from an organisational point of view is made up of people, processes, tools and governance.  Lastly, design also requires the appropriate space.  The outcome of this stage is to establish User Experience as both a capability as well as embed it into your organisation culture.

Gerrit Kotze

03 - UX Value

Posted by Gerrit Kotze Oct 2, 2014

Note: This is a repost of a blog I wrote earlier for our Experience SAP site.


Why invest in UX?  Leaning on the basic principles of investment, I would say you should invest in UX to get a worthwhile return.  At SAP we therefore hold the view, validated by our experience of working with many of our customers, that improving UX offers the opportunity to realise business value.


To make this concrete we have developed a balanced scorecard approach to integrate business value into a holistic view that best represent the full value of improved UX.  We define the two axis as (1) Value quantified in monetary terms to value that is qualitative in
nature; and (2) Value for the organisation as a whole to value that attaches to an individual user.



UX Value Framework.png


Based on this, we have identified 4 specific quadrants of business value:


1. User Satisfaction (Qualitative + Individual)

The level of satisfaction of an end user is a strong determinator of their likely behaviour in terms of system use.  Due to this principle, it is imperative to monitor and manage the level of user satisfaction to reduce the risk that the value of your UX investment erodes due to user resistance and non-compliance.  Further, we see a strong correlation between the level of user adoption and user satisfaction.


2. Enterprise Value (Qualitative + Organisations)

This quadrant is a collection of a number of different measures and principles that collectively help to express the qualitative business value to the organisation.  For example, the ability to follow your IT strategy for business applications in relation to the value of an ERP / Integrated system and ‘best-of-breed’ applications; the ability to minimise application licence shelf-ware; the ability to track the effectiveness of maintaining data quality; and the value of your brand to attract new talent or when providing access to external parties.


3. User Productivity (Quantitative + Individual)

An individual end users’ productivity is affected by the combination of user interface, application functionality, business & system process, data & information as supported by the underlying infrastructure.  Some examples include the time element of searching in SAP, the ability to collaborate immediately and seamlessly, and the effectiveness of workflow.


4. Cost Reduction (Quantitative + Organisation)

We leverage the principles of Total Cost of Ownership (TCO) to gain business value through improving the UX related elements that make up the direct and indirect total cost of ownership.  For example the cost of training connected to the time and resources required;
the amount of support connected to UX pain points; The cost of data cleansing due to data quality erosion that results from UX pain points such a complex screens, and the ability to respond in due time to UX pain points.


It is clear that there are many examples of how it is possible to gain business value by improving UX and for this very reason we believe that UX improvement can be based on a business case.

It is a real privilege for me to be a part of the SAP UX Strategy work group.  In this blog I want to share a little bit about this process as well as highlight a key practical message relating to how you translate the SAP UX Strategy into reality.



Evolving the SAP UX Strategy


Although the UX Strategy document only lists 5 authors, there is a group of people involved with us.  The imperative of a coherent UX Strategy from SAP came at the very first Executive Advisory Board meeting for Usability, hosted by Nestle at their head office in Vevey, Switzerland.  During this meeting there was a groundswell of support from our customers for the complete refresh of our UX Strategy with the defined purpose to help them make better investment decisions for the future.


This process broadly involves facilitation of multiple groups internal in SAP, plus discussions and validation with EAB customers.  During these meetings we always need to discuss the best way to explain what is currently available and our own 'course and speed' - where are we investing, what are we working towards, what are the best estimates of the future state.  Although this sounds easy, believe me these discussions can be very intensive.  One of our key roles as an author group is to ensure coherence of all aspects of the UX Strategy.


As I write this blog, we are already well underway to complete the fourth version of the UX Strategy in time for the
next UX Council meeting in mid-October.  We are working hard to cover a wider scope and I believe this will continue on in 2015 as we work towards full coverage of our portfolio.


Translating the SAP UX Strategy


Now on to the practical side.  The SAP UX Strategy defines New, Renew and Enable as key strategic pillars, underpinned by UX & Design Services.  The full implication of this strategy is that SAP is in a transition state where multiple UI technologies exist in parallel.  This can be a source of confusion, or on the other hand I suggest it is an opportunity to create better solutions.  Better in the sense that we can leverage the strengths of multiple solutions and UI components as well as target specific user groups with a specifically designed solution.


To put this in another way, it is now possible to create a coherent user experience for a specific role or user group by combining multiple UX solutions and UI components together in a UI client.  I refer to this as the 'Coherent Multi UI technology Solution'.


This approach is based on the fundamental initiative to better utilise your existing estate and available solutions from SAP.  This is a transition solution that is a result of the massive scale of what SAP is undertaking by transforming our user experience to a cloud based, HANA platform with Applications and Analytics that utilise SAP Fiori UX.  Please refer to my blog 01 where I highlighted the key architectural decision for each of our customers.  In this regard please consider that standard maintenance of ECC 6 was set to continue to 2020 - a key planning milestone.


Desktop_Multi UI Solution.png




In order to realise the Coherent Multi UI Technology solution, you need to have real insight into transactions, pain points, and end users.  Without doing Discovery work it would not be possible to determine a holistic solution and a subset of this as the scope for the UX prototype.  A key pre-requisite is the availability of a representative customer SAP environment with all the UX solutions ready for
use.  Once you have all the details to determine the exact scope ito. processes, users, and solutions, you need to design and build the solution components.


At this stage the next practical consideration is End User Coherence.  Specifically, a single point of access.  We need to avoid that a particular end user suddenly has multiple access points to consume different scenarios, processes or tasks in SAP.  The key component of this step is the UI client.  In a way, SAP has been preparing for the Multi UI technology solution by developing highly capable UI Clients that act as the foundation for future UX improvement initiatives.  Both the UI clients integrate SAP Embedded/Enterprise search, support role based menus, and integrate multiple UI technologies.


• Desktop Users: Utilise the Netweaver Business Client;

• Device Users: Utilise the Fiori Launch Pad.


Note: Portal is a valid UI client in this context.  A portal has extensive capabilities and will be the right solution if you require these additional capabilities such as application hosting, content hosting and management etc.


A final note. I have seen many customers take a technology based approach to drive a UX initiative.  I have not seen many successes with this approach.  A key issue is that each solution from SAP has strengths and weaknesses.  By going at this with one or 2 solutions only (as a wild guess SAP Fiori and SAP Screen Personas), I see most customers run into the limitations of the solutions.  This is the so called 'I have a hammer, and now I am looking for nails' approach.  NB: What are you trying to achieve? How do you know that you are targeting the right areas? Why limit yourself to only 2 solutions?


In conclusion it should be clear to our customers that while SAP is undertaking this transformation journey in User Experience, there are huge opportunities to realise business value through UX improvements. I encourage you to make best use of the wide array of
opportunities as soon as possible.

In 2014 UI/UX has become one of the hottest topics for TechEd && d-code.

To emphasis this, SAP has setup for the first time an own track related to topics around how to apply superior design, implement a UX strategy and how to build, extend and adapt user interfaces. This UXP track comes with more than 60 hours of SAP and customer sessions all across the stack.

Beside the traditional session types like lectures and hands-on workshops there will be some more, completely new, formats like mini code jams, code reviews and hacker lounges.

The UXP track itself is structured in four sub-tracks


User ExperienceFrom design thinking to how to best design good applications
Portal and UI ClientsFrom SAP Enterprise Portal to Netweaver Business Client to Fiori launchpad
FioriEverything around Fiori
UI DevelopmentEverything around UI development frameworks and tools


There are related tracks with additional UI content like


TrackTopics with UI relation
Strategy and Technology (TEC)UX strategy and roadmap lecture
Development (DEV)End to end development scenarios



To get an impression of the variety of different sessions covering all hot and strategic topics in the UI/UX area I highlighted a view of them underneath:


Session IDTitleSub-TrackSession Type
TEC104SAP User Experience Strategy & UI Roadmap - The next stepsN/A (TEC track)Lecture 2h
UXP100SAP Fiori OverviewFioriLecture 2h
UXP101Create Business Value with UX Design ServicesUXLecture 1h
UXP104SAP Fiori Launchpad - An OverviewPortal and UI ClientsLecture 1h
UXP109Customer Roundtable - UX Strategy ImplementationUXPanel discussion
UXP200Overview about SAP UI technologies and when to choose whatUI DevelopmentLecture 2h
UXP202SAP Portal Portfolio - Overview and OutlookPortal and UI ClientsLecture 1h
UXP207ASUG Influence Council: Portal and SAP UIs Influencing channelsPortal and UI ClientsLecture 1h (only US)
UXP263First look at the all-new SAP Screen Personas - Simpler screens in two hoursUI DevelopmentHands-On Workshop 2h
UXP264Building and Extending Fiori-like applications using the SAP River RDEFioriHands-On Workshop 4h
UXP300SAP River RDE - The simple way to build and extend SAPUI5 applicationsUI DevelopmentLecture 1h



The complete session catalog for TechEd && d-code and UXP in particular can be found here.

Don`t miss it, see you in Vegas, Berlin or Bangalore.


Filter Blog

By author:
By date:
By tag: