App Unification -- Not always an Elixir

I decided to pen this down, after a hit back with my clients on a prolonged discussion on Apps unification, which I'm totally against, where my clients is very much inclined with.

What is unification of Apps?

Post the revolution of Smart phones, leading to mobile application development, every institution/organisation has built an App for them, trending apps evolution. There are millions and billions of App in both Apple and Google (Play) store. It is quite often, that an organisation builds more one than one app for their business. Even  Apple and Google have multiple applications under their umbrella. Apple has the following apps

• iTunes
• iBooks
• iMovies
• And many more

So Google

• Gmail
• YouTube
• Drive
• Allo
• Duo
• Hangouts
• And many more

Similarly say a banking solution will have several apps like

• Mobile Banking
• Market (Share) trading
• Wallet/e-Payment solutions
• Enterprise Banking
• And many more.

Since then, there started a debate of unifying all apps into one app, there is always an argument whether to build separate apps for each functionality or build a single app incorporating all functionalities, which has there own merits and demerits as follows:

Pros:

1.  One APP for the user to download, rather hunting for the apps for all  requirements
2.  Easy marketing, as reduces time and energy in marketing multiple apps, hence reducing cost.
3.  Single Code Base
4.  Single Authentication and Session management

Cons:

1. One Blotted APP, user might be eligible for only one functionality however he/she will be forced to download the entire application, where other functionalities are of no use to him/her. Not only that, by consuming huge space on his physical device, user will be forced not to use the functionality that (s)he fond off, forcing user to uninstall the application. Resulting business to lose a customer.


2. Single marketing diversified messages, psychologically turns down the user, resulting no returns. By diversifying I mean, marketing the same application for trading, banking and all, give an impression to the user, that jack of all trades fits none, and if any one functionality fails to meet the expectation, that will add fuel to it.


3. Single code base - might sound like a merit, but it is time bomb on its own, when it explodes no rescue team in the world has the capability to recover, because a single code base leads to shared code and resources, any change on trading functionality might lead to a disaster in banking module. Leading to both trading and banking customers frustration.
   
   More over, Every single module that gets worked out for subsequent development, all the other modules need to be tested as well, involving OPEX, avoiding such intensive testing will compromise on quality and security. It is like a situation between devil and deep sea.  


4. Single Authentication & Session Management - It is another myth that this is a merit, as there is nothing called as single session management, as session timings differ for each functionality say for example banking might have 5 minutes where as trading 60 mins. Single authentication but multiple session will puts lot of work in my back end and considerable amount of effort in my application as well.


5. Lack of Analytics -- We will never why the customer has downloaded our application, as it could be one functionality or more


6. Reckless Marketing -- We wont be able to target the customers for a specific functionality to promote the application. It is like shooting in the air

Reasons why I suggest multiple applications

1.  Targeted Marketing -- It becomes easy to evaluate the marketing medium and the population.


2.  Analytics -- When a Trading application is downloaded, we know for sure the customer  requirement and intention and this analytics will help to target the marketing.


3.  Customers Jurisdiction -- Making customer to feel king, giving the flexibility of choosing what  to download and what not. Atleast assuring that (s)he not getting spammed.


4.  Multiple Session -- This is huge advantage, giving flexibility to have different session for  different application and also multiple authentication if required or SSO.  a la carte  implementations.


5.  Multiple Codebase -- It still gives the flexibility of sharing common resources, thanks to  modern build tools, and also gives the uniqueness for each application, a perfect combo.


6.  Discontinuation -- My favourite, any time without affecting the other modules (APPs),  business can  decide to discontinue the support for a functionality (if APP)

There is a saying "There is a reason why these roads are less travelled", when big giants take back foot on unification, then it becomes a subject for scrutiny.  Unity is strength, but not always, especially in APP unification it is stampede..

ChatBOT for Banking Services

Ever since I started tracking Bots, I was very fascinated and excited to see domain-specific use cases that are genuinely helpful. I always had a crave for innovativeness and digital transformation, which made me to move from main stream application development to mobile application development almost half a decade ago, this urge has made me to derive a use-case for banking solutions, and here is my first ChatBot for banking solutions, unlike other chatbots which can perform only non-financial transactions, I took a giant leap (very calculated) by training and executing the BOT to perform a financial transaction in par with banking security norms.

