Council Spotlight: What would you want a Content Editor to be like?


First thing's first; please read this post from Peter Laker (this explains the forward movement to dreaming up a new community platform):

We're continuing our discussion with the community about the migration process and the new platform. We're building on our last two related discussions:

There are many different topics to chat about, and this one came to mind, based on a comment from .paul:

  • "I think we should concentrate on getting the quality of the wiki editor... before anything else…"

That's right. It's a very important topic, and we should have led with that before PMs. So now we're getting to it!! ...

What would you want a Content Editor to be like?

Here's what the Wiki Editor looks like:

I happened to have it open on another tab (Wiki Ninjas Blog Authoring Schedule - 2018) so that's our image!

It's funny; I had one person go on and on about what the Wiki Editor should be like instead. I said, "I agree. We've had all those requests out for years." "Oh." -- Lots of conversations go that way.

So nobody built the Editor as the perfect system. We started with an Editor that we got by default with the platform back in early 2010. By mid 2010, the Wiki's PM (Eric B) got a new editor implemented. That editor worked fantastic on the website where we played with the prototype, but then when it was implemented, it actually solved very little. So the problem wasn't with the toolbar and editor. The problem was with the limitations of how the platform could interpret what the editor was trying to create and format. That's what limited it.

With that in mind, we'd hope to take a fresh approach to what a community-authoring editor should look like!

Please answer the question (and the following related questions) in the comments below.

  1. Should the Editor be more limited? For example, you might have one available default font and font size (with no font color or highlighting). Would that be beneficial or just a limiting pain? What would you want to limit like that? Would you remove strike through and underlining? This next question is related...
  2. What would you want to keep in the Editor? (Such as Bold, Italics, Bullets, Left/Center/Right Justify, Indent, Insert/Edit Link, etc.)
  3. How should the Editor handle tables?
  4. How should the Editor handle Code Snippets?
  5. How should the Editor handle images and embedded videos? 
  6. How should the platform handle External Links? Currently the Wiki automatically flags links that go to external (non Wiki) locations. It also opens up those URLs in a new tab. That way it promotes and expects navigation on the Wiki. If the platform as a community section on Docs, would you expect it to have similar behaviors (where it flagged links that take you off of Docs and opened those links in a new tab)?

 

Please drop your answers in the comments below, and I personally want to thank all of you for the impact you've had on the community!

- Ninja Ed

