[xwiki-devs] Thoughts about the attachment and image insert
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. 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. I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
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.
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.
I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page.
WDYT ?
+1 -- Sergiu Dumitriu http://purl.org/net/sergiu/
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.
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) 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). Happy coding, Anca Luca
I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page.
WDYT ?
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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.
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)
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).
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. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, On Wed, Apr 8, 2009 at 11:24 AM, Sergiu Dumitriu <[email protected]> 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?
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
Guillaume Lerouge wrote:
Hi,
On Wed, Apr 8, 2009 at 11:24 AM, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Sergiu Dumitriu 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.
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)
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).
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.
Opens == expands over the form for selecting a file / image in the current document?
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.
I can't quite visualize this... however I think a split window inside the wysiwyg dialogs (sidebar + main panel) is a bit too much (they're somewhere around 480x480px). I think we need a general approach of allowing multiple sources for selection of a wikipage / file / image, since we should want to integrate alternatives for wikipage selection too (search in page content, recently viewed, etc). Happy coding, Anca Luca
Anca Paula Luca a écrit :
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.
This option in my opinion is not good enough. The tree will actually go in the way of people understanding the tool. I believe the first impressio of the user needs to be simple and simple means less information shown on the screen. So it means a UI much more like the current Image UI (with the page choice removed). The tree or whatever concerning images or attachments from different pages than the current one should be hidden from the user. And this feature is actually NOT a priority. I'm not even sure we have had any people asking for inserting images from other pages did we ?
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.
Yes Tabs is an option.
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)
I think this is less optimal for the simple case. We need to focus on making the simple case optimal. I vote for 2/ or sergiu's hidden tree idea. Ludovic
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).
Happy coding, Anca Luca
I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page.
WDYT ?
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Re, On Wed, Apr 8, 2009 at 1:09 PM, Ludovic Dubost <[email protected]> wrote:
Anca Paula Luca a écrit :
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.
This option in my opinion is not good enough. The tree will actually go in the way of people understanding the tool. I believe the first impressio of the user needs to be simple and simple means less information shown on the screen. So it means a UI much more like the current Image UI (with the page choice removed).
The tree or whatever concerning images or attachments from different pages than the current one should be hidden from the user.
And this feature is actually NOT a priority. I'm not even sure we have had any people asking for inserting images from other pages did we ?
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.
Yes Tabs is an option.
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)
I think this is less optimal for the simple case. We need to focus on making the simple case optimal.
I vote for 2/ or sergiu's hidden tree idea.
Ludovic
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).
Happy coding, Anca Luca
I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page.
WDYT ?
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I've thought a bit more about the topic and I think an elegant solution that would both match user expectations and be elegant exists. I'll explain it after providing some context. - Our aim in the new WYSIWYG has been to let users do more than they could in the previous one - We dissussed a lot about what the best way to achieve easy browsing of pages & other items - We eventually agreed on using a treeview approach for most purposes - However, the tree view isn't necessarily the most effective for some use cases such as the one Ludovic identified - Thus we may want to look at the way other pieces of software resolve this type of file browsing issue - For instance, Mac OS X's finder offers 4 different kind of views: folder contents, tree, miller columns & coverflow - Some users favor the tree view while other like the folder view better (the last 2 are pretty much superfluous) - The view Ludovic is pushing forward would be pretty much covered by a standard folder view showing the images / files attahed to the current page as thumbnails (similar to http://i21.tinypic.com/29zyott.png in the context of the wiki) - If we look at http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface?xpage=p..., we see that it would be pretty easy (from an UI point of view, not a technical one) to add a zone at the top of the screen (between "select an image" and the tree itslef) that would provide the following 2 elements: - Buttons / select box to switch between tree view and folder view - A search box (Vincent has been asking for it and I believe it's important too) - Here's a tentative mockup showing what I have in mind: http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/AlternativeI... - We could hide the Wiki address field from standard users (show it only for advanced users) - The default view would open on the folder view for insert image and insert attachment links - This feature can be implemented at a later stage, once the current tree is done, so it doesn't disrupt the current planning - The WYSIWYG editor would provide a configuration option allowing to choose whether to hide some of the views in some cases (show only the folder view on the current page for instance) - Note: my proposal doesn't have back / forward buttons since it doesn't take into account the possibility of full folder browsing: the folders opens only on the current page attachments. This might have to be discussed. I think this proposal would address most (if not all) of the points still under discussion about our dialog boxes (view on the current page only, search, possibility to browse other pages, etc). However it implies a lot of additional work by the WYSIWYG team, and it's not necessarily the direction we want to push the editor forward. Thus I'd like to get everybody's feedback about it before pushing for any kind of implementation plan. Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
participants (5)
-
Anca Paula Luca -
Guillaume Lerouge -
Ludovic Dubost -
Ludovic Dubost -
Sergiu Dumitriu