|
The hunt for hidden opportunities – IV
Tech Forum - Dr. Nitin Paranjpe
 This
series seems to be turning into a book! But the response to the
previous episodes has been so good that I am compelled to continue
and explain what can be done with every user action. Please refer
to Techforum
for the previous episodes of this series.
12. Notify relevant
persons and processes
Most of the items listed in the previous articles were related to
logging relevant information and analysing it. Now, this type of
usage is more for notification rather than logging. Notification
can take various forms. Consider a simple example, say, the largest
order entered for a given period (day, week, month, etc). Inform
the sales head about it. Notify the guy somehow—direct message
on workstation (Using SEND command), e-mail or SMS. Similar notification
can go to another process—either for information or for taking
further action (see next item). Notification can be for the current
user itself. You can display a birthday or anniversary, provide
information about qualification for some volume discount, or whatever
else is needed.d.
13. Start related
processes automatically
Here we venture into two areas that are popular hype in today’s
IT world—workflow and Enterprise Application Integration (EAI).
Generally both these are afterthoughts. Very rarely do we realise
that all business processes are workflows and all applications will
require integration sooner or later. Therefore, a lot of Line of
Business (LOB) applications that necessarily automate business processes
are not built as workflow applications. Moreover, while building
a given application, no thought is generally given to its integration
with other (existing or future) applications. This is the right
place to manage the show. Of course we are assuming here that a
user activity is some type of database transaction. The way to weave
workflow into business transactions is to use database triggers.
The way to manage EAI effectively is to have a transaction manager
which controls what happens next (whether within the same application
or some external application). Very easy to manage it here, if it
is thought of at the design stage. The best part of this methodology
is that you can introduce workflow or EAI functionality just by
putting in additional code, before or after or during a given transaction—either
at UI Code or at database level (preferred) or at log (the custom
log mentioned earlier) level.
14. Check for
backup adequacy
This is a nice twist. This one applies more to desktop applications
than server applications. Most users do not take backup. How often
have you said “No” to the ‘Auto archive Now?’
message! Apparently there does not seem to be any practical way
of forcing end-users to backup their data. And when they lose it
they make life difficult for the IT department! And how many of
us in IT actually take regular backup of non-enterprise data? Anyway
here is a nice way of persuading and then forcing end-users to take
backups.
- First of all, find a method of logging
important activities in your application that generate data worth
backing up.
- Then find out a threshold of the number
of items, which, if pending, must be backed up.
- Also find out a lower threshold called
the warning threshold.
- Example: Suppose your application is
a personal finance manager. The warning threshold would be 10
entries, and the absolute threshold could be 20 entries pending
for backup.
- Now, your application needs to check
the actual vulnerable entries against the limits set.
- When the warning limit is reached, show
a startup message requesting users to backup. Users can ignore
this message. Also mention that if they ignore this message the
system may force a backup.
- Now when the actual limit is reached,
display a message which gives only two options—Backup or
Quit. Nothing in the application works..
I have used this method and found this
to be very effective, practical and feasible. Users do not feel
offended, as they have been warned well in advance and repeatedly.
It also ensures safety of your data and
reduces support requirements.
15. Licensing
and usage access feature management
Application licensing can be hardware- or software-based. In either
case, it is about deciding whether to allow the entire application
or parts of it to be used by a given person at a given time. User
activity like choosing a menu is the best place to control feature
access. If you have security that’s based on a hardware lock,
it can be even more flexibly managed. Most hardware locks come with
on-device RAM. This memory can be used to keep flags that allow
or disallow feature usage. A stub can be sent by mail, which activates
these flags when the user purchases additional modules.
16. Log analytical
or debugging data
Check for an error log. See if there is any update available. Add
data to export log. The export log is a log that the vendor needs
for refining the product. The ‘Send Error Report’ functionality,
which Microsoft introduced, is a nice example of this. This function
is invoked when an unhandled exception occurs, and could be used
under other circumstances as well. Remember, users may or may not
give direct feedback about product improvement. But it is so much
simpler to device a product which itself accumulates relevant data
and sends it to vendor for further analysis. Of course this needs
to be done with user consent. To make it more attractive, it may
be a good idea to incentivise end-users to send such logs to you.
17. Invoke specific
type of help automatically
This is a very useful feature. If your application has a very complex
user interface or features, it makes sense to provide help upfront,
rather than wait for users to press F1. If you start the pivot table,
the Office Assistant pops up and offers help, remember? The next
usage (No. 18 from the original list) is a special case in this
category. In case of accessibility, you could provide visual, auditory
or tactile feedback to the user (based upon the user profile).
20. Provide quick
upgrade help
This is a particularly nice way of informing users about new features
when an upgrade or new version is introduced. How does this generally
get done? Two methods you must be familiar with are the ‘What’s
new?’ section of help and ‘Tip of the day’. The first
method is not very useful because all users might not read it; and,
the second is too randomised to be of any guaranteed use. What we
need is a way by which we can ensure that every user who has been
familiar with earlier versions of the product should now learn of
the new or improved functionality. What better way to do that than
in the click of a toolbar button or menu selection!
Here is how you could implement it.
- First ensure that your user profile
database (registry or custom) contains a flag for every new feature
for every user.
- When a user chooses a particular menu,
check in your database whether there is any upgrade help to be
shown. If yes, check if this has already been shown for current
user. If not, show it and set the flag (so that the next time
it would not be shown).
21. Third-party
validation of committed transaction
This is required in special circumstances, when validation can be
managed as a separate transaction after the original one has happened.
This could also be a type of workflow where submitted transactions
need manual authorisation by the next level of hierarchy, using
some appropriate user interface. Of course, we have been achieving
all this by separate, additional code. But the point is that if
you can manage to do all the work related to a business process
step as the time when it happens, you are eliminating costly and
cumbersome batch processing and plumbing. The need for EAI often
arises due to myopic original design and inter-application incompatibilities,
which are inherent to the platform. If we could plug these as near
to the point of the base transaction as possible during the design
stage itself, then we have actually eliminated further dirty and
complex work.
22. Show related
form
This is actually an extension of the business process automation
functionality. But the issue is that the form needs to be shown
to this user or some other user, depending upon circumstances and
roles.
23. Show related
report
This is not difficult from a technical point of view. But very often
we do not think of the need to do so. Consider a sales guy who has
just entered today’s new orders into the system in the evening,
sitting in a cyber café. What would he want to know next?
Difficult to guess? Not really. He would like to know his target
for the month and how much is pending. He would further like to
know, if he does achieve the target, how much incentive would he
get. Now, why not show this report to him upfront? Why wait for
him to wade through an arcane collection of hyperlinks? Understand
one thing. Entering data is boring to everyone. Why not give some
benefit to people who have just fed in information? Actually, it
would be a nice idea to create a set of tables which link users,
transactions and auto-display reports, so that there is no hard
coding and you can change the profile of automatic reporting by
simply changing the mapping.
24. Conditional
UI management
Very often, you need to show additional menus or disable existing
menus or toolbar items depending upon various circumstances. This
is best done in the menu handler. This is something which is done
to some extent by most application designers. But the issue is whether
it should be structured or ad-hoc? Here is a good way: The menu
handler should receive some return value from the executed form
and execute another function that handles the User Interface changes.
If you don’t put some structure in UI management, a lot of
hard coding happens over a period of time and then it becomes unmanageable.
This is very important in managing packaged products as well as
complex LOB Web applications.
25, 26 and 27
Handle detected abnormalities
Whenever some abnormality is detected in the execution of last menu
option, we need to take action. The abnormality was obviously not
a fatal error. Otherwise, it would have been handled anyway. It
could be some wrong data committed, which may destabilise the session;
it could be spam detected; it could be a user session which is suspect
for some reason. There are two parts to this functionality—detecting
abnormality and actions based upon the severity. Both these are
to be decided based upon your business needs. But remember to think
about it, and if found relevant, implement it.
What has been
learned from this series?
This has been quite a long series. But let us consolidate the learnings.
Some of the key learning points are:
- User-level features are created by understanding
needs and thinking simply rather than by using high technology.
- A simple set of user actions can lead
to and can be enhanced by various apparently unrelated technologies.
- Applications should be developed to
solve business needs. But while doing so, the designer should
look at additional opportunities of value addition. Myopic application
(and data) design is the biggest problem we have today.
- Users do not necessarily interact with
your application the way you had thought they would. Application
design requires tolerance, patience, user pampering and proactive
expectation management.
- Nobody uses business applications willingly—till
they can see some value which benefits them personally. Application
designers, therefore, should not just concentrate on organisational
value. Remember the users also!!
I hope this series has been useful to all
readers. Your feedback is welcome. But in addition to the feedback
and suggestions, I would be glad if you try to use the ideas and
concepts highlighted in your day-to-day work and let me know the
results.
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 |
|