Comments (13)

  1. Dave Rendón says:

    Handle drag and drop images, also import from external source, github markdown integration

    1. Drag and drop images would be cool! What platform does that now? Not this WordPress one. =^)

      I just did that on Skype. That’s fun. It’s so much easier.

      What would the import be like? Like from a Word file? Couldn’t you just copy and paste it in? I’d love to paste an image in and have it instantly get attached for upload. That would be great.

      Well GitHub Markdown would be part of the platform. It would exist on GitHub, like Docs.Microsoft.com does now.

      Thanks, Dave!

  2. pituach says:

    Very important question and it’s definitely a good opportunity to influence the future. I thought for example about a nice feature that we need… I want that each time I click the save, a hot coffee will jump out of the screen while I am waiting 🤣

    Well… to be more serious, we need to remember that WYSIWYG editors including the Wiki and forum editors, are based on the built-in ability of the browser

    * which is why each browser creates different HTML code. For example, some browsers use <strong> for bold text while others use the tag <b>. Any request must fit all common browser, or we will get different behaviors. We cannot just open the question to any wild idea 🤔

    1. You want coffee while you wait for it to save?

      How about faster saving and loading times instead? =^)

      We’ll make sure it doesn’t work on your favorite browser. =^)

      You’re right. That will limit what is possible, but we can still see what everyone would want out of the editor. Thanks, Ronen!

      1. pituach says:

        Faster saving should be the goal 🙂
        The coffee is only he tools

        There is no reason and in my opinion no sense in limit the type of browsers.

        Unfortunately, there is no way to make sure the result is exactly the same in all browsers, since each browser uses its own text rendering engine parsing differently the keyboard’s clicks and the text that we type.

        I mentioned for example the difference in bold text, but this is only one example. In fact the most problematic issue in the Wiki regarding the way browsers parse the text is the differences in implementing paragraph vs line-break. While chrome uses paragraph <p> by default IE uses line break <br> .

        It is a bit complex but these differences can be fixed with JS. For example with simple JS you can replace all bold tags to the same one so not mater what browser you use the client code is the same… I am not sure this is something that we souldfocus on, when there are much more important issues/needs

        * by the way, I AM USING ONLY CHROME, since it has a portable version which you can execute without installation, directly from Disk-On-Key. I usually prefer portable versions which is why I prefer SOS over SSMS as well (and since it fit Linux at the same time).

  3. This is very nice blog Ed and please see my opinion on your questions,
    Should the Editor be more limited? [As per my opinion editor functionality should be globally unique but if we set this based on user profile, for example user set their default editor functionality, their default font and font size or color then all articles will different.]
    What would you want to keep in the Editor? [Font design should be their as it is, because sometimes, we’ll mark point to bold or Italics based on topic, so my suggestion we should have this as an editor.]
    How should the Editor handle tables? [Table Wizard is great in TechNet Wiki and I used this multiple times, so not sure if can have different thing.]
    How should the Editor handle Code Snippets? [Code snippets should be based on programming lang and should be browser compatible.]
    How should the Editor handle images and embedded videos? [This is the major challenge to handle images and embedded videos, for image, it should take any length or size but auto crop or auto handle in Wiki platform so user shouldn’t worry about this and they can focus on content. Same for embedded video, if user upload any video then shouldn’t take much time to upload or load on browser.]
    How should the platform handle External Links? [Many time we see where external links not work after some period of time or if external server down, so for external links we can only add in another section or we can add something to indicate this is external link.]

    1. “Should the Editor be more limited? [As per my opinion editor functionality should be globally unique but if we set this based on user profile, for example user set their default editor functionality, their default font and font size or color then all articles will different.]”

      Sometimes it’s best to limit the font color and size for that reason.

      “How should the Editor handle tables? [Table Wizard is great in TechNet Wiki and I used this multiple times, so not sure if can have different thing.]”

      That’s true. I miss having the table wizard in blogs like this WordPress one. The Wiki does pretty good comparatively.

      “How should the Editor handle images and embedded videos? [This is the major challenge to handle images and embedded videos, for image, it should take any length or size but auto crop or auto handle in Wiki platform so user shouldn’t worry about this and they can focus on content. Same for embedded video, if user upload any video then shouldn’t take much time to upload or load on browser.]”

      Some cropping and resizing features would be nice. Thanks, Kamlesh!

  4. 1. The default font and font size are good. I suggest to remove the strike and keep the underlining as it is. Also, It would be better if we have an option Format painter like in the word.
    2. Format Painter
    3.Good enough
    4. Currently, the code snippets are available for some particular languages. It would be better to auto-sense (Intellisense) about the code similar to StackOverflow
    5. Agree with @Dave handling drag and drop images would be nice.
    6. The provided suggestion is good enough,

    1. “1. The default font and font size are good. I suggest to remove the strike and keep the underlining as it is. Also, It would be better if we have an option Format painter like in the word.”

      A format painter? When would you use that? I think if the font and formatting options are limited, wouldn’t that limit the need of a painter? When do you use underlining? I think there are a lot of theories between whether or not to use underline or to instead use bold or italics.

      “4. Currently, the code snippets are available for some particular languages. It would be better to auto-sense (Intellisense) about the code similar to StackOverflow”

      Meaning that instead of picking your language, it automatically determines the programming language that you’re using? Thanks Jayendran!

  5. Pete Laker says:

    I love the TechNet editor. You can just hover over an icon if you don’t know it. I find sites that don’t have such a rich set of features very frustrating after using our TNW editor for so many years. External links should always be marked as such. All links should open in a new tab, which has been the only frustration with our editor. Having to edit link details and set target to “_blank” is beyond most normal users, so they don’t do it and so you lose them from the site. I’m loving the current craze for adding related animated gifs, like Yammer does. That adds a lot with little effort, as the search/suggestions are often good ones. Yes, the save & image upload has always been a frustration, but also a spam deterrent. You should make sure you reprocess images, in case you have any hidden content being shared through your [anonymous] file sharing feature. Also, remove a user’s details from the files, which phones often add, like name and location.

  6. pituach says:

    Important!
    Something that we are asking for the last 10 years or so, and usually can be done in several minutes!

    SUPPORT FOR RIGHT-TO-LEFT (rtl) LANGUAGES

    In 2013 when Microsoft changed the editor in the MSDN forum to Telerik Editor, I decided to do the work for Microsoft team, hoping that this will finally bring the support of RTL languages to the forum. I was in-contact with the team administrator and following our discussion over emails I wrote the next blog where I explain how to implement it step by step, and I provided a full code…. It did not helped and we still dont have support for RTL 🙁
    http://ariely.info/Blog/tabid/83/EntryId/116/Adding-RTL-LTR-buttons-to-Telerik-Editor-on-DotNetNuke-System.aspx

  7. Anonymous says:
    (The content was deleted per user request)
  8. Hi Ed ,

    1. The current font & font size is looking standard ! If we add color to the font then it would be destroying the wiki article standard.
    2. We need to add extra fields like preview ( Before submission we can see the entire article preview ) & Fit to window – F12 ( This will expand and fit the editor into the current screen ).
    3. The current format is good.
    4. We need to add Java,Ruby,Pascal,etc code format in the editor.
    5. We need to change the current image upload format because it is taking too much time for uplaoding an image in the article. I think we can use the image uploader in the “https://code.msdn.microsoft.com” that would be more faster comparing to technet wiki or we can go with drag and drop approach ( This is not mandatory ).
    6. No suggestion.

Skip to main content