[Plone-UI] A TinyMCE UI proposal

Ricardo Newbery ric at digitalmarbles.com
Wed Mar 24 22:18:04 UTC 2010


Hi all,

Recently, I was with a colleague (Robert K) going over the process to  
add links using the TinyMCE editor and he offered several suggestions  
on how to improve the experience.  I think some of his suggestions may  
be sound so I figure I'll start this discussion with the folks most  
interested in Plone UI issues to get some feedback.

Keep in mind that this guy is totally new to the Plone UI but he's a  
very capable developer in his own right.  Also keep in mind that I've  
only started to scratch the surface of Products.TinyMCE so I'm not  
familiar enough with the code yet to decide whether all these  
suggestions are wise or even doable.

Before I go on though, I wanted to also point out that TinyMCE does  
not appear to respect the multiple text-formats setting from the  
control panels (at least in Plone 4, I haven't tested the previous  
releases).  Kupu's support also seemed a bit buggy to me but at least  
it sort of worked.


The following is a summary of the feedback from Robert K:
----------------------------------------------------------------------------

Some observations:

1) Developers describe links as "internal" or "external".  Users say  
"pages" and "URLs"... or at least those are terms they're more likely  
to understand.  But ideally you don't force them to think in either-or  
terms like this.

2) The search field is in the wrong spot for two reasons.  First,  
search fields go at the top of a page/panel, not the bottom.  Second,  
it's only functional when you've selected the "Internal" library, and  
so should either be disabled or hidden when looking at the other  
libraries.

3) That latter is true for the folder path display at the top of the  
page.  Not meaningful if I have "External" or "Mail" selected.

4) External link "preview" is not useful. Remove it.

5) Accessing the lists of anchors on the current page yields different  
results if you click Libraries -> Anchors , .vs. clicking on the  
current page in the Libraries -> Current Folder -> (current page).

6) Visually, there are too many nested borders. 2 on the panel border,  
another for the tabs, another for each section on the tab, yet another  
on whatever list/control is in the section.  (One could argue this  
deep nesting is an indication of engineers having more influence on  
the UI than UX designers.)

7) The term "Libraries" is just odd.  "External" and "Email" are  
definitely not libraries, and it's debatable whether or not the .  
"External" is listed under "Libraries"?  That's just odd.  Sure  
doesn't seem like a library. Unless you're going to present them with  
a list of external links they've already added to other pages.

Some concrete suggestions:

1) A wireframe based on the following suggestions is here,
http://docs.google.com/present/view?id=0ATjKjZDEJB0BZGZjanF2c2JfMzJjcDRtdnFmdA

2) Get rid of all the hidden UI (no more general/advanced tabs, no  
more "Libraries" to choose from)

3) Base the UI around the act of creating a "Link to" URL (which is  
what this is about, after all).  Expose this value as the primary  
field so power users can easily paste/edit if they choose to.  But  
make this field usable/useful to newbies by giving it smart behavior.

     - The default value is text that tells them what they can type in  
there or how to select a page.

     - Let the user enter a variety of common link-y type things: a  
complete URI ("http://foobar.com/fdsfsd"), an abbreviated URI  
("foobar.com"), or an email address ("fred at foobar.com").  Once they  
hit <return> or change focus, convert their entry into the appropriate  
href value.  E.g. fred at foobar.com becomes mailto:fred at foobar.com).  If  
the value isn't recognizable, indicate the error to the user (e.g.  
field gets red border, warning text appears below the field, "

4) The title and target options (previously "advanced" features) are  
exposed here, but always have reasonable defaults so the user can  
ignore them if they want.

     - The "Email subject" field is only visible when the "Link to"  
field contains a "mailto:" URL

5) Use a "Page Chooser" to allow the user to create a link by  
selecting a page/anchor.

     - Selecting a page from the page list immediately updates the  
"Link to" field with the URL for that page

     - ... ditto for selecting an anchor from the anchors list

     - When the page list is showing the contents of a folder, show  
the (clickable) path to that folder above the list.

     - When the page list is showing search results, show search term  
above the list instead of the folder path.  (And also show a "clear  
search" link that will return them to the folder list)

     - The anchors list on the right always shows all anchors on the  
currently selected page.

     - You're already including jquery... so use a decent jquery list  
widget to display the pages and links, instead of the radio-button  
based thing you've got currently..

----------------------------------------------------------------------------

So... any thoughts?

Cheers,
Ric






More information about the UI mailing list