Xinha and the Future of Rich Text Editing

mharrisonline · 2006-04-19 06:17:51

There is an interesting article online about WYSIWYGs by Jakob Nielsen at

http://www.useit.com/alertbox/wysiwyg.html

He talks about the move to results oriented GUIs and how the new paradigm will be What You Get Is What You See, or WYGIWYS. He points to the uncluttered toolbar of the next version of Microsoft Word (Office 2007) as an example of giving people results of how something should look instead of primative tools to create it themselves; with the warning that users always demand that interfaces work like Microsoft Office.

The next version of Office is shown at http://www.microsoft.com/office/preview … rview.mspx with a fullsize screen shot of the Word GUI at http://www.microsoft.com/library/media/ … 00x600.jpg .

In this area there are some ways that Xinha has fallen behind other editors, and some ways that Xinha leads the pack.

Some editors such as FCKeditor have adopted dropdown menus that display what the heading, font, and font size will look like. It would be easier to use Xinha if it did this too, and it results in a more pleasing GUI.

Xinha's GUI is more advanced than many other editors because of its panels, which have been put to very good use with many plugins like Stylist, etc.

How could Xinha maybe be much better, other than WYSIWYG dropdown menus?

The biggest complaint that I hear about XINHA is how cluttered, scary, and confusing the toolbar gets once you start adding plugins. How about a toolbar overhaul, in the style of Word 2007? OK, I'm not a big Microsoft fan either, but once you look at the screenshot of the Word 2007 toolbar, you'll see what I mean. And why not be the first WYSIWYG to look the way people will expect WYSIWYGS to look next year? It would add great "first-to-market" value and appeal to any CMS using XINHA.

What if we first classified every toolbar button, and every plugin into a group. That should be easy, since the plugins already set what button they come after, etc. Visible or hidden by default could be a configuration that could be optionally set on the page with the default in the plugin's js file.

Then, what if we built the Xinha toolbar to be similar to the Word 2007 toolbar with tabs for each tool group. So, you could have a tool group for media and include ImageManager, NoteServer, Marquee, etc.

Maybe some buttons and plugins could be set to be hidden by default and require the user to click on a down arrow to see them. So, if you didn't want to show your users right away NoteServer, Equation, or all the possible types of form elements they could insert, they could be configured to be part of the hidden area of that tool group's tab.

So, each tab could be a span or div set up like its own toolbar and could consist of three sections that would be enclosed in a bordered area. The top section would contain the buttons you want to always have set as visible, the middle section could have a default display:none and contain buttons that you think would scare most users, and the bottom could contain a text label and a down arrow. Clicking on the down arrow would set the middle area to display:block, and replace the arrow with an up arrow. There could be a timeout that would eventually re-hide the middle area after the user mouses away from the tab.

We could even make the dropdown backgound area have an optional 85% or 90% alpha value, to have the modern glassy look users will expect after Vista comes out.

The "Results Oriented" toolbar Jakob Nielsen talks about could be partialy obtained if the template and snippets plugins used the side panel.

What do you think? Hate the idea, love the idea, don't care? Why not push all the non-critical open 1.0 tickets to 2.0, release Xinha 1.0, and start modernizing the GUI for Xinha 2.0?

Last edited by mharrisonline (2006-04-19 06:37:07)

waving · 2006-04-20 02:14:52

I agree that a good interface design is key. Xinha is the most feature complete WYSIWYG editor I know, I love it, except for the clutter.
Some plugins like the table operations and the forms plugins have a lot of icons. It would be a huge improvement if these were dropdown menus.
More control over the placement of (plugin) icons would be a welcome addition too.

Having a userinterface that looks the same as word. I don't know about that. Xinha is also used on other platforms. Microsofts user interface design may not be the holy grail. I like to have the ability to change the look of the interface to match my cms design.

Last edited by waving (2006-04-20 02:20:23)

mharrisonline · 2006-04-20 02:58:12

I think it would be great if it was a config choice to choose between toolbar types, rows or tabs.

