SAP Portal Usability and Branding

Former Member · ‎01-05-2008

SAP Portal Usability, Branding design

December 1st 2007

Art Attar, SAP EP PM and consultant.

Summary: With over Eight full software life-cycle (SLC) SAP portal (EP4 - EP7) ERP implementations, Mr. Attar, a Portal Project PM, provided portal branding and usability advice in "Every" portal project, despite the change of technology the past 7 years, and wide range of Portal deployments that Mr. Attar managed (including CRM, ESS-MSS, BI, KM, DM, WCM, ECC5). SAP EP interface adapted by many companies where ROI is bottom line.

Intro: SAP Portal Usability and Branding design process, is and integral part of every portal project requirement. In fact, the last thing Portal project sponsor expects, is user resistance to the NEW Portal due to change of look and feel, difficult to use, performance, users lost in navigation, resulting in requirements are not met. What matters in user experience to get their daily tasks done, simplicity and ease of use, that will create a lasting (product or service) Brand experience. The critical balance among performance, ease of use and security is a crucial operational element for any business website, SAP Portals (Vendor/Customer/Employee) face these challenges to deliver optimum value.

From practicing SAP EP consultant perspective, this blog/article below shed light on the importance of the Branding and Usability in ANY SAP Portal project, that is usually overlooked (some times sacrificed for technical issues) for lack of time/resources.

Why Branding: In general branding plays less of a role for portals than for Websites. Given all the difficulties involved in changing the default GUI, one might naturally ask if it makes sense to change the visual design of professional software. Companies are increasingly relying on business software to generate parts of their Websites and intranets, supplying value-added access and information to employees, clients and partners by linking their entire SAP back-end system to a Web interface available from any computer connected to the Internet. For this reason, the front-end must reflect the branding of the company whose data is being interacted with. All this is happening increasing over the Internet and within corporate intranets; for this reason, the visual design of software running in a Web environment must respond accordingly. The trend toward re-branding business software will require that corporate Web designers learn more about traditional software UI design and that software UI designers learn more about Web design. Good software for Internet applications will be measured partly on how well it supports designers faced with the challenge of branding the software to meet their company's needs. Consider Brand as an Asset (not liablity) a five evolutionary steps to creating a brand that is an asset while each step will lead to the other Authenticity, Impact, Alignment, Depth and Loyalty. Executed properly, each layer adds significant value to the organization. (Ref. 2)

Branding Methods:

Customers don't just pay attention to marketing campaigns – they also take note of how a company reacts in matters like goodwill, call backs, adherence to environmental standards, settlements, and so on. Branding can be labeled as the sum of all a company or group's perceptible activities (both positive and negative), products, sponsoring. (Ref. 3)

Marketing is active, direct communication with customers.
Usability affects the relationship between tools and their users, a usable tool enables the user to complete tasks as effectively as possible.
Branding is more subtle. Often it is indirectly perceived by clients and therefore encompasses a wider area.

From Portal Project Management perspective: (Time, Cost, Resources)

Design work models capture the work of individuals and organizations in diagrams. Five different models provide five perspectives on how work is done: the flow model captures communication and coordination, the cultural model captures culture and policy, the sequence model shows the detailed steps performed to accomplish a task, the physical model shows the physical environment as it supports the work, and the artifact modelshows how artifacts are used and structured in doing the work. Effort includes; Field Data Collection, Visioning and Storyboarding, User Environment Design, Paper Prototyping. (Ref. 6and Ref. 😎

A Practical tool to utilizing Usability Methods Table: to optimize resource allocation within project time frame (Ref. 7)

Technically speaking,

SAP Portal, technically to brand portal your way, you have to define a framework page(s) and theme(s), add them to a portal desktop, and add this portal desktop to portal display rules. More than one theme and/or framework page are available to be selected by portal user in portal personalization. Taking into account limitations of the Theme Editor exclusively changes values in style sheets and replaces image files, i.e. only attributes and images which are controlled by style sheets can be changed, such as colors, fonts, spacing, background images, etc. As no HTML code is changed, layout changes (for example, changing the position of the detailed navigation) are not possible with the Theme Editor.

Theme Editor Ease of Use and Cost-Efficiency

The Theme Editor is a cost-effective branding solution for the mySAP Enterprise Portal. It is best suited for projects with a "conservative" approach to portal branding without changing the layout of the portal. While the branding options are pre-determined and in some ways restricted by the Theme Editor, this tool offers two big advantages: No technical knowledge is needed to adapt the design and custom designs are protected when the portal is upgraded

Project planning UI and Navigation:

As project manage or team lead, we advise to include UI and Navigation, early in the project scope/plan, a well defined objectives, and resourced task driven by Portal User-Role assignment.

Usability

User community driven approach, design, prototype, communicate effectively then realize.

Layout – Differences between Portals, Intranets, and Websites

In general then, branding plays less of a role for portals than for Websites, The client style guides are generally over detailed and too geared towards Websites, not all customer ideas or style-guide templates can be put into practice or make sense in a portal environment – Client first have to recognize and understand this. Often at the start they are not prepared to make concessions or compromises.

Client expectations and templates are often defined by their Website or intranet, and In many cases clients whose internal departments have already built up an intranet, and there we often discuss the difference between portals and intranets because the fine-line between the two are so flexible. An intranet is typically an internal source of information, just with fewer applications. For a portal, on the other hand, the applications are much more highly developed. Our portal is therefore neither simply a tool to exclusively power web-content management, nor simply a Website. The client style guides are generally over detailed and too geared towards Websites.

Style guides:

Website-oriented style guides offer design ideas but can't be used as a strict foundation. This becomes particularly obvious with the layout rules. Goal is to reproduce the company's style guide or rules as closely as possible, many don't make any sense in a portal environment or are a hindrance in some cases: If you, for example, limit the width to 600 or 800 pixels, that may be enough for a Website. For a portal, on the other hand, you need as large a work area as possible, as the portal is both a tool and a source of information at the same time. You also often lose valuable work space when the style guides set the dimensions of headers with logo and branding elements and navigation surfaces too large. When it comes down to it, our standard design with its narrow header area is optimal. If branding elements demand too much space then there will no longer be enough room for applications and iViews which were originally developed to fit a defined height and width. If we "squash" them into the remaining room, then ugly scrollbars appear all over the place, which we unfortunately can't avoid. Keep in mind the font size, browser type and age of the user community relating to accessibility issues.

Navigation

The standard solution that we offer with our mySAP Enterprise Portal needs to meet a whole range of demands: It must deliver

1. Unlimited number of navigation levels,

2. Flexibly support different languages and browser platforms,

3. Meet strict ergonomic and accessibility guidelines.

Many users, however, don't need the entire range of these capabilities and can, for example, define which browser their employees install, insert text on pictures, as only one language is needed, or limit the navigation depth when there is a narrower scope of information to be recorded. In such instances it can make sense to limit the possibilities of the standard product and adapt the design so that it fulfills the specific demands and wishes of the customer. A further reason can be that the customer style guide stipulates a particular navigation concept, for example, dropdown menus. Many clients would like to have the navigation exactly as it is on their Website again, or simply want it to be "distinct." Even though there are many arguments in favor of the SAP concept, we have to accept that clients have, and want to realize, their own ideas.

The changes to the portal navigation demand extensive technical knowledge. With the portal, we are supplying two navigation elements that, although they are can be adapted to each other, combine several technologies: Java code reads the user roles from the navigation tree and goes through it in several loops. The result is transmitted in HTML, in order to represent the navigation structure. CSS classes define the details of the representation: They are defined in the style sheets, which developer can adjust. We also need JavaScript for the navigation functions as one click triggers several processes: For example, when you click on the top-level navigation, you fill the content area while at the same time altering the optical appearance of the top navigation and the element clicked on.

Developers seldom come across clients being able to simultaneously process Java, JavaScript, HTML, and CSS. You also have to remember how the tree is read if you want to represent something differently than predetermined. If, for example, the top-level navigation only consists of one line and has drop-down menus, you have to look in Java-API to see how the Java classes are defined and understand the mechanism. This demands relevant knowledge.

It is not difficult to adapt the header, most clients manage this, but changing the navigation is definitely more of a challenge.

Improving Accessibility and 508 compliance:

Many countries are planning changes to accessibility legislation. Along with experts from other software vendors, the SAP Accessibility Team is involved in efforts to amend Section 508 (USA), the ordinance on Barrier-Free Information Technology and the WCAG (the Web Accessibility Initiative from W3C). SAP's external commitments with respect to accessibility legislation motivate the team to take a close look at SAP's products. The software and service structures are tested at various points of the product life cycle, sometimes in Walldorf, but primarily at a lab in India. These tests determine the nature of the product and its status with respect to accessibility. Some SAP products are not yet fully accessible, but the more up-to-date an application or technology is, the easier it becomes for developers to meet accessibility requirements. The SAP team now plays a much larger part in testing these basis technologies and makes sure that new technologies allow accessible applications to be developed. Examples of these basis technologies include Dynpro and Web Dynpro, which are available as part of SAP NetWeaver. Many applications are developed using these technologies.

Which Products Are Accessible?

The definitive accessibility status of a product is recorded in Voluntary Product Accessibility Templates (VPATs). These templates document the accessibility or partial accessibility of a product or its individual components. One example is the administrator role in SAP NetWeaver. If an ERP product is based on an SAP NetWeaver release with an enhanced administrator role, a database administrator with a visual impairment benefits from improved accessibility features for this ERP system.

The Accessibility Road-Map is a blueprint for the future. This is a declaration of intent by SAP to guarantee certain product characteristics before a specified deadline in the product planning process, usually involving a time frame of two to three years. The Accessibility Team can provide more details on request. The road map can change, however, subject to changes being made to product life cycles or to legislation.

Going forward with EP7:

ITS became -Embedded- as integral part of the EP WAS, eliminating another connection layer and SPoF (Single Point of Failure); but there no free lunch; while SAP transactions goes through WAS-ITS, the EP rendered transactions, may not have the same mySAP expected visual behavior, look and feel. Extended testing of these transaction in EP is highly recommended.

Conclusions

If branding requirements and usability are taken into account in the Design phase, followed by the BluePrint phase, this provides all the requirements for individual visual modification for our customers later branding.
Companies will want their own branding on the front-end of software that stores, administers, and reports on their data. That's not creating bells and whistles; that's supporting reasonable customer expectations.
It is extremely important part involves initially informing the clients of the possibilities and advantages of the standard solution and making them aware of the problems involved with adaptation and with using the Theme Editor.
User experience matter, don't ignore it.