Guillaume Lerouge wrote:
Hi,
On Wed, Apr 8, 2009 at 11:24 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Anca Paula Luca wrote:
Ludovic Dubost wrote:
I'm having some thoughts about the
attachments and image insert. I just
tested the current work on attachment link insert.
The more I think about it, the more I believe that images and
attachments should be mainly attached to the CURRENT page.
It is a nice to have to be able to use images or attachments for other
pages (and even less upload to another page).
However, when I look at the superbe tree UI, I have the feeling it will
actually get in the way of the main usage, which is having the file
attached to the current page.
1/ I can make sure the currently selected page in
the tree on loading the
dialog
is the current page, so that the main usage is
facilitated: either one
selects a
file attached to the current page, either she
hits "Add attachment" and
uploads
> a new one.
I think that this is our best option right now. It addresses most
of
Ludovic's concerns while building on the same foundation as our other dialog
boxes. We'd better wait for actual feedback before changing it.
Therefore I believe we should have 2 different UIs.
One simple and one
advanced. The simple one would only manager files or images attached to
the current page. The advanced would be the tree one.
So one would not be able to
add a link to an attachment / image from
another
page, using the simple UI? I think this is
acceptable only if we provide
the
simple and advanced UIs accessible almost as
easy.
2/ One idea for this would be to have 2 tabs in the selection step, one
with a
simple UI, the other with the advanced tree, and
let the user select an
attached
file / image from any of them.
3/ Another idea is that the simple UI is still the tree, but drawing only
the
current page's node. On hitting a
"More" button, the tree will be
completed with
the whole wiki, so that the user can select other
things too (we need to
check
> if that's possible with the tree)
In some cases (I'm thinking about Curriki here), the XWiki admin will not
want users to be able to see other pages. Thus maybe we could add a WYSIWYG
configuration option such as "display all pages / only the current page
treeview for images and attachments" -> default behavior stays 1/, and 3/
can be configured by admins when they need it. WDYT?
Well, the tree should take into account the user rights for the wiki: i.e. not
show pages for which the viewing user does not have rights, or not allow to
upload files to pages where user does not have this right. If it does not do it
yet (btw, I should test), then we have to fix this.
I think the use case you presented is just a case of user rights. With the risk
of acting like a dev jerk, I must confess I don't understand why would an admin
want to limit view/upload from the wysiwyg interface, when it could be easily
done from the wiki interface by users who want to do it. If admin also restricts
it in the wiki by some hackish manner, then it's wrong. Correct restriction
manner should be rights, which the tree selector should take into account.
I agree with making it easier to upload to current page, I don't agree with
artificially restricting it.
Happy coding,
Anca Luca
My vote
goes for 1/ for consistency reasons (same widget everywhere), for
not
crowding the UI with tabs, buttons, options, for
not having to make the
user
understand what is the difference between the two
and why she needs two,
and
because I think it would do its job smoothly
(will get the tree out of
the way
> of the main usage).
I mostly subscribe to these arguments. I think that given the current state
of our work, we'd better complete this implementation (using the tree with
current page node opened) and have it tried and tested by users before
modifying it any further. This way we wait for actual feedback before trying
to rewrite a new dialog box.
How about a hidden sidepanel, with a handle 8px
wide, with an arrow in
the center, that opens when you click it? And when it does, the current
document is already selected.
Or, if we'll have more such tabs, mayba something like the sidebar
Acrobat Reader has: a vertical bar with nice big icons, that open a
sidebar when clicked: pages, bookmarks, howto.
That's pretty far from what we're currently doing. I think right now is not
the time to open yet another debate about the UI of the WYSIWYG editor, we'd
better complete it first, shouldn't we?
Guillaume
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs