Find a post...

DNN-Connect Blogs

Responsive/Mobile Web Solutions with DNN - #3 The Good Death of WYSIWYG

Remember the old days when we pretended we had What-You-See-Is-What-You-Get? Right now I'm writing this blog on the Telerik-editor built into DNN and it's terrible. 

There are a zillion bugs - like hitting backspace at the beginning of a paragraph will reformat my text (no joke). I had forgotten how bad it is, because we barely use the WYSIWYG nowadays - and you too will soon stop using it. If we're totally honest with ourselves, it never worked - and now it's clear that it never will work. 

100 Previews

These pictures show the very same content - in 3 of over 100 different previews that would be possible:

The reason is very, very simple: When A4-paper was the final destination of our work at the computer, the goal was to show the resulting paper on the screen - eliminating the guesswork of what we get when we print. So WYSIWYG meant simulating paper on a PC while the editor added content (texts, images, etc.) so that ever move would look like it's being done on paper. This is simply not possible when creating responsive content - as it will look different everywhere.

Preview would also need to show behavior

Ideally it will not just look but also behave. Something that you can't See before you Get it. Touch/Click is not the same thing, and forget mouse-over in a mobile device. But even if reduced to layout-behavior - you're stuck. Let's just review the options where the image could go when screens vary:

  1. The image could go above the title (which it actually does after a while)
  2. The image could go between title & text (which it also does for a while)
  3. It could go under the text
  4. We could remove it
  5. The size could change
  6. It could become super-tiny with a click to view (not shown)
  7. It could be replaced with an icon with a click to view (not shown)
  8. ...or a combination of these (very, very common)

This is impossible to preview, and even harder to configure - especially in a tool that tries to simulate a paper-simulator.

Preview is impossible, Code is absurd

Writing the correct code is even harder. Here's the code for the bit above, most of the text was removed to make it easier:

And here the annotated version

  1. special classes to ensure correct display-behavior based on various rules/screens
  2. some content inserted more than once
  3. special resizing-parameters

A normal editing person simply cannot do this - and shouldn't! And the WYSIWYG-Tool can't handle this - and shouldn't.

Here a few links from a current project that show some responsive behavior (open the link and try various screen sizes).

  1. a classic list with images which looks different on every screen size
  2. an overview page with content that can be 2-column or 1-column
  3. here is a before-after widget that must change behavior based on the situation
  4. this content-rotator hides some information if the screen gets too small

Redefining the Mission of the Editing Interface

So let's redefine the mission of an editing interface to match future needs: We need a UI to add content to a system, in such a way that the system can then present it to the user as best fits the user's situation (device, capabilities and context). I love bullet points, so let's just repeat that:

  1. UI for the editor to add content...
  2. a Content-Management-System
  3. that the Content-Management-System can show the content to a user...
  4. ...optimized to the user's device, capabilities and context

I would love to write more about context, but will reserve that for another blog. What I would like to emphasize is that it's not the editors responsibility to show the content in a designed fashion but the responsibility of the CMS. A lot of work wasted by the editor is now for the CMS to do. 

  • Show the full text or the intro? Let the system/web designer decide. 
  • Show a large image or just a thumbnail? Let the system/web designer decide. 
  • Image to the right or above the text? Let the system/web designer decide. 
  • Resolution of the image? Let the system/web designer decide. 

The content-editor clearly lost many of his responsibilities. The things an editor must do in the future don't need a WYSIWYG any more. It's actually important that he doesn't believe he's seeing what he gets. 

What must an Editor-UI do in the future?

  1. Divide an Conquer: The CMS of today needs information split into it's smallest parts, so that it can use it as best as possible. The title of an image can never again be mixed in the same "field" of data (like with a WYSIWYG) because that would limit the CMSs abilities to optimize presentation. This way the CMS will also be able to hide information if appropriate, present it in an overlay or pass the information to another sub-system like an on-device calendar or mapping-tool. 
  2. Semantics - understand the Content-Type: The UIs must know what kind of information the editor is adding - to correctly offer him the right fields. Are you adding an image? offer 2-3 fields for that. Add a gallery-item? needs a few more fields. An address? 20 fields.  
  3. Choose presentation: Although the editor cannot define how the content is presented (what HTML, CSS, etc.) the editor still wants to control which presentation is used for his content (I want to show the image to the right of my text if possible and not to the left...). The UI must allow the editor to choose this. 

Yes, we still need editors for formatted text

...but not because it shows us how the result will look. We need it, because parts of what we write still needs features like emphasis with bold/italic or because we need inline-references (links) to other information. But that's the entire scope. Many of the things we could do in a WYSIWYG will go away.

These WYSIWYG-features will die

  1. Inline images and all the necessary features for alignment and such
  2. Font-definitions - this always was bad practice, and now it's really time to go
  3. Tables - also something than barely ever worked - the CMS must "know" more about what it's showing, so a WYSIWYG-table is a no-go
  4. Inline videos
  5. HTML-templates (a popular workaround to get some consistent look in the WYSIWYG) - obsolete

Where can we find such editors today?

There is of course the competition - for example, drupal and umbraco are pursuing such an approach. Within the DNN-environment I believe the only real tool for this is 2SexyContent (disclaimer: we created this). You could also do some of this with XMod or Form and List - but it would be a lot of work and not deliver a satisfying user experience. This is actually one of the core reasons we started with 2SexyContent 2 years ago - there just was no other solution for this. be continued...

With Love from Switzerland

Daniel Mettler learned programming with the bible translation computer of his parents, deep in the jungles of Indonesia. Since he was only 12 years old at that time and the BIOS only had a version of BASICA, that's what got him started. With 16 he went back to Switzerland and learned German and basic city-survival skills. Equipped with this know-how he founded 2sic internet solutions in 1999 which was focused on web solutions on the Microsoft platform. After a few self-developed CMSs 2sic switched to DNN in 2003 and has been one of the largest partners (17 employees, 700+ projects) in Europe. Daniel is also the chief architect behind the open source 2sxc, a strong promoter of standardization (boostrap, patterns, AngularJS, checklists, etc.) and loves to eat anything - dead or alive. His motto: if the natives eat it, it game.
Daniel Mettler
Daniel Mettler  Just had to update the post again - all images had gone missing, sorry. Probably a bug in the site, but I'm sure they are working on it :). Thanks guys!
· reply · 0 0 0
  Hi Daniel, Nice blog post. I invite you to come to my session on dnn connect to see how to transform the DNN WYSIWIG editor to a new age. Maybe you can find ideas to be more sexy :) (Reusable blocks – Tokens, Templates, Widgets)
· reply · 0 0 0
  Very informative article!All the points are covered in the article .I hope that your article gonna help me a lot. Keep posting!
· reply · 0 0 0

Hosting liberally provided by

Philipp Becker 6011 7
Geoff Barlow 542 4
DNN-Connect 431 6
Peter Donker 5101 30
Christopher Hammond 683 2
Olivier Jooris 418 1
Daniel Mettler 12060 88
Clint Patterson 1 1
Jos Richters 65 1
James Rosewell 327 2
Will Strohl 1551 27
Ernst Peter Tamminga 438 4
Barry Waluszko 2804 2
Declan Ward 471 1
Gifford Watkins 722 9
Torsten Weggen 2804 3