My chatBot is capable of performing local and international transfers in almost all major currencies.

It also gives the flexibility of withdrawing cash from our ATMs through banks unique without card cash withdrawal feature. The power packed combination of transferring money to beneficiaries and withdrawing money for self, has been well received by my customers, and I see increase in BOT transactions. No wonder this has given our customers to do banking any time any where with a personal touch. Along with this financial transactions BOT is also capable of responding users on queries of accounts information, and their recent transactions as applicable.

In order to give this digital excitement to every one including non-banking customer, have trained BOT to accept registration from Non-Banking customers as well, as long as they have valid local mobile number. A Non-Banking customer can view the products and services and enroll to them online to experience the full benefits of the BOT.

It is just a start and there is lot more to achieve, industry is already moving towards the higher end technologies like human less branches, personalized offers through BigData and all. There is a transformation of this industry from Branch banking to SMS banking to IVR banking. Then came the internet era giving path to Internet Banking, and the smart phone era leading to Mobile Banking. We are stepping into Artificial Intelligence (AI) era, BOTs, humanoids are the future, and I just took a step towards it.

Mobile Website --- touch events

I was asked to assist a developer who is working on a  task with hard deadlines, it is a kind mobile game built in HTML5/CSS3 (technically issue is not in HTML). Task is to swap images on touch events, say there 3 images (img1, img2, mg3), user taps and holds on img1 drags it and drops on img3, then img3 should take img1 position on the screen and img1 should take img3. It sounds simple,it is, however it has got it own difficulties too. Just two things to keep in mind 1) Touch events are not exact replacement for mouse events 2) there are no direct solutions always. Below the solution I arrived (it doesn't handle multiple touches).


<!DOCTYPE HTML>
<html>
<meta name="format-detection" content="telephone=no" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="viewport" content="initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, width=device-width" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<head>



</head>
<body>

<div id="div1" style="width:100px;height:100px;background-color:black;color:white;left:10px;position:absolute;"> div1 </div>
<div id="div2" style="width:100px;height:100px;background-color:red;color:white;float:left;left:120px;position:absolute;"> div2 </div>
<div id="div3" style="width:100px;height:100px;background-color:green;color:white;left:230px;position:absolute;"> div3 </div>


<div id="write" style="float:left; width:100%; margin-top:150px;"> </div>


<script type="text/javascript">
var position = ['div1','div2','div3'];
var elemts = document.getElementsByTagName("div");

var pageX ;
var pageY ;
var StyleX;
var StyleY;
var strEle ;
var strPos = 0;

for(var i=0;i<elemts.length;i++)
{
    settouchevents(elemts[i]);
}

function settouchevents(div)
{
    div.ontouchstart = function (e) {
             e.preventDefault();

    strEle = div.id;

    for(var j=0;j<3;j++)
     {
       if(position[j] == div.id) strPos = j;   
       
     }
   }   
 
    div.ontouchend = function (e) {
    var pos = 0;
    var newleft;

    if(parseInt(StyleX) < 100) {div.style.left = "10px"; pos=0;}
    else if(parseInt(StyleX) < 210) {div.style.left = "120px"; pos=1;}
    else if(parseInt(StyleX) > 220) {div.style.left = "230px";pos=2;}
   
    if(pos != strPos)
    { 
        document.getElementById(position[pos]).style.left = (100*strPos + 10*strPos + 10).toString() + "px";
        document.getElementById(position[pos]).style.left + "<br>";
         position[strPos] = position[pos];
         position[pos] = strEle;
           
    }   
    e.preventDefault();
}   

    div.ontouchmove = function (e) {
        pageX = e.touches[0].pageX;
        pageY = e.touches[0].pageY;
        StyleX = pageX - div.offsetWidth / 2;
        StyleY = pageY - div.offsetHeight / 2;  

    if (e.touches[0].pageX < 0) {
               div.style.left = "10px";
        }
           else {
               div.style.left = StyleX + "px";
        }       
    e.preventDefault();
    }   
}
</script>

</body>
</html>

Beyond HTML5

There is a hue and cry for HTML5, why not? As a new standard (yet to be standardized) every one want to seize it at the earliest, which has its own cost, and that is forfeiting old browsers (esp IE6/7/8), for few it may not be an expensive deal, but for many it is very expensive as they cannot afford to lose their valuable customers. Because of this many hesitate to switch to this new technology, as they are scared of losing there customer base without even knowing HTML5 is a not a new standard, but a culmination of existing two technologies, yes HTML4 (DHTML) and JavaScript.  Today we are going to see how to make HTML5 to work in old browsers, however before we get to there, first we will see how HTML4 and JavaScript can make HTML5 (close to)

To support my statement, I’m going use few attributes in HTML5 and how they can be achieved in before HTML5 standards.

1)      Contenteditable :  This is something which is already existing in HTML4+, however implementing the same was tiresome, people who have worked/working on WYSIWYG would know what I mean, even before HTML5 emerged, Wikipedia, Google were using this in their website to build rich text formatting. Let’s see the implementation of the same in HTML5 vs earlier version    

                                                  EX (in HTML5): <p contenteditable="true">                           This is as simple as that in HTML5. However in earlier versions                                                                                 <html><HEAD>

