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.