Re-using user interfaces

There is a lot of attention, in the software development industry, upon software reuse. It’s a good practice, also if, often, reusing “old” software, may be a compromise solution.

Now, I want to share my ideas about “reusing” user interfaces.

In my Company, we manage an ERP system. Our business architecture is quite complex, and several processes are managed with the ERP system. System users are mainly “expert” users, people who post transactions, interact with the system, during all the workday.

There is also a set of “non-expert” users: field technicians, managers, salespeople. These people follow different interaction paths: they require information, but are not aware of “codes”, “transactions”, “modules”. At the same time they should interact with the system, but only in a limited way: an approval, a feedback, etc.

Asking them to login to the system, learn how it works, its internal logic, may be hard. At the same time, each user may consume a “seat licence”. This means additional licensing and maintenance fees.

There are many solutions for this common issue: enterprise portals, or web based applications (for purchase requisitions approval, time sheets, service reports,and so on).

But, still, all these apps require that the user adopt a new “channel” to interact with the system. This means a user interface, application logic, etc. With the term “channel”, I mean the aggregate of user interface and human machine interaction paths, or execution environment. Every time that a user has to “switch” from a channel to another (consider leaving your email client and opening a spreadsheet), he will spend an amount of mental energy only because the environment changes, and his brain have to “recall” the knowledge about the new channel. This amount of energy increases if the new channel is used with much less frequency than the previous one; eventually this may cause a “rejection” of the second channel.

We tried something simple, nothing new, but a comprehensive approach, leveraging the opportunities offered by an integrated cloud service. We tried to use a number of well known “channels”, like email and intranet, to deliver some simple interactions with our ERP system.

Today, quite every business operate some basic services to support collaboration:

 

  • Email
  • File sharing
  • An intranet

 

Every user is able to interact with these systems.

My Company have migrated, few years ago, those services on a cloud platform, a project that I have managed. It was a good move; anyhow you may find a lot of documents and discussions about this kind of solutions, googling around.

But the key advantage of an integrated, cloud-based, collaboration services solution, is search.

The search engine paradigm is one of the easiest pattern for user interface: you need something, you type in a box what you need, the system returns a list of results. You can browse through results, searching what you need, and, eventually, finding something useful that you weren’t aware of.

Al, happens in a fraction of a second. Cloud-based search engines are really powerful.

I have imagined that leveraging this feature, and using the email as a “transactional” interface, may lower the ERP adoption barrier for “non-expert” users.

So, we started to architect and develop some simple software modules, following three main patterns:

  • Publish: a report, as a document or web page;
  • Push: notification about transactions posted, or status changes;
  • Ask confirmations, approvals, or information.

 

For the first pattern, we used document sharing or intranet; for the other two, email, or web-based forms in some cases.

For example, if a mall manager wants to open a purchasing request, he uses a web form. The systems then creates a shared folder, that will be used to store RFP, Vendor offerings, budget status reports, and all the documents required for the approval process.

The organizational units involved will receive an email, with the notice of the new request. The central purchasing administration office will create a request in the ERP system, linking it with the shared folder.

The ERP system will start publishing some documents, about the request, in the shared folder: budget status, potential vendors list, etc.

Just imagine. Users not directly involved with data entry and transactions on the ERP system are able to find all the information, searching their inbox, or their file collection. They may not be aware that an ERP system is working behind the scenes. All the documents are linked together, just as usual for web pages. The search engine can be used to find everything, typing the name of the vendor, or a project description, or a tenant name.

 

We have applied this approach to several processes. The final result is that a user can simply search his mail/file/intranet archive, freely, typing just few keywords, and find what he needs.

The training required was near to zero.

 

Now, few notes for the techies.

Creating a communication link between an ERP server buried in a closed, protected, subnetwork, and a cloud service (which usually is protected in an insane way) is not easy.

Luckily our requirements weren’t so strict, no “real-time” interaction was required.

We built our interface on two widely used standards: SMTP and JSON. They are not specific of any platform,  they are vendor neutral,  and well supported on both our subsystems. So:

  • Direct email from the ERP to the user inbox for notifications and requests;
  • Structured data in a JSON document enclosed in a email for publishing.

 

