[Plone-UI] A TinyMCE UI proposal
ric at digitalmarbles.com
Wed Mar 24 22:18:04 UTC 2010
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:
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
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,
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?
More information about the UI