Archive - Edition 6: Branding

back To Overview of Branding Edition

Leading Article and Introduction

All About Branding

SAP and Branding

 

Brand Adaptation of the mySAP Enterprise Portal

By Sven Kannengiesser, Christine Wiegand, & Gerd Waloszek, SAP AG – 02/21/2003

German version

Sven Kannengiesser is an SAP consultant for mySAP Enterprise Portal. His current role involves tailoring the portal to customers' corporate design. In this interview with the SAP Design Guild Team he discusses his experiences.

Legend: Sven = Sven Kannengiesser, DGT = SAP Design Guild Team (Christine Wiegand, Gerd Waloszek)

 

The Interview

Why Do Customers Want to "Brand" the Portal?

DGT: Currently, topics such as corporate design and corporate identity are playing a large role even for software products such as mySAP Enterprise Portal. Why do customers want to "brand" the portal?

Sven: The portal's target group are its daily users – they should be able to identify with it as if it were part of their own company. There was no talk of branding with SAP R/3, as the exclusive concern was enabling users to efficiently process their tasks. Evidently, portal software is still designed to help users to process their work, but in this Internet age, there is more emphasis on showing an independent "face," in other words, on "corporate identity."

Implementation Areas

DGT: In what situations is portal branding necessary?

Sven: Last year we had several small projects. The Enterprise Portal 5.0 had just been launched and was due for testing. Many large companies were toying with the idea, or had already decided in favor, of implementing our product. We therefore started a range of pilot projects and presented the results to the respective companies' management. The managers first impressions are crucial which was why, for this target group in particular, it was so important that the portal made a striking statement. Evidently, the functions and benefits of the portal are important, but appearance exerts a large influence on the decision to purchase.

mySAP Enterprise Portal 5.0 standard design Mango and Polarwind

Figure 1: mySAP Enterprise Portal 5.0 standard design Mango and Polarwind

Main Customer Wishes and Expectations

DGT: What are the main customer wishes and expectations when they take you on as a "brander"?

Sven: Quite simply to bring the design away from that of our standard portal.

DGT: That's a very broad job description.

Sven: That's right, I go to the customers and although many of them don't have a very clear vision of how they want it to be, the key word is "different" – to demonstrate independence.

DGT: Most companies have their own Websites or intranets. Surely there they will have already experimented extensively with design and branding. Do they expect to be able to transfer this to the portal?

Sven: Sometimes customers have no such expectations at all. One case in point was a household-appliance manufacturer where I initially based the design on their external Website, as this was better suited as a template than the company's intranet. The Website was simply constructed, the only problem being the dimensions of the header. We reduced it to 20 pixels and placed the welcome greeting, our search function and personalization area, and the logo, in the top right. This worked well until the company decided that it wanted to model the portal on its intranet. I nevertheless managed to persuade the customers to adopt our standard navigation.

DGT: So some customers expect the portal to resemble their intranet?

Sven: Yes, in cases where the portal is supposed to replace the intranet. In most of my projects where the layout wasn't predetermined by a style guide, either the intranet or the company Website served as the basis for the design. Having said that, there can also be style guides for intranets.

Theme Editor

DGT: To get back to the idea of "distinct" – SAP offers a tool called the Theme Editor that allows customers to achieve this "distinct" look to a certain extent. If a customer style guide predetermines colors or fonts, you can program them into the Theme Editor and already be a significant step on the way.

Sven: That tends to be my starting point: I take the Theme Editor and use it to adapt all colors, logo and graphics, in order to get an initial impression of the desired design.

DGT: And are the customers happy with this?

Sven: For many customers, this form of tailoring is entirely adequate as it is then much easier to carry out upgrades and patches. In certain business areas, we sometimes use the Theme Editor even when customers have their own style guides, in order to keep a large work area, for example.

Contacts

DGT: Who are your customer contacts? Who takes on the branding of the portal there?

Sven: Many tasks are sent out to external design companies. In other cases, the project members carry out the adjustments.

DGT: So the customers don't necessarily always have the necessary knowledge?

Sven: No, if customers have their own designers they will generally be very skilled in the spheres of HTML and graphics, but tend not to have the technical knowledge needed to implement ongoing branding requirements.

DGT: In what contexts are you involved with the designers?

Sven: I have very little contact with the designers, but what contact I do have tends to be limited to the style guides.

Projects – From Free through to Defined by a Style Guide

DGT: What kind of conditions and requirements have you encountered during your projects with customers?

Sven: I come across a wide range of different situations – from "everything must be as predetermined in the style guide" to "let's get inspiration from looking out of the window." This last scenario was the case with the heating manufacturer Weishaupt. There, I was asked to derive inspiration from the building outside. It was a real challenge, especially as my contact there had already developed her own ideas. One of the basic principles of the New York architect Richard Meier, who designed the Weishaupt building, was to embed everything in squares and that was also her suggestion. In the end, the tiled background was too overpowering and we had to simplify the design.

Branded Weishaupt portal

Figure 2: The Weishaupt portal imitates the style of the Weishaupt building, which is displayed in the upper left corner of the portal (click image for larger version)

DGT: Despite, or even due to, this challenge, this project was certainly among your more creative.

Sven: Yes, many large companies come with a pre-prepared style guide in which everything is defined in detail. These can be designed for the print media or for the Web, with the possibility of differentiation between the intranet and extranet. In other cases, the company is in the process of drawing up a style guide and I have to be guided by the relevant department.

