9 Posts

Recently at the SAP CRM conference in Orlando, we had the chance to speak about the topic of SAP User Experience, and users' expectations regarding SAP UX in the marketplace today.  While there were many examples that were cited from the audience, in particular SAP CRM, many different words were used to describe what the SAP User Experience should be.  When the dust settled and all the comments were in, it seemed that two words were just right to sum up the UI expectations of those that use SAP applications - Easy and Fast.


Here's a clip of the session


And while those buzzwords are certainly great guiding principles to shoot for in your SAP based UI Projects, its much easier said, than done.  Great UI's don't just happen overnight.  It takes thought - the kind that places us in the users' shoes, lots of user feedback, and keeping up on current UI best practices.  Any project that is UI intensive though, will undergo many iterations till the UI is right - that is to say, the UI has decreased risk and inversely increased potential for adoption. 


And that's how we like to describe our experiences with SAP UI based projects - Iterative.  Perhaps highly iterative, maybe more so than non-SAP based UI projects.  And we've also seen, as you've seen in the clip, that "Iterative" is best served "Onshore".  Many times, the proverbial hand-off between tech specs, time zones, complex explanations of usage patterns, and use cases, are lost in the weeds between onshore and offshore personnel.  No manner of tech spechs, no matter how well written, properly keeps the UI requirement sand from inevitably falling through the cracks in the offshore UI model.  These hand-offs represent failure points to producing iterative, intensive, UI driven SAP projects.


In the end though, it really doesn't matter whether the platform is SAP, Non-SAP, complicated, or easy.  Why - because that's how the use sees it.  In the end, they simply want easy and fast. 


Its our job, here in the SAP world of assorted UIs, to give them exactly that.  And it starts and ends with the acceptance of being highly iterative.

Making SAP simple.  That's our mission.  It’s a big statement, for sure, but we willingly and gladly enter into the fray.  We've spent years working with SAP User Interfaces such as WebDynpro, JSP DynPage, BobJ UIs, and CRM UIs to name a few.  We’ve learned that customers who’ve made a significant investment in SAP really want to get the most out of it – and many times that leads to better, simpler UIs.



We also design native mobile applications, and we bring this experience to the table as well. We've learned that a traditional UX background comes in handy when designing a best practice mobile UI as well.  Combining traditional web based UI chops with mobile design skills allows us to take a full scale approach to SAP Usability - and to really make certain mobile design points stand out by differentiating from web based apps.  And, so its from that perspective that we've lived through some bumps and bruises along the way to achieve great SAP UIs, and we understand the history there.  While its true that traditional SAP Web App UIs have taken some hits from a usability perspective, the time is right to help SAP Mobile UIs flourish where traditional SAP UIs have faltered.



And the timing couldn’t be better. 



The explosion of mobility could be the beginning of a new dawn for SAP Usability – right from the get go.  I think, to a large extent, the sins of past UI missteps can be made whole with a fresh take and focus on SAP Mobile UIs.  



It’s our goal to take SAP UIs from also ran, to market leader, one app at a time– and SAP Mobile UIs could help lead the charge.


But it’s not just SAP.  Mobile enterprise apps need better UIs across the board.  I wrote recently about some mobile app design points, which if adhered to, will help make mobile enterprise application UIs stand out from the rest. 



The take really comes from how mobile expectations have risen so high, and continue to do so.  Users don’t care that a mobile application is labeled as “enterprise” or “consumer”.  Clearly, as it stands now, mobile UI expectations tend to be driven from the consumer side.


To echo this sentiment, Eric Lai recently picked up on this trend as well.  Eric spells out some Unaddressed Pain Points from Enterprise Mobility  Guess what - number one on the list?  Better UIs for mobile enterprise apps.


And we concur.


Mobile UI design and branding is a commonplace topic which we cover with clients with amazing, increasing frequency.  There’s no slowing the topic down - it only seems to heat up.  Everyone wants great mobile apps, and customers view enterprise apps by the same guidelines used to judge any app they may download from the Apple Appstore or from the Android Marketplace.


The point is, people expect more from their Mobile UIs – they want appealing, easy, and fast.  So whether it's a Sybase-driven app built upon SUP, or a Syclo app built upon Agentry, the same set of expectations apply – appealing, easy, and fast. 


So, with this in mind, we wanted to discuss some common mobile UI mistakes that ruin the mobile user’s experience.  Some mistakes that we should look to avoid - if we want to create a best in class app that exceeds the growing UI expectations of the mobile user base. 


Here, we’ll mention three of the most common pitfalls to avoid.


