wissel.net

wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Explaining web enablement challenges to business users

With XPages Notes and Domino application can be the new sexy and run beautifully on all sorts of devices big and small. So a whole cottage industry (no insult intended) of offerings around Domino Application Modernization appeared.
Modernization always also means: browser and mobile enablement.
Expectations ran high, that a magic button would transform (pun intended) a code base organically grown over two decades into beautiful working responsive web 2.0 applications. But GIGO stands firm and not all applications are created equal. Domino's (and LotusScript's) greatest strength, turned into a curse: being an incredible forgiving environment. Any clobbered together code would somehow still run and lots of applications truly deserve the label " contains Frankencode".
There is a lot of technical debt than needs to be paid.
The biggest obstacle I've come across is the wild mix of the front-end (a.k.a Notes client) and back-end (core database operations) in forms views and libraries. This problem never arises in the popular web environments, since there are different languages at the front and back at work (e.g. JavaScript/PHP, JavaScript/Ruby, JavaScript/Java) - only in very modern environments it is all JavaScript (the single language idea Notes sported 20 years ago).
The first thing I taught every developer in LotusScript, is to keep front- and backend separate and keep the business logic in script libraries that only contain back-end classes. Developers who followed these guidelines have a comparable easy time to web enable application.
But how to explain this problem to a business user (who probably saw some advertisement about automatic conversion to web, be it on IBM technology or a competitor)?
Tell them a story (if they are not interested at listening at any of that, there's a solution too)!
Here we go:
You are supply specialist for natural resources exploration company and your current assignment is to get your geo engineers set up in a remote jungle location. So you have to source vehicles, build roads and establish a supply chain. Probably you get a bunch of those (a living legent since 1948), stock spare parts and ensure that you have diesel stations along the way.
Everything is fine - the road might be a little patchy here and there, but that's not a problem, you get you guys delivered and working. You even look good (sometimes).
This are your Notes client applications, delivering business value, robust, efficient and can deal with a lot of road deficiency (that would be code quality).
Your remote location becomes successful and suddenly the requirements change. People want to get there in style (Browsers). Your gas stations will do, no problem here, but already the roads need to be a little less patchy and your stock of spare parts and the mechanics trained on them are useless. That would be your front-end classes and the "mix-them-all-up" coding style that worked in the past.
If the "arrive-in-style" meme escalates further (mobile devices) you need to build flawless roads (unless your oil has been found in Dallas where proper roads supposedly exist).
An experienced supply planner might anticipate what is coming and while sending in the Unimogs already prepare the gravel foundation, so paving of the road for the fragile cars is just a small step. Or nothing has been done for a while and the health road check comes back with a huge bill of material.
You get the gist, now go and tell your own story.

Posted by on 04 January 2013 | Comments (3) | categories: Show-N-Tell Thursday XPages

Comments

  1. posted by Giulio Campobassi on Tuesday 08 January 2013 AD:
    I liked your analogy. Modernisation is a bit hit or miss. In Australia, we're finding customers already have the relevant components web-ified. So, modernisation for web is not a big topic. But mobility leap-frogs over web, and is where customers want to go now. As the mobile technologies have evolved so quickly, IBM's current offerings are way to expensive to use, and the "modernisation" crowd have no cost-effective response, (yet). I would think Mobilite is not a modernisation technology, but an extension system.

    Frankly, business users don't care about the past, and never will. Most of them certainly don't like being told how their old systems, which they spent '000's on, are poorly built. They don't want to pay for that "technical debt". When we speak to customers we point out that we avoid legacy issues. Sometimes the data is poor, and found it's minimal cost to fix.

    We didn't want to get caught up with decades of baggage from existing systems, so we constructed our own delivery mechanism using Sencha Touch and Java. We take the best aspects of Domino, (like identity, security, document model, agents, and views), and combine it with the best web development technology.
  2. posted by James Fricker on Friday 15 February 2013 AD:
    [QUOTE]keep the business logic in script libraries that only contain back-end classes[/QUOTE]

    There is a lot of native Notes apps with business logic stored in the hide-when formulae of fields, labels, table cells, action buttons etc. I am interested to find out how you solve this problem of moving hide-when logic into a backend script library?
  3. posted by Stephan H. Wissel on Monday 25 February 2013 AD:
    @James: Show/Hide of design elements translates quite well from a Notes form to an XPage. The real mess is LotusScript code that mixes front- and backend classes wildly.
    I would NOT move any SHow/Hide Business Logic on an existing Notes form, but I can move that easily in an XPages application:

    1) Understand the rules (you can use an DXLMagic reportin the process)
    2) Design a JSON class or bean - depending on your skill level (I would always use a bean) - that has methods returning true/false for visibility rules. Something like:
    "approvaldisplay.showApprovalButton" which you can use in EL.

    If you feel the urge to do that in classic notes too: Create a field "HideController" on top of your form (computed when composed, hidden, multivalue). It would have one value for each hide element. E.g. "ApprovalButton":"Comment":"Something":"AnotherThing"
    Then in your hideWhen you use @IsMember("ApprovalButton";HideController). Now you can go and update that field using a backend function call. e.g. ApprovalController.updateHideFormula("HideController") where ApprovalController is the class containing your backend stuff.

    But: rather invest the time to do that in an XPage