People already in this issue queue have been really helpful in identifying some of these. Here's a canonical issue for keeping track of stuff we should research and consider bringing in:

Content authoring

- Panopoly: Distribution which includes tightly integrated + customized WYSIWYG editor + Panels/Panelizer/Panels Everywhere/Panels In-Place Editor/etc. out of the box.
- Aloha: Provides integration with Aloha Editor to support inline editing.
- Editable fields: Allows fields to be edited in place.
- Content Menu: Incorporates several improvements to menu management tools in Drupal, allowing content creation from the menu hierarchy. See video @ http://wunderkraut.com/en/blog/content-menu-module-%E2%80%93-menu-author...
- Draft: The Draft module provides the ability to create drafts of existing nodes as well as new nodes before you have saved them. D6 only; D7 patch at http://drupal.org/node/1120336#comment-5393522.

Site building

- Form Builder: Drag and drop interface for creating forms. Can see it in action with the 7.x version of Webform module.

Workflow

- Workbench, Workbench Moderation, Entity revision scheduling, Workflow, State Machine, Revisioning, Maestro are all projects in this general space. There is work going on to consolidate in http://groups.drupal.org/node/198188. Here's a write-up of what most of them do: http://groups.drupal.org/node/198223#comment-662173

Comments

Two more for content authoring:
Linkit - autocomplete field to add links into a WYSIWYG
Menu Order - drag and drop placement of content into menus on the node edit screen

Maybe also this two modules for better menu handling experience:

  • Menu Browser - Makes it easier for editors to place their content exactly where they want it inside their menus.
  • Hierarchical Select - This module defines the "hierarchical_select" form element, which is a greatly enhanced way for letting the user select items in a hierarchy.

module_filter: I install this on nearly ever site I touch. The modules page is almost unusable without it.

Views UI: Edit Basic Settings is a must for all of my sites.

This could be better as a groups.drupal.org page since that would allow me to at least give a +1 for module_filter.

That said here's my contribution:

  • menu_views: great for shoe-horning in a view to drive your menu. As a middle way to complete dynamic menus that are simple enough to not need a fully custom approach.
  • admin_menu: surpised there were 3 other comments without mentioning this. It's still useful in D7 despite the admin menu provided by default. A lot of devs still use this one.

  • Instant filter - I prefer this over module_filter
  • Fast toggl - for quickly un-publishing, promoting, etc. content from the "front-end"
  • Media - for the Media Browser widget for file and image fields, among many other benefits and struggles of the module

More on the site builder side than anything else: I'm liking Coffee, for its "oh man, where IS that in D7?" helpfulness.

Contextual Administration: I use this on practically every site I build. It's potential utility is limitless.

Eclipse

As part of the FBSS/Statuses project, I've spent a lot of time thinking about what mass user content authoring should look like (by which I mean content creation by site visitors, not site administrators/editors). Basically the goal is to lower the barrier to entry, i.e. make it as easy as possible for someone to create new content with no prior knowledge, as well as make the result a rewarding experience. To do that, a few things are important: emphasize minimum information overload by exposing as few fields and as little explanatory text as possible; avoid being intimidating, for example by reducing the overall size of textarea inputs or by using familiar terminology; be fast, e.g. with AJAX updating; make it obvious, e.g. by immediately showing the results of your actions and by not requiring users to read anything to know how to use it; and be effortless, for example by not having too many similar content types. What matters to the end user is the result, not the process; the process is a problem we want to remove to let the user focus on what they actually want to achieve and not worry about how it's done. Essentially, don't make me think, and don't make me afraid.

The long-term direction for Statuses will likely be a single unified content creation form. Some discussion here. The basic idea is that there is only one "create new content" form, and the content type is decided in the background based on what fields the user wants to fill out. This requires some sort of system to let users choose to dynamically add fields to the form they're filling out. So rather than predefine an Image content type and a Link content type, there is just "content" with an image field or a link field. You can imagine preconfiguring fields that the user can add to the create-content form by clicking an icon, in lieu of preconfiguring complete content types. For something more complicated you can imagine adding complete fieldsets.

I don't know if this would make sense in core -- probably not, since the focus seems to be on a better experience for a privileged set of users who presumably have more knowledge of the site and what it's for than passers-by. Just another content-creation perspective to think about.

For the node editing side certainly Field group to allow you to progressively reveal information if dealing with long forms.

http://drupal.org/project/field_group

