Last week I ended by stating “Next week I will highlight a non-syntax based example. This example will show how potential that exists to achieve phenomenal functionality is often completely ignored—not because of lack of simple thinking.” It is a confusing sentence. It is intended to be so. Good functionality is often ignored completely. But the main reason is NOT that all of us lack the thinking power that is required to unearth the potential. The reason is somewhat different. But I will explain all that later in the article. First, let us take another example of how hidden potential is often not managed well.

User activity in your application
Yes, the activity that a user does in your application is one of the most under-utilised hidden opportunities—from a technical as well as business point of view. Don’t believe me? Read on. Before we search for hidden opportunities, let us first enlist what a user does in your application. Of course, it would depend a lot on your application, but there are some things that are very common anyway. They are detailed below, in Table 1.

That’s it. Leaving aside some other rare exceptions, that’s about all that any user does with any application. Okay, now that we have listed all these actions, what’s the big deal? You knew all this before, right? Now let’s do a small exercise. The question is, do you track these actions within your application? Most often, the answer is NO. Why should we track these actions? What difference does it make?

You would of course know that clicks were and are tracked in some Web applications. But most of those things were used as revenue-generating/billing tools to attempt to make money during the dotcom boom time. Lately, that focus seems to have gone down. It was used in various ways—page views, clicks, log of clicks and so on. But if you notice, most of these were a secondary capture of information. All activity is logged in the Web server log (in an internationally standardised format). The analytical utilities have to pick up and process data from the log to achieve further results. Often the Web logs are massive in size and take hours to process. Therefore, many organisations simply don’t end up using logs.

What I am talking about here is not based upon Web server or other third party logs. I am highlighting direct opportunities of capturing information while users are performing these actions.

User activity logging
Let us see how to log each of these actions from a technical point of view (See Table 2 above). We will then discuss what to do with them. Moreover, once you see the utility of this idea, the methods of logging will also evolve further.

Menu Handler functions
Most often, pull down menus lead to dialogs or forms. We generally tend to directly call a form from the menu selection event by specifying the name of the form directly. One small tweak here and you can actually transform the way your menus are handled. The idea is very simple but the impact is great. All you have to do is write a function that is your menu handler. Any new call to a new module/form/dialog will be routed through this function.

Therefore, instead of invoking the form from the menu, you call your menu handler function and pass the form name as the parameter.

Function Menuhandler (formname as string)
< do something useful>
< call the form>
<do something useful>

End Function
Sounds boring? Wait till you see the list of what you could do in the ‘something useful’ part! Each item listed below may be generally applicable or may be relevant only in specific types of applications. However, the list is intended to highlight the available opportunities. This is just a list. Some of the aspects are detailed below.

• Before invoking the form

1.) Log usage.
2.) Check for adequate diskspace.
3.) Check for prerequisites.
4.) Check for role-based security.
5.) Compare previous log and take action, if required.
6.) Analyse existing user activity log and provide specific information/help/tips.
7.) Control Spam or denial of service attacks.
8.) Analyse and manage misuse or intrusion.
9.) Consider whether you require re-authentication of current user.
10.) Check for functional blocking security.
11.) Check for Web and/or data server load and bottlenecks.
12.) Notify relevant person(s) or processes.
13.) Start related processes automatically.
14.) Check if adequate backup is taken, if not give warning messages.
15.) Implement licensing / trial - full version / counter based feature management.
16.) Log technical data for further analysis and debugging.
17.) Invoke specific type of help automatically.
18.) Provide voice / visual / other type of feedback (accessibility).
19.) Provide warnings.
20.) Provide quick upgrade help (if functionality of this menu has changed a bit due to an upgrade).

• After the form is used and closed
  Many of the above may be applicable at this stage as well. But some specific ones are useful here.

