michael favia

Content Overlay

I traditionally find content overlays extremely useful for simple content operations and modal dialogs. For instance I patched and advocated an issue that would promote the delete operation on a node to a Menu Local Task like Edit and View currently are. This is in line with my views on implementing actions as decorators on the objects they perform their work on.

The proper use of a content overlay in this situation would be as a confirmation dialog for the delete operation. This would save us a page load and still provide the users protection against unintentional data loss. Another valid use of this system is the on the fly creation of a taxonomy term for a node that is being created, terms are simple concepts and their creation as an interruption of the node creation process makes sense because it inhibits the nodes creation (which is after all the real purpose of a modal overlay).

A misuse of this content overlay system would be in the creating of a complex piece of content like a node. Take a quick look at most REAL sites and you'll see that the node edit form can get to be rather large and complicated. Trying to stuff all of this content into a content overlay will surely result in having to scroll (even with the new vertical tabs in d7). If you want to see a deer in headlights give a user a content overlay that requires scrolling to see the submit button or the rest of the form. You might be there for hours if you don't break the spell on the poor subject.

I see the problems you are attempting to solve by introducing content overlays for node creation as two fold: the first is that you perceive the creation of content as too disjunctive form the normal sites flow (i.e. you create it, where does it go/live, and where should you go when you're done). The second is that I think you perceive the task of content creation as overly arduous and complicated. Reducing it to a content overlay would certainly provide the push to fix this issue. Let me start by saying that i think both concerns are valid but that i think the solution is suboptimal and might introduce more problems than it solves.

I'm a fan of making easy things easy and hard things harder. Applying that to this scenario might lead to an additional "Settings" tab (aka Menu Local Task) to accompany View, Edit, and (Delete)[http://drupal.org/node/196758]. This section would contain all of the "default settings" we've defined in the content type administration section. It could include comment (disable, enable), workflow (published, unpublished, promoted), and authoring information. It would also provide a place for contrib modules that operate in this same fashion to override their settings. For example pathauto module could be set on the content type with a pattern and the path could be overridden on a particular node in the settings tab with the user never having to know what generated the default path, only that if they want to change it they can do it there. We could reuse the forms and most of the validation logic for such a setup because it is a perfect mirror of itself.

We should be able to assume that the "defaults" we set in content type administration decently fit the usage scenario of the content type in question and not have to provide places for this to be changed during the simple act of creation or editing the actual content. This further reinforces the value of separating these actions from the node form (aka "add/edit).

Header

I traditionally favor decorating objects (nodes, comments, users, categories) with the actions that you can perform on them (view, edit, delete, categorize, etc). To that end using the header as a decorator on the whole site works very well as a natural relationship for me.

Where the header concept seems like a really good idea for items that don't usually belong to something but instead belong to the site. These tend to include "1 off items" like account, status, creating content, search and shortcuts to administrative sections (content type admin, site info, user admin, etc) and help.

Where this analogy fails is when it attempts to extend that relationship to specific items on the site or page in question. Using the header to create a distance between the item being operated on and the action being performed on it seems detrimental to the process of getting the user to understand the relationship dictated above. I would favor the approach of decorating the actual content itself with that operation along with the other you might wish to privilege the user to perform (track, delete, etc).

Furthermore, while I understand the reasons behind wanting to hide what could amount to a cluttered list of actions on each content item (e.g. node, block). The concept of an "activation edit" button, assumes a false dichotomy between the normal use of a page and the interaction with its content. Because so many diverse sites are created with drupal we cant always predict how the functionality we write might be deployed on a particular implementation.

As a simple example "Developer A" might deploy the five star rating system on the site of a movie reviewer and "Developer B" might deploy it on a Yelp or Netflix style site that solicits normal users for input. In the first case the voting action is clearly administrative and would occur while creating the content but in the second case the user would interact with the widget in a much more casual fashion. This is just the simple example I could come up with on the fly. I'm sure talented others could extend it across other modules and actions for you if you'd like.

Instead of implementing a page wide "edit mode" thats enforces this dichotomy perhaps a more content item specific hover effect similar to the way "Views2" embeds administrative function links above displayed views could be adopted. This would unclutter the base interface while providing context sensitive actions that the present user has privileges to perform. For the example above "User A" might be able to rate a movie or a business by clicking on the widget, and "Administrative user B" might be able to clink on a link to the itemized result list.

Inline Editing

I LOVE inline editing. It appeals to every inclination of every person ive ever watched use drupal. Editing content where it lives is a great and noble idea. Unfortunately a lot of the power of drupal also lies in a developers ability to hook into various stages of the contents rendering and modify it before it is output for display. Teasers and computed fields are wonderful examples of "content you cant edit" because it isn't content but is the aggregate of user input from multiple places mixed with the context of display. This makes it VERY difficult to "edit this content" in any meaningful way.

I could imagine using multiple callbacks to discover how the field is computed and provide the necessary forms and items for the user to manipulate the field but this might significantly hamper possibilities with out current infrastructure that are key to drupals value proposition (it would also greatly complicate the modules that had to implement them). We could disable such fields but then we introduce inconsistencies in the UI that mean less predictable interfaces for relatively little gain on the simple fields that do allow it. There are much better people to approach about the complexities and possibilities of edit in place as it isnt a new desire by any stretch of the imagination but i think it si a complicated one that might be better (or at least more easily) served by simply providing more contextual "edit actions" on content as it is displayed throughout the site.