The goal of this session is to create some WYSIWYG configurations as Features that meet the needs of the Stanford community.
Jen's work is awesome. Super generous of her to work on articulating all this for us! http://wysiwyg.jenlampton.com/
Like John, I also think a wysiwyg feature is an exciting prospect.
I believe the ideal set-up should have 2 WYSWYG editor profiles, a basic one (for most contributors) and an advanced one (for site editors). For example, I often find there is a need to post tables on the site, but don't want to open up this option to everyone, all the time…
I also think there are options to consider. For example, you might want to have your WYSIWG editor display similar stylistic rendering as will be rendered on save (you are supposed to see what you get, no?). There some tricks to get this working properly. Simply using your theme's main css style might not suffice if you are relying on a reset.css, and the WYSIWYG can be rendered dysfunctional if you have a background on your body class. I've been manually creating a wysiwyg.css in my themes, but maybe there is a better way.
Also, I feel that the transliteration module is an essential component if you use insert – really if you use any file/imagefields on your site. Images with illegal characters will often preview fine on the node/edit form, but display as broken links on save.
Insert + filefield_sources can also be used to recycle images already in your file system, allowing site editors to re-use existing assets, like departmental logos, or faculty headshots. IMCE or other options can be configured so. Jen demonstrated this feature of IMCE at the camp, much to the awe of many in the room. I think a lot of people are interested in this option!
filefield_paths and imagefield_tokens are very useful if you are doing the above, so that uploaded images can be located in an intelligently organized structure according to a role-conscientious set of permissions.
-- Andrew Mallis