Xinha moved ahead some time ago from the Windows 95 grey look to a more XP look when it adopted Word - style icons for its buttons, and offers the blue background skin that looks like Word. The CSS no longer uses the old shadow borders, it highlights just like the Word toolbar. This isn't just Windows-centric, every other OS had already "prettified" their GUIs long before Windows got the ugly out.

Next year the very structure of Xinha's toolbar will make it look dated, something that a new CSS file alone won't be able to fix. Worse, the structure of the toolbar will present a dated clutter that already makes a partly-loaded Xinha intimidating to users that aren't Web developers. Next year users will look at editors like Xinha and say they aren't as user-friendly as they need to be, because of cluttered toolbars.

I already run into this, constraints on presenting "too much functionality" to the user, which ultimately cripples the tool for the power user and micro-manages away the ability for creative users to innovate, yet limiting button selection makes it a usable toolbar for the computer-challenged. We need the ability to hide buttons that most users don't need to see, and make them available to those that need them.

Last edited by mharrisonline (2006-04-20 03:07:14)

ray · 2006-04-20 19:09:42

I fully agree with you. It would be great if we could push xinha really at the peak of UI design fashion!

mharrisonline wrote:

I think it would be great if it was a config choice to choose between toolbar types, rows or tabs.

Here i would like to propose to go even farther and establish a plugin concept for the toolbar. In the moment the toolbar is anchored in the frame work which is quite unflexible. There were recently several threads in the forum about using one toolbar with several editors. another thing I was working on is no toolbar but only a context menu with all options. another possibility is a floating toolbar like in photoshop.

What I want to say is that there is, apart from the very good ideas you had how the tb could be organized, a range of ways a developer could want to implement the user interface.

So my idea is that the xinha core only implements the blank iframe and provides an object with all the icons and functions etc. for the toolbar (like there is already). Then there would be plugins that take the object and implement the actual representation of a toolbar or context menu or dropdown or whatever

mharrisonline · 2006-04-21 01:45:58

That would be sweet. Then, the way the toolbar would be manifested could be controlled by which toolbar plugin is called on the specific page.

I've always thought it would be really cool if Xinha could be put over an entire content page, no borders, if someone had editing rights. Xinha would be in a div with display:none until the user doubleclicks on the content, then the content would suddenly be in Xinha, looking pretty much as it did on the page, with a floating toolbar, or all the buttons in a side panel.

ray · 2006-04-21 04:40:43

right, right. Have a look at this working study I did http://foh.spilles.de/XinhaFD/ (click edit and use the context menu)

mharrisonline · 2006-04-21 22:38:58

Nice, how do you get out of HTML mode though? Unfortunately I have to support IE and eventually Safari, in addition to Firefox. I guess inline editing will probably work in Safari before it works in IE.

steveo125 · 2006-04-24 04:10:05

The office stuff does look cool, and yes all the menu options in Xinha even confuse me sometimes. I'm not a designer but would be keen to see a 'modern' menu layout. Was thinking it may be possible to make the style panel into a floating window so you can position it where you want instead of within the text area. Kind of like the detachable menus in macromedia studio apps.

gogo · 2006-04-29 09:31:03

I havn't posted here much lately (ok, for quite a while) because I just havn't had time to work on Xinha Have a project coming up though that might allow me some time for the X (actually, I really want to get it working in Opera 9 now it's in beta -- I use Opera almost exclusively nowadays).

Anyway, a toolbar cleanup has always been "on the books", for the simple reason that plugins adding buttons to toolbars is completely haphazard at the moment. Like you say, I would like to see set named groups of toolbars which plugins can, well, plug into; I think I've mentioned this either in a post here or in a ticket before. I think this could be achieved without too much trouble because we already have toolbar groups in a fashion, they just are not named.

The styled-selects for fonts etc is something I've wanted for a while. A friend of mine was working on it for a while but never was able to get it to work quite right cross-browser.

As for tabs of buttons, I think the panels system could be used in this regard, perhaps even a plugin which replaces/extends the existing toolbar creation with a panels-based one.

I have reservations about that new Word toolbar screenshot, personally, I don't like it. But then I'm a programmer, not a joe bloggs who actually uses Xinha, so I'm not the best person to design the toolbar.

gogo · 2006-04-29 09:47:22

As for floating toolbars, I don't know about that, I don't think they would be very nice to use in a web application, not really suited to them IMHO. One toolbar to control many editors is something that comes up quite often, I seem to remember somebody was working on it but who escapes me. Just thinking about it now, the easiest way of doing that would be to just hide the toolbars (display:none them), move them to a single toolbar div (specified in config) and when an editor is activated set display:block on the correct toolbar (and display:none on the previously shown). That should work now I think with very minimal changes. I think.

mokhet · 2006-04-29 11:05:40

gogo wrote:

actually, I really want to get it working in Opera 9 now it's in beta

http://mokhet.com/xinha/examples/full_example.html

This is my first attempt to make Xinha work under Opera9 beta 2, and i'm quite satisfy right now. Still a lot of issues but there is only a few lines to change to make it work

1) browser identification
(issue : this is a bad way to detect feature, we should check for objects instead of something not reliable like useragent, anyway ...)

