surfin' the information highway

learning through the tides of the information revolution... a smart take on e-information...

Tuesday, January 10, 2006

End-User Programming: Empowering the End-Client

Since the advent of the new technology and the increasing popularity of automation and quick solution, the advances in the computer industry which has been akin to addressing the inceasing demands of consumers have created ingenuis formulations and dicoveries that would keep man constantly on his feet to expect, every now and then, something new to put his hands on and explore. The bygone days of manual transactions of firms are now done automatically through the use of fast processing computers and/or over the internet that contributed to decreasing the original work load.

Globalization has been a catalyst for firms to adopt changes in their own organizational structures to address the change brought by the increasing interaction of individuals and entities throughout the world. The proper use of real-time information has what kept every firm competitive in their own businesses.

In this age of the information revolution, information can count much for a firm's success or demise. It is imperative, therefore, for every firm to take on actions that would make sure will benefit them. The kind of employees that a certain corporation hire definetely will affect on how a company fare in the business market, being the employees keys to the company's future.

The improvement of technology has help us manage our business dealings, data and our important, relevant information better than before but things should not end just as is. The empowerment of end-users by giving them the hand to fully explore and create programs on their own is the new trend that most companies are doing. Who know best on company dealings and its important undertakings but the employees themselves?

With computers, firms have managed data accordingly, creating their own relevant information which are vital for their aim to compete in the global market. Big companies the likes of Unilever and Nestle have adopted computer-based information systems to aid them in managing their company data and in creating timely, relevant and important information to use for their future decisions at their own advantage.

But together with the benefits these computer-based information systems give to companies are the hidden disadvantages that hinders every firm to make full use of the theory. Most people experience computers as "end-users" of packaged programs. Unfortunately the writers of these programs can't know the details of the job one is trying to do. Trying to meet the needs of diverse users, they bloat their programs with hundreds of features most people never use. Life (and programs) would be much simpler if each user could add the functions he or she wanted. This has been the reason why end-user programming has gained popularity and has become a trend for companies to adopt.

So what really is end-user programming? Not all programs are written by professional computer programmers. "End users" with the right tools automate laboratories and corporate data access, model fusion reactors and animate Web pages. This page covers the tools, techniques, and theory of people who exploit computer automation for their purposes without becoming professional programmers.

Providing this capability in a program is not trivial. The programs must be designed to to accept user-written components in appropriate places. There must be a way to store and manage them. Most important, since most users do not have the time or inclination to learn the tools and skills of a professional programmer, reasonable compromises are required. The expressiveness and generality of full-fledged programming languages are traded for usability by a variety of metaphors and tricks. Programming can be done much more easily within the metaphor -- a desktop with file cabinets and wastebaskets; a formula of spreadsheet locations or mathematical symbols; a sequence of GUI actions; a circuit diagram; an application-specific language -- than with conventional programming.

Because the appropriate metaphors, with their capabilities and limitations, differ widely depending on the users and their purposes, there is no one method of end-user programming. Instead there is a variety of techniques, such as Programming by Demonstration, visual programming, and many domain-specific languages and formalisms. Ideally there is a smooth progression from simple but limited metaphors, to more complex and powerful techniques as the user-programmer advances.1

But like any other technology, the promises of benefits it is to bring are also the costs the user may incur when adopting it. So what really are the costs and benefits when a firm adopts end-user programming. I have come across an article by Howie Goodell and here are the things he gives.

The Costs:

How hard is it to give users the ability to program in your system? That depends on how much programmability you plan to offer, and what methods you intend to use. Adding preferences merely requires a GUI and some dialogs enabling them to set parameters. However the degree of "programming" you achieve this way is limited. On the other hand, a thorough implementation of a scripting language may require:

  • an editor, preferably with at least syntactic assistance for the beginner,
  • an interpreter or compiler for your script language that links to application
    functions,
  • an executive, possibly multitasking, for scripts to execute in conjunction with your system,
  • error checking and debugging tools, and
  • documentation and version management tools.

Yet such a tool can let your users program a large and complex application themselves. You get what you pay for.

Other approaches, such as visual programming (e.g. the "G" language in National Instruments LabviewTM) or Programming by Demonstration PBD, may be better for your users. Each has its own costs. For example PBD has the smallest cognitive distance between programming and working, because they are the same: you are literally "programming in the user interface". Yet determining your intent in PBD may require sophisticated inferencing and has a chance of error.

If you decide to pay the price and add significant programmability to your system, there are additional costs to consider before you can start to enjoy the payoff.

  • Management and those currently responsible for the performance of your product will fear the loss of control to users. "They'll screw it up, and then we'll be blamed/have to clean up their mess." Deep-seated social divisions and long-standing organizational traditions may lie between the group that used to control the programming of your product, and the users who can now join in.
  • The initial impact on documentation, training, and customer support will be major. Your users may be slow to adopt the new tools, They probably aren't used to programming, and they certainly aren't used to the tools you are about to provide.
  • Some of the programs they produce will confuse them; others will do unintended and damaging things, and at least initially some will blame you.
  • Regardless of their field, a certain proportion of your users will discover a natural bent for programming. Expect them to push the limits of the support they are offered, and find their way to the programming group again and again with questions and requests. This interaction is gratifying and very useful, but can be time-consuming.
  • If your tool is really useful, some user programs will be copied and passed around by people unaware of their limitations and assumptions.
  • User programmers are even less prone than professionals to document their productions, and programming is only a sideline for them. When a prolific amateur moves on, she may leave quite a vacuum.
  • The next version of your program may have radically different features; hardware and operating system sands may shift under you, but your users will expect their programs to keep working.

The bottom line: adding significant user programmability has large and continuing costs that will shape your job as long as you support your system.

The Benefits:

If your users find the programming features you have added appropriate
and useful, the payback can be tremendous.

  • Users know their problems best. The solutions they create for themselves are rich with detailed features they wouldn't have time to specify or explain to a programmer. A good tool allows many small experiments and becomes part of a style of working (and system building) that is exploratory, iterative, and highly productive.
  • Freedom begets responsibility. Once users get used to having control over their system, they question themselves when there is a problem instead of reflexively blaming "software." An engineer supporting a user-programmable system told of the customer who demanded, "Stop babying me!" That was a first in his 2 decades of customer support.
  • In a system designed around user programmability, the system program can be orders of magnitude simpler and more reliable. Instead of maintaining megabytes of specials for their whole customer base, programmers are set free to build the general functions they are good at, while users create the specific features they care intensely about. Both are happy!
  • There is a critical mass of functionality before end-user programming becomes useful. However once it is reached, tools don't need to be fancy. Serious users will work around missing features and push your tools into applications you never dreamed of -- witness all the far-fetched applications people found for spreadsheets.
  • The closet hackers who pestered the system developers while they were learning later become a resource for other users; "Gurus" or "Gardeners" in the terminology of A Small Matter Of Programming.

The bottom line: appropriate user programmability can transform a system, multiplying the effectiveness of programmers and users alike. 2

__________
1 "What is End-User Programming?" by Howie Goodell http://www.cs.uml.edu/~hgoodell/EndUser/whatsEUP.htm As of 10 January 2006.
2 "The Costs and Benefits of End-User Programming" by Howie Goodell http://www.cs.uml.edu/~hgoodell/EndUser/cost-ben.htm As of 10 January 2006.

0 Comments:

Post a Comment

<< Home