Gabe Sumner

Wanted: Video-conferencing solution for mid-sized teams

Gabe Sumner — Tue, 14 Feb 2012 22:32:20 +0000

The Telerik Evangelism team has recently been experimenting with new techniques for staying connected and in-sync. One of these techniques was to utilize video-conferencing for our bi-weekly meetings. Sadly, I’ve not discovered any video-conferencing solutions that accommodates a team of our size (15 people). Below I’ve summarized my experiences thus far:

Video-conferencing solutions at a glance

All video-conferencing solutions limit how many attendees can participate with their webcams. Once this limit is exceeded, the behavior varies from service to service. However, most services will support several more audio-only participants. Below I’ve summarized the video and total limits for each service.

Service	Video Limit	Total Limit
GotoMeeting	6	15
Webex	7	25
Skype	10	20
Google Hangouts	10	10
Oovoo	12	12
Vidtel	12	12
Blue Jeans Network	25	25
Microsoft Lync	250	250

What happens when the video limit is exceeded?

Gotomeeting -Video in Gotomeeting is first come, first serve. Each participant must manually enable their webcam. However, once the 6 video-user limit is reached the option is disabled for other attendees. These other attendees will be audio-only, able to see the 6 video users, but not utilize their own webcam.

Webex – When more than 7 participants join the meeting the meeting moderator can select who can share video. Up to 25 total participants can join the call but only 7 will have video sharing options available.

Skype – When more than 10 participants join, video conferencing and screensharing get disabled for everyone. After this, the call continues and up to 25 participants can join for audio-only conferencing.

Google Hangouts – There is a hard cap of 10 participants. Anyone else who joins the conference will be put into spectator mode. They can hear the conference, but not participate. I’m intrigued by Google Hangouts, but the 10 person limit is a deal-breaker.

Microsoft Lync – Using Lync all participants can utilize their webcam, but only the speaker gets focus (no Hollywood Squares style display). Furthermore, I’m seldom able to get Lync to perform reasonably with 2 participants, let alone 250. This problem becomes even worse for our telecommuters who are forced to VPN into the network to utilize Lync. On a LAN this might be a great solution; however, for our distributed team Lync does not produce great results.

Oovoo – I have no direct experience with Oovoo yet. If you do, feel free to comment below.

Blue Jeans Network – I have no direct experience with Blue Jeans Network yet. I’m intrigued by its ability to bridge multiple solutions (WebEx, Skype, etc.) though. I would love to see feedback from others who have direct experiences with this service.

Our current solution

For the time being we’re using Skype for voice-only communication. It’s ubiquitous, which is nice; it also has integrated chat which the evangelism team seems to enjoy using during the meetings. For screen-sharing, we’ll probably just fire-up a Gotomeeting session as needed. We’ll only use it for screen-sharing and disable the audio.

In a nutshell, we’re abandoning video-conferencing entirely. I’m not happy about this, but I haven’t been happy with any of the other options either. I’ll update this post if I locate a better solution or more information.

Special thanks to @ryanlowdermilk for helping with this post.

How to Export Blog Comments from Sitefinity 3 to Disqus

Gabe Sumner — Mon, 13 Feb 2012 02:04:22 +0000

Over this past weekend I decided to retire my old goondocks.com blog. This domain name is a reference to The Goonies which is a movie I remember fondly from the 80′s. I picked up this domain many years ago and held on to it. When I discovered Sitefinity 3.0 I used it to experiment and share my lessons & experiences.

After joining Telerik, I launched sitefinitywatch.com and never again touched goondocks.com. Consequently, this blog has stagnated and become a dumping ground for spammers. There are now thousands of blog comments that contain nothing but spam:

I wanted to import my old blog posts and legitimate comments to this blog. If you scroll down below you’ll see I’m using Disqus to manage my comments on this blog. Consequently, I needed to find a way to filter the SPAM from these comments, export the comments from Sitefinity 3.x and then import these comments into Disqus.

How to import comments into Disqus

Creating a Test Forum on Disqus

Seriously, you’re going to make mistakes

Read the following resources:

Create your Sitefinity Comments Export

Add the code below to your Sitefinity 3 project
Access the page and paste the resulting XML into Notepad

Upload the XML file to Disqus
Wait….

Exporting Sitefinity 3 Comments using the API

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="test.aspx.cs" Inherits="test" %>


 xmlns="http://www.w3.org/1999/xhtml">
 id="Head1" runat="server">
    </span>Use Ctrl + A to select All, then Paste into Notepad.  This is your XML export file.<span class="nt">
     id="form1" runat="server">
    

     ID="xmlRepeater" runat="server">
    
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:dsq="http://www.disqus.com/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:wp="http://wordpress.org/export/1.0/"
>
  <channel>
    

    
    <item>
      <title><%# Eval("[Title]") %></title>
      <link>http://www.goondocks.com/blog<%# Eval("[Url]") %>.aspx</link>
      <dsq:thread_identifier><%# Eval("[ID]") %></dsq:thread_identifier>
      <wp:post_date_gmt><%# Eval("[DatePosted]")%></wp:post_date_gmt>
      <wp:comment_status>open</wp:comment_status>

       DataSource='<%# Eval("[Comments]") %>' runat="server">

      
        <wp:comment>
        <wp:comment_id><%# Eval("[ID]") %></wp:comment_id>
        <wp:comment_author><%# Eval("[Author]") %></wp:comment_author>
        <wp:comment_author_email><%# Eval("[Email]") %></wp:comment_author_email>
        <wp:comment_author_url><%# Eval("[Website]") %>/</wp:comment_author_url>
        <wp:comment_author_IP><%# Eval("[IpAddress]") %></wp:comment_author_IP>
        <wp:comment_date_gmt><%# Eval("[DatePosted]")%></wp:comment_date_gmt>
        <wp:comment_content><![CDATA[<%# Eval("[Text]")%>]]></wp:comment_content>
        <wp:comment_approved>1</wp:comment_approved>
        <wp:comment_parent>0</wp:comment_parent>
        </wp:comment>
      

      

    </item>
    

    
  </channel>
</rss>    
    
    
    
    
    

view raw DisqusExport.aspx This Gist brought to you by GitHub.

using System;
using System.Collections;
using System.Web;
using Telerik.Cms.Engine;
using System.Text.RegularExpressions;

public partial class test : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Telerik.Cms.Engine.ContentManager contentManager = new Telerik.Cms.Engine.ContentManager("Blogs");
        IList posts = contentManager.GetContent();
        ArrayList Posts = new ArrayList();
        int Count = 0;

        // Loop through all blog posts
        foreach (IContent post in posts)
        {
            // Yes, I know ArrayLists and Hashtables are lame.  However, Sitefinity 3 was built with .NET 2.0 
            // which doesn't support generics and I didn't want to take the time to fully implement IList.

            Hashtable Post = new Hashtable();

            Post.Add("ID", post.ID);
            Post.Add("Title", post.GetMetaData("Title"));
            Post.Add("Url", post.Url);
            // That "GeteCreationDate()" only exists in later version of Sitefinity 3.x.
            Post.Add("DatePosted", post.DateModified.ToUniversalTime().ToString("yyyy-MM-dd HH:mm:ss"));
            Post.Add("Comments", new ArrayList());

            foreach (IComment comment in post.Comments)
            {
                ArrayList Comments = new ArrayList();

                // I had a TON of spam in my blog (thousands of comments), this is used to filter this SPAM.
                // Sorry for the offensive language, you can thank spammers for this.
                if (
                    comment.Visible == true &&
                    comment.IsReadByUser("admin") == true &&
                    comment.Text.Length > 100 &&
                    comment.GetCreationDate() < new DateTime(2011, 1, 1) &&
                    Regex.IsMatch(comment.Email, @"aol\.com") == false &&
                    Regex.IsMatch(comment.Author, @"\@") == false &&
                    String.IsNullOrEmpty(comment.Author) == false &&
                    Regex.IsMatch(comment.Text.ToString(), @"penis") == false &&
                    Regex.IsMatch(comment.Text.ToString(), @"sex") == false &&
                    Regex.IsMatch(comment.Text.ToString(), @"herbal") == false &&
                    Regex.IsMatch(comment.IpAddress.ToString(), @"121\.204") == false
                    )
                {
                    Count++;
                    Hashtable Comment = new Hashtable();
                    Comment.Add("ID", comment.ID);
                    Comment.Add("Author", comment.Author);
                    Comment.Add("Email", comment.Email);
                    Comment.Add("Website", comment.WebSite);
                    Comment.Add("Text", HttpUtility.HtmlEncode(comment.Text));
                    Comment.Add("IpAddress", comment.IpAddress);
                    // That "GeteCreationDate()" only exists in later version of Sitefinity 3.x.
                    Comment.Add("DatePosted", comment.GetCreationDate().ToUniversalTime().ToString("yyyy-MM-dd HH:mm:ss"));

                    ((ArrayList)Post["Comments"]).Add(Comment);
                }
            }

            if (((ArrayList)Post["Comments"]).Count > 0)
            {
                Posts.Add(Post);
            }
        }

        xmlRepeater.DataSource = Posts;
        xmlRepeater.DataBind();
    }
}

            view raw
            DisqusExport.aspx.cs
            This Gist brought to you by GitHub.
          

