ShowMe API for generic alternate link presentations (such as Lightbox, Thickbox)
A recent issue posting (here) prompted us to reconsider the way I are using Lightbox2 and other such "pop-up" or alternative presentation modules.
The problems, as I see it:
- The proliferation of modules such as Lightbox, thickbox, greybox, etc. is confusing, and it's not easy to choose. They have features which "hook" into many other modules, have significant interdependencies, and often are doing tasks suited to the original module (pop up login boxes, contact forms, fields whose links behave differently).
- There is no way for fields to publish their suitability for use in such pop-up contexts. Therefore, emfield must know about Lightbox2 and Lightbox2 must know about emfield. If you want to use a different video type with Lightbox2, you're out of luck and need to implement your own (or hack Lightbox to support your field).
- There is an endless list of desired behaviors which can be triggered when links are clicked that can never be satisfied by integrated "all in one" modules and it is not reasonable for every field implementer to be responsible for all possible ways that field data may want to be viewed.
As a result, I implemented a prototype called the "Show Me API" which has the following features:
- Allow any number of plug-in presentations for field data. Such presentations are triggered when links are clicked, and are not limited to visual representations. So, presentations like Lightbox, Thickbox, or even audio players like iTunes can be developed as separate modules without any relationship to the fields where their data originates.
- Allow any number of data providers (such as field implementations) to publish methods whereby their source links (which appear on pages) and target data for display (video, audio, graphics, html).
- Very clean separation between modules which provide data, and those which display it, essentially creating a more versatile layer which can completely replace field formatters (if desired) in any field implementation, and inherit significantly more functionality while consuming fewer lines of code.
- Implemented so that code is loaded only when needed by a page. So, there is almost no overhead in having many extension modules if they are not actually used on pages.
- Lean, robust API built in a manner similar to views.
Included in the prototype package are the following modules, each designed mostly to demonstrate a feature of the API:
- ShowMe API - provides the basic framework. Required. The rest are optional modules.
- ShowMe Lytebox Presentation - uses Lytebox (a Lightbox2 derivative) to display graphics or html content.
- ShowMe Browser Window - provides an extremely simple "targetted browser" window as an alternative to Lytebox.
- ShowMe Link - provides support for "link" types so that pages can be displayed using any available presentation module.
- ShowMe Image - provides support for images in imagefield or filefield fields, and automatically creates formatters so that link and presentation presets can be chosen.
- ShowMe Text - provides basic text fields as data sources (this truly is useful only as an example).
We have also added a ShowMe provider interface to our internal video modules. We have our own player and video server API so these modules are not useful outside of our system. However, it was enough to prove to me that the API is robust enough to handle video easily.
Installation is simple. Enable the modules, and you should instantly find new field display options present for existing fields. There are no settings whatsoever. However, during implementation it was obvious that some of the sub-modules could benefit from some customization settings, but none of that was needed to create a demonstration. Also, there is no consideration for "user login" or "contact form" providers, though those could be implemented as well after considering how such "link scraping" additions should best be done in a generic fashion.
Of course this code is free for anybody to do anything they want with, or nothing at all. It is a prototype, really just for discussion or experimentation. Though I have tested it thoroughly, it has only been used in a limited environment and of course there are bugs. But, I believe it works well enough for demonstration purposes. My environment:
- Drupal 6.14
- Firefox
Some of this has been based upon various bits of code and the good examples of how to do things set in the Thickbox, Lightbox2, and jQuery Lightbox modules, but it is mostly new code.
Note that I have never contributed any Drupal code, but am testing the water to see if this makes sense. So, I expect that there are coding standards gaffes and I am certain there are things which could have been done much better if I were more familiar with the Drupal core APIs.
Let me know if it is a useful demonstration of the concept and whether there are any such efforts underway that duplicate this effort.
The working code is available in the issue posting on drupal.org: http://drupal.org/node/582334


But if you make these
But if you make these annoying modal box things easier to use, people might actually use them more often…
In all seriousness, use of Thickbox et al is (thankfully) more rare than, say, WYSIWYG editors, so I'm not sure if an API for them will have the same sort of impact as the WYSIWYG one. And there also tends to be a "jack of all trades, master of none" issue with these sorts of things, which makes it difficult to take advantage of the unique features of one of the tools if you're using it through the API (the main reason I'm sticking to the standard FCKeditor module instead of using the WYSIWYG module for the clients who insist on such atrocities on their sites).
But don't let me stop you. If you have working code, commit it. The worst that can happen is that your code will be ignored.
I probably will apply for CVS
I probably will apply for CVS access to get this one in there.
Many of your comments were my motivation for actually writing the set of APIs and modules to begin with. We have a new video site coming up, and while normally some of these thickbox-style pop-ups can be annoying, it truly benefits a video site where there are 12 or so videos on a page and you don't want users to navigate to the node page just to "sample" the content.
So, some of the design goals for me were to:
* Keep it simple so it's easy to use.
* Don't try to anticipate every whiz-bang feature but make it possible for presentation designers to extend a presentation module to be as complex as they want (hopefully eliminating the "least common denominator" problem with many APIs).
* Make it so easy to add new presentations that people can add their own without understanding how the whole "framework" works.
Any ideas are surely useful, and this has been working great for us during development. Hopefully you'll see the module at some point soon.
-G
Australian Scuba Diver? Visit http://scubalot.com
Many of your comments were my
I understand that. I was being a bit overdramatic with my post. But I think they're overused sometimes, and there's one particular type of these modals which infuriates me. It's the one where you click on an image and the modal comes up with a spinny "loading" thing. Then when it's done loading, the modal slowly stretches vertically to fit the image, then slowly stretches horizontally, then the image finally slowly fades in. Okay, so now I want to see the next image, so I click "next," and I see the spinny thing again, and then the modal stretches slowly again and the image slowly fades in again. There's like two full seconds of visual wankery -- excuse me, "eye candy" -- between each image. Just show me the damn image! It's like those damned DVDs that make you sit through like a full minute of unskippable clips of the movie you're about to watch before it'll even show you the main menu so you can select the "play" option, and then it shows you a few more before it actually starts the movie. Spy Game, you run-of-the-mill espionage action/drama with Brad Pitt and Robert Redford, I'm looking at you.
Anyway… sorry. Personal crusade. As long as you're using Thickbox or one of the others which just shows the content immediately without stupid unnecessary animation, I think we can get along.
Well, the point of the API is
Well, the point of the API is that the choice of litebox/thickbox, etc is a choice that you can make more easily. For example, I loved all the features of the Litebox2 module as far as how it integrates with Drupal.... except I wished it were using some other pop-up technology than Lightbox2 itself! So, I think the idea of tightly integrating a complex javascript display technology with Drupal features is a bad idea. Rather, the Drupal display "hooks" should be generic, and the pop-up technology should be the easy thing to swap in or out.
Australian Scuba Diver? Visit http://scubalot.com