HTMLArea.is_opera  = (HTMLArea.agt.indexOf("opera") != -1);
// wrong way to find if it's opera9, but needed
// until we change the behavior of checkSupportedBrowser()
HTMLArea.is_opera9 = false;
if ( window.opera && (/Opera\s?\/([0-9])/.test(navigator.userAgent)) )
{
  if ( parseInt(RegExp.$1, 10) >= 9 )
  {
    HTMLArea.is_opera9 = true;
  }
}

2) update checkSupportedBrowser()
(issue : still a bad way to detect stuff, we should give up on useragent detection)

// FIXME!!! this should return false for IE < 5.5
// @todo : this should check for objects existence and NOT on useragent strings
HTMLArea.checkSupportedBrowser = function()
{
  if ( HTMLArea.is_gecko )
  {
    if ( navigator.productSub < 20021201 )
    {
      alert("You need at least Mozilla-1.3 Alpha.\nSorry, your Gecko is not supported.");
      return false;
    }
    if ( navigator.productSub < 20030210 )
    {
      alert("Mozilla < 1.3 Beta is not supported!\nI'll try, though, but it might not work.");
    }
  }
  if ( HTMLArea.is_opera9 )
  {
    alert('Support for Opera 9 is still in beta stage and everything is still not totally supported');
  }
  return HTMLArea.is_gecko || HTMLArea.is_ie || HTMLArea.is_opera9;
};

3) update HTMLArea.prototype.generate
(issue 1 : I cant manage to have HTMLArea._addEvent(this._frame, 'load', ... to work, so i changed it to this._iframe.onload)
(issue 2 : In actual changeset the event is set after the src, as a result the event is never started at least with opera, cant understand why it is working with others browsers, anyway, just setting the src after we have set (not before) the event and the issue is gone)

    // create the IFRAME & add to container
  var iframe = document.createElement("iframe");
  // Add an event to initialize the iframe once loaded.
  // MUST BE SET BEFORE THE IFRAME SRC ATTRIBUTE IS SET
  editor._iframeLoadDone = false;
  // @warn : cant make the _addEvent(iframe, 'load') work on Opera 9
  // @todo : check if iframe.onload is enough for IE to start Xinha
  iframe.onload = function(e)
  {
      if ( !editor._iframeLoadDone )
      {
        editor._iframeLoadDone = true;
        editor.initIframe();
      }
      return true;
  };
  iframe.src = _editor_url + editor.config.URIs.blank;

4) update HTMLArea.prototype.activateEditor and the same goes for HTMLArea.prototype.deactivateEditor
(issue : once again, we rely on useragent and not on objet detection)