While I applaud the UX efforts and agree that progressive revelation (for example) can be a great tool for improving the experience of 90th percentile users, most of the techniques available for that will fail accessibility tests (and indeed won't be accessible for visually-impaired users).

This is not simply a matter of excluding a percentage of the population: Here in the US, all federal and many state websites are required to comply with what's known as the "Section 508" guidelines. UX enhancements that rely on interactively hiding or revealing elements without fully reloading the page will not be in compliance with those guidelines. The situation is similar with the WCAG guidelines.

What that means is that if Drupal is redesigned to rely on that type of tactic, without a graceful degradation for the non-visual UX, Drupal will technically no longer be an option on the table for US and Canadian government websites, that I know of - probably also will have problems in the EU, not to mention progressive non-EU nations. (BTW, I'm aware that the current state is that the section 508 compliance is simply ignored. Sometimes you can't count on that. We have a New York State client who would very explicitly evaluate all aspects of the UX for section 508 compliance.)

So, in all these considerations, there needs to be some way of gracefully degrading to an accessible UX. Perhaps another response mode for a responsive design?

@Dave Reid, I'm partly biased but prefer iToggle over FastToggle, it allows toggling pretty much any boolean entity properties, integrates with Views and Field UI.

Re #12: Well, like I said, this exact approach probably wouldn't make sense for core, and Statuses has a narrower use case (the hypothetical setup I described will still probably be 508-compliant -- pre-loading fields, maybe alternate forms, but that's another story). Still, even if a unified content creation form isn't something that can meet all of core's needs, I hope my comment does help people think broadly about what a content authoring experience can be like, and who the authors might be. The point is more that what I think Statuses has to offer is minimum distraction between "I want to write something" and "I wrote something on the site," and there are aspects of that focus that core could adopt. More AJAX loading/saving, for example, or not requiring that required fields be filled out in order to click a delete/cancel button, or smaller textareas by default. Or better ways to hide rarely-used fields, like maybe Views-esque "create" / "create and edit" buttons where the second one reveals additional advanced fields that aren't visible on the initial form. Or hiding the entire set of vertical tabs in a collapsed fieldset. Or only revealing field description text when the field is in focus. I think a goal of this thread is just to consider a lot of ideas and see which ones might contribute useful paradigms rather than to focus on a specific implementation (though the point is well taken).

Outline Designer -- http://drupal.org/project/outline_designer -- basically adds ajax functionality to the tabledrag js in drupal core. Original outline designer only worked with books but 2.x branch provides a pluggable framework for use with anything. Menu being worked on as well as D7 upgrades of the whole thing. We don't install a site without it and would never recommend anyone use books without it.

I use the module called Fast Permissions Administration (http://drupal.org/project/fpa) to easily search for permissions on the permissions page. I also use Better Permissions module (http://drupal.org/project/better_perms) to easily collapse the permissions.

And last I use Admin Role module (http://drupal.org/project/adminrole) which automatically gives a specific role all rights after installing a module. But this is already implemented in core Drupal 7 now.

I would suggest considering Maestro as an alternative to the 'do-it-all' workbench model. I don't have a 1-1 comparison of the two but Maestro offers a very nice notifications system.
http://drupal.org/project/maestro
Also:
http://drupal.org/project/maestro_toolbar_notifications

http://drupal.org/project/caption_filter for captions. Likely near identical to the solution Wordpress uses because the project page explicitly references it (it was even used to simplify the porting of Wordpress sites to Drupal). Supports alignment. Integrates with lots of existing WYSIWYG things.

The Panopoly distribution uses this too.

(Extensively discussed in quicksketch's DrupalCon London talk: http://drupal.org/sandbox/quicksketch/1088256.)

http://drupal.org/project/imagefield_focus is another one, providing nice support for dynamic image effects.

http://drupal.org/project/ife or http://drupal.org/project/clientside_validation for inline form errors. We should evaluate them to figure out the differences.

http://drupal.org/project/ife or http://drupal.org/project/clientside_validation for inline form errors. We should evaluate them to figure out the differences.

Great stuff, folks. PLEASE do the work needed submit patches to Drupal 8 for much of this stuff. The Drupal 8 committers really want a lot of this stuff in core. We will review patches quickly!

Multiple Node Menu - Allows a node to be added to multiple menus from the node edit page

Content Lock - notifies user on leaving a node form with unsaved content, and prevents users from editing nodes concurrently.

Another one - DraggableViews

Allows 'in place editing' of table views row order/parentage already.

Somebody also had what I think is a great idea of using this for orgcharts, see http://drupal.org/node/548854#comment-5212836 - which I think would be brilliant UX for hierarchical user views.

I haven't compared Content Lock & Node Edit Protection, but the latter is probably simpler (former probably more powerful). Nothing's more frustrating than loosing your blog half way through editing it.

For that matter, might want to consider - http://drupal.org/project/autosave

I would discourage autosave in its current form going into core. A much better solution for that problem space is to use localStorage. The problem there is dynamic forms in form API, such as node forms, where you have to update a server-side data structure in parallel with a client-side structure. I don't know how to resolve that, which is why autosave still uses server-side post caches and form AHAH replacement, ugly as that is.

(Disclaimer: I'm the D7 autosave maintainer.)

Check out http://substance.io/ which is an in place publishing platform (you can create an account on there and try it out creating a document, or just watch the video). Very impressive!

As part of the platform it uses http://quasipartikel.at/proper/ another contenteditable non-iframe-based editor, which I like. It's fairly simple, but it does do nested lists. Pasted markup just gets stripped.

Edit: Oops wrong thread, I thought this was the competitor solution thread.

mgifford: in UX terms Content Lock is simple (all my editor colleagues seemed to understand it straight away), and it appears to contain the functionality provided by Node Edit Protection.

Thanks @Crell - hopefully someone else has solved the localStorage issue as that would be way nicer.

@pjcdawkins - Agreed that it has the same functionality. Might be some technical advantages of one over the other, but I can't really speak to it either. Mostly just another option for a feature which would be great to have in core.

LocalStorage is IE8+. Was that the minimum requirement for D8, or was it IE7? I can't remember, blasted old mind!!!

Drupal 8's minimum requirement is IE 8, with the caveat that we don't care that IE 8 lacks media query support so everything ends up single-column.

So LocalStorage is perfectly safe to use.

@#33 - LocalStorage sounds like the better solution then. You can do near real time saving of data with out hogging down a server with a bunch of AJAX calls. Actually a combination of the two. Use AJAX/server for anything that actually alters the form, as to prevent FAPI validation errors, and LocalStorage for field values.

Below a list of modules that (in my opinion) could be enough interesting to be considered:

  • Menu Badges to give user notifications (i.e. how many comments are in moderation queue)
  • Node Subpages to create subsections in a node, separating in a easy way the main content from other related stuff like galleries, video and in-depth articles.
  • View unpublished to let users watch how nodes fit in the page before their publishing.

Hope the list will be useful

Search like Google Instant, perhaps by utilising apachesolr_ajax or search_api_ajax.

Version:» 7.x-1.x-dev

#21: difference between clientside_validation and ife (quick comparison)

ife adds the error message inline after a post back

clientside_validation does a lot more:

  • 'translates' all validation to javascript validation so no post back is needed
  • supports 8 different placements methods to decide where to place the error messages
  • see project page for more information

If you need help with clientside_validation let me know.

Thanks @attiks, that's very helpful :)

Regarding that "translation":
- What's the general mechanism used for it? Write a JS equivalent for every PHP validation function that's available?
- Does it work reliably?
- How do you guarantee that it works exactly the same and provides exactly the same validation error messages?

Mechanism:

  • We look at the field settings: data type, widget, min, max, required, ...
  • Core FAPI is supported as well is some popular contrib modules
  • There's support for other validation modules like FAPI Validation and Field Validation

Reliable:

  • for core FAPI yes
  • for contrib it sometimes breaks, mostly because a contrib module changed some code
  • to be 100% reliable we need an API to declare validation functions

Exactly the same:

  • We only map functions when we're absolutely sure they work the same
  • For edge cases clientside_validation can use an AJAX callback so the validation is done by PHP

Thanks for the fast reply — that all sounds very reasonable :)

You also have unit tests up & running, which is major plus of course! We still need to tackle validation at large as part of the Edit module (see #1669054: How to deal with form validation when editing in-place?), so we'll definitely take this under very serious consideration.

EDIT: oh, and FYI: this module already was on my radar ;) :) Great work!

From the point of view of a site builder I think LESS CSS Preprocessor would be a useful addition to core.
It makes site design/building easier and more productive. And I am sure many of us use it already.

mbret5062: There's already an issue for that: #1310698: Add a CSS preprocessor library to core, which is fairly sold on Sass over Less at this point. (For whatever reason, most Drupalers seem to have gone Sass over Less.)

Crell: Thanks for the update. And yes, I have been using Sass rather then Less, I think it is more intuitive and easier to get into. I only posted the feature request as Less due to the fact it seemed to have better server side support. I will check out the issue.

FYI, there's also http://leafo.net/scssphp/ doing the same as lessphp but for scss

UX plugin for mobile -- Tiny nav. Uses media query to determine when to convert the targeted menu navigation from traditional to a mobile friendly <select> field.

http://www.youtube.com/watch?v=JfNhhVjVbks -- video demonstrating it working with the Admin menu module to make it more mobile friendly.
https://drupal.psu.edu/blog/417 - Blog post with video demonstrating just the tinynav technique

Issue summary:View changes
Status:Active» Closed (fixed)

Thanks all for the great feedback in this issue. I'm archiving this now since we chose to keep Spark as close to core as possible, which means we won't be making use of most of these things.