<SCRIPT>

function EditContent() {

    currentState = oSpan.isContentEditable;

    newState = !currentState;

    oSpan.contentEditable = newState;

    oCurrentValue.innerText = newState;

    newState==false ? oBtn.innerText="Enable Editing" :

        oBtn.innerText="Disable Editing"

}

</SCRIPT>

</HEAD>

<BODY onload="oCurrentValue.innerText = oSpan.isContentEditable;">

<P>Click the button to enable or disable SPAN content editing.</P>

<P>

<BUTTON ID="oBtn" onclick="EditContent()">Enable Editing</BUTTON>

</P>

<P><SPAN ID="oSpan">You can edit this text.</SPAN></P>

SPAN can be edited: <SPAN ID="oCurrentValue"></SPAN>

</BODY>  </html>                                                                                                                                                           This is extensive javascript, well still it is worth, and we can use the same syntax (for html) as in HTML5, which will be discussed in the next example.

2)      PlaceHolder :  This attribute specifies a hint, the tells the user what is expected on this input field, the hint is displayed in the input field when the input field is empty, it can be short description or format which will educate the user as to what to enter in this field. Ex (in HTML5) <input type="text" name="fname" placeholder="First name" /> as we can it is pretty neat and simple, all we to do is add the placeholder attribute with the appropriate text, rest is taken care by the browsers, which supports HTML5 on browsers HTML5 not supported the placeholder is of no use,  but how to make it work in old browsers as well, here comes the JavaScript (Can use Jquery or other frameworks which is not in the scope of this article) to rescue us                                                                                                                                                                                                                           

<script type="text/javascript">

var ids = document.getElementsByTagName('input');

for(int itm =0; itm<ids.length();itm++)

{

        if(ids[itm] != null && ids[itm].type != 'text' && ids[itm].placeholder != undefined)

          {

                        ids[itm].onblur = 'javascript:AddDefaultText(this);';

                        ids[itm].onfocus = 'javascript:RemoveDefaultText(this);';

          }

}

function AddDefaultText(txtCtl)

    {

         if(txtCtl.value == "")

            txtCtl.value = txtCtl.placeholder;

    }

function RemoveDefaultText(txtCtl)

    {

        if(txtCtl.value == txtCtl.placeholder)

            txtCtl.value = "";

    }

</script>

With the above example you can see how the HTML4+ can be used as HTML5, but with little extra effort, however this little extra effort can be isolated and can be developed as framework ( well, there are frameworks already available http://remysharp.com/2009/01/07/html5-enabling-script/ )

In the same way the other new attributes (like Min, Max, Pattern, Required and all) can be made work in older browsers.

The new elements in HTML5 (like article, header, footer, nav and so on) can also be made work in earlier browsers even in IE6 by just simply adding below JS code, I’m not going to discuss about this here, I leave this to you for self study.

·  document.createElement("article");  

·  document.createElement("footer");  

·  document.createElement("header");  

·  document.createElement("hgroup");  

·  document.createElement("nav");