I wish to consider the potential of end-user tools as a next step in the evolution of personalization. What if end users could use their own personal specialized tools to perform tasks anytime, anywhere? What if I had a better bookmark tool than the one embedded in my Web browser? I suspect I would prefer to use my standalone bookmark tool with the browser.
Let's consider another situation. We often use tools embedded in the various content obtained from services on the Internet. For example, a given Web page may contain a calculator tool to compute mortgage rates, but once again, what if I have a better software mortgage calculator tool? I would prefer to use my personal calculator in real time with the Web service instead of the embedded tool provided by the service.
Let me catch myself here, I wish to point out that this focus of end-user tools is not restricted to Web-based services. As a matter of fact, why can't I have a universal bookmark tool that works with my unified messaging service, with my screen-me reach-me service, with my cell phone during actual conversations, with my cable entertainment service, and a range of other services and activities? Right now you might be asking, what is a universal bookmark? Well, that's the vision and research.1 The main idea here is about empowering real end users with their own tools to do what they want or need to do the way they would like to do it!
End users enabled to perform a task with their own personal tool that allows them to perform a task in the manner they wish to achieve a specific desired result might surely exemplify a very personalized opportunity. In the near future, end users will perform tasks with their own software tools. A number of these tools will not be embedded within a given application, operating system, or service, but instead will exist as personal, individual software tools.
When purchasing a tool such as a calculator, pen, telephone, hammer, or any other type of tool, an individual typically selects a specific instance of a tool best suited for the task to be performed and that is also best for that individual. We have options in the types of pens, hammers, and other tools we select and use. With our computers, we have configurable tools designed by engineers to be embedded within a service, application, or operating system. But, are such configurable options extensive, useful, and usable by the diversity of end users?
Plans for future releases of major browsers are now defining new unbundled tools to complement the browser rather than embedding more tools in the browser; watch for future marketing blurbs from your favorite browser company.
What if an end user likes a certain software tool, but it is restricted to use within a specific context and the user would like to use this tool with a different service or application? Users should be able to select the tools they prefer and be able to use them anywhere at any time.
Recall the last meeting you attended. In the conference room, each individual came to the meeting bringing their own specific types of tools reflecting their personal style of working. Such a situation might have different individuals using laptop computers or handheld computers or pen and paper.
This is the opportunity: my tools anytime, anywhere.
Have we lost the focus for this opportunity? In earlier systems, such as the Xerox Star and the NeXT Machine, the user work environment allowed users to construct tool trays, some of which were context sensitive to current user tasks. The evolution of this earlier work has taken a turn reflecting companies capturing customers in closed applications and services for the almighty market share in revenue from software products and services.
The pipe in the Unix shell was a significant contribution. The pipe enabled Unix users to build composite tools out of simpler tools. In the context of the Unix work environment, users could build personal tools to perform tasks in the Unix environment. While the Unix pipe and shell scripting enabled individuals to quickly craft personal tools, this opportunity was never effectively embraced by end users partially due to the fact that crafting of tools required certain programming awareness and skills. Nonetheless, technical individuals did develop various personal tools for members of their organizations.
As networking has extended environments like Unix to include an enormous number of information sources, networked working environments, and transaction systems, the fundamental ideas of personal end-user tools and the building of end-user tools by end users are an important challenge and opportunity. David Smith, since his early work on Xerox Star, has often stated that end-user programming is the interface (see Smith's article in this section). End users empowered with personal tools they've crafted themselves is an important next step. An individual's own tool is a representation of that user's desire to perform a task and satisfy a goal in a specific individualized manner. This is a key element in the realization of personalization in future services and products.
Evolving open standards with their APIs are extending access and interworking between software applications and services. As open systems evolve, personal tools will be able to interwork with other tools and services more effectively. Individuals will be able to use personal tools for various tasks in conjunction with tools and functions embedded in a service or product.
Plans for future releases of major browsers are now defining new unbundled tools to complement the browser rather than embedding more tools in the browser; watch for future marketing blurbs from your favorite browser company. The legacy of OS system calls and operation codes (opcodes) that represent drawing and input events in the X Windows protocol or a Macintosh OS toolbox have become a historical part of software design and engineering. Today's systems are designed with APIs providing rich methods/opcodes to request specific functions to be performed in interprocess communication (IPC) and remote procedure call (RPC) models.
There are now two important design elements for interworking tools with other services and their respective tools: function and content. APIs now provide an engineering approach for distinct systems to interwork and enable independent systems to perform functions for each other. For example, a software tool can request the browser to perform via its API a legal function for the software tool.
XML is providing a symbolic technique for a software tool to act upon a given body of content. Traditionally, content could only be parsed and processed by a specific targeted application or service. Knowing both the format of a "file" and the semantics of the "fields and data structures" of specific data enabled an application to correctly process the data and present it as content/information to a user. XML and other declarative norms provide a formal technique for heterogeneous software applications to share, parse, and process each other's data and content.
APIs and declarative content provide new opportunities for distributed systems. To the end user, this means an opportunity to employ personal tools to explore, examine, and work with information provided by other tools, applications, and services. For example, a user can use a personal tool to request a browser to obtain content from an investment Web service, then with that tool, interwork with the browser to access the retrieved content. Next, the user can modify the content via the tool, and request the browser to submit the modified content back to the service. What the tool does with the original content, how it presents it to the user, what actions the user can legally perform, and what results from the user actions applied to the content can be a range of different cases.
Interworking personal tools will produce better individualized productive work environments. I recall seeing an interesting new tool I could use to examine large amounts of information from different perspectives quickly. It was called InfoZoom from humanIT (www.humanIT.com) based in Germany. For specific tasks, this tool would be an excellent front-end tool to drive my browser, much in the same way that many companies today use front-end OLAP tools with their data warehouses.
How often does a user go to perform a task on a computer only to realize the data or tool or other resource required to perform the task is on another computer. For example, a user could have different sets of browser bookmarks on a computer in the office versus a computer at home. An important issue to examine is the actual location where a user stores, accesses, and maintains his or her personal tools. Today, there are multiple options in defining such a location via improved portability of software programs and transcoding technologies (see Maglio and Barrett in this section) that address device dependencies.
A plausible solution might be to store personal tools in the network and to replicate to maintain identical personal tools on local computing devices for performance purposes or when access to the network is not possible. Tools with persistence and static information can be effectively stored and managed in the network. The clear advantage of this is simple: The network is always there and a majority of the time one can be connected to the network via a given device. Networked tools and their replicated local copies are always consistent in state and behavior no matter where you are because they are the same set of tools.
Personalized services must maintain a consistent look and feel across the different customer interfaces (Web sites, call centers, brick-and-mortar, and other types of voice services). If end-user tools become an integral way to deliver personalized services, then design considerations must be given to enable end-user tools to behave in a consistent manner for the different customer interfaces. Speech interfaces and Web sites must provide ways for users to plug-in their personal tools when performing a task.
If an end user's tools are available anytime from a managed network resource or service, then users can request a dynamic binding between their personal tool and a given service. The trick is to design an abstraction to perform the bind for the different customer interfaces by which a user is working with a service. Based on the customer interface, the user would request the use (dynamic binding) of a specific personal tool possibly via:
An objective for research and development is to study and design services that support multimodal use of end-user tools when designing personalization for services and products. The opportunity is to enable the use of personal tools in performing tasks and in some cases (or many cases) other tools like browsers and cell phones function only as tools to transport the information/content and the actions performed by end users.
Just like the great pianists who each use their own personal concert grand piano in performance, using one's own personal tools is a personal user experience.
©2000 ACM 0002-0782/00/0800 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.
No entries found