DGT: If there is no style guide available, how do you proceed? Do you look at the company's printed media and letter headers?

Sven: Initially, I look at the company's Website. Unfortunately, where more than one exist, they tend not to be consistent. I then take a look at the printed media, such as brochures, although these are also not always suitable templates. With the Weishaupt portal, for example, their printed media made too much use of the colors black, red, and yellow which jarred with the style of the building that was supposed to serve as the basis for the design.

Another Customer Example: Of the Experimental Variety

Sven: Working for a week with Telecom Italia demonstrated that southern European countries are much more experimental when it comes to Web interfaces: everything was much more colorful and the navigation made use of graphics – in this way, Germans are more austere.

DGT: So were you able to fulfill their wishes?

Sven: Yes, but it involved completely stretching the boundaries of the portal. The end result wasn't really a portal anymore. We hid our standard navigation and instead displayed a page with internal links within which everything took place. There was no header, nothing which would identify it as our portal. The page was therefore very strongly oriented to customer wishes. In this instance though, it was evidently a suitable solution.

DGT: And how did you proceed?

Sven: First I explained what could be done and then put it into practice. There were, however, problems due to the depth of the modifications once the whole thing had been transported into a production system. We hadn't documented the modifications fully enough.

Modifications and Portal Updates

DGT: So you would say that good documentation is essential?

Sven: Yes, absolutely. That's why I document each modification in source code – out of personal interest. With upgrades, for example, I need to carry out a version comparison and then the documentation in source code comes in extremely useful.

DGT: If you change so much, as with Telecom Italia, surely you later encounter problems with patches. Is it then your responsibility to resolve these problems? How do you protect yourself against burn-out if this happens frequently?

Sven: Yes, that can be a problem and, of course, you have to support the customer. I've therefore started to ask customers every time whether they really want me to make the modifications and whether they are aware of the consequences. I personally try to be as targeted as possible when making modifications to the navigation, for example, so as to avoid later updates overwriting them. When importing modifications after an upgrade, some of the new functionality is evidently lost. For this reason I also try to dissuade customers from making modifications.

Layout – Differences between Portals, Intranets, and Websites

DGT: Let's get to two main focuses of your work, the layout and the navigation. I imagine the customer expectations in this area don't always correspond to what is practical and meaningful.

Sven: No, not all customer ideas or style-guide templates can be put into practice or make sense in a portal environment – customers first have to recognize and understand this. Often at the start they are not prepared to make concessions or compromises.

DGT: Customer expectations and templates are often defined by their Website or intranet. Where do you see the place of the portal in relation to intranets and external Websites?

Sven: An example would be customers whose internal departments have already built up an intranet, and there we often discuss the difference between portals and intranets because the limits 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 customer style guides are generally over detailed and too geared towards Websites.

DGT: So companies often give you their own style guide to work with?

Sven: Yes, then I have to clarify that I can't strictly follow this template. Website-oriented style guides offer design ideas but can't be used as a strict foundation. This becomes particularly obvious with the layout rules. Although it is our primary aim 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 I unfortunately can't avoid.

DGT: SAP iViews have predefined dimensions. If a company defines a particular frame in their layout style guide, doesn't that fit together?

Sven: Here's an example: In the Fibonacci grid, used globally by a large German enterprise, a value corresponds to the sum of both previous values. For a basis unit of 18 pixels you end up with the grid values 36, 54, 90, 144, and so on. And that simply doesn't fit. Having said that, this layout template relates to the frame, that is, header at the top and navigation column on the left. The content area is free so I don't need to pay so much attention to the distances here.

DGT: In general then, branding plays less of a role for portals than for Websites. This puts you in the paradoxical position of trying to either reduce the importance of branding elements or even to leave them out entirely when you are adapting the portals?

Sven: Yes, I then have to make the customers aware that it is impractical to make branding elements too large and ask whether they're really necessary. With certain customers there is no way of flexing the style guide rules, others are prepared to make concessions.

Demo of a customized portal page

Figure 3: Demonstration sample of a customized portal design (click image for larger version)

Navigation

DGT: One of your main tasks with customers involves creating the navigation in a different way to the way in which SAP planned it. Why do customers want to change the navigation?

Sven: I need to go back a bit to answer that question. The standard solution that we offer with our mySAP Enterprise Portal needs to meet a whole range of demands: It must be able to cope with an unlimited number of navigation levels, flexibly support different languages and browser platforms, and meet strict ergonomic and accessibility guidelines. Many customers, 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 customers 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 customers have, and want to realize, their own ideas.

DGT: How simple is it to change the navigation of the portal?

Sven: At the moment, 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 we 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.

You seldom come across customers 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 customers manage this, but changing the navigation is definitely more of a challenge.

DGT: So the problems that make it difficult to change the navigation tend be more technical than related to layout.

Sven: Yes, above all if style guides stipulate behavioral as well as visual characteristics. For example, what should actually take place when you click on a particular link. If such guidelines also need to be implemented, then the navigation component is the most time-consuming.

DGT: To sum up, you could say that your task is actually divided into two parts.

Sven: Yes, I approach the customers as a brander and the majority of my work is to adapt the portal to the wishes of the customers, but an equally important part involves initially informing the customers 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.

DGT: Sven, thank you for the interview and for taking the time to talk to us.

 

top top