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
Comment #1
chris_h CreditAttribution: chris_h commentedTwo 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
Comment #2
mariomaric CreditAttribution: mariomaric commentedMaybe also this two modules for better menu handling experience:
Comment #3
Crell CreditAttribution: Crell commentedmodule_filter: I install this on nearly ever site I touch. The modules page is almost unusable without it.
Comment #4
mherchelViews UI: Edit Basic Settings is a must for all of my sites.
Comment #5
cosmicdreams CreditAttribution: cosmicdreams commentedThis 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:
Comment #6
Dave ReidComment #7
CatherineOmega CreditAttribution: CatherineOmega commentedMore on the site builder side than anything else: I'm liking Coffee, for its "oh man, where IS that in D7?" helpfulness.
Comment #8
EclipseGc CreditAttribution: EclipseGc commentedContextual Administration: I use this on practically every site I build. It's potential utility is limitless.
Eclipse
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commented/me throws down 2 cents
http://drupal.org/project/ideal_comments
http://drupal.org/project/piecemaker
Comment #10
IceCreamYou2 CreditAttribution: IceCreamYou2 commentedAs 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.
Comment #11
ronald_istos CreditAttribution: ronald_istos commentedFor 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
Comment #12
escoles CreditAttribution: escoles commentedWhile 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?
Comment #13
alexweber CreditAttribution: alexweber commented@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.
Comment #14
IceCreamYou2 CreditAttribution: IceCreamYou2 commentedRe #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).
Comment #15
btopro CreditAttribution: btopro commentedOutline 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.
Comment #16
MsG CreditAttribution: MsG commentedI 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.
Comment #17
calte CreditAttribution: calte commentedI 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
Comment #18
Wim LeersAnother one: WYSIWYG fields. http://drupal.org/project/wysiwyg_fields. Demo: http://www.youtube.com/watch?v=-CYGPCCzWYo.
Comment #19
Wim Leershttp://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.)
Comment #20
webchickhttp://drupal.org/project/imagefield_focus is another one, providing nice support for dynamic image effects.
Comment #21
Wim Leershttp://drupal.org/project/ife or http://drupal.org/project/clientside_validation for inline form errors. We should evaluate them to figure out the differences.
Comment #22
Wim Leershttp://drupal.org/project/ife or http://drupal.org/project/clientside_validation for inline form errors. We should evaluate them to figure out the differences.
Comment #23
moshe weitzman CreditAttribution: moshe weitzman commentedGreat 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!
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedMultiple Node Menu - Allows a node to be added to multiple menus from the node edit page
Comment #25
pjcdawkins CreditAttribution: pjcdawkins commentedContent Lock - notifies user on leaving a node form with unsaved content, and prevents users from editing nodes concurrently.
Comment #26
lightsurge CreditAttribution: lightsurge commentedAnother 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.
Comment #27
mgiffordI 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
Comment #28
Crell CreditAttribution: Crell commentedI 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.)
Comment #29
lightsurge CreditAttribution: lightsurge commentedCheck 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.
Comment #30
pjcdawkins CreditAttribution: pjcdawkins commentedmgifford: 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.
Comment #31
mgiffordThanks @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.
Comment #32
Jamie Holly CreditAttribution: Jamie Holly commentedLocalStorage is IE8+. Was that the minimum requirement for D8, or was it IE7? I can't remember, blasted old mind!!!
Comment #33
Crell CreditAttribution: Crell commentedDrupal 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.
Comment #34
Jamie Holly CreditAttribution: Jamie Holly commented@#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.
Comment #35
kongoji CreditAttribution: kongoji commentedBelow a list of modules that (in my opinion) could be enough interesting to be considered:
Hope the list will be useful
Comment #36
MustangGB CreditAttribution: MustangGB commentedSearch like Google Instant, perhaps by utilising apachesolr_ajax or search_api_ajax.
Comment #37
attiks CreditAttribution: attiks commented#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:
If you need help with clientside_validation let me know.
Comment #38
Wim LeersThanks @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?
Comment #39
attiks CreditAttribution: attiks commentedMechanism:
Reliable:
Exactly the same:
Comment #40
Wim LeersThanks 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!
Comment #41
mbrett5062 CreditAttribution: mbrett5062 commentedFrom 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.
Comment #42
Crell CreditAttribution: Crell commentedmbret5062: 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.)
Comment #43
mbrett5062 CreditAttribution: mbrett5062 commentedCrell: 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.
Comment #44
attiks CreditAttribution: attiks commentedFYI, there's also http://leafo.net/scssphp/ doing the same as lessphp but for scss
Comment #45
btopro CreditAttribution: btopro commentedUX 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
Comment #46
webchickThanks 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.