2011 reflections on Telerik’s Sitefinity CMS

Gabe Sumner — Mon, 19 Dec 2011 15:36:07 +0000

The Holidays are upon us and 2011 is nearly gone. This past year has been extremely busy and significant for Sitefinity. Before we move into 2012 I want to reflect on 2011. This post is strictly my personal opinion and, consequently, is being published to my personal blog.

I’m publishing this for Sitefinity customers who might be interested in a Telerik insiders’ perspective on this past year. Hopefully this provides some context and a glimpse into what’s coming in 2012.

Rewind, back to January 2011

I can’t address the significance of 2011 without talking about the release of Sitefinity 4.0.

Sitefinity 4.0 was a huge milestone for us and its release marked a transition to a new chapter in Sitefinity’s evolution. Sitefinity 4.0 changed everything. This isn’t marketing babble, this is truth. Not one line of Sitefinity 3 code was used in Sitefinity 4. Furthermore, in addition to rebuilding the product, we also introduced a new licensing and pricing model.

If you’re thinking “that looks like a lot of change to navigate”, then you’d be right. Saying Sitefinity 4.0 was “disruptive” would be an understatement. We were prepared for some measure of this, but it took a lot more time than expected to fully assimilate these changes.

Why was all this change needed?

For those who don’t know, I was a Sitefinity customer before I was an employee. When I discovered Sitefinity (back in 2007) this was the tag-line:

At the time, this tagline matched my mental model. I was a “developer” and I needed to deliver a website that could be managed by “end-users”. Sitefinity spoke to me with this message and the product walked the talk. I loved it!

However, this message now looks simplistic to me. “End-user” is just a generic bucket where we dump everyone who isn’t us. If you talk to those “end-users” you quickly discover real people with rich skillsets and objectives. The CMS belongs as much to them, as it does developers. Managing a modern website requires collaboration between multiple audiences and a good CMS enables this collaboration while simultaneously empowering diverse audiences throughout the organization.

This trend is a natural by-product of the web’s popularity. An organization’s website is no longer a piece of technology, but instead a vital communication conduit. As a result, the website impacts the entire organization and CMS stakeholders are diversifying. Consequently, Sitefinity needed to engage beyond developers to address complex organizational challenges (governance, communication, collaboration, syndication, etc.).

Historically Sitefinity was an $899 product marketed and sold to developers. If we wanted to move beyond this model, then substantial changes were required to the product and our organization.

Getting from here to there

I understand there could be debate about whether the premise outlined above is correct. Some organizations still view the website as a “technology resource”. As a result, CMS selection continues to be driven exclusively by the IT department and “users” simply inherit their decision. For those scenarios, an $899 developer-focused product continues to be very attractive.

However, these scenarios are diminishing. Internally, we became convinced Sitefinity needed to evolve beyond its historic market positioning to remain relevant.

This led to 3 conclusions:

We needed to rebuild Sitefinity from the ground-up.
We needed to double+ the size of the Sitefinity team.
We needed to change Sitefinity’s licensing.

I could write very long posts exploring each of these 3 decisions; instead I’ll try to quickly summarize:

Rebuilding Sitefinity – When Sitefinity 3 was conceived, .NET 2.0 was the predominant framework. A lot has happened since then and it was becoming difficult (hacky) to evolve the platform. Rebuilding on .NET 4 enabled us to utilize a lot of newer technologies (WWF 4.0, web services, LINQ, etc.). In addition, Sitefinity 3 was built on Nolics and Nolics is dead.
Doubling the team – Rebuilding and then extending the product takes a lot of manpower. In addition, selling a CMS to non-developers takes a very different sales organization. Not to mention support, partner managers, etc…
Changing the licensing – I could simply refer to #2, but it goes beyond that. A flat $899 price would not fuel product development at our current pace, nor support the large customer projects that we were engaging with. The new tiered pricing was implemented to provide a more sustainable & accessible licensing framework.

