Hi,
I think that the various propositions we've had (from Laurent, Sergiu and I)
are not that much different and that we can come to a first version that
keeps most of their advantages under the tight time constraints we're
working under. Here goes :
1. Provide lists only for wikis (in multiwiki mode), spaces and pages as
of now (and take care about additional things that can be related to a page
- headers, objects, attachments - at a later stage)
2. Going opposite to my initial thoughts, it is probably better to keep
link creation towards existing and not yet existing pages in the same place.
3. On the whole we all agree on providing 3 lists: one for wikis, one for
spaces, one for pages. The issue was of presenting it in 1 column with 3
steps or 3 columns. I think that given today's screen sizes, using 3 columns
should work and it's not that counterintuitive to users.
4. We can follow Sergiu's proposal quite closely for each list :
1. Column title (Wikis, Spaces, Pages)
2. Dynamic filtering field
3. List of items (10 visible by default) centered on the current wiki,
space, page highlighted (as in Sergiu's proposal)
4. "Or input the name of a new [space, page]" input field
5. A small italics link titled "more options" that opens a 2nd dialog
box with additional options (parameters, target, anchors, etc)
6. A big, green "Create" button. Upon clicking the button, the user is
brought back to the editor.
| Column Title (Wikis, Spaces, Pages) |
| [filter items input field] |
| Item 1 |
| ... |
| Item 10 |
| [Or input the name of a new element field] |
| Advanced options |
| CREATE ITEM BUTTON |
WDYT ?
Guillaume
On Thu, Oct 30, 2008 at 12:01 AM, Sergiu Dumitriu <[EMAIL PROTECTED]> wrote:
> 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/wysiwyg%2Dsuite.pdf
> >>> 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.zip/default.png
> >>
> >> 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.zip/loading.png
> >
> > 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.zip/custom.png
> >>
> >> 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.zip/filter.png
> >>
> >> 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.zip/params.png
> >>
> >> 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/
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://blog.xwiki.com/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