HTMLArea.prototype.activateEditor = function()
{
  // We only want ONE editor at a time to be active
  if ( HTMLArea._currentlyActiveEditor )
  {
    if ( HTMLArea._currentlyActiveEditor == this )
    {
      return true;
    }
    HTMLArea._currentlyActiveEditor.deactivateEditor();
  }

  if ( ( HTMLArea.is_gecko || HTMLArea.is_opera9 ) && this._doc.designMode != 'on' )
  {
    try
    {
      // cannot set design mode if no display
      if ( this._iframe.style.display == 'none' )
      {
        this._iframe.style.display = '';
        this._doc.designMode = 'on';
        this._iframe.style.display = 'none';
      }
      else
      {
        this._doc.designMode = 'on';
      }
    } catch (ex) {}
  }
  else if ( !HTMLArea.is_gecko && !HTMLArea.is_opera9 && this._doc.body.contentEditable !== true )
  {
    this._doc.body.contentEditable = true;
  }

  // We need to know that at least one editor on the page has been activated
  // this is because we will not focus any editor until an editor has been activated
  HTMLArea._someEditorHasBeenActivated = true;
  HTMLArea._currentlyActiveEditor      = this;

  var editor = this;
  this.enableToolbar();
  return true;
};

And that's it, the first beta version working on Opera9 beta 2

Despiste ALL the bugs all around I hope you'll like this first attempt

mharrisonline · 2006-04-29 15:45:44

I wonder what it would take to get Xinha working in Safari...

Styled selects work for fonts, font sizes, and font format in Mozilla but not IE, for cross browser it would have to be something like a div that normally has a display:none, or something like that, with all the selections written in. IE pretty much only allows you to change background color for individual selects.

I think replacing the toolbar with a panel would be really cool. If you weren't actually clicked into a table, you wouldn't need to see any of the ghosted table operation buttons, etc.

Last edited by mharrisonline (2006-04-29 15:54:55)

gogo · 2006-04-29 22:04:58

mokhet wrote:

http://mokhet.com/xinha/examples/full_example.html
This is my first attempt to make Xinha work under Opera9 beta 2, and i'm quite satisfy right now. Still a lot of issues but there is only a few lines to change to make it work

A while ago I created a fork in the SVN for initial Opera compatability - you can check that out (/branches/opera) to see what changes I've made in that; but this was for the first preview release so may not work in the Beta.

1) browser identification
(issue : this is a bad way to detect feature, we should check for objects instead of something not reliable like useragent, anyway ...)

Yes.... to an extent. But when you have to work around browser problems/differences you really need to know, "is this IE in quirks mode" or "is this Opera version xxx with the yyy bug" - you can't just look to see if a certain feature is there sometimes.

matte · 2006-07-26 08:42:40

TWO BIG QUESTIONS about XINDA>

1) You wrote: <<This is my first attempt to make Xinha work under Opera9 beta 2, and i'm quite satisfy right now. Still a lot of issues but there is only a few lines to change to make it work>>

I am using Opera 9 build 8502. Your demo page doesn't work at all. There has been a lot of dsicussion of Opera support for over a year, particularly by gogo, the lead developer. Has it happened? Is there a working demo?

2) Since this thread started discussing toolbars, let me also ask about what +can and cannot be done (the FAQs on the wiki are of little help). Can I easily configure the toolbars to a small feature set most used can deal with, without being overwhelmed? Is there a sample page with some configurations already setup? This would be a big timesaver.

gogo · 2006-07-26 23:30:34

matte wrote:

I am using Opera 9 build 8502. Your demo page doesn't work at all. There has been a lot of dsicussion of Opera support for over a year, particularly by gogo, the lead developer. Has it happened? Is there a working demo?

Not yet, feel free to contribute.

2) Since this thread started discussing toolbars, let me also ask about what +can and cannot be done (the FAQs on the wiki are of little help). Can I easily configure the toolbars to a small feature set most used can deal with, without being overwhelmed? Is there a sample page with some configurations already setup? This would be a big timesaver.