We knew these decisions would cause discomfort for existing customers and none of us felt happy about this. However, we viewed this as a necessary transition needed to evolve Sitefinity.

Weathering the storm

We underestimated what it would take to assimilate all of this change. It’s like dropping a boulder into a pond while you’re sitting in a boat. You expect some waves and brace for them, but in this case the waves continued for months.

A big part of 2011 was devoted to stabilizing Sitefinity (the product, the organization, the community) after this change. This included a stream of product releases, license extensions, extensive support, etc. It’s been an exhausting year.

However, under difficult circumstances the team has pulled together to deliver the best possible results. We’ve made massive headway in 2011. Today, Sitefinity is seeing strong adoption and customers are now delivering a stream of results on Sitefinity 4.

With our recent upgrade initiative, we’re largely closing the book on this difficult transition. Of course it’ll never fully be done, but we feel good about where we’re starting in 2012.

A quick word for the developer audience

I already expressed our desire to engage beyond developers with Sitefinity 4. In practical terms, this meant a heavy emphasis on usability. It also meant a lot of features like scheduling, layouts, workflows, granular permissions, a form builder, rich classifications, etc., etc. These features are designed to empower people throughout the organization.

However, in the midst of empowering non-developers we complicated things that .NET developers loved about Sitefinity 3; this primarily being the accessibility of Sitefinity’s extensibility. My phrasing is very precise here. Sitefinity 4 has obscene amounts of extensibility, but to a developer with a tight deadline (most of us) this extensibility isn’t easily grasped or utilized.

We’ve addressed this through “teaching resources” (Sitefinity SDK, extensive documentation, webinars, videos, blogs), but it still takes too much time to absorb. Our goal in Q1 2012 is to create an extensibility framework that is naturally intuitive to .NET developers. We’ll do this primarily through the Module Builder and with Sitefinity Thunder (roadmap).

Expect to hear more about this in January and February. We’ll iterate on these tools rapidly until extensibility is widely accessible & utilized. After all, developer productivity is what Telerik is widely recognized for. It’s time for us to reclaim this benefit.

Wrapping up…

As many of you know Telerik is based in Sofia, Bulgaria and most of the Sitefinity team resides at this office. I personally work from our Houston office and I visit Telerik HQ each year in October. I chat with my co-workers constantly, but I only get to see them (in person) once a year. This provides me a chance to view a time-elapsed perspective of this team and their growth.

Here is the team in October of 2010:

Here is the team in October of 2011:

This past October I left very optimistic. My optimism didn’t stem from any grandiose idea that I saw prototypes for. Instead, my optimism stemmed from the maturity and discipline I saw in action. It was great to listen to their scrum meetings, their testing conversations, their planning meetings, etc. The difficulties of this past year have made this team stronger and wiser.

Of course, we still have a lot of work ahead of us. But we’re closing the book on 2011 and with it the high-volume of change that we needed to assimilate. In 2012 we will finally get to explore the capabilities of this new team and product we’ve created. As an evangelist, that makes me excited. As a customer, hopefully it makes you excited too.

Happy Holidays and we’ll chat next year! :)

Amazon’s Silk Browser breaks Web Personalization

Gabe Sumner — Thu, 29 Sep 2011 20:29:58 +0000

Yesterday Amazon’s Jeff Bezos announced their new Kindle Fire tablet. This tablet is a full color, touch-enabled device that is capable of apps, games, books, movies or web browsing. To put it bluntly, it’s like an iPad…except it’s $199.

However, it’s the web browser component of this device that caught my attention.

Introducing Amazon’s Silk Web Browser

Amazon is calling the Kindle Fire’s browser “Amazon Silk”. This browser is based on WebKit, but utilizes Amazon’s Elastic Computing to optimize the delivery of web content. [More details]

This video gives a nice overview of how this works.

http://www.youtube.com/watch?feature=player_embedded&v=_u7F_56WhHk

The key point to understand is that the web request will be coming from Amazon’s Elastic Computing infrastructure, not the visitor’s Kindle Fire device. For web sites that are doing personalization, content targeting or analytics, this presents a challenge.

It’s all about the experience

Web Experience Management is the latest hot trend in CMS. WEM enables marketers to slice & dice their visiting audience into segments (based on behavior patterns, geolocation and profiles) and personalize content accordingly.

The ultimate goal is increased engagement (we want to cultivate a more engaged audience). In practical terms though, this translates into more buying, sharing, subscribing, clicking, etc.

