Forum OpenACS Development: infobutton package

Posted by Stan Kaufman on
One of the interesting sessions at the recent American Medical Informatics Association meetings was about "infobuttons". This seems like a functionality that would have general value for the OpenACS toolkit. (I have a vague recollection that there may have been discussion about something similar to this in the past, but I can't find it now.)

Here's the basic idea: attached to various items in a page of information are small buttons (consisting graphically of an image like this). When clicked, these buttons bring up a window with context-appropriate information. For instance, in a patient record containing a serum potassium level, an infobutton by the level might bring up a page of links -- to a discussion of causes of high and low potassium levels from an external online reference, a Medline search of medical literature, a list of relevant medications from pharmacy records, etc etc.

The resources which an infobutton links to an information item in a page thus include (among probably other things):

  • links to internal pages/images/etc in the site
  • links to external site pages/images/etc
  • search queries within the site
  • search queries to external sites
  • calculations
  • agents

The challenge obviously is maintaining these mappings between informational "about items" and the various resources. Currently this is a labor-intensive process. For example, when an EpicCare medical record links to Micromedex reference data, the search params are arbitrarily constructed per Micromedex's apis and can't be easily reused for a different reference vendor. HL7 standards for messaging will help regularize the syntax of such calls, but the management of the links themselves remains complex.

I think the broad strokes of a solution would include the following:

  • An "infobutton-aware" package would specify which of its object types it wants to provide infobuttons, include the buttons with each "about_item" of these object types, and register these object types with the infobutton package.

  • The "infobutton package" would supply an abstraction for all resources it can map to client "about_items" plus an "infobutton manager" that would handle configuration tasks (registering new resources, handling popup window size/location preferences, etc) and realtime use tasks (taking the object_id of the "about_item" plus any other "context" ie key-value pairs sent with it, if any, to generate the links and display them in the popup window; tracking infobutton use -- ie which one was clicked, when, and by whom; etc).

  • Beyond these basic functions, the infobutton package could append a more general Google search to the links provided so that users who aren't satisfied with the provided information can hunt on their own. The package could store a record of infobutton use -- simply for admin users to review, or for a "receipt" for users -- such that they could get education credits for using the infobutton, or even cash payments. This could be coupled to a short quiz, even, at the end of the infobutton page.

At this point, I haven't thought through any implementation details, but the new callback system seems ideal for this application. And the basic functionality seems like it would be useful generically, much as is categorization, with which this has a number of semantic similarities. Does this sound like something worth adding to the toolkit?

2: Re: infobutton package (response to 1)
Posted by Patrick Giagnocavo on
It sounds like a combination of the glossary package (expanded to include URLs) plus some insertion into the posted content when content is first entered into the system, to wrap infobutton URLs around text that is recognized.

There are some JavaScript packages that do this as well, I think, but I doubt they pull much information from a database.

You would need to distinguish between unambiguous words/phrases and ones that could be ambiguous. For instance the word "psoriasis" only has one meaning and should probably be linked to the same set of info regardless of the page it is found on.

However, "twins" might refer to identical or fraternal twin children, or could be used as a figure of speech. You would want to have some method of determining when it would be appropriate to link to the "twins" URL.

3: Re: infobutton package (response to 1)
Posted by Torben Brosten on
Interesting. Could this be a mix of the categories package and some cataloging package to browse through "objects" in each category?

I'm working on a catalog package[1] (key: online-catalog) that might be similar in function:

"Catalog package provides the browsing part of a traditional ecommerce service. Emphasis on presentation and search engine optimization. Shopping basket functions are separate. Includes ability to choose item(s) using a specifications configurator."

Essentially one can browse a category tree, viewing items in each category. The ecommerce stuff would just be an "infobutton" to the shopping basket functionality (which will be in a package called accounts-recievables). The infobutton could just as easly link to something else...


4: Re: infobutton package (response to 1)
Posted by Malte Sussdorff on
Torben, while you are doing this, can you make sure that the catalog package would become the display part of categories?

But not only categories, all types of relationships that have links in between them (e.g. a different view for relationships in contacts, a different view for the parent_id relationship in the content repository, a different view for the .LRN course system)

Patrick, in what way would this infobutton package be a combination of glossary? We looked at glossary some time ago before we wrote the glossar package and realized it was fairly limited in it's use.

5: Re: infobutton package (response to 1)
Posted by Torben Brosten on
Yes. The current ecommerce package features custom templates for viewing various items.

I forsee this package using available category sets, and custom templating to permit import of most any text or html fragment.

Would be nice to use Dave's proposal for "adding support for URLs without query variables to the request processor"[1] with this, for those who want the content to be indexed well with search engines.