Marius Dumitru Florea wrote:
Hi Sergiu,
First of all, thanks for the proposal. I know how busy you are. See my
notes below.
Sergiu Dumitriu wrote:
Vincent Massol wrote:
On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean
wrote:
Hi,
The last proposal for links management in the wysiwyg editor can be
found here :
http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wy…
Sounds nice. Some comments:
* The link menu items should be improved IMO:
- I would put adding an external link at the bottom since it's not
the most used one
- The labels should be improved. I don't know if "wanted page" is
obvious (it wasn't for me)
* The screenshots are missing wiki selection (for multi wiki installs)
* I'm not sure I like the wizard like approach, i.e. having to select
some value before selecting others. I think I would have preferred a
single screen but that's me only.
* It's missing the ability to specify any number of parameters (for
advanced usages)
Thanks
-Vincent
How about this interface:
http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui…
This works a bit like the way the Mac file explorer works. By default,
when creating or editing a link, the current wiki/space/document are
selected. If the user clicks on a different wiki, space or anchor, the
descending columns are cleared, and a "loading" message is displayed,
like in:
http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui…
In Guillaume's proposal the user is able to insert a link to a space
directly without selecting the WebHome page (same for a wiki, without
selecting the Main space and the WebHome page). How is this achievable
in your design? I guess there could be a button at the bottom of each
list or maybe the user could double click on a list item.
If the user selects just the wiki, without selecting a space, or just
the space, without selecting a doc, or the doc without selecting an
anchor, then the default is used: Main.WebHome, Space.WebHome, no
particular anchor. (Note that 'Main' and 'WebHome' can be customized, so
be sure to use the proper API instead of hardcoded strings)
And yes, at the bottom are buttons, I didn't add them to save time, and
because I thought they are obvious.
For links to
non-existing documents ("wanted"), under spaces and
documents a custom input box can be displayed, as in:
http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui…
The list of spaces/documents is populated on display, like the RMUI
tables. Above the list, a "Displaying S-E out of T" message is displayed
only when the list does not fit in one page.
But the list of pages doesn't seem to be 'paginated'. I'm afraid of what
could happen if there are a lot of pages (like hundreds). I guess we
should look for a smart list that loads only the visible items.
WDYM? "Like the RMUI tables" means exactly this: just the documents
corresponding to the selected range are queried from the database and
sent via AJAX. It is not classic paginating, but a dynamic range.
> The anchor column can be used to link to a
document section (should we
> display sections from the saved document, or from the edited document if
> the selected document is the currently edited one?), to an attachment,
> or to a comment. Custom ID means entering in an input box a custom ID,
> without any checks if such an element exists or not. Should we also have
> a "page section" which allows to choose between the content area,
> comments, attachments, history?
OK to move this to the params tab.
Each column
can be filtered by entering some text in the respective box:
http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui…
Besides the "Simple" view, there's also the advanced view, and the
"additional params" view.
The params view allows customizing the link, by entering target, rel,
class and id attributes:
http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui…
For the advanced view I don't have screenshots, but it could contain the
suggest input boxes for wiki, space and document name, and some way of
selecting a custom action (view, edit, cancel, ssx...), a custom version
from the history, a query string.
Sorry for the raw aspect of the drawings.
I'm also worried about the horizontal layout. In some cases (I suspect
Watch) space and page names could be really long. I've noticed you cut
the long names and added "..." to avoid horizontal scroll. Even with a
tool tip showing the full name this might still be annoying for some users.
Yes, the ... mean that the document name was cropped, and the full title
is displayed as a tooltip.
With a small font and the large resolutions that are frequent nowadays,
I don't think this is a problem. We'll probably have to use a different
for smaller devices. Something like what macs do seems good enough:
Display the columns that fit, up to the most specific one selected, and
the rest are hidden on the left or right sides (Ask Jerome to show you
on his mac, if he still has it).
Basically, things go like this:
| Wiki | Space |
| | |
| wiki1 | Space1 |
| wiki2 | Space2 |
| |wiki3| | Space3 | >
| wiki4 | Space4 |
| | Space5 |
After selecting the space:
| Space | Doc |
| | |
| Space1 | Doc1 |
| Space2 | Doc2 |
< ||Space3| | Doc3 | >
| Space4 | Doc4 |
| Space5 | |
This allows having just 2 columns (or even 1) with plenty of space to
display 80 or more small characters.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/