However, these personalization and targeting tools are often initially based on the IP address of your anonymous visitor. Using their IP address the CMS can approximate which region of the world they are in and subsequent page requests bring their profile into clearer focus.

But what happens to this personalization when all the web requests are coming from Amazon’s Elastic Computing infrastructure?

Opera did it – and it broke personalization

Although not entirely the same, Opera already implemented a similar feature known as Turbo into their browser. Opera, like Amazon Silk, is acting as a proxy and pre-fetching content on behalf of slower browsers.

As a little test, I fired up Opera Turbo and pointed it at WhatIsMyIPAddress.com.

For the record, I’m not off the cost of Africa and my ISP isn’t Opera Software. Here is another test searching for “restaurants” with Google:

Google is very good at approximating your location (try it) and presenting restaurant results for your area. However, with Opera Turbo it completely fails and they are forced to ask for my zip code.

There is still hope

Amazon Silk was only announced yesterday so details are still emerging. It’s possible that Amazon has a solution to these challenges. However, as demonstrated, these pre-fetching techniques can present sizable challenges for organizations that are employing personlization or content targeting on their web sites. It will be interesting to see how Amazon addresses these challenges and how the CMS industry is impacted (if at all).

Long-term, I can’t imagine these pre-fetching technique will become widespread. Mobile devices are getting increasingly more powerful and wireless broadband is becoming ubiquitous. It will only be a matter of time before page load times are a non-issue.

WYSIWYG Rich Text Editors: Your CMS’s Achilles’ heel

Gabe Sumner — Sun, 08 May 2011 15:13:22 +0000

Most of what you read online flows through web-based (browser-based) WYSIWYG Rich Text editors. These tools are central to every CMS and enable content authors, who might know little about HTML, to create HTML.

However, content authors are often baffled by the behavior of these tools. In fact, many characterize their Rich Text editor as the most fragile part of their CMS. This blog post is inspired by my research into this challenge.

Why is web-based Rich Text editing so challenging?

Web “browsers” were never designed to be MS Word.
Lack of standards around browser-based WYSIWYG editing
Each browser has a unique implementation of this functionality
Rich Text editors require many layers of ‘hacks’ to create WYSIWYG editing

** Standards are beginning to emerge through HTML5

How can Rich Text editors be improved?

Get control of the toolbar
Automatically clean pasted content
Eliminate ad-hoc usage of fonts, font sizes & colors
Eliminate tables
Use good typography
Go ‘full screen’
Use TAB for indent
Apply custom styles to the editor to create WYSIWYG
Auto-save content

Enough talk, where is a demo?

I created a demo that implements many of these recommendations:

Rich Text WYSIWYG Demo

** This demo is a work in progress. Please report any issues you discover. Some of the scripting needs refactored. I also haven’t done extensive testing for browser compatibility. Consider this demo a proof-of-concept, at this stage.

See it in action

DO NOT use font styling in your Rich Text WYSIWYG editor

Gabe Sumner — Wed, 04 May 2011 17:13:28 +0000

This web page looks the way it does because of a combination of HTML and CSS. These 2 technologies are the primary languages of the web. However, very few people who publish web content know HTML & CSS. This is okay though; very few people who drive cars can build a car.

Rich Text (WYSIWYG) editors enable content authors, who know nothing about HTML, to create HTML. However, there are good & bad practices with regard to HTML & CSS. When Rich Text editors are poorly configured these tools make it easy for unsuspecting authors to accidently ruin their web site.

Using font types, sizes, colors & background colors in a Rich Text editor will eventually ruin your web site

Most Rich Text editors (and CMS’s) enable authors to arbitrarily select new fonts, font sizes, font colors and background colors. However, these tools should not be used! In fact, these tools should be entirely removed from the toolbar.

Understanding why these features are destructive requires some basic HTML & CSS knowledge. Here is a simple example:

This is an important link.

The HTML shown above defines a web link (like this). These links are easy to create using a Rich Text editor. However, this is an important link and the font should be bigger and red. This is also easily accomplished using the font size and color features…

However, this is what these features do to the HTML:

This is an important link.

The Rich Text editor injects in-line styling directly into the HTML. This looks fine and it’s easy to understand why many authors are entirely happy with these results. Eventually, however, this in-line styling will create insidious challenges for the web site.

What will in-line (or ad-hoc) styling do to your web site?

