Forum OpenACS Development: infobutton package
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
- 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.
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:
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?
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.
I'm working on a catalog package (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...
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.
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" with this, for those who want the content to be indexed well with search engines.