Some scripts running on the cloud platform do the processing required for publishing the data embedded in JSON files. We developed a simple template engine, to speed up the graphical/layout design phase.

In this way we are able to manage the ERP-to-cloud channel.

Figura per post mail ERP integration_02

To get back Data, from the cloud, toward the ERP, we still use an email,  with some control codes embedded in it,  delegating to a small java application the task of retrieving mail messages, parsing their content, and performing a remote function call on the ERP (this can be developed directly within the ERP platform, but our current release doesn’t support the required APIs). Open source tools like Gradle and Maven provided a convenient support for packaging the runtime artifacts and retrieve/align the required libraries.

Developing everything was quite easy: both systems provide simple conversions from/to JSON. Both systems have a development environment supporting interfaces for email sending/processing. Both systems have templating engines, critical to achieve “presentation” components that are easy to maintain.

 

With this approach, we have a certain degree of independence from each of the connected subsystems.

Clearly, we have used a specific ERP and a specific cloud solution, but I don’t want to make reference to a single product, because this kind of approach can be easily followed using any of the main products available in each segment. All the “my product is clearly the best” marketing claims overestimate the differences existing among different architectures. I think that a professional ERP manager or solution architect can obtain quite the same result working on any platform.

Advertisements

Cloud based collaboration and office suites

Image The traditional landscape for Office Automation application has changed significantly.

The disruptive new entry was Google. During time, the Mountain View Company has built its online offering over four main pillars:

  • Drive,  this is both a generic cloud storage, but at the same time offers a suite of Office applications (Documents, Spreadsheets, Presentations, Drawing);
  • Gmail, just for mail processing;
  • Hangouts for text, audio, video, chatting;
  • G+, adding a Social platform to the suite.
Microsoft, durign the last years, but mainly during the last months, have followed, with an offering that is similar, by some points of view, but different in non trivial details.
  • Outllok.com offers the mail functionality, integrated with text chat (the old Messenger);
  • One Drive offers the cloud storage functionality, integrated with Office apps, with a subset of the traditional PC based Office suite.
  • Yammer: is the Social component, but in an “Enterprise” flavour. Yammer is the result of an acquisition, and is still under “integration” with the other products.
  • Share Point, in the cloud version, is a derivation of the mature on premise product, with a simpler deployment curve. This product offers an unique, structured, platform for file archiving, that doesn’t compete with Drive, or other similar products, like Dropbox or Box, but rather with platforms like Alfresco.
  • Lync, for internet based video/audio communicaton.
  • One Note, is a mature note taking product, that wasn’t able to gain user traction, leaving space for other competitors like Evernote.
Now, the two competitors are pushing their marketing efforts toward the rich Business market, and this is the big shift that I have introduced at the beginning, and that each CIO should consider carefully.

 

Significantly,  both platforms don’t put a big emphasis on the “mail” component, and both struggle to obtain a good acceptance for their Social apps.
The two things are linked, in my opinion: why any Social app require so a big effort, in a business environment, to conquer the user attention and involvement? 
The answer, I believe, rests in the lack of integration with the mail component. The great part of our daily interaction, at work, comes from mail messages. Managing messages, organizing them, forwarding and processing them, absrorbs the biggest part of the time  that we commit to interaction. This is why few minutes are left for engagement in other collaborative platforms, and we are, somehow, scared of being further involved in other things.

 

The solution would be quite simple: integrate mail in the “stream” of posts that populate our social dashboard. This could work well if we are able to organize mail, posts, documents around the big “themes” that we deal with, projects, prospects, processes.
This require two things:

  1. An intelligent classification system that is able to spot the right hashtag that is to be applied to each message/post;
  2. An intelligent search mechanism, capable of finding related posts/messages/documents, beside the “natural” linking mechanism provided by hashtags.
Another point: the majority of the cloud apps users consider them only as a practical online replacement for the traditional PC versions, enjoying the availability on fixed and mobile platforms. The real time collaboration features are often overlooked. But the ability to work, in real time, by multiple users, on the same spreadsheet or document, while chatting, introduced a new paradigm for collaborative work, that has still a long way to go.