Occasional use of in-line styling won’t create many problems for the web site. However, as the web site grows and in-line styling multiplies it creates visual inconsistencies between pages. Each time authors compose content they are arbitrarily deciding what, for example, an important link looks like.

This lack of consistency creates usability issues for web visitors. Each page in the web site is redefining the visual interface.

The other challenge arises when the visual style of the web site needs modified. This might be due to a simple redesign, or it might be needed to adapt the web site to a new form factor (phones, tablets, etc.). When styling is injected directly into the content it becomes extremely difficult to modify.

Using pre-defined styles will make authors more productive and produce better results

Instead of arbitrarily sprinkling ad-hoc styling through the web site, authors can work with web developers & designers to establish a menu of pre-defined styles. Once established, these styles can be used by authors to style content:

Behind the scenes, the Rich Text editor is applying pre-defined class styles to the content.

This is an important link.

In this example, the “ImportantLink” class was pre-defined. The styling associated with this class (font size, color, type, weight, etc.) is defined outside the web content. This class could be used thousands of times and, if it needed restyled, modified in a single place.

The pros of pre-defined styles vastly outweigh the cons

Pre-defined styles take some extra time (initially) to define. In addition, content authors might feel limited when they encounter new scenarios for which pre-defined styles do not exist.

However, once established, pre-defined styles are easy to use, produce rich results, and create a consistent visual experience throughout the web site. Furthermore, these styles can be easily adapted by web developers & designers if needed.

Long-term, web site management will be much easier when in-line styling is avoided.

Modifying the width of the CKEditor Styles dropdown

Gabe Sumner — Sun, 01 May 2011 22:51:26 +0000

CKEditor comes included with a handy-dandy style selector:

Unfortunately this style selector defaults to a very small width. This small width can result in larger styles being truncated:

Thankfully this can be fixed with a couple of custom styles:

div.cke_panel.cke_ltr.cke_rcombopanel { width: 300px !important; }
span.cke_rcombo span.cke_styles a span span.cke_text { width: 150px; }

Where should these styles be put?

For my own project, I was using the contentsCss setting to apply a set of custom CSS styles to CKEditor. Consequently, I simply put the styles shown above in this file.

However, these styles could also be put in the Editor.css file for the skin being used by CKEditor. (The default skin is the Kama skin.)

Lastly, it’s possible these styles might not work with other (non-Kama) skins.

Best of luck!

Create a Rich Text editing experience that authors won’t avoid

Gabe Sumner — Thu, 28 Apr 2011 13:19:55 +0000

WYSIWYG Rich Text editors are central to every CMS. These tools enable content authors, who might know nothing about HTML, to create HTML content.

However, content authors frequently fear and avoid their CMS’s rich text editor. These tools are perceived as confusing, buggy & fragile. As a result, content is written off-line, using tools like MS Word, and then pasted into the CMS’s Rich Text editor. Unfortunately, this behavior creates a completely different set of challenges.

This post is devoted to reshaping this behavior. The goal is to lure content authors away from their trusty off-line tools and instead use their CMS to compose new content. Below are some recommendations for creating a more friendly web-based authoring experience.

1. Use good typography

Many Rich Text editors use extremely hostile fonts & font sizes. No content creator is going to spend an hour writing content in an editor that makes them squint.

Readability is a problem, in general, on the web. In fact, there are applications devoted solely to transforming the web into a readable format. The same principals used to create legible web sites, can also be used to create a pleasing authoring environment.

2. Go ‘full screen’ for distraction free writing

In most CMS’s, the Rich Text editor occupies a very small portion of the screen. This is appropriate for small content touch-up’s, but completely undesirable for extended writing sessions (like this article).

It’s frustrating to edit a 4-page article and only see 2 paragraphs at a time. It’s even more frustrating when most of the screen is completely unused.

Most Rich Text editors (TinyMCE, CKEditor, RadEditor) have a full-screen feature that can be added to the toolbar. By using this feature authors can easily toggle into (and out-of) full-screen mode.

3. Wrap long-lines of text for readability

A single line of text should not be wider than 65-70 characters. Anything longer will be difficult to read. This rule is well known in typography, but often ignored in Rich Text Editors.

This problem is particularly noticeable with full-screen mode, or any CMS that occupies the entire width of the screen. Thankfully custom CSS styles can be applied to the Rich Text editor and establish a width to wrap text.

Here is an example of ‘full screen’ edit mode with comfortable word-wrapping:

