When gathering project requirements, hearing a client ask for "WYSIWYG" can be cause for concern. Clients see an easy way to manage content but are often unaware of potential consequences. As more tools are leveraged within an editor, the potential that something may clash with CSS on output can increase. Prudent developers may immediately work to limit the set of tools provided to the client. If you're lucky, you can get away with supporting "links", "bold", "italics", but not "underline"!
Inline WYSIWYG editing gives content managers the ability to click on part of a page to edit content within that part. This means fielded data as well as body text.
This approach provides several benefits:
- Better Editing - What you see is truly what you get. You no longer have to reconcile differences between the view and edit pages (like CSS and editor window width).
- Better Usability - It's easier to see a change that is needed and make edits vs. the standard edit-view cycle of Drupal content management
- Better Semantic Markup - By enabling WYSIWYG editing for multiple data fields rather than using a single body field, the need to use WYSIWYG for content positioning can be reduced and the meaning of a field, defined within its markup, need not be lost.
What's out there for Drupal 7?
A good place to start is the Spark distribution. This combines inline editing via the Edit module, WYSIWYG Editing via Aloha, as well as responsive layout management via Layout and Gridbuilder modules.
- In the spirit of managing presentation inline, The Context Inline Editor allows users to edit contexts inline without going off to an admin page.
- CKEditor 4, currently in beta, offers inline editing. This is relatively new so Drupal integration is limited but is definitely one to watch.
- Editable Fields - Ajax-based inline, editable fields. You can set a field to be editable via its display. This also supports editing view content.
Keep it simple and try to use fielded data:
- Do you really want to use a WYSIWYG? If possible, try inline editing without a WYSIWYG or at least with minimal markup tools enabled. For clients who like the simplicity of seeing what you get rather than navigating a bunch of fields on an edit page, inline editing could be your ace in the hole.
- Try to avoid the standard block of WYSIWYG content. If you can help it, only use WYSIWYGs for basic markup. Chances are, bold or italicized text will look good whether it's on an IE7 or an iPhone; however, throw in a few hidden tables to get your content's image just right and there may be issues.
- Each tool you give a client increases the possibilities of what they might do, good or bad. Start off simple and try to avoid 4 rows of tools. As the complexity of the markup increase, the possibility of bad presentation across target browsers, not to mention mobile devices, increases as well.
- Breaking content up into fields based on meaning helps future-proof your site. Have you ever needed to migrate WYSIWYG data? It can be pretty messy when content that looked good on the old site looks broken when new css is applied. If content is broken up via fields rather than by markup, the need for manual review can be reduced since the import process can better map data from its old location to the new. This approach also lends itself to faceted search and sidebar content lists.
Ultimately, the goal should be to maximize content management usability without sacrificing semantic markup or data structure. Due to the inherent loss of data when something is abstracted, something can always be lost when WYSIWYGs are used. Although WYSIWYGs can be a great help to clients, it's up to you to prevent the content's meaning from taking a backseat to its presentation.