DRAIP - an old idea renewed

Ambrose's picture

DRAIP: Drupal Remote Administration Interface Protocol

"Pay no attention to that man behind the curtain, err drape, err draip!"
--- with appologies to L. Frank Baum :)

About 20 years ago when the PC world was mostly DOS and the internet was mostly text there was a cry for better online user interfaces. Programmers began to develop graphic front end "RIP" clients that could grab the text menus of BBS systems and restructure them into more attractive and more manageable layouts. The RIP screens could look nothing like the original menus and yet provided all of the required functionality and more. RIP clients proliferated and that early concept eventually led to what we know today as Mosaic.

Today Drupal faces the same dilema, a cludgy administrative interface that desparately needs a cosmetic and functional facelift. Fortunately we also have the modern day equivalient of RIP clients, RIA clients based on such tools as Flex and Ajax. I propose that rather than trying to wholescale rewrite Drupal and all the various Modules, instead we create a new "RIP", a protocol and an RIA that is smart enough to interface with the "raw" Drupal menus and yet modular enough to allow various people to create, juggle and reprogram how it looks and reacts with the admin-user. Various simple hooks would be added to the existing Drupal/Module codebases to minimize the communication signals between them and the RIA client. Menu databases could be built to simplify navigation across large lists of items like nodes/pages/users/etc.

If this is done right, the Drupal admin world will self-evolve new "useful" interface designs. Frankly, we do not know what Drupal will look like in the future, we do not know what twists and turns will be created by new killer modules. Any attempt to statically improve the interface is doomed to dead-ends and constant revisions. Any attempt to say "my menu design is the best" will certainly lead to disputes and unhappiness in the community.

So instead of futility and dispute, let's create a universal and adaptable interface to the menu system and leave the menu code pretty much alone.

One of the early pioneers in GUI was Robert Trifts who said this about RIP:

"In 1991, RIP was the first attempt to add standard graphics and low res .gif GUI interfaces to the BBS. RIP was important as it was designed not to be BBS software, but to be a means of displaying output from ANY BBS software that could be interpreted and graphically decoded by any communication software on the user's end that supported RIP. RIP, like ANSI, was designed to be independent of the BBS software that ran it."

That is what we need, a stable protocol for interfacing with Drupal menus, and one or more standalone Admin GUI clients to use that protocol independent of the various Drupal configurations.

Here is a whitepaper on RIP for those of you who missed that era of software evolution:
--> http://www.bbsdocumentary.com/library/PROGRAMS/GRAPHICS/RIPSCRIPT/whitep...


An API for controlling

Shannon Lucas's picture

An API for controlling Drupal would definitely be useful as screen scraping is somewhat fragile. On top of that one could layer a remoting API to more easily accommodate interfaces built in Flash/Flex/AIR, Silverlight, or even something heavier like a Swing app.

You could implement this as an add-on module.

This probably isn't the best group for this discussion since the module is much more of a back-end concept at this point. I'm actually not sure where this best fits; there is a web-scraping group, but this idea is a bit different.

Perhaps creating a group to discuss it?

Not so much an API as you think

Ambrose's picture

The basic idea is to create three things:

1) A data transfer protocol. I envision something like an XML scheme where each web page contains hidden/embedded information about what menu choices and data formats are available. This protocol would guide developers how to define the interface data schemes and command structures used in their code.

2) A GUI client which can parse the information and send commands based on the DRAIP protocol. This client would have the ability to function as a "smart terminal" sending requests for additional information and commands to modify settings and data.

3) A special routine that can be added to the interface of Core and Module code to receive DRAIP enabled commands from the client and pass them thru to the code for response. This would make such code "DRAIP Enabled (DXE)". Because modules internal structure can vary greatly I believe it would be best if this was actually included into the module as adaptable source rather than implemented as a fixed API. It would be the responsibility of the developer to make sure the DRAIP code was correctly interfacing with the modules structure.

Using this approach it should be possible to set up a series of automated data requests which would be executed after signing into an administrator's account. First the DRAIP client would request a list of all installed Modules (and Core functions), then poll each module to determine its DXE status (+/-). Finally for those modules that are DXE+ the client would request basic command structure (menu options, current settings, etc). In a matter of some very few seconds the DRAIP client would be able to display a master menu of all possible commands without ever going past the post-login welcome screen.

If this is done right, the

illuminaut's picture

If this is done right, the Drupal admin world will self-evolve new "useful" interface designs.

I would argue with that. While abstraction layers are generally a good idea, their existence alone doesn't lead to improved usability. And usable (if I may interpret your "useful" that way) interfaces certainly don't self-evolve. Take a look at CSS for example: it's a humongous success on several levels, but it doesn't magically make the interfaces you create with it more usable. Once the "various people create, juggle and reprogram how it looks and reacts with the admin-user" you're back at square one, because in the end the people who do this juggling need to understand what makes an interface usable.

Mind you, it's still better than defining the look and feel at the system level where only programmers would be responsible for it, but Drupal is already way more flexible than that.

Software Design Self-Evolution

Ambrose's picture

I respect your comments but I disagree. Yes, the useful/usable interpretation is correct but this is not about "magically making the interfaces more usable". It is about giving admin-users a wide set of choices over time, and then seeing which choices generate the most favorable responses.

If the GUI/DRAIP client interface is adaptable to admin-user redesign and these designs are distributed much the same way as Themes are, those designs that become most popular should reasonably be presumed to represent the most desireable and useful administrative interfaces. This is not a beauty contest like Themes, but rather a usability contest driven by admin ease-of-use appreciation.