1.  Miniaturizing, not mobilizing.  Many times this mistake is manifested due to a lack of understanding the true difference between desktop and mobile.  Its not just about size.  It’s about context. With mobile, you have to be prepared to serve up an experience from anywhere, at any time, knowing distractions are routine.  The UI must account for this.  Additionally, there's accounting for the input devices - no, not plug ins via USB, but how you get data into the device.  With desktop, its the user's 10 fingers, with mobile, its typically the users' fingertip.  Care must be taken to truly mobilize the UI, not just make it smaller.



Mobilize, Don't Miniaturize



2.  Violation of “Three Clicks” rule.  This could be manifested as the three click/tap/press rule as well.  This has a lot to do with the information architecture of the mobile app.  Every good mobile app allows the user to get where they need to go with minimal clicks.  So, in the design, account for that in the mobile site map.  It should definitely not take a lot of taps or clicks to get where the user needs to go, in all cases.  The below example depicts a flat IA (information architecture) on the left, and a deep IA on the right.



Three Click Rule



3.  Not Reusing Learned Behaviors.  Learned behaviors are the actions and UI elements users get used to within your application.  These are things like soft keys and navigation.  In the example below, this represents what not to do.  The UI here is plentiful, to be sure, but confusing.  Its not about quantity, its about quality.



Learned Behaviors



These are tangible mistakes to avoid when designing SAP Mobile Applications.  It really all starts with having a mobile mindset from the start and that out of the box only gets you so far.  Whether the app is packaged, or customized, there will always be a level of UX that needs to be adjusted, built, or overhauled.  In the UI world, especially in mobility, one size doesn’t always fit all.  If we take some time to avoid some of the common pitfalls at the outset, we can get much closer to meeting mobile users’ rising UI expectations.

As an interactive agency that specializes in SAP UIs, we work with companies to design the best possible user interfaces we can.  In my SAP UI Design Patterns - Forms post I focused on forms, an SAP UI staple.  But what's a great form without proper button design?  In fact some may argue that buttons are the most common if not important digital UI element in existence today.  And it's not so much about aesthetics as it is about context and placement.  A great looking button does no good if its in the wrong place or says the wrong thing. 


So today, let's focus on those little UI elements that mean so much in the SAP UI world - buttons. 

Many designers take buttons for granted. They just exist - purely just a clickable means to an end. But I say we need to dig deeper.

If you take a look more closely, you'll see there are some design points or guidelines to follow that can allow your buttons to communicate context to your users when and where needed.  Have you ever clicked a button that didn't do anything?  You probably scratched your head and clicked it again.  Same result.  Frustrating right?  How about the button maze?  You know that situation you find yourself in when you are presented with a litany of buttons that apparently do so many things but all you really want is just the one button you need?

Don't worry.  Today we set the button road straight.  Here are some design points to consider when creating best practice buttons for SAP UIs.

1.  Show or Hide Judiciously