21. Third party validation of committed transaction (For example, parent to verify child’s transaction in a kid’s bank account).
22. Show related form—in case of a workflow where process is well-defined and one activity is predictably followed with another.
23. Show related report, if users often see the report after performing a particular task.
24. Depending upon success or failure or any other business condition of the transaction done in the form, enable or disable other UI elements and menus.
25. Forcefully quit the application in case some type of abnormality was detected in the last transaction.
26. Forcibly logout the current user and block his further access in case some type of intrusion was detected.
27. Shutdown the entire system and alert administrators in case some abnormal and severe event was detected.

Does this sound useful? Remember, we are not talking about a particular type of application yet. But still, most of the above will be relevant to you in most application scenarios. Now, let us discuss some items from the above lists, which are not commonly and easily known. I am retaining the serial numbers for easy correlation.

2. Check for diskspace
This may sound like a very minor thing. But, if you are an administrator, you know how many times an application, or even worse, the entire OS has come to a halt or become painfully slow because of a sudden decrease in available diskspace. So would it not be very smart to prevent invocation of a module itself if the diskspace is below a given limit? You define the limit in some configuration file for your application. Checking is a simple function call in whatever language you use. If it is below the threshold, give a nice message to the user and that’s it. You have avoided the user getting bugged due to a very slow system. Simultaneously, you can alert the administrators. What’s more you can take automatic actions to free up diskspace like:

• Truncating logs.
• Erasing older logs.
• Extending database to another disk.
• Moving some bulky data to another machine.
• Running some custom script.

A typical problem with this type of checking and alert mechanism is that when it occurs, the administrators may not be in a position to respond immediately. One nice tweak of this functionality is that you could have two thresholds defined. One where the application refuses to work and another threshold where it just generates alerts but continues working. The alert threshold should be sufficiently more than the shutdown threshold so that the alerts start coming at least a few days in advance. The exact threshold numbers will depend upon your application. But it is worth giving it a thought.

Incidentally, this facility can be implemented in Windows NT / 2000 without any coding. It is a feature available in Performance Monitor alerts. Why don’t you find out how it works for yourself? Some stimulus for the not-so-utilised parts of your brain!

3. Check for prerequisites
Prerequisites could be one of two types—technical or functional. Technical prerequisites could be availability of some related website, diskspace, capacity of the system to manage the load which will be generated by executing the selected menu, and so on.

More important is to check prerequisites that are business-oriented and functional. How often have you selected a transaction menu only to be rudely reminded (after the form appears and you try fiddling with it) that there are no products in the product master or no location is available or that you needed to enter the expense heading first? This type of design is frustrating to users. The obvious thought in their minds is that if the form is not going to work, they should have been informed before the form appeared. That is exactly what I mean by ‘Check for prerequisites’. If you find that some other things need to be completed before effectively utilising a table, then inform the user about it. Moreover, you can actually give the user a choice of performing the prerequisite action there and then. Does it sound like too much of user focus? Believe me, it is not. This is REQUIRED.

4. Role-based security
Role-based access to application functionality is a common application requirement— whether Web-based or client-server. Most of us manage it by having a role master, functionality master and role-functionality map. But where do we manage the actual enforcement of role based security? In case of Web applications, the Links that a user has rights for are rendered. Others are simply not rendered. So no problem. In case of client-server applications, menu/toolbar items can be disabled depending upon the role-based map.

But there still remain some circumstances where you can decide whether to allow or disallow the current user to perform an action only after the menu/URL is clicked. For this purpose, it is nice to have role-based security checked just before form invocation.

Assuming you already have a user-role-functionality map table structure, you simply have to add another field—function to be called to perform a “LATE”—role based check. This is especially useful when the given task could be done by any of the persons within a given role. But once a person does it, others in the role cannot or should not do it. Another reason is that, in case of the Web, a link that was available to a person when the page was rendered is not available, but the page has not been refreshed. Now, if you are just relying on URL rendering for role based security, this would provide unauthorised access.

Continued
Actually, I had thought I would finish this topic this week. But as usual, when I started listing what can be done with a simple menu selection or a mouse click, the list went on an on. To do justice to these ideas, I need to continue this discussion next week. Kindly adjust...

Feedback
Your feedback, suggestions, requests for covering specific topics or issues are welcome. Please send feedback to techforum@mediline.co.in

About the Author Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in