Think Info

Exploring the information space

6 responses to “What you see is SMUC

  1. Jeff Eaton 2013/06/05 at 12:51

    Two massive thumbs up. The problem with WYSIWYG editors isn’t that they give people assistive tools, it’s that they give people a *generic, presentationally-focused vocabulary* in the form of standard HTML.

    This is precisely the approach we’ve been taking on our own projects, and the biggest challenge is the semantic data itself. It’s very rare, in our experience, that all sites share the same semantic vocabularies. A cooking site may need good markup for “a sequence of steps” while an insurance web site needs to capture the semantic meaning of “warning that affects your coverage”.

    We’re hoping to roll out a reusable version of the approach we’ve been taking in Drupal sometime in the next month or so — further updates as events warrant. The interesting thing is that the current generation of WYSIWYG editing software — CKEditor, TinyMCE, etc — can be customized to function this way. It just takes a clear vision of what semantic-editing is, and a use case where the value of the data is obvious enough to the business to justify the extra configuration time.

  2. Wim Leers 2013/06/05 at 13:12

    Very interesting article, thanks!

    I find it especially interesting because you’re pointing in the same direction as I’m trying to steer Drupal towards, even though you’re not at all a Drupal person AFAICT:). Independently reaching the same conclusion is always a good sign.

    You may be interested in this strongly related article that I published just a few days ago on Drupal 8’s authoring experience for structured content: http://wimleers.com/article/drupal-8-structured-content-authoring-experience

  3. tkoleary 2013/06/05 at 13:28

    Excellent article. At Drupalcon Portland we held a BOF to discuss just this type of idea (referred to by some as WYSIWYM, “what you see is what you mean”). Are you aware of RDFace? http://aksw.org/Projects/RDFaCE.html it is essentially doing precisely what you are proposing with the added benefit of linking directly to the schema.org API. There are quite a few performance and usability issues that need to be worked through, but AFAIK it’s the first real implementation of this in the wild and as such very promising.

  4. Jay Gilmore (@JayGilmore) 2013/06/05 at 14:56

    Tremendously interesting idea. As Jeff Eaton points out the challenge is in building semantic interfaces that fit the project that are exceptions to commonly defined or standard content objects.

    Another thing to consider is assisting authors to ensure they incorporate these semantic content objects in the specific context for the specific content type. I.e., When editing staff bio/profile vs a product record there will be different needs, fields, metadata etc. Certainly this does address incorporating inline MicroData and other semantic data types into long form articles and maybe that’s the only problem you’re attempting to solve here and I’m off down the rabbit-hole.

  5. Ellis Pratt 2013/06/06 at 06:29

    Have you taken a look at MadCap Flare and the structure bar in its editor?http://www.madcapsoftware.com/company/presscenter/pr20110329.aspx It’s sounds like you’re outlining a solution similar to that. Flare store its content in XML, but the authoring environment is WYSYWYG. It’s designed for topic based authoring, but you could use it for long form writing. The downsides are it’s not a CMS, but an authoring tool (although you have the option of silent, command line publishing)

  6. Pingback: Structured Authoring By For And Or Nor With In the Web | I'd Rather Be Writing

Follow

Get every new post delivered to your Inbox.

Join 30 other followers

%d bloggers like this: