Natural Language

SAP Developer Network blog by Andy Ross, September 2006

Syntactic sugar

SAP takes the trouble to adapt its frontends to suit its users. For example, SAP screens are routinely translated into any number of languages for the presumed comfort of users worldwide. My own team's product, a search engine, currently supports indexing in 31 languages. My team was lucky enough to get the extra languages for no extra effort from a third-party plug-in, but SAP as a whole works hard to maintain apps in multiple languages. Is it worth it? And if it is, why not go even further?

Let's start by looking at the case for internationalization. New or casual users of SAP products face a steep learning curve. Our screens and interfaces are not famous for being easy to use. When a user recognizes words and phrases in his or her own native language, this should raise the comfort level and speed the learning process. Yet most users know enough English to recognize words like Edit and Save, so how much benefit do they really get from our translations? By providing translations, we may simply be creating a dependency that we shall later have to support with continuing translation of every new development.

Natural languages evolved to enable their users to convey meaning, where the meaning of a word is something like a pattern of past usages or contexts in which the word worked as intended. Each word carries a set of associations to other words and thus awakens memories and expectations in users. The word Save on an SAP screen awakens in English speakers memories of saving money and saving documents, and thus conditions us to do the right thing when we enter information we want the SAP system to store. Each time we stimulate our Save neurons in this way we reinforce the mental association of the word Save with storing stuff in an SAP system. This is Pavlovian conditioning, and works for any word we see in this context.

By decorating its screens with words from a user's own language, SAP is reinforcing their association of these words with SAP applications, which does not particularly help SAP. SAP is also leveraging the user's prior investment in learning that language to implant SAP skills more quickly in that user, which does help SAP. So the benefit to SAP is that although the SAP transactions work the same way in any language, the syntactic sugar we sprinkle on the screens makes the user feel at home more quickly. Given how easily an SAP system platform can support the extra logic and data required to present the language sugar, the whole language customization of SAP solutions is really just frontend paint. It's like a car manufacturer offering its cars in a range of colors. The cars are the same under the skin, but if users want pretty colors — hey, why not?

Any color so long as it's black?

So users tend to think in their own natural languages, and SAP puts different language skins on its apps to help the users feel at home. What's the problem? Well, it costs a lot. Henry Ford got rich by selling Model T Fords in any color so long as it was black. Maybe SAP can get richer by selling SAP apps in any language so long as it's English. Users who know SAP transactions already would adapt easily enough. For them, the words are only labels for logic they understand already. And once they know the English words they need never go back to the old words they started on. Those words are like training wheels on a kid's bike - nice at first but not for keeps. The best learning transcends words. The words are like a ladder you kick away once you've climbed it.

More yet, if you work with icons you don't even need the ladder. You can read the icons like words and forget about those ridiculous mappings of alphanumeric strings to screen interactions. Just like iconic road signs that enable international drivers to navigate in foreign cities, a good set of screen icons can replace words altogether. By all accounts, Chinese started as a set of pictorial icons that gradually evolved into a language. Similarly, SAP screen icons can eventually become the elements of a language in its own right. But wait. What is a language? A language is a set of elements plus rules for recursively generating an infinite set of combinatorial expressions from the elements. Even if the original elements had an analog, pictorial quality, the combinatorial expressions soon lose the analog flavor and become essentially arbitrary indicators of meanings that are so convoluted as to be practically impossible to represent in pictures.

SAP has faced this problem before. In the beginning, SAP table names and transaction codes often had a mnemonic quality that made them memorable. A few thousand such names and codes later they became essentially arbitrary, and since then most users have been intellectually challenged by SAP interfaces. Learning all those codes is like learning Chinese, with the difference that there are fewer friendly natives to help you. The answer for the easy cases was to use icons, and for the harder cases there were always menu items and buttons labeled in natural language. SAP didn't need to reinvent the wheel. We just fell back on the native coding each person learns in childhood. The only drawback was that we had to offer dozens of different language skins.

The extra complexity generated by language skins is linear in the number of languages, and an SAP app can be reskinned easily enough, so this is not a Henry Ford problem. If Ford produced too many red cars, say, and not enough blue cars, repainting the red cars was not an attractive option. But there is another cost in the SAP case. Developing each new language skin carries a high fixed cost but brings a return proportional to the license revenue from new customers who use that language. A plot of revenue against language shows a high peak for English and a long tail for all the rest. Finding the breakeven point in the plot for investing in new language skins is not easy. Language versioning soon becomes an unprofitable business.

One answer would be to outsource language versioning. This is what my team has done for the indexing task with its third-party plug-in for 31 languages. With a certification program for quality control, SAP could outsource the entire language issue and ship only in English. Alternatively, SAP can keep the skinning business in-house to (a) simplify quality control, (b) make any profit to be made from our legacy of language expertise, and (c) project a more convincingly global image. These are pretty good arguments.

Frontend flexibility

Given that users like their native language skins, the logical next step for SAP would be to offer fully functional natural language frontends. Users would be empowered to type any input they liked, even tangled and idiomatic sentences with anaphoric cross-references ("find the document and index it") and metaphoric allusions ("the blockbuster revenue increase"), and get more or less meaningful replies back from the system (in the worst case a polite request to rephrase the input). The frontend would translate their garbled input into something the SAP system can understand. Such user empowerment may or may not be a big step forward in terms of usability - what sort of misfit needs to chat with an SAP system? - but it could be a big step backward in terms of maintainability and control of development budgets. So, given the cost, can the benefits outweigh it?

First, let's look at the cost. Natural language functionality is a well researched field, with plenty of open source tools to get started with. And it is a popular field with talented young researchers who sense its big potential. So SAP can get started and implement something vaguely respectable at relatively low cost. We do not need to offer a conversational interface for SAP systems (or to offer voice enablement, except perhaps as an optional plug-in), but we could certainly benefit from offering enough frontend flexibility to handle entries in input fields that deviate from the sort of strict syntax that still passes for correct style in SAP systems. All we'd need is a frontend that can handle the sort of casual prose people write in quick emails. This much we can certainly implement at a cost that pales into insignificance beside other development costs.

Next, consider the benefits. Any usability expert will confirm that some level of dialog capability would increase productivity for infrequent or inexpert users (who may not remember exact syntax) and distracted or disabled users (who may be unable to enter long strings or see the screen). Together, these use cases can add up to incremental revenue opportunities that easily outweigh modest development costs. This is not the place to cite the numbers, but I've seen quantified arguments here that make the case for going forward look very attractive. So I vote we go for chattier frontends.