[xwiki-devs] [Proposal] Having the docextra tabs in edit mode.
Hi. Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor. However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly! So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400 To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments). But this might be not relevant for the class and the object editor. My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs. WDYT? Thanks, -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue. The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused. Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing). Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 . So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal). Thanks, Caty On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor.
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a pain to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments. Thanks, 2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue.
The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused.
Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing).
Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 .
So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal).
Thanks, Caty
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor.
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On 12 Oct 2016, at 18:47, Guillaume Delhumeau <[email protected]> wrote:
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a pain to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments.
For the sake of the discussion, also note that there’s another option. Don’t leave the view page when editing (ie. inline editing) and just replace the view area by an edit area. And find how to display the page syntax and include/display references in the UI. The nice part is that it 1) it saves a reload of the UI (good for perf) and 2) it feels more snappy and no context switching for the user (better usability). If you remember this was a proposal done a very long time ago by Jean-Vincent Drean (tried to find the thread again but didn’t succeed). Thanks -Vincent
Thanks,
2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue.
The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused.
Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing).
Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 .
So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal).
Thanks, Caty
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor.
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
Something is not clear to me. What is exactly going to happen in edit mode when you select an attachment ? If the plan is to let the attachment tab behave exactly as it does in view mode (which is to actually upload the attachment and save the document) I'm really not a big fan of this. If we support attachments in edit view it should not send anything until we click save. On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <[email protected]> wrote:
On 12 Oct 2016, at 18:47, Guillaume Delhumeau <[email protected]> wrote:
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a pain to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments.
For the sake of the discussion, also note that there’s another option. Don’t leave the view page when editing (ie. inline editing) and just replace the view area by an edit area. And find how to display the page syntax and include/display references in the UI.
The nice part is that it 1) it saves a reload of the UI (good for perf) and 2) it feels more snappy and no context switching for the user (better usability).
If you remember this was a proposal done a very long time ago by Jean-Vincent Drean (tried to find the thread again but didn’t succeed).
Thanks -Vincent
Thanks,
2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue.
The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused.
Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing).
Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 .
So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal).
Thanks, Caty
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor.
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Some notes about the comments: - @GD: In CkEditor when drag&dropping it doesn't open a file explorer (that's for the simple upload), instead you just drag the image from Desktop and it inserts it. - @Vincent: the inline editing approach (with keeping the attachments tab in the same location) doesn't work for cases when we hide the docextra: we will have the same problem, and we might plan to remove that area for other skins. - @Thomas: yes this approach to have attachments tab in edit is problematic because of the save and other js events, plus to me is still oldish. So I don't want us to include the attachment tab in edit mode (although it sounded as a nice option). Instead I would like at least to have an improved drag&drop for CkEditor (improvement) and in the 'future' to support drag&drop in wiki mode (new feature). Thanks, Caty On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne <[email protected]
wrote:
Something is not clear to me. What is exactly going to happen in edit mode when you select an attachment ?
If the plan is to let the attachment tab behave exactly as it does in view mode (which is to actually upload the attachment and save the document) I'm really not a big fan of this. If we support attachments in edit view it should not send anything until we click save.
On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <[email protected]> wrote:
On 12 Oct 2016, at 18:47, Guillaume Delhumeau <
[email protected]> wrote:
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a
pain
to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments.
For the sake of the discussion, also note that there’s another option. Don’t leave the view page when editing (ie. inline editing) and just replace the view area by an edit area. And find how to display the page syntax and include/display references in the UI.
The nice part is that it 1) it saves a reload of the UI (good for perf) and 2) it feels more snappy and no context switching for the user (better usability).
If you remember this was a proposal done a very long time ago by Jean-Vincent Drean (tried to find the thread again but didn’t succeed).
Thanks -Vincent
Thanks,
2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) <[email protected] :
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue.
The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused.
Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing).
Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 .
So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal).
Thanks, Caty
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor.
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 13 Oct 2016, at 11:07, Ecaterina Moraru (Valica) <[email protected]> wrote:
Some notes about the comments: - @GD: In CkEditor when drag&dropping it doesn't open a file explorer (that's for the simple upload), instead you just drag the image from Desktop and it inserts it. - @Vincent: the inline editing approach (with keeping the attachments tab in the same location) doesn't work for cases when we hide the docextra: we will have the same problem, and we might plan to remove that area for other skins. - @Thomas: yes this approach to have attachments tab in edit is problematic because of the save and other js events, plus to me is still oldish.
So I don't want us to include the attachment tab in edit mode (although it sounded as a nice option). Instead I would like at least to have an improved drag&drop for CkEditor (improvement) and in the 'future' to support drag&drop in wiki mode (new feature).
I think we all agree about this. What I understood from GD’s remark, was to find an easy way to have this now and not in one year. So the real question is: is it better to wait or do something that is marginally better than what we have now but without being how we want to do it in the end (it’s an open question)? FYI I’ll send a proposal for the roadmap for 8.4.x before the end of the week but ATM I don’t have this item in it. Thanks -Vincent
Thanks, Caty
On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne <[email protected]
wrote:
Something is not clear to me. What is exactly going to happen in edit mode when you select an attachment ?
If the plan is to let the attachment tab behave exactly as it does in view mode (which is to actually upload the attachment and save the document) I'm really not a big fan of this. If we support attachments in edit view it should not send anything until we click save.
On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <[email protected]> wrote:
On 12 Oct 2016, at 18:47, Guillaume Delhumeau <
[email protected]> wrote:
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a
pain
to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments.
For the sake of the discussion, also note that there’s another option. Don’t leave the view page when editing (ie. inline editing) and just replace the view area by an edit area. And find how to display the page syntax and include/display references in the UI.
The nice part is that it 1) it saves a reload of the UI (good for perf) and 2) it feels more snappy and no context switching for the user (better usability).
If you remember this was a proposal done a very long time ago by Jean-Vincent Drean (tried to find the thread again but didn’t succeed).
Thanks -Vincent
Thanks,
2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) <[email protected] :
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue.
The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused.
Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing).
Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 .
So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal).
Thanks, Caty
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor.
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
On 13 Oct 2016, at 11:17, Vincent Massol <[email protected]> wrote:
On 13 Oct 2016, at 11:07, Ecaterina Moraru (Valica) <[email protected]> wrote:
Some notes about the comments: - @GD: In CkEditor when drag&dropping it doesn't open a file explorer (that's for the simple upload), instead you just drag the image from Desktop and it inserts it. - @Vincent: the inline editing approach (with keeping the attachments tab in the same location) doesn't work for cases when we hide the docextra: we will have the same problem, and we might plan to remove that area for other skins. - @Thomas: yes this approach to have attachments tab in edit is problematic because of the save and other js events, plus to me is still oldish.
So I don't want us to include the attachment tab in edit mode (although it sounded as a nice option). Instead I would like at least to have an improved drag&drop for CkEditor (improvement) and in the 'future' to support drag&drop in wiki mode (new feature).
I think we all agree about this.
Don’t want to speak for others ;) So let me rephrase: I completely agree with both Thomas and Caty’s points. Thanks -Vincent
What I understood from GD’s remark, was to find an easy way to have this now and not in one year. So the real question is: is it better to wait or do something that is marginally better than what we have now but without being how we want to do it in the end (it’s an open question)?
FYI I’ll send a proposal for the roadmap for 8.4.x before the end of the week but ATM I don’t have this item in it.
Thanks -Vincent
Thanks, Caty
On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne <[email protected]
wrote:
Something is not clear to me. What is exactly going to happen in edit mode when you select an attachment ?
If the plan is to let the attachment tab behave exactly as it does in view mode (which is to actually upload the attachment and save the document) I'm really not a big fan of this. If we support attachments in edit view it should not send anything until we click save.
On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <[email protected]> wrote:
On 12 Oct 2016, at 18:47, Guillaume Delhumeau <
[email protected]> wrote:
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a
pain
to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments.
For the sake of the discussion, also note that there’s another option. Don’t leave the view page when editing (ie. inline editing) and just replace the view area by an edit area. And find how to display the page syntax and include/display references in the UI.
The nice part is that it 1) it saves a reload of the UI (good for perf) and 2) it feels more snappy and no context switching for the user (better usability).
If you remember this was a proposal done a very long time ago by Jean-Vincent Drean (tried to find the thread again but didn’t succeed).
Thanks -Vincent
Thanks,
2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) <[email protected] :
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue.
The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused.
Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing).
Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 .
So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal).
Thanks, Caty
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
> Hi. > > Currently a user have 2 ways to attach a file to a wiki page: > - in the attachment tab in VIEW mode only ; > - if it's an image, using a WYSIWYG editor. > > However, if it's not an image, you cannot add it while you're writing the > content. It's a bit as if you were not able to attach a file while you were > writing an email... not user friendly! > > So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400 > > To fix it, I see 2 options: > - add the handling of attachments in edit mode. > - add *all* docextra tabs like we have in view mode (it's not because you > are editing a page that you don't need to see the history of the page, nor > the comments). > > But this might be not relevant for the class and the object editor. > > My proposal: > * Display docextra tabs by default. > * In class and object editors, set $docExtras = []. > * Set $docExtras = [] in all sheets where we consider it's not relevant to > have the tabs. > > WDYT? > > Thanks,
2016-10-13 11:07 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
Some notes about the comments: - @GD: In CkEditor when drag&dropping it doesn't open a file explorer (that's for the simple upload), instead you just drag the image from Desktop and it inserts it.
I think I was not clear. I know CKEditor does not a file explorer. But you have to open that kind of application by yourself (in mac it's called "Finder", on my laptop it's called "Nautilus") if the file you plan to drag is not on your desktop (which is the case 99% of the time). That is exactly what I dislike.
- @Vincent: the inline editing approach (with keeping the attachments tab in the same location) doesn't work for cases when we hide the docextra: we will have the same problem, and we might plan to remove that area for other skins. - @Thomas: yes this approach to have attachments tab in edit is problematic because of the save and other js events, plus to me is still oldish.
So I don't want us to include the attachment tab in edit mode (although it sounded as a nice option). Instead I would like at least to have an improved drag&drop for CkEditor (improvement) and in the 'future' to support drag&drop in wiki mode (new feature).
Thanks, Caty
Thanks,
On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne < [email protected]
wrote:
Something is not clear to me. What is exactly going to happen in edit mode when you select an attachment ?
If the plan is to let the attachment tab behave exactly as it does in view mode (which is to actually upload the attachment and save the document) I'm really not a big fan of this. If we support attachments in edit view it should not send anything until we click save.
On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <[email protected]> wrote:
On 12 Oct 2016, at 18:47, Guillaume Delhumeau <
[email protected]> wrote:
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a
pain
to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments.
For the sake of the discussion, also note that there’s another option. Don’t leave the view page when editing (ie. inline editing) and just replace the view area by an edit area. And find how to display the page syntax and include/display references in the UI.
The nice part is that it 1) it saves a reload of the UI (good for perf) and 2) it feels more snappy and no context switching for the user (better usability).
If you remember this was a proposal done a very long time ago by Jean-Vincent Drean (tried to find the thread again but didn’t succeed).
Thanks -Vincent
Thanks,
2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) < [email protected] :
There are some problems with docextra, because it contains comments, which are mostly needed in view mode, not in edit. So in edit mode, we would need just some tabs from docextra. But I'm not sure that adding docextra now will fix the underlying problem of the issue.
The issue was trying to fix the attachments uploading limitation of the editor. The problem is that the editors (including CKEditor) are advertising that they add images and not other file types. If users want to add a PDF they might be confused.
Ideally the users would just need to drag&drop a file and we would insert a displayer depending on the dragged type (viewer for PDFs, gallery for multiple images, image macro for single image, etc.) Also even if in CKEditor the drag&drop option for images is permitted, nobody knows about it. And currently CKEditor has the limitation to allow dragging just images and not other types (dragging an image inserts it, dragging a text file does nothing).
Other thing to consider is that for Groupware flavor, where we promote applications, we hide the docextra, since this is not so relevant for application entries. Hidding docextra creates http://jira.xwiki.org/browse/XWIKI-13799 and http://jira.xwiki.org/browse/XWIKI-12993 .
So, a conclusion: I'm not sure adding #docextra in the edit mode is the best solution, especially since we try to make the interface more simple and we usually hide docextra also from view. An idea would be to better mark in the Edit mode that Drag&Drop is permitted (at least for the CKEditor - the wiki mode will still have the same issue). Have a drag&drop behavior also for other file types, not just images (for text files we could create a link for the attached file, etc.). Plus have a link to manually go to the attachments viewer as a backup (by fixing the 2 additional issues mentioned). The problem will still remain on wiki mode, but let's say those users are more advanced and know how to use viewers (although consistency between the edit modes would be ideal).
Thanks, Caty
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor.
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
Guillaume, would you not rather be in favour of an attachments’ tab display (it could be iframed) as pop-up for the wiki editor? And the let JS modify the action on link-click to be a selection, and then make selection insert something useful depending on the type of the selected item and, possibly later, on the wiki-text around the cursor. paul
On 12 Oct 2016, at 18:47, Guillaume Delhumeau <[email protected]> wrote:
Just some remarks before I go: * As a developer, I always use the Wiki editor, and even for me it's a pain to go to view mode to upload a file (for example, an image in the release notes). * I never use drag&drop in whatever application I have. I have never liked it because it requires to open a file explorer specially for that and it's always a pain because I use applications in full size mode. I'm sure I'm not the only one so I'm not fond of having it as the only way to upload attachments.
On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < [email protected]> wrote:
Hi.
Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ;
- if it's an image, using a WYSIWYG editor.
It doesn't have to be an image. You *can* attach any type of file. You can drag & drop only images, but that's different (we have CKEDITOR-30 for this).
However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly!
So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments).
But this might be not relevant for the class and the object editor.
My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs.
WDYT?
Thanks,
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Ecaterina Moraru (Valica) -
Guillaume Delhumeau -
Marius Dumitru Florea -
Paul Libbrecht -
Thomas Mortagne -
Vincent Massol