Eventually common threads of design will rise to the top and become the "recommended" or "preferred" way to set up the interface for various Drupal Modules. In essence this is a form of "survival of the fittest" (evolutionary) design. While not true "natural selection" (after all none of the "species" actually becomes extinct, just unused) the effect is that those DRAIP design sets which feel best to the majority of admins will rise to the top of the food chain.

At some point it then becomes possible to identify the various "most popular" DRAIP design Elements and create a "default interface" for the Core admin screens which reflects these Elements.


eigentor's picture

While in itself it is not a bad idea to provide a "playing area" for admin users, it is not quite clear to me how you want to do this - use Flash and things?

I agree with illuminaut that this is rather adding another layer instead of tackling the problem. If Admin users want to play and provide ideas - how about doing Mockups or whatever.

If you can provide a starting point, your ideas might get clearer. Maybe there is a thing like the one you talk about? Show us.
For there are reeeaaly impressive interfaces out there with fresh ideas.

At the moment the entire thing sounds too abstract for me to get the point of it.

Life is a process

Life is a journey, not a destination

Abstract, de-abstracted...

Ambrose's picture

eigentor: I am going to see if I can helpfully address your comments and then try to demystify this idea so my appologies in advance for a long post.

ABSTRACT: I would agree I have presented an abstract idea. It is however based on an operational and proven idea known as RIP (Remote Interface Protocol) which I provided a link to a detailed whitepaper on above. Back in the days of telephone based BBS's and low-res VGA monitors this was a cutting edge interface that allowed graphical local displays in place of text only ones.

EXAMPLE: While not the exact technology I am describing here, one well known example of this concept is the AOL client software. This was a direct descendant of the RIP idea, just written as proprietary code. It was bloated but what it did was allow millions of non-techsaavy users to join the (then) mostly text based internet with a slick graphic interface. The design was periodically updated from a central distribution with little control by the user. What I am proposing is similar, only (a) open source, (b) not bloated, and (c) allows user level design changes.

FLASH: I am suggesting we take this old idea and update it using Flex which is ideally suited for this kind of work. Others might prefer to use Ajax or something else but I think Flex would be the best tool because of it's close relationship with Flash, arguably the most universally available web graphics engine available today (500+million installations I believe). Note that I am NOT a Flex programmer, but I have been looking for the right project to justify the time learning it and I think DRAIP could be it. I will appeal to anyone here who has worked with Flex and RIA (Rich Internet Application) development for a more informed view... Is there a better tool?

MOCKUPS: Mockups are nice, but they do not prove usability. Anyone can mockup a design of a cool looking menu system, but if that menu system is cumbersome and requires too many click to get something done it will not be desirable no matter how cool it looks. As I said in another reply on this thread... "This is not a beauty contest like Themes, but rather a usability contest driven by admin ease-of-use appreciation."

REEEAALY IMPRESSIVE INTERFACES: Yes, there are. Personally I like the whole concept-map interface idea (see www.thebrain.com) and with DRAIP it might be possible to create a drill-down sitemap interface of similar appearance. For me that would be cool, but I have a coworker who hates concept-maps. DRAIP would allow us both to administrate the same website in whatever way we wanted.

ANOTHER LAYER: Yes, it is. But that is the beauty of it, because it is optional. Admins could if they so choose use the default HTML/PHP menu system. But the DRAIP client would always be available for those who want to push the limits and experiment/use different designs. This is no different that THEMES. A webmaster could elect to never use THEMES and just go with whatever look comes out of the box. Yet we do use THEMES because the default look is just not cutting it for us. THEMES has practically become a subculture of the DRUPAL community and I expect DRAIP will likewise, because it is both user adaptive and optional.


Having said all this let me see if I can explain the idea in bare-bones simple terms:

DRUPAL has a set of admin menus which we currently see as a series of links on the admin page thru HTML/PHP. The design is fairly static, driven by a simple display schema.

A screen-scraper program could copy these links and then redisplay them in a popup window that could look pretty but basically would have the same functionality of the HTML/PHP page. A more advanced program might keep a collection of these links locally and keep the popup window always available even when not on the admin page.

The problem with the screen-scraper approach is it is slow and prone to breakage if the page layout changes too much, and since DRUPAL is all about flexibility in design that is highly probable.

Another problem is that each added module would need to be explained to the program so that it could correctly gather the menu options that are added to the admin page.

The solution is to have the same code that generates the visible (HTML) menus also generate a set of carefully defined invisible (XML) menu definitions without concern for where they end up on the screen. Note that this is already somewhat in play in a different form with the module menu definitions to the admin pages.

Now an RIA built on Flex can easily read the XML and display the menus in whatever layout the user desires.

Going a few steps further imagine the following: DRAIP gathers an XML version of all the data in the ..\admin\build\sitedoc page. However the XML data contains a bit more information than just the values of each item. This information is then displayed in the RIA client but rather than being just static data, each item is dynamically linked to the exact place where it can be edited or modified. What was previously just an informational display now becomes a full portal to modifying practically everything on the website with one click!

Doing a global text change might also be super easy with such an interface, as an RIA client could certainly have the ability to do basic macros/scripting.

The possibilities are virtually endless because an interface protocol allows the client to talk to the DRUPAL engine in complex ways, yet always respects the existing code and most important it never needs to "write directly to the database".

My own selfish reason is for

Shannon Lucas's picture

My own selfish reason is for liking this idea is that it would ensure that everything doable through the UI can be done by calling a function. Sometimes when writing a test, I'd rather not have to go through the form submit or directly to the database.

So it's basically like REST

illuminaut's picture

There are already APIs for RESTifying content. If you extend that to the admin interface you can achieve many of these goals quite easily. The absolutely coolest part of doing that is that this would allow for remote-administration of several drupal installations in one interface. Yummie.