Aside from the fact that I just used the word judicious in a technology blog about buttons, this is an interesting point.  Consider this - people click what they see.  If they do not see it, they will not click.  It may be tempting to show buttons that are disabled just because you can.  Or maybe to show state.  But this creates confusion.  Ever get confused when an  edit button is disabled?  You may have muttered under your breath - "Really?  Why is there a button I can't use?".  Here the point is show edit when you need to, and don't when you don't.  People want to click buttons.  And they will no matter if they are disabled or not.  So take the high road and avoid the confusion. (btw - I have nothing against edit buttons, literally, it's just the word I used to prove the point/concept :-) )

2.  Don't "Overbutton" it

Yes, overbutton it.  Referred to as the button maze, this is where we find ourselves in the midst of a world of buttons, trying to find which one we need - just to escape!  When it comes to buttons in the world of SAP UIs, strength does not lie in numbers.  The more buttons you have, the more choices are there, the more confusion sets in. If you find your design presents more than a few key buttons, strongly reconsider the design.  You don't want to start asking yourself -  "Wait - what does this one do?".  If you say it, your users will say it.  So, think less is more and don't "overbutton" it.

Here' an example.


Overbutton Example






















3. Use Levels of Emphasis

Quick - raise your hand if you know what this means!  For those who do - kudos.  For those who don't - dont worry I'll explain.  You see, with buttons you may want to indicate different levels of importance.  For example, primary and secondary actions.  You may want to draw notice to a particular button which is prominent on a page, while de-emphasizing others.  This is the primary / secondary rule.  For instance, on a cart or order screen, "Submit" is most likely primary while "Back" might be secondary.  Using this principle will allow you to draw attention quickly to exactly where you want your users to go first, reducing error rates and increasing efficiency.  And let me state lest we get carried away, I'm not talking a different color for every button.  Two is max and more than sufficient to differentiate emphasis levels.

Here's an example.

Button Emphasis











4. Use Proper Placement

Top right?  Bottom left?  Neither?  Clients always ask which one to use.  But there really is no right answer here as long as you stay consistent and keep your buttons in sight. In SAP UI Design Patterns - Forms i talked about forms and staying above the fold.  With buttons, you most certainly want to stay consistent in your placement, screen after screen after screen.

Repetition breeds familiarity and familiarity is a user's friend.  I am not big on "it has to go on the left or it has to go on the right".  I just think you need to be consistent.  I do think though that if you have a large form, you should offer top and bottom placement - aside from the fact you should consider a shorter form design.  So with placement - consistency is key.

5. No Mega Buttons

Ok so I had to throw this one in there.  I am not a fan of buttons with more than a few words -MAXIMUM.  When you find a button you are designing has this issue, you should rethink the button caption.  Don't use more than one or two words.  If more description is needed, use contextual descriptions above or beside the button that tells the user what to expect.  Don't try to stuff all those words in the button itself.  It looks a bit messy and is unaligned with those buttons which stick to the standard, making it stand out like a sore thumb even more.

Here's an example.

Mega Buttons




Lets take a deep breath now. Bet you didn't realize buttons were so deep right? :-). And here we are, one whole blog later, and we can begin to see there is indeed a method to the madness.  It's not about using buttons just because they're there. 


Its about using them in the right way - better use if you will.


It's key to design for ease of use with SAP UIs, and buttons are at the top of that list.


Heck - buttons are even important in kids movies...

( here's the url in case the embed doesn't play -




Trust me - it pays to think through all of these things. Little things mean a lot to today's digital users - and these are some easy points I hope you can start using today.


As an interactive agency that specializes in SAP UIs, we work with companies to design the best possible user interfaces we can.  In todays digital world, there’s so much data that is both input by the user and displayed to them, that it’s sometimes challenging to find the right mix of white space, information architecture, layout, and UI elements.  But it’s important to get it right – especially when it comes to SAP user interfaces.

There’s lots of design patterns to consider, but one of the biggest and widely used in the SAP UI world is forms.

And there’s lots to pick from - Adobe forms, WebDynpros, and JSP Dynpages to name a few.

But if you take a look more closely, you'll see there are some design points or guidelines to follow that can make your forms easier to read, complete, and navigate.  I must admit, nothing is more frustrating than having to fill out a form that is just tooooo long.  Or how about filling out a form, making a mistake on trying to submit, then only to find all the info you've filled out is blown away? 

Fret not.  Here are some design points to consider when creating best practice SAP forms.


1.  Stack labels over elements

This one may seem au contraire to the norm, but you'll find that stacking labels over elements helps to create visual flow in your forms and allows you to group like elements together more nicely. This is an example of good information architecture and making good use of real estate on the page or form.

Here's an example:

Good Example of Stacking Labels over UI Form Elements


2.  Underline links

For this point all I can say is - it's the little things that count.  A best practice UI design standard is to indicate an action before it happens - and with links - that usually starts with underlining.  This visually tells the user "I'm clickable" at first glance.  A simple design step, but simple is the key to a great online form. 

3. Use whitespace

Here the point is "busy is bad". Or some refer to this design faupaux as black space. One mistake form designers make sometimes is thinking more is better.  And it's easy to fall into that trap since there is always so much data to display and process in SAP applications. They may say "wow - look at all this info - there's so much for the user to do!".  But if you find you have too much data on the screen you should rethink your design or find other places for it on other screens or with use of tabs.  Remember less is more.



Proper User of Whitespace



4. Stay "above the fold"

This form design point is actually getting easier to implement now that bigger monitors are becoming more commonplace. But it still happens painfully enough times for me to need to mention it here.  The fold represents the Mendoza line on your screen. It's the point at which you start to have to vertically scroll. If you need to push tons of data below the fold, you definitely should rethink the form design. In todays online apps, quick visual inspection and then resulting action is the key.  The more you have to scroll down to look for things or to complete fields, the less quick visual inpection and action your users can take.  I liken this to too many words on a PowerPoint slide - nobody reads all that text and what's more nobody wants to - same principle applies for data below the fold.  At the very least, core data and processes need to exist above the fold.

Good example of staying above the fold


5.  No horizontal scrolling - ever.

It may be ok for showcasing picture or print designs, but if there was ever one UI "form" standard that should never be broken it's this one. This is the holy grail of form commandments if you will.  If your forms make the user scroll horizntally at any point throughout the experience - than the design needs to be adjusted.  This gets tricky for instance with WebDynpro UIs because of the ability to right click and add fields dynamically.  But the standard still holds true - horizontal scrolling is a big no no and never best practice for your forms.  

Here's an example of what not to do below.


Horizontal scrolling with forms = bad

So there you have it.  While there are many more points to discuss specific to forms, these are 5 simple points that don't take a lot of time to implement, but will save your users a lot of frustration and angst. They are easy to abide by and implement no matter what SAP UI technology you are using.  And while there are many types of UIs offered by SAP that range in complexity, abiding by these simple truths will align your forms to some basic standards and save your users time and effort - which is always a very good thing.


Pete Lagana

Mobile Apps or Mobile Web?

Posted by Pete Lagana Jan 14, 2011

Driving into work today I noticed a few things from my fellow drivers that made me grab the steering wheel a little more tightly and slow down.  The driver in front of me was hitting his brakes every 5 seconds, and it was becoming quite annoying.  So, rather than endure this the entire drive, I decided it was time to pass him.  As I finally had the opportunity to pass, I noticed as I was driving by that there was an iPad somehow attached to his steering wheel – that he was reading and tapping while driving.

Interesting?  Yes.  Unsafe?  Yes.  Shocking?  No.

This really solidifies what we already know as true – mobility is on the upswing at an unprecedented level, even to the point where people are willing to do unsafe things so they can still be connected to their beloved mobile devices – because these devices connect them to the people and information they need.

This is a microcosm of the mobile market today, where business need is finally catching up to consumer demand.  So, as mobile grows, the ability to expand the footprint of business solutions grow, and thus utility, usage, and time on device will also grow.

But really the question becomes - what’s the best way to feed the mobile frenzy?  What’s the best way to design, build, and deploy mobile applications?  Which provides the best UI - mobile app or mobile web?

There are quite compelling arguments for each, and I believe there are key considerations when taking into account SAP aobile apps.  There’s the Netweaver Mobile client that allows us to take web or traditional platform solutions and make them compliant from a mobility standpoint.  There’s also Sybase that provides a solid foundation to jump start your SAP apps in SUP.  Let’s take a look at the pros and cons of each side.

Mobile App vs Mobile Web

300,000.  That’s how many apps are in Apple’s App Store.  And that number is growing as we speak.  Then add in another 50,000 apps on Android and you start to get into a silly numbers game.  They're popular and multi-generational.  My 2 1/2 year old knows how to use my iPhone, open up her kid apps, and stay occupied for a while.  And I didn't have to teach her.  So there's no question the popularity and utility is there.

For mobile webb apps and sites the picture typically hasn't been as rosy.  Not so long ago if you accessed a website on your mobile phone that WASN'T an iPHone or Droid, you'd see a white screen background with some blue hyperlinks.  Not what I would call a polished UI worthy of building a site on.   But the argument for actually doing these low-fidelity screens was because bandwidth was usually low, browsers weren't advanced enough to support more, and HTML / CSS hadn't caught up to mobility yet. 

But that's all changing. 

We all know that with mobile apps, you get polished UIs, ability to call operating system apis natively ( like camera, or flash), and you get performance boosts from the device hardware.  Also native apps provide better performance which is why gaming and entertainment apps are much more prevalent than that of the mobile web.

But there are some cons associated with mobile apps.  One of the cons for apps lies in the deployment mechanism of the app store itself  (at least for iOS ).  It's very locked down and the time-to-fix / enhancement ratio is days to weeks.  So if you're looking at instant updates or releases, you have to consider this downside.   Comparatively a mobile web app has an unbelievably fast deployment mechanism in the web itself.  Got an update?.  Deploy it now.  Enhancement release or bug fix?  No problem.  Mobile web as a medium to deploy updates to users is fluid and not locked down. 

Let's take a look at the app market.  An app by nature limits your potential market.  For examp if you have an iOS app,  your market by default is iOS users - precluding those with other devices and platforms such as Android, Nokia, Windows, etc.  So to reach those, you'll need to spend time and effort to design and build in other OS apps to reach that other demographic.  With mobile web, if you code correctly in HTML5 / CSS3 (ie in WebKit), you have the ability to build your app once and deploy to any device with a mobile browser that can handle the HTML5/CSS3/JavaScript mix.  Your styles can recognize the different platforms and push familiar native UI controls out to the device.  For instance, if you have a design pattern that looks like iOS, when you deploy to Android, you can pick up and display Android styles.  Also, if you develop a really nifty HTML5/CSS3 mobile web app, you'll be able to port that over to other mobile app operating systems, and create specific wrappers to get them to run as apps on those OS's.  These all are upsides.

Also consider navigating from app to app or from an app to the web on your smartphone device.  When you launch a URL from the app, it will always close the app and opens a browser.  This is kind of annoying but there's really no way around it if you need to bounce around apps to and from the web or other apps.  With mobile web, you have the ability to keep the user experience consistent while in the mobile browser, and annoying closes and relaunches will not exist.  Food for thought.

Another con with apps is a biggie.  There's a lot of apps.  Almost too many to handle.  And maybe, even before the end of the year we could be talking about a million apps Apples' app store and another 200 thousand for Android.  That's very significant.  Finding an app is definitely an issue right now, imagine what it will be like in one year.  So unless your app is one of the top 20, or your marketing program is off the hook, your app will be buried.  "there's an app for that" could turn from catchy ad slogan to annoying reality.

But its still a very rosy picture for the native app market.  The popularity alone is going to drive acceptance and use, thus demand.  So mobile apps appeal to users in way's that mobile web may not.  And until mobile browsers on ALL mobile devices and platforms can handle really great HTML5/CSS3 UIs, the market for iOS and Android apps will continue to grow.  End there is some prestige involved with mobile apps -  personalization, and that little satisfactory thrill when you see a new app icon appear and start loading on your phone desktop screen. 

So, right now, mobile apps win out.  But, if you are betting on the future of HTML5, than mobile web will become much more prominent as time goes on.  They're not as common as native mobile apps are now, but if you can push the technology to get the UI to look and feel and work like a native mobile app, than they will be.  Let's see what 2011 holds for Mobile UIs and maybe we'll eventually be able make a choice - mobile app or mobile web.

Pete Lagana

WebDynpro UIs - Usable?

Posted by Pete Lagana Dec 4, 2010

Being an interactive shop means being involved in lots of projects where the user experience is "the"critical component towards achieving success.  So, we've had our fair share of questions like "Can we make the UI look like this?" Or "Why does it look like that?"


And on SAP projects, those questions come up a lot.


 When working with software that lots and lots of people use, those questions typically turn into statements such as "It needs to look like this" or "It needs to look like that".


Today, more than ever, companies depend on their digital solutions to drive their business, so getting the user experience right is mandatory towards hitting the mark with the user base, internal or external.


And that's no different for SAP projects.


So - where does SAP WebDynpro fit into the UX picture?  How does it stack up as a UI technology? 


Anybody who's anybody who's ever been involved in an SAP project has been exposed to WebDynpro to some degree, one way or the other.  Web Dynpro is the default UI technology for SAP custom development projects and its also becoming used more for some of SAP's packaged software.


But, having been involved now in a number of SAP projects where a key goal is creating a great user experience, it's been somewhat challenging when working with WebDynpro.  Designing great user experiences for SAP WebDynpro based projects is such an interesting phenomenon namely because constraints rule the roost and function dominates form.


But that needs to change.


Form should be just as important as function. 


WebDynpro seems to value speed in UI creation - evident when an ABAP developer creates a WebDynpro screen with some drag and drop UI elements on them after spending hours and hours writing the ABAP for the back end business logic, to process the data into the screen.  This is what typically happens, and I believe the scenario that SAP wanted to hit when designing the WebDynpro product as a UI technology - create less emphasis on the UI and more emphasis on the backend logic development.  Then let "styles" sort the rest out.


There are a couple problems I see with this.



One - that theory in the face of today's users expectations finds itself flawed.  Users in today's digital world have increasingly high expectations when it comes to how they interact and do business online; see Amazon, Google, and the iPhone.



But secondly, the person who codes the backend in this scenario is the same person who creates the user experience.  It's the same person.  The.  Same.  Person.  That's like my dermatologist prescribing a medication for my heart.  My dermatologist is a doctor too - and I'm sure he's a good one.  But does he have the skillset necessary to be a good cardiologist?  The skillset required to design and develop the user experience is quite different from the skillset required to build the backend business logic.  It's like night and day.  So, I can understand the speed in delivering screens like this, but ultimately users don't care how long it takes to build a screen, only if it's really easy to use and looks great.


Some will say that you can modify the UI - and this is true.  But it's not straightforward.  The issue is dealing with the numerous style sheets that dictate the look and feel of WebDynpro.  These stylesheets are both Portal and WebDynpro related, so you'll have to negotiate both, if your porting your WDA apps into EP.  The CSS is nested and deep, and care must be taken to align.  I have the perfect example for you.  Buttons.  Good old buttons.  The most classic UI element in the entire web.  In WebDynpro out of the box, all buttons are square.  So, what if you wanted to make them round?  Sounds pretty simple right? Not so much. The way that "buttons" are laid out in the CSS, they are really sliding cells or containers, meant to grow as the text or label of the button grows.  So, it makes it difficult to close the edges to be round.  So, what should be really straight forward, is quite the opposite for such a simple concept.


The good news is that when the right skill set is applied, you can make WebDynpro UIs look great.  Much of this depends on a lot of CSS massaging and granted, this is not something that “just happens” out of the box.  But the right know-how and experience can turn rigid and square into pleasing and round.  In the end WebDynpro can be what you want it to be.  We've had clients look twice and ask us "is this really SAP?". 


Here are a few before and after examples comparing the familiar out of the box WDA UI to one that has been customized.


WebDynpro Out of the Box

















Custom Styled WebDynpro


So when I ask is WebDynpro usable?  The answer is yes. Yes it is - if you first determine that creating a great user experience is important to you and your company, and that accepting "out of the box" is not the answer. 


That starts with the following:


- Augment the development team with UI Designers and UX Developers.  This separation of duties pays off in spades.


-Create a process for UI design and development, and create a style guide that can dictate the layout and design patterns that developers adhere to.


Looking into the future, we'd like to share our WebDynpro experiences and pointers with SAP and ultimately work in some really critical UX flexibility points into the WebDynpro product.  We've worked with it so much over the years that we know the things in detail which, if redesigned, would bring more smiling faces to WebDynpro users everywhere.  Now WDA and Floor Plan Manager bridge the gap only so much.  There is so much more that can be done with WebDynpro - it really is a powerful product that can do a lot from a functionality or process perspective.  But the magic will really happen once the power of the front end finally matches the power of the back end.



That's what today's digital users want, and that's what they should get.

As an interactive company, we are engaged in many digital projects that touch people in some way.  iPhone apps.  Websites.  Enterprise software.  Social Media apps.  These digital projects span different kinds of clients in different industries.  The type of project varies, the business requirements change, and we always need to put on our thinking caps to come up with a great user experience that hits the mark for our clients.  Clients are different.  Businesses are different.  And UI needs are different.  With all these differences though, there is one underlying truth that is always the same - out of the box UIs, at best, only partially hit the mark.


The reason is simple – we see it every day.  Clients are placing increasing value in their digital offerings.  I can’t tell you how many times we’ve heard “Can you move this button?” or “Can you plug this screen into our other product?” or “Our customers need a seamless experience across all these apps.”  Clients always want to modify a packaged product to some degree.  It’s becoming more prevalent with each passing day - clients not only expect easy, simple, and fast for their users, but also expect a seamless UI across different software solutions, often from different software vendors.  This means combining SAP and non-SAP apps together to produce ONE seamless solution.


With this in mind, we wanted to comment on the UI design approach with SAP BusinessByDesign.  In this article SAP is trying to make the UI better for some of its on-demand products.  And we think this is a noble attempt.  Everybody knows the oil and vinegar mix that somewhat describes SAP software and usability, so any attempt at remedying this is a step in the right direction.  But, in the end, the out of the box UIs will never be the end-all-be-all. Customers will always want to change it. 


So, it’s really like putting a band-aid on a broken leg, or treating the symptom not the cause.  Its not about trying to hit the mark with out of the box UIs so much as it is allowing the UI to be as flexible as possible, expect modification, and make that process as inviting and easy as possible.  This is the new reality for user interfaces.  Facilitate customization, don’t resist it.


Here’s an example.  One client we're working with wanted to produce a seamless user experience for its external customers that allowed them to create orders, process returns, create invoices, run reports, and administer users.  To the users, this was ONE process, or at least it was supposed to be.  But to the client, this was much more complex – many apps run by different software vendors (SAP, Microsoft, Ariba,IBM), all needing to be combined for their customers to offer end-to-end process-based solutions.  The old solution cobbled together many different user experiences from the disparate software solutions, to the point where help desk calls started getting so bad, that they needed to hire 10 new customer support advocates to handle the issues.  Customers often threatened to “jump ship” to a competitor whose UIs were “much easier to use”.  Similar processes like pagination, placement of form controls, UI patterns and actions – these were all different across each app, and worse, they were different across each SAP app.  But the customer needed to negotiate each UI to place an order, process a return, create an invoice, and run a report.  The number one help desk complaint - “Why is it that this all can’t work the same and look the same way – this is way too complicated.”


The point is – it’s impossible for any out of the box product to satisfy all UI needs with a blanket approach.  Enterprises today often own many different kinds of software that they expose to their users, internal or external.  Different software with different UI layouts, design patterns, processes, aesthetics, and usability.  Each individual app may do a fairly good job of standing up a decent UI, but there will always be situations where that app needs to-be modified for some reason, and needs to be blended with other apps.   So, in our experience, it isn’t as much about producing UIs out of the box that try to meet all user experience needs, but rather create a UI that is extremely flexible, and lends itself toward change - because change is the norm in the digital UI world.  Since customers always want more, out of the box solutions will almost certainly fall short. 


We would like to think of SAP software as clay – the soft maleable kind, not the hard, dry kind.  Soft clay would be UIs that anticipate and facilitate customization.  Hard clay would be out of the box UIs, and the blanket expectation that it will work for all users.  Some will say – "well you can still use a chisel to make the hard clay be what you want it to be."  This is true, but you lose pieces.  Not to mention, you'll have difficulty correcting mistakes.  We don’t want to lose pieces of SAP because of out of the box constraints. 


From a design perspective, out of the box UIs should have the ability to heal, to be soft clay.  Make customization and modification simple and inviting.  Expect it.  Embrace it.  Foster it.  In the end everyone wins, users will get what they need, and SAP will look very good in the process.

After returning from Tech Ed, SAP's new strategy is firmly cemented in my mind -  on device, on demand, on premise.  Having done lot's of UI projects for clients where the user experience has been extremely important to success, on device has special meaning to me.  It means designing a user interface that hits the mark with users, is appealing and flexible, and is certainly anything other than out of the box.  That's one of the things I've learned over the years in terms of designing great digital User Interfaces for clients - out of the box UIs are becoming more and more unacceptable


And its no different for SAP. 


Sure, everybody knows the power of the SAP backend, but can the SAP front end, the “true” user experience, match that power?  That's what today's digital users have come to expect - great UIs.  At Excellis, these are the kinds of things flowing through our mind daily, as we look for the best ways to make SAP simple and appealing across many different devices and many different platforms.  Its what we do all day, everyday - make SAP look great - and there's lots of products to pick from - to name a few: Web Dynpro ABAP and Java, NW Portal, CRM Web Shop / ISA, Bobj / Webi, and now Sybase as well.  The thing is, all of these UIs are being rolled out to users to access the backend of SAP in some way.  We always ask, what if that accessing of backend SAP was easier - so users can have it their way, in terms of utilizing SAP data to do their work? 


And then I ran across some information on Project Gateway, and that's when the juices started flowing.


Here’s what we learned - "Project Gateway enables UI-centric consumption of SAP Business Suite data by popular devices or platforms in an easy and standards-based fashion".  


It's not that connecting to SAP from these devices and platforms was a foreign concept before - it's just that now it's easier.  “On device” is really is a microcosm of reality.  There are so many devices and platforms today, which equates to all of the UIs being different.  Embracing the fact that customizing UIs are what users want, and making it easy to access SAP on top of that, makes touching 1 billion people with SAP a whole lot easier.  Project Gateway makes accessing SAP easier than pure web service consumption or with JCA, which was the way to do it in the past.


While the direct benefit of project gateway is open APIs to SAP (with standards), there is more of an indirect underlying message with all of this - UX design.   I think now UIs can be designed for SAP projects more from a traditional UX project perspective - around the users and how they work and what they need.  Project gateway places prominence on designing truly great UI's on any device or platform. Because now the focus can be around improving the users experience on their platform of choice, and not on writing tons of custom code to access SAP or change it's out of the box UIs.


With Project Gateway, we get a chance to see how SAP is recognizing this rise in the prominence of UIs, and how important it is to get the user experience right.  I believe Gateway will help SAP keep pace with users' growing UI expectations in terms of creating UI flexibility and allowing clients to have their own UIs that consume SAP.  It’s a win-win situation.  SAP back ends will still be utilized, and users will still get the UIs that they want - exactly as they want it, without having to settle for constraints in flexibility or out of the box shortcomings.  This ultimately makes the role and craft of UX design much more prominent on SAP projects moving forward.  Now, true user centered design can prominently take place on sap based projects where things like wireframes and mockups are no longer dirty words and don't produce eye rolls.  Instead the focus shifts from what can’t we do to what can we do.  Users don’t care about why something “can’t” be done, only that it “can” be done.  They want easy and they want fast.


So with Project Gateway - it looks like SAP has finally realized - that the power of the front end is just as powerful as the back end.   Times have changed.  Users want more.  And now with a focus on the UI, they’re in line to get it.

Being an interactive shop, we always are looking to produce the best user experience possible for our clients.  And because we do a lot of SAP projects, it's inevitable that those customers also run some version of the SAP Netweaver Portal. 

What has been increasingly evident over the last year, is that most of those same clients ALSO run some manner of Microsoft SharePoint.  Some companies will use SharePoint extensively, while others barely use it even for document management.  So, this is typically the backdrop of conversations that start out something like this: " We have the SAP NetWeaver Portal - but we also have Microsoft SharePoint Portal.  Which one should we use, should they be standalone, or merged?". 

That question seems to always come up for clients who have both SAP and SharePoint.  And it's not slowing down.

 The answer to that question really can get quite complicated, and can go in many different directions.  For now, though, I thought it would be helpful to list the things that we talk about with clients when consulting on SAP / SharePoint integration:


1.  User Experience. From a UX perspective, the SAP up a few ways to deliver UIs through SAP Netweaver Portal - all the familiar names such as BSPs, WebDynpros, JSPDynPages, etc.  These are controlled through a massive array of style sheets, and can be accessed directly from the server or via the Theme Editor.  With SharePoint, styles are controlled through SharePoint Designer.  So if you are familiar with your typical WYSIWYGs, then you will be in good shape.  Be sure to start out with a clean masterpage, though, or it could get messy.  


Advantage?  SharePoint.  Because SPX (SharePoint Designer) allows you to adjust the master page layout which controls all of their UIs (ASPX pages, InfoPath forms), you can start with minimal css layouts, and keep it clean.  For the Netweaver Portal, there is a lot of style sheets there to sort through, and going through the theme editor is much more limiting than SPX.  You can produce great user experiences in both NW Portal, and SharePoint, but experience and know-how are generally the secret sauce to make it look great. 

2.  Connection and Communication.  This really boils down to which platform is easier to integrate to, in other words - which is more open.  Connection and communication could come in the form of pre-built connectors, using applications like Duet, or  writing custom code.  Here we are really talking about APIs, Web  Services, and/or SOA.  Having done a bunch of projects for both NW Portal and SP Portal, its usually custom code that best enables integration.  Also worth mentioning here is connection and communication via the Federated Portal Network.  FPN provides a way for SP Portal and NW Portal to recognize and trust each other.  Throug set up and system configuration, FPN does present an alternative to APIs, Web Services and SOA.  We've set up a few FPNs at clients with this hybrid scenario, and it has worked well, especially in situations where iViews need to be surfaced in SP Portal, or WebParts need to be surfaced in NW Portal.  FPN provides soem interoperability in these cases.  

Advantage?  Even.  Both are about the same to integrate to.  Just different code, different syntax, different configurations.  

3.  Content and Collaboration.  SAP does a good joob with the KMC product, and we've built some great solutions utilizing the KM API's (  Can be pretty light and fast.  But document management and collaboration within the sharepoint platform is probably more robust.  The ability to administrate freely, the lightness of the layout, and the ability to scale horizontally make it easy to work with.

Advantage? SharePoint  Given the extensibiity of the collaboration tools, and the horizontal scalability.

4.  Single Sign On.  SAP Logon tickets rule.  Let me just say that right now.  I can't tell you how many times we've integrated SSO to an SAP portal, and most of the solution has come from manipulating the logon tickets.  With SharePoint, there are some close equivalents, but you'll generally need Kerberos to integrate fully.  Here again, FPN, once set up correctly, can allow simple sign-sign between systems, once trust has been established.

Advantage? SAP.  Logon tickets push the advantage SAP's way.

5.  Unified Search.  Search is an important factor with both platforms.  SAP Portal touts the TrEX search engine, and integrates to SAP Enterprise Search.  MS SharePoint has its own unified search, that also allows drill down by meta and quick sub searches.

Advantage? SharePoint.  Reason - open APIs for the indexes and repositories, and easy manipulation of the search results layout.

Final Thoughts for now - both platforms have their advantages and disadvantages.  SharePoint tends to be the UI Portal that sits on top for most clients we've seen, and SAP content is pumped in as iViews.  However, we've implemented it the other way around too, and that's been pretty successful as well.  I think the ramp-up of Gateway will help influence this topic significantly over the next year, and I'll be writing about that in another post.  But for now, SAP Netweaver and Microsoft SharePoint are two major factors in the enterprise ux market.  I tend to think, based on experience, that they can most certainly co-exist quite nicely.  The business case is certainly there for that.