In Step 3 (see NewbieGuide in the wiki) you can control the toolbar. Edit as you desire

  xinha_config.toolbar =
  [
    ["popupeditor"],
    ["separator","formatblock","fontname","fontsize","bold","italic","underline","strikethrough"],
    ["separator","forecolor","hilitecolor","textindicator"],
    ["separator","subscript","superscript"],
    ["linebreak","separator","justifyleft","justifycenter","justifyright","justifyfull"],
    ["separator","insertorderedlist","insertunorderedlist","outdent","indent"],
    ["separator","inserthorizontalrule","createlink","insertimage","inserttable"],
    ["separator","undo","redo","selectall","print"], (HTMLArea.is_gecko ? [] : ["cut","copy","paste","overwrite","saveas"]),
    ["separator","killword","clearfonts","removeformat","toggleborders","splitblock","lefttoright", "righttoleft"],
    ["separator","htmlmode","showhelp","about"]
  ];


   xinha_config.fontname = {
    "&mdash; font &mdash;":         '',
    "Arial":       'arial,helvetica,sans-serif',
    "Courier New":       'courier new,courier,monospace',
    "Georgia":       'georgia,times new roman,times,serif',
    "Tahoma":       'tahoma,arial,helvetica,sans-serif',
    "Times New Roman": 'times new roman,times,serif',
    "Verdana":       'verdana,arial,helvetica,sans-serif',
    "impact":       'impact',
    "WingDings":       'wingdings'
  };

   xinha_config.fontsize = {
    "&mdash; size &mdash;"  : "",
    "1 (8 pt)" : "1",
    "2 (10 pt)": "2",
    "3 (12 pt)": "3",
    "4 (14 pt)": "4",
    "5 (18 pt)": "5",
    "6 (24 pt)": "6",
    "7 (36 pt)": "7"
  };

   xinha_config.formatblock = {
    "&mdash; format &mdash;"  : "",
    "Heading 1": "h1",
    "Heading 2": "h2",
    "Heading 3": "h3",
    "Heading 4": "h4",
    "Heading 5": "h5",
    "Heading 6": "h6",
    "Normal"   : "p",
    "Address"  : "address",
    "Formatted": "pre"
  };

matte · 2006-07-27 09:01:43

Thanks for that. That helps

Ok, so Opera is still not supported. Might others tell me what editor they offer their opera users, if they also offer xinha to everyone else? Or do they just tell Opera users they are out of luck.

I will never understand why opera is out there on its own so often. Since so many love it, can't Opera do something ot make it a bit more compliant with the rest? This has been going on for years. This is like the beta/vhs problem on steroids.

gogo · 2006-07-28 08:53:18

Opera is very compliant in my general experience, right up there with Firefox, infact, better in many regards. However the editing systems we (and every other WYSIWYG editor) use in Xinha are not part of any standard, each browser implements it in thier own only mildly similar ways.

For Opera, I don't know if any of the competition has made thier stuff work with it yet. It shouldn't take toooo much work to get it working in Opera, I've already demonstrated that in the Opera branch (you can check this out, it worked in one of the pre-release Opera's, I don't know if it still does), all be it with opera identifying as Mozilla.

Xinha Discussion Forum

Announcement

#1 2006-04-19 06:17:51

Xinha and the Future of Rich Text Editing

#2 2006-04-20 02:14:52

Re: Xinha and the Future of Rich Text Editing

#3 2006-04-20 02:58:12

Re: Xinha and the Future of Rich Text Editing

#4 2006-04-20 19:09:42

Re: Xinha and the Future of Rich Text Editing

#5 2006-04-21 01:45:58

Re: Xinha and the Future of Rich Text Editing

#6 2006-04-21 04:40:43

Re: Xinha and the Future of Rich Text Editing

#7 2006-04-21 22:38:58

Re: Xinha and the Future of Rich Text Editing

#8 2006-04-24 04:10:05

Re: Xinha and the Future of Rich Text Editing

#9 2006-04-29 09:31:03

Re: Xinha and the Future of Rich Text Editing

#10 2006-04-29 09:47:22

Re: Xinha and the Future of Rich Text Editing

#11 2006-04-29 11:05:40

Re: Xinha and the Future of Rich Text Editing

#12 2006-04-29 15:45:44

Re: Xinha and the Future of Rich Text Editing

#13 2006-04-29 22:04:58

Re: Xinha and the Future of Rich Text Editing

#14 2006-07-26 08:42:40

Re: Xinha and the Future of Rich Text Editing

#15 2006-07-26 23:30:34

Re: Xinha and the Future of Rich Text Editing

#16 2006-07-27 09:01:43

Re: Xinha and the Future of Rich Text Editing

#17 2006-07-28 08:53:18

Re: Xinha and the Future of Rich Text Editing

Board footer