4. Use the TAB key to indent lists

Outside of the web-world, the tab key is used to indent a list item. (Shift-tab is used to out-dent a list item). However, on the web the TAB key moves to the next field in a web form. These 2 conflicting conventions are at war in Rich Text editors. As a result, authors are frequently frustrated that a familiar convention (TAB to indent) sends them somewhere else in the web page.

Rich Text editors (TinyMCE, CKEditor, RadEditor) have an option for capturing the TAB key and modifying the behavior. However, web savvy users are going to be equally frustrated if their browser’s traditional TAB behavior is modified.

My advice, modify the behavior of TAB when authors switch into ‘full screen’ mode. In this mode there are no other web form fields. Consequently, no one will be using the TAB key to move to the next field. When ‘full screen’ mode is switched off, restore the traditional web-behavior of the TAB key.

5. Auto-save to protect against computer mishaps

Imagine the unimaginable happens…

Authors are lured away from MS Word in favor of web-authoring tools. These tools create a comfortable authoring environment and they forget they’re on a web page. Instead, they are purely focused on writing.

An hour passes and the author clicks Save…

This error will quickly cause authors to regain their fear of web-based authoring tools and retreat to predictable off-line environments. In MS Word, even if power is entirely lost, the content is typically recoverable.

On the web this level of auto-recovery is also possible by periodically saving the editor’s state. This can be done through…

HTML5’s off-line storage
Browser cookies – beware limitations
Server-side – through web services or the CMS

Realistically, #3 is the path most projects will pursue. However, this will require developers to invent a storage & recovery solution. To my knowledge, no Rich Text editor offers a canned solution to this challenge. However, there are likely CMS products that have implemented this feature.

Parting words…

Microsoft Word has been around since 1983. It’s unreasonable to think that a blog post with a few tips could prescribe a full alternative to this software. Like it or not, MS Word will continue to be an enormous force behind the content that finds its way online. Accept it and learn to cope with it.

However, it’s also true the Rich Text editors (and CMS’s) frequently make UI decisions that are downright hostile to content authors. These systems work great for developers (who are pasting “Lorem ipsum” sample text all day), but create poor experiences for extended writing sessions. It’s little surprise authors actively avoid them.

Hopefully the recommendations described above will help repair some of this damage. In addition, I’ve attempted to put many of these recommendations into practice in the following sample (give it a try):

Try It! – Best Practice WYSIWYG Rich Text Editor

Copy from MS Word, Paste into a Rich Text WYSIWYG editor

Gabe Sumner — Tue, 26 Apr 2011 13:21:02 +0000

This title will send chills up the spine of web developers & content authors everywhere. Web Developers fear the bloated markup caused by this action. Content authors fear the difficulty of mixing their favorite authoring environment with their CMS’s editor.

Why is copy & paste a problem on the web?

The problem isn’t copy & paste. The problem is WHAT is being copied & pasted.

Plain text (content without any styling) is completely safe to paste into a Rich Text editor. However, rich text content consists of 1) text and 2) styling.

This sentence has a bolded word.

In this example, my Rich Text editor added hidden markup around the word “bolded”. This markup instructs the web browser to apply special styling. If this content is copied & pasted into another program then this hidden styling is included.

And despite what you think, this isn’t what you want…

MS Word is not good at creating web sites

There are plenty of choices for accessing the web (PC, Mac, phones, iPad, IE, Chrome, Firefox, Opera, etc). Ideally, a web site needs to function reliably in all of these environments.

To address this challenge, web developers establish styling for the entire web site. This styling, in addition to creating a consistent visual experience, enables the web site to be adapted for each device or browser.

By importing styling from MS Word authors are circumventing their web site’s styling.

As a result, styling that worked wonderfully in one environment (MS Word) will behave very poorly in another environment (your web site). Even if it looks okay during publishing, this imported styling will create insidious long-term issues for the web site.

What’s the solution to copy & paste?

As described above, the embedded styling (found in copy & pasted content) is the problem. Consequently, the solution is simple and obvious:

Copy the text, but remove the styling.

Towards this end, special ‘paste’ buttons are popular with many Rich Text editors:

However, this is a ridiculous waste of toolbar real estate. The Rich Text editor should automatically clean pasted content. The alternative is educating end-users regarding which of these 8 buttons they should click.

All major Rich Text solutions (TinyMCE, CKEditor, RadEditor) have options for automatically cleaning pasted rich text content.

This solution has a downside though:

When styling is removed the content will look radically different. This requires content authors to reapply missing styling within the Rich Text editor. By doing this, authors are replacing MS Word styling with web friendly styling.

This solution is unrealistic, content authors will revolt

Everything I’ve written is well known to developers. Furthermore, features for automatically detecting and cleaning dirty content are widely available.

However, these features are often disabled in the face of user revolt.

It’s normal for content authors to react negatively when their nicely formatted MS Word document turns to garbage in the CMS. These reactions are given credibility since their actions worked fine in another CMS or Rich Text editor.

So…just disable the feature that strips MS Word styling and make them happy…

This will eventually ruin the web site, but the customer is always right. Right?

Is Clippy the solution to our problems?

This post has now come full circle and we’re no closer to a real-world solution:

Developers remove pasted styling to protect the web site
Authors create content in their preferred writing environment.
Authors want to move this content to the web site.
Copy & paste is a logical choice.
Authors are confused when everything goes to hell.
Authors complain to developers.
Developers allow pasted styling to make authors stop complaining.

However, as I look over this cascade of events, I see an opportunity for intervention at stage #5. Education (as much as technology) is the problem.

To address this, here is what I propose:

I was chatting with a colleague about this dilemma and showed him this mockup. He replied with “you want Clippy” and then smiled. This reply severely shook my faith in my proposal. I certainly have no desire to interact with Clippy…

However, there is a lot I like about this proposal:

It doesn’t involve an animated character
It empowers authors to make their own choice
It educates authors about the consequences
It only displays when relevant
It contains useful information
It will go away

None of these things could be said about Clippy.

If you build it, they will come!

Everything described happens because authors avoid writing content in their CMS’s Rich Text editor. The hacky style stripping & modal windows are completely unnecessary if authors simply type the content in the CMS.

Towards that end, I’m very interested in creating an attractive web-based authoring experience. Why are authors avoiding web-based authoring tools in favor of off-line tools? How can we change this behavior?

There are some big players (Google Documents, Word Live) that are also wrestling with this challenge. This topic is covered in another post.

Unclutter your Rich Text Editor’s toolbar– Essential vs. Useless Features

Gabe Sumner — Sun, 24 Apr 2011 15:50:57 +0000

WYSIWYG Rich Text Editors (like TinyMCE, CKEditor, RadEditor, etc.) are central to how content gets into a CMS. These tools enable content authors, who know nothing about HTML, to create HTML. However, these tools are notoriously fragile, buggy and confusing to non-technical authors.

There aren’t any perfect answers to this challenge, but a helpful strategy is to disable unneeded features that are cluttering the Rich Text editor’s toolbar. This is a minor task that creates a vastly improved authoring experience.

At best, these unneeded features confuse content authors & encourage bad practices. At worst, these features will cripple the web site. Identifying (and removing) unnecessary Rich Text features creates a friendlier, safer and more predictable content authoring experience.

Essential Rich Text (WYSIWYG) features

Lists
- Unordered, Ordered
- Indent, Outdent
Links
- Insert & Remove
Images
- Upload, Resizing
- Alignment
Styling
- H1, H2, H3
- Paragraph
- Bold, Italics

Optional Rich Text (WYSIWYG) features

More styling…
- H4, H5
- Blockquote
- Preformatted
- Pre-defined custom styles
Spellcheck
Special Characters
Page break
Full-screen edit mode

Unnecessary Rich Text (WYSIWYG) features

Copy & paste operations should be handled (and cleaned) automatically:
- Clear Formatting
- Paste from Word
- Paste as Plain Text
Styling with limited use-cases, disable to create a less cluttered toolbar
- Strikethrough
- Horizonal rule
- Subscript
Features that clutter the toolbar and are never used:
- Find
- Word count
- Date/time
- Print

Inappropriate or dangerous Rich Text (WYSIWYG) features

Any feature that generates in-line CSS styling
- Colors
- Sizes
- Font types
- Background colors
- Left & right alignment
- Centered
- Justify
- Layers
Any features that encourages content authors to do advanced HTML development:
- HTML mode
- Form elements
  - Textboxes, checkboxes, buttons, etc.
Any feature that encourages authors to create ugly or confusing end-user experiences:
- Emoticons
- Underline – this is reserved for links on the web.

What am I missing?

What are your experiences? Are some of these “unnecessary” options essential for your organization? Why? What have you done to create a friendlier (and safer) Rich Text editing experience?