[xwiki-users] [Proposal] Selective Export UI
Hi, Please provide feedback for the Selective Export UI: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize. Thanks, Caty
Hi, On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica <[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale? I'm asking because given the current implementation of our treeview I know that this can be a huge PITA. Guillaume
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Very nice. I have the same concern as Guillaume about scalability. Also, do we need custom checkboxes ? Can't we use regular ones ? JV. On Wed, Apr 28, 2010 at 4:44 PM, Ecaterina Valica <[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Wed, Apr 28, 2010 at 17:23, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will
be
improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
I know, but my questions stands nonetheless -> how does the tree accommodate a 1000-pages-big space? Using a scrollbar? Guillaume
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 SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Wed, Apr 28, 2010 at 18:30, Guillaume Lerouge <[email protected]>wrote:
Hi,
On Wed, Apr 28, 2010 at 17:23, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will
be
improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
I know, but my questions stands nonetheless -> how does the tree accommodate a 1000-pages-big space? Using a scrollbar?
We can use a scrollbar or just accommodate the div for it. Another solutions would be to load just the fist 50/100 pages and have a load "more" pages link at the bottom, that is gonna load on demand. From a usability point of view, I think the user is gonna use the search in this case and refine that number of pages.
Guillaume
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 SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On Wed, Apr 28, 2010 at 18:29, Jean-Vincent Drean <[email protected]>wrote:
Very nice. I have the same concern as Guillaume about scalability. Also, do we need custom checkboxes ? Can't we use regular ones ?
In the case of regular checkboxes, you need to: - first select the desired pages - then click on the "move"/"delete" action In the case of custom checkboxes, on click the page is automatically taken in the other view. Plus you have that nice on hover effect, that lets you know that you can interact with that page. Plus it looks much smoother.
Hi, On Wed, Apr 28, 2010 at 18:12, Ecaterina Valica <[email protected]> wrote:
On Wed, Apr 28, 2010 at 18:30, Guillaume Lerouge <[email protected]
wrote:
Hi,
On Wed, Apr 28, 2010 at 17:23, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It
will be
improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
I know, but my questions stands nonetheless -> how does the tree accommodate a 1000-pages-big space? Using a scrollbar?
We can use a scrollbar or just accommodate the div for it. Another solutions would be to load just the fist 50/100 pages and have a load "more" pages link at the bottom, that is gonna load on demand.
The "load more" option for 50+ pages sounds good to me.
From a usability point of view, I think the user is gonna use the search in this case and refine that number of pages.
Indeed. Guillaume
Guillaume
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 SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
In my opinion we should actually aim to replace the treeview with this one (that's why I initially referred to it as a new 'extensible' treeview, in the sense it could be used for navigation in its simplest mode, but could be extended for selection). I'd also like to see how it scale (in terms of UI) to a large number of documents. What about the parent/children relationship? Should we imitate what the current treeview does? If we were to replace the treeview by this new one, should it behave as the old one, or should it display the pages flat ? Jerome.
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Apr 28, 2010 at 17:23, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
Very nice !
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
If the current treeview is not good enough it should be improved instead of having several.
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Thomas Mortagne
Hi, On Wed, Apr 28, 2010 at 18:37, Jerome Velociter <[email protected]> wrote:
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
In my opinion we should actually aim to replace the treeview with this one (that's why I initially referred to it as a new 'extensible' treeview, in the sense it could be used for navigation in its simplest mode, but could be extended for selection).
I'd also like to see how it scale (in terms of UI) to a large number of documents.
What about the parent/children relationship? Should we imitate what the current treeview does? If we were to replace the treeview by this new one, should it behave as the old one, or should it display the pages flat ?
I'm strongly against the way the treeview works right now. Nobody understands the mix of space and parent/child relationship. I'd KISS it, keeping only the space/page relationship. Guillaume
Jerome.
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ 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 Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On 04/28/2010 06:42 PM, Thomas Mortagne wrote:
On Wed, Apr 28, 2010 at 17:23, Sergiu Dumitriu<[email protected]> wrote:
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
Very nice !
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
If the current treeview is not good enough it should be improved instead of having several.
The current one is the one from SmartGWT, which is an external library, hard to patch locally. Improving it would mean contributing to this huge, very generic library, wait for approval, release, integration. I'd rather write a clean/lean one from scratch, which would support what we need.
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On 04/28/2010 06:46 PM, Guillaume Lerouge wrote:
I'm strongly against the way the treeview works right now. Nobody understands the mix of space and parent/child relationship. I'd KISS it, keeping only the space/page relationship.
One idea: ghost symlinks. [s] Main - [p] WebHome - [p^] /Blog . WebHome/ - [p] Great news! - [p] BigClient contract - [p] BigClient project description - [p] More great news! [s] Blog - [p] WebHome - [p] Meet Joe Dyke, our new CTO - [p^] /Main . Great news!/ - [p^] /Main . More great news!/ [s] is the space icon, [p] is the page icon, [p^] is the page icon with the shortcut overlay. The ghost documents are written in italic with a lighter color, and clicking on such a symlink will show the real document, by expanding the tree to it, scroll it into view (with anymation), and select it. Note that in the Main space the other children of the Blog.WebHome page are not displayed, and in the Blog space the deeper hierarchy of the external documents is not shown WDYT? Of course, this as a better UI for the alldocs/tree view; the export UI should could keep just the space/docs two-level hierarchy. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, On Wed, Apr 28, 2010 at 20:15, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 06:46 PM, Guillaume Lerouge wrote:
I'm strongly against the way the treeview works right now. Nobody understands the mix of space and parent/child relationship. I'd KISS it, keeping only the space/page relationship.
http://en.wikipedia.org/wiki/KISS_principle
One idea: ghost symlinks.
"The KISS principle states that simplicity<http://en.wikipedia.org/wiki/Simplicity>should be a key goal in design <http://en.wikipedia.org/wiki/Design>, and that unnecessary complexity should be avoided." Ghost symlinks? - how does the treeview thing work? - well, it's easy, just click the ghost symlink below that other page and the whole thing will start scrolling to get you somewhere different from where you were located - oh
[s] Main - [p] WebHome - [p^] /Blog . WebHome/ - [p] Great news! - [p] BigClient contract - [p] BigClient project description - [p] More great news! [s] Blog - [p] WebHome - [p] Meet Joe Dyke, our new CTO - [p^] /Main . Great news!/ - [p^] /Main . More great news!/
[s] is the space icon, [p] is the page icon, [p^] is the page icon with the shortcut overlay. The ghost documents are written in italic with a lighter color, and clicking on such a symlink will show the real document, by expanding the tree to it, scroll it into view (with anymation), and select it.
Note that in the Main space the other children of the Blog.WebHome page are not displayed, and in the Blog space the deeper hierarchy of the external documents is not shown
WDYT?
Of course, this as a better UI for the alldocs/tree view; the export UI should could keep just the space/docs two-level hierarchy.
I think the same, simple, understandable, Space / Page hierarchy should be used everywhere. An alternative is what we do for WebDAV and provide 2 different interfaces: EITHER space/page OR parents/children but never a mix of both. 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 SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
2010/4/28 Guillaume Lerouge <[email protected]>:
Hi,
On Wed, Apr 28, 2010 at 20:15, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 06:46 PM, Guillaume Lerouge wrote:
I'm strongly against the way the treeview works right now. Nobody understands the mix of space and parent/child relationship. I'd KISS it, keeping only the space/page relationship.
http://en.wikipedia.org/wiki/KISS_principle
One idea: ghost symlinks.
"The KISS principle states that simplicity<http://en.wikipedia.org/wiki/Simplicity>should be a key goal in design <http://en.wikipedia.org/wiki/Design>, and that unnecessary complexity should be avoided." Ghost symlinks?
- how does the treeview thing work? - well, it's easy, just click the ghost symlink below that other page and the whole thing will start scrolling to get you somewhere different from where you were located - oh
[s] Main - [p] WebHome - [p^] /Blog . WebHome/ - [p] Great news! - [p] BigClient contract - [p] BigClient project description - [p] More great news! [s] Blog - [p] WebHome - [p] Meet Joe Dyke, our new CTO - [p^] /Main . Great news!/ - [p^] /Main . More great news!/
[s] is the space icon, [p] is the page icon, [p^] is the page icon with the shortcut overlay. The ghost documents are written in italic with a lighter color, and clicking on such a symlink will show the real document, by expanding the tree to it, scroll it into view (with anymation), and select it.
Note that in the Main space the other children of the Blog.WebHome page are not displayed, and in the Blog space the deeper hierarchy of the external documents is not shown
WDYT?
Of course, this as a better UI for the alldocs/tree view; the export UI should could keep just the space/docs two-level hierarchy.
I think the same, simple, understandable, Space / Page hierarchy should be used everywhere.
An alternative is what we do for WebDAV and provide 2 different interfaces: EITHER space/page OR parents/children but never a mix of both.
Or may be never follow symlinks. Personally, I like the idea to show that one space I want to export have dependencies on other space. With symlinks display I can decide or not to add other space to my export. Arnaud.
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 SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On 04/28/2010 11:55 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 20:15, Sergiu Dumitriu<[email protected]> wrote:
On 04/28/2010 06:46 PM, Guillaume Lerouge wrote:
I'm strongly against the way the treeview works right now. Nobody understands the mix of space and parent/child relationship. I'd KISS it, keeping only the space/page relationship.
I'm going to ignore that.
One idea: ghost symlinks.
"The KISS principle states that simplicity<http://en.wikipedia.org/wiki/Simplicity>should be a key goal in design<http://en.wikipedia.org/wiki/Design>, and that unnecessary complexity should be avoided." Ghost symlinks?
- how does the treeview thing work? - well, it's easy, just click the ghost symlink below that other page and the whole thing will start scrolling to get you somewhere different from where you were located - oh
[s] Main - [p] WebHome - [p^] /Blog . WebHome/ - [p] Great news! - [p] BigClient contract - [p] BigClient project description - [p] More great news! [s] Blog - [p] WebHome - [p] Meet Joe Dyke, our new CTO - [p^] /Main . Great news!/ - [p^] /Main . More great news!/
[s] is the space icon, [p] is the page icon, [p^] is the page icon with the shortcut overlay. The ghost documents are written in italic with a lighter color, and clicking on such a symlink will show the real document, by expanding the tree to it, scroll it into view (with anymation), and select it.
Note that in the Main space the other children of the Blog.WebHome page are not displayed, and in the Blog space the deeper hierarchy of the external documents is not shown
WDYT?
Of course, this as a better UI for the alldocs/tree view; the export UI should could keep just the space/docs two-level hierarchy.
I think the same, simple, understandable, Space / Page hierarchy should be used everywhere.
Even in the hierarchy view that is specifically designed for displaying the parent-child relations? I'd also like to keep things simple whenever possible, but then why do we have this tab in the AllDocs? Should we remove it? Then why do we have the parent field if I cant see the children of a page?
An alternative is what we do for WebDAV and provide 2 different interfaces: EITHER space/page OR parents/children but never a mix of both.
So how do you explain this? webdav://localhost/xwiki/webdav/spaces/Blog/_W_/WebHome/Categories/News
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, On Thu, Apr 29, 2010 at 12:00, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 11:55 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 20:15, Sergiu Dumitriu<[email protected]> wrote:
On 04/28/2010 06:46 PM, Guillaume Lerouge wrote:
I'm strongly against the way the treeview works right now. Nobody understands the mix of space and parent/child relationship. I'd KISS it, keeping only the space/page relationship.
I'm going to ignore that.
:-)
One idea: ghost symlinks.
"The KISS principle states that simplicity<http://en.wikipedia.org/wiki/Simplicity>should be a key goal in design<http://en.wikipedia.org/wiki/Design>, and that unnecessary complexity should be avoided." Ghost symlinks?
- how does the treeview thing work? - well, it's easy, just click the ghost symlink below that other page and the whole thing will start scrolling to get you somewhere different from where you were located - oh
[s] Main - [p] WebHome - [p^] /Blog . WebHome/ - [p] Great news! - [p] BigClient contract - [p] BigClient project description - [p] More great news! [s] Blog - [p] WebHome - [p] Meet Joe Dyke, our new CTO - [p^] /Main . Great news!/ - [p^] /Main . More great news!/
[s] is the space icon, [p] is the page icon, [p^] is the page icon with the shortcut overlay. The ghost documents are written in italic with a lighter color, and clicking on such a symlink will show the real document, by expanding the tree to it, scroll it into view (with anymation), and select it.
Note that in the Main space the other children of the Blog.WebHome page are not displayed, and in the Blog space the deeper hierarchy of the external documents is not shown
WDYT?
Of course, this as a better UI for the alldocs/tree view; the export UI should could keep just the space/docs two-level hierarchy.
I think the same, simple, understandable, Space / Page hierarchy should be used everywhere.
Even in the hierarchy view that is specifically designed for displaying the parent-child relations? I'd also like to keep things simple whenever possible, but then why do we have this tab in the AllDocs? Should we remove it? Then why do we have the parent field if I cant see the children of a page?
As I said, I think both can be useful but that the 2 ways of browsing should not be mixed together. It should be either Space / Pages or Parent document / children documents / children of the children documents. The parent / children relationship is also displayed through the information tab and the breadcrumb so it's not lost. As for the tree currently located in AllDocs, I think the way it is implemented is a mistake we should correct.
An alternative is what we do for WebDAV and provide 2 different interfaces:
EITHER space/page OR parents/children but never a mix of both.
So how do you explain this? webdav://localhost/xwiki/webdav/spaces/Blog/_W_/WebHome/Categories/News
2 factors: - My mental representation of how XWiki's WebDAV interface works wasn't aligned with how it actually works (in other words: I didn't do my homework) - The WebDAV space display is indeed using the same flawed mix of space / page relationship and parent relationship and should be fixed Guillaume
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 SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Thu, Apr 29, 2010 at 12:00 PM, Sergiu Dumitriu <[email protected]> wrote:
On 04/28/2010 11:55 PM, Guillaume Lerouge wrote:
On Wed, Apr 28, 2010 at 20:15, Sergiu Dumitriu<[email protected]> wrote:
Of course, this as a better UI for the alldocs/tree view; the export UI should could keep just the space/docs two-level hierarchy.
I think the same, simple, understandable, Space / Page hierarchy should be used everywhere.
Even in the hierarchy view that is specifically designed for displaying the parent-child relations? I'd also like to keep things simple whenever possible, but then why do we have this tab in the AllDocs? Should we remove it? Then why do we have the parent field if I cant see the children of a page?
I second those questions, imho one of the main purpose of a tree view is to represent the parent/child relationship. JV.
On 04/29/2010 12:13 PM, Guillaume Lerouge wrote:
Hi,
On Thu, Apr 29, 2010 at 12:00, Sergiu Dumitriu<[email protected]> wrote:
On 04/28/2010 11:55 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 20:15, Sergiu Dumitriu<[email protected]> wrote:
On 04/28/2010 06:46 PM, Guillaume Lerouge wrote:
I'm strongly against the way the treeview works right now. Nobody understands the mix of space and parent/child relationship. I'd KISS it, keeping only the space/page relationship.
I'm going to ignore that.
:-)
One idea: ghost symlinks.
"The KISS principle states that simplicity<http://en.wikipedia.org/wiki/Simplicity>should be a key goal in design<http://en.wikipedia.org/wiki/Design>, and that unnecessary complexity should be avoided." Ghost symlinks?
- how does the treeview thing work? - well, it's easy, just click the ghost symlink below that other page and the whole thing will start scrolling to get you somewhere different from where you were located - oh
[s] Main - [p] WebHome - [p^] /Blog . WebHome/ - [p] Great news! - [p] BigClient contract - [p] BigClient project description - [p] More great news! [s] Blog - [p] WebHome - [p] Meet Joe Dyke, our new CTO - [p^] /Main . Great news!/ - [p^] /Main . More great news!/
[s] is the space icon, [p] is the page icon, [p^] is the page icon with the shortcut overlay. The ghost documents are written in italic with a lighter color, and clicking on such a symlink will show the real document, by expanding the tree to it, scroll it into view (with anymation), and select it.
Note that in the Main space the other children of the Blog.WebHome page are not displayed, and in the Blog space the deeper hierarchy of the external documents is not shown
WDYT?
Of course, this as a better UI for the alldocs/tree view; the export UI should could keep just the space/docs two-level hierarchy.
I think the same, simple, understandable, Space / Page hierarchy should be used everywhere.
Even in the hierarchy view that is specifically designed for displaying the parent-child relations? I'd also like to keep things simple whenever possible, but then why do we have this tab in the AllDocs? Should we remove it? Then why do we have the parent field if I cant see the children of a page?
As I said, I think both can be useful but that the 2 ways of browsing should not be mixed together. It should be either Space / Pages or Parent document / children documents / children of the children documents.
The parent / children relationship is also displayed through the information tab and the breadcrumb so it's not lost.
As for the tree currently located in AllDocs, I think the way it is implemented is a mistake we should correct.
An alternative is what we do for WebDAV and provide 2 different interfaces:
EITHER space/page OR parents/children but never a mix of both.
So how do you explain this? webdav://localhost/xwiki/webdav/spaces/Blog/_W_/WebHome/Categories/News
2 factors:
- My mental representation of how XWiki's WebDAV interface works wasn't aligned with how it actually works (in other words: I didn't do my homework) - The WebDAV space display is indeed using the same flawed mix of space / page relationship and parent relationship and should be fixed
Anyway, I looked at the hierarchical structure used in WebDAV (the one starting in /webdav/home/), and indeed it could be a better representation of the hierarchy. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On 04/28/2010 06:37 PM, Jerome Velociter wrote:
On 04/28/2010 05:17 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Apr 28, 2010 at 16:44, Ecaterina Valica<[email protected]> wrote:
Hi,
Please provide feedback for the Selective Export UI:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize.
I like it a lot. I only have one outstanding question: what happens for a space with 1000+ documents in it? How does the UI scale?
I'm asking because given the current implementation of our treeview I know that this can be a huge PITA.
We're NOT going to use the current treeview, no way.
In my opinion we should actually aim to replace the treeview with this one (that's why I initially referred to it as a new 'extensible' treeview, in the sense it could be used for navigation in its simplest mode, but could be extended for selection).
A starting point, works with and without javascript pretty well: http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/SpaceTree
I'd also like to see how it scale (in terms of UI) to a large number of documents.
What about the parent/children relationship? Should we imitate what the current treeview does? If we were to replace the treeview by this new one, should it behave as the old one, or should it display the pages flat ?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, I've made Selective Export Proposal 2 (HTML + CSS) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposa... This proposal follows more closely existing features from MultiPageExport application, like: + Search by title/name/space/tags + Ordering in the export list (important for HTML and PDF) *Improvements* from Proposal 1 ( http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal): - separation of "Saved Packages" in another top tab - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed - Added: "reset to defaults" to export options values - Combined "Package Content" and "Export Options" under "Export documents as package" - Changed "Export" button position to top - Added deletion for saved packages + saving date Also, this proposal has 3 modes for pages relationship visualization: Space/Page Tree, Parent/Child Tree, List View Currently MultiPageExport application and XWiki WYSIWYG Search feature uses "List View" (page title + location) mode to display information. This should be the default mode to display information: less cryptic, with search you could find information that you don't know the location. Also the ordering (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries are independent. http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3... IMO, for export applications (XAR) "List View" is less usable and the the perfect candidate is "Space/Page Tree" view. http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8... Advanced users that will need "Space/Page Tree" or "Parent/Child Tree" will have to manually changed the display view and/or the export options, the others will relay on defaults. WDYT? Caty
On Mon, Jun 21, 2010 at 21:55, Ecaterina Valica <[email protected]> wrote:
Hi,
I've made Selective Export Proposal 2 (HTML + CSS) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposa...
This proposal follows more closely existing features from MultiPageExport application, like: + Search by title/name/space/tags + Ordering in the export list (important for HTML and PDF)
Why is it important for HTML export ? HTML export produce a different file for each page.
*Improvements* from Proposal 1 ( http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal):
- separation of "Saved Packages" in another top tab - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed - Added: "reset to defaults" to export options values - Combined "Package Content" and "Export Options" under "Export documents as package" - Changed "Export" button position to top - Added deletion for saved packages + saving date
Also, this proposal has 3 modes for pages relationship visualization: Space/Page Tree, Parent/Child Tree, List View
Currently MultiPageExport application and XWiki WYSIWYG Search feature uses "List View" (page title + location) mode to display information. This should be the default mode to display information: less cryptic, with search you could find information that you don't know the location. Also the ordering (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries are independent. http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3...
IMO, for export applications (XAR) "List View" is less usable and the the perfect candidate is "Space/Page Tree" view. http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8...
Advanced users that will need "Space/Page Tree" or "Parent/Child Tree" will have to manually changed the display view and/or the export options, the others will relay on defaults.
WDYT?
Caty _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Thomas Mortagne
On Mon, Jun 21, 2010 at 23:17, Thomas Mortagne <[email protected]>wrote:
On Mon, Jun 21, 2010 at 21:55, Ecaterina Valica <[email protected]> wrote:
Hi,
I've made Selective Export Proposal 2 (HTML + CSS)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposa...
This proposal follows more closely existing features from MultiPageExport application, like: + Search by title/name/space/tags + Ordering in the export list (important for HTML and PDF)
Why is it important for HTML export ? HTML export produce a different file for each page.
I don't know for sure, Ludo said that for HTML. I think it's important for PDF and RTF, so that you can customize page order for the final file. The problem with Proposal 2 is that I put the move arrows also for Space/Page Tree, but they shouldn't be there, because moving the pages, will break/duplicate the hierarchy. The reason I put them is to allow the same functionality in all the views, but we better remove them and keep them only for List View. Another problem with Proposal 2 is the initial view for List View: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MultiExport2Pro... Theoretical, initially there shouldn't be any results in the display (because no search has been made). The spaces are added to have consistency with the Tree View (when you change to Space/Page all spaces should be there). So the idea was to have the same data and the same functionality (moving) no matter the view (Space/Page or List), but I think they will be better made custom, and remove the spaces from initial display of List View (especially if List View will be the default display, and beginner user will not understand what they can do with those spaces, how they can navigate them). Problem number 3 :) is automatic change of views depending on the Export Type the user selects. The idea is to auto-change the view to "Space/Page Tree" when the user chooses XAR Export; or to auto-change the view to "List View" when the user selects PDF/RTF export. Is not indicated to mess with user preferences (maybe he wants only list view, no matter of export type), and should be done only if we agree that that's the best/optimum view for that export type. I would like to know your opinion on this 3 problems. Thanks, Caty
*Improvements* from Proposal 1 (
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal ):
- separation of "Saved Packages" in another top tab - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed - Added: "reset to defaults" to export options values - Combined "Package Content" and "Export Options" under "Export documents
as
package" - Changed "Export" button position to top - Added deletion for saved packages + saving date
Also, this proposal has 3 modes for pages relationship visualization: Space/Page Tree, Parent/Child Tree, List View
Currently MultiPageExport application and XWiki WYSIWYG Search feature uses "List View" (page title + location) mode to display information. This should be the default mode to display information: less cryptic, with search you could find information that you don't know the location. Also the ordering (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries are independent.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3...
IMO, for export applications (XAR) "List View" is less usable and the the perfect candidate is "Space/Page Tree" view.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8...
Advanced users that will need "Space/Page Tree" or "Parent/Child Tree"
will
have to manually changed the display view and/or the export options, the others will relay on defaults.
WDYT?
Caty _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On Tue, Jun 22, 2010 at 12:35, Ecaterina Valica <[email protected]> wrote:
On Mon, Jun 21, 2010 at 23:17, Thomas Mortagne <[email protected]>wrote:
On Mon, Jun 21, 2010 at 21:55, Ecaterina Valica <[email protected]> wrote:
Hi,
I've made Selective Export Proposal 2 (HTML + CSS)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposa...
This proposal follows more closely existing features from MultiPageExport application, like: + Search by title/name/space/tags + Ordering in the export list (important for HTML and PDF)
Why is it important for HTML export ? HTML export produce a different file for each page.
I don't know for sure, Ludo said that for HTML. I think it's important for PDF and RTF, so that you can customize page order for the final file.
The problem with Proposal 2 is that I put the move arrows also for Space/Page Tree, but they shouldn't be there, because moving the pages, will break/duplicate the hierarchy. The reason I put them is to allow the same functionality in all the views, but we better remove them and keep them only for List View.
Another problem with Proposal 2 is the initial view for List View: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MultiExport2Pro... Theoretical, initially there shouldn't be any results in the display (because no search has been made). The spaces are added to have consistency with the Tree View (when you change to Space/Page all spaces should be there). So the idea was to have the same data and the same functionality (moving) no matter the view (Space/Page or List), but I think they will be better made custom, and remove the spaces from initial display of List View (especially if List View will be the default display, and beginner user will not understand what they can do with those spaces, how they can navigate them).
Problem number 3 :) is automatic change of views depending on the Export Type the user selects. The idea is to auto-change the view to "Space/Page Tree" when the user chooses XAR Export; or to auto-change the view to "List View" when the user selects PDF/RTF export. Is not indicated to mess with user preferences (maybe he wants only list view, no matter of export type), and should be done only if we agree that that's the best/optimum view for that export type.
I think the Selective Export UI proposal should forget about the current PDF/RTF exporter and go in the direction of PDF/OpenOffice instead (PDF would probably still use FOP instead of OpenOffice). That means let use choose between a lot more formats depending if the openoffice server is connected or not.
I would like to know your opinion on this 3 problems. Thanks, Caty
*Improvements* from Proposal 1 (
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal ):
- separation of "Saved Packages" in another top tab - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed - Added: "reset to defaults" to export options values - Combined "Package Content" and "Export Options" under "Export documents
as
package" - Changed "Export" button position to top - Added deletion for saved packages + saving date
Also, this proposal has 3 modes for pages relationship visualization: Space/Page Tree, Parent/Child Tree, List View
Currently MultiPageExport application and XWiki WYSIWYG Search feature uses "List View" (page title + location) mode to display information. This should be the default mode to display information: less cryptic, with search you could find information that you don't know the location. Also the ordering (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries are independent.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3...
IMO, for export applications (XAR) "List View" is less usable and the the perfect candidate is "Space/Page Tree" view.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8...
Advanced users that will need "Space/Page Tree" or "Parent/Child Tree"
will
have to manually changed the display view and/or the export options, the others will relay on defaults.
WDYT?
Caty _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Thomas Mortagne
Hi Caty, I really apologize in advance for looking at this so late and also for my upcoming comments.... do not feel hurt please, but I do not feel that this interface will provide the nice export functionality we expect. First, here is a resume of my main remarks: - You need a big, large screen to see it properly, and at the same time, everything is small and concentrate. - There are too many choices at the same time, and this cause a real excess of complexity - Navigation in the list of document, and filtering, are absolutely different to what the user is accustomed to with LiveTable - Scalability issue increase the complexity in the document list, and choice of export format will not scale easily - Some export options (in the format box) change the list of document that will be exported after your initial choice Let me now review this in more details. 1) Screen size and complexity Putting together the 3 parts of this interface (full list, selected list and export options) make it complex and cluttered. IMO, there isn't several way to solve this. Each part should be in a separate screen. This will both decrease complexity, and allow more flexibility for composing each screen. These screens could than be linked together in a wizard like interface (Back/Next), and a direct access could also be provided using tabs or similar control. These tabs should also show the normal path of actions. 2) List of documents and scalability IMO, we should inspire the list of document from the livetable (not the tree) actually in AllDocs. We need to have it improved (also in AllDocs), but keeping the same look and feel between both of them will obviously helps both users and developers. The livetable in AllDocs already solve the scalability problem nicely, and users will be accustomed to it. What should be improved (in both place) ? - Allow filters on document contents or using the tagcloud. This will provide a mix with the search feature and the tag feature, but in a filter way (without sorting by relevance) - Allow customizing columns, since we might want to choose document based on creation date, modification date, authors, creators, presence of attachements, ... and not all of them could be proposed at once - Allow displaying hidden documents - Allow small popup document preview ? What should be added for export ? - A display of the selection status, probably near the name, on the left. - To allow user to select whole Space, why not list them in there own row, next to the documents, and provide a "type" filter to list only spaces, document or both. For spaces, the selection box could be three states, showing partially selected space. - "Add/remove all displayed item", "add/remove the whole filtered list", should be proposed for easy large selection/deselection. An undo option could be nice to have. 3) List of selected documents / Spaces To stay simple, this list should be very similar to the previous one (and influenced by the column customarily displayed in the previous step by the user). This is in fact a filtered view on the selection status. I would not mix it with the previous one, to provide a clear step by step way and a slightly different interface : - The selection status should be replace by a removal button. - Some external button should allow: - "Add Children" which will add one level of children of all selected page to the list - "Add All Children" which will add all children of selected page recursively to the list - "Add Linked Pages" which will add pages linked from currently selected page to the list - "Add All Linked Page" which will add pages linked from currently selected page recursively to the list - "Undo last addition" using one of the previous buttons which will return the list to its previous state - "Save current selection" which will allow saving the current selection for later use/reuse If the export contains unselected children pages, or unselected linked pages. It may be useful to warn the user of that situation on this screen. 4) Export options This last screen should allow the selection of the export format from a free list. After a deep refactoring, we should be able to easily implement new export format (using components) and this list of format should be dynamic. Obviously, the format options will be displayed depending of the chosen format (including custom interface by custom formats). But, these options should not change the list of exported pages in any way, this is confusing. 5) What about the hierarchical views IMO, we should stay away from them as much as we can since trees of large sets have a serious scalability issue (I means for the user, not only the computer). I have already provide some hints on how to provide children and link inclusion, but may be we can go one step further with reasonable complexity. For each rows of both table describe above, we may have several expanding box (a "small" lightbox), that shows: - the list of direct children of the page/space - the list of all children of the page taken recursively - the list of linked page from the page - the list of all linked page from the page taken recursively These boxes will display a similar list to the current one (without further expanding boxes), allowing review/selection of additional pages Well, there is probably many adjustment that could be needed on the way to this interface, and I hope my remarks will be the source of inspiration for an even better solution. Thanks to those who have read me, this is a little bit long... I know. Denis On Mon, Jun 21, 2010 at 21:55, Ecaterina Valica <[email protected]> wrote:
Hi,
I've made Selective Export Proposal 2 (HTML + CSS)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposa...
This proposal follows more closely existing features from MultiPageExport application, like: + Search by title/name/space/tags + Ordering in the export list (important for HTML and PDF)
*Improvements* from Proposal 1 (
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal ):
- separation of "Saved Packages" in another top tab - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed - Added: "reset to defaults" to export options values - Combined "Package Content" and "Export Options" under "Export documents as package" - Changed "Export" button position to top - Added deletion for saved packages + saving date
Also, this proposal has 3 modes for pages relationship visualization: Space/Page Tree, Parent/Child Tree, List View
Currently MultiPageExport application and XWiki WYSIWYG Search feature uses "List View" (page title + location) mode to display information. This should be the default mode to display information: less cryptic, with search you could find information that you don't know the location. Also the ordering (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries are independent.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3...
IMO, for export applications (XAR) "List View" is less usable and the the perfect candidate is "Space/Page Tree" view.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8...
Advanced users that will need "Space/Page Tree" or "Parent/Child Tree" will have to manually changed the display view and/or the export options, the others will relay on defaults.
WDYT?
Caty _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Tue, Jun 22, 2010 at 14:32, Denis Gervalle <[email protected]> wrote:
Hi Caty,
I really apologize in advance for looking at this so late and also for my upcoming comments.... do not feel hurt please, but I do not feel that this interface will provide the nice export functionality we expect.
First, here is a resume of my main remarks:
- You need a big, large screen to see it properly, and at the same time, everything is small and concentrate. - There are too many choices at the same time, and this cause a real excess of complexity - Navigation in the list of document, and filtering, are absolutely different to what the user is accustomed to with LiveTable - Scalability issue increase the complexity in the document list, and choice of export format will not scale easily - Some export options (in the format box) change the list of document that will be exported after your initial choice
Let me now review this in more details.
1) Screen size and complexity
Putting together the 3 parts of this interface (full list, selected list and export options) make it complex and cluttered. IMO, there isn't several way to solve this. Each part should be in a separate screen. This will both decrease complexity, and allow more flexibility for composing each screen.
These screens could than be linked
together in a wizard like interface (Back/Next), and a direct access could also be provided using tabs or similar control. These tabs should also show the normal path of actions.
I don't agree having separate screens. The pattern for this case is Collected Selection: when you want to collect items in one place from multiple pages / sources / searches. You should be able to change your mind (delete, reselect) about a selected page, without the need to go back and forth across wizard pages. Also you can't see all the already selected pages in the "Select documents for export" (search), because you can always change that view state (make another search, go into tree view, etc). So separate screens would be disturbing my flow, relying on my memory in order to know what I've selected. So "Select documents for export" and "Selected Pages / Package Content" need to stay together, in order for the actions (select/remove) to be natural and the user to feel in control about his selection. The user can have more paths of completion: 1) (A) Search/Browse/Select pages -> (B) See/Manage selected/saved pages -> (C) Adjust Export Options -> (D) Export 2) (B) See/Manage saved pages -> (C) Adjust Export Options -> (D) Export 3) (B) See/Manage saved pages -> -> (D) Export (rely on defaults) Export Options should be placed somewhere near the "Selected Pages", because they are part of the export process, but it's not mandatory to be on the same level. So the process is something like (A) - (B) ; (B) - (C). Idea (nr.1) Now, when you resize the prototype is trying to fit and has relatives width, but we could do something like: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MultiExport2Pro... The options could float on the next level. In the case we have lots of pages we want to export, we need to provide a shortcut top link to options. Another idea (nr.2) would be to have something like an vertical accordion that could expand/collapse elements that we don't need anymore. Something like "Hide Advertisement" http://www.nirmaltv.com/wp-content/uploads/2007/10/ads.gif done for hiding/showing search part "Select document for export" or done for "Export Option". Idea nr.3 would be to have just "Select documents for export" + "Selected Pages" and when you press on "Export", it will happen something like when you press on "Annotation". An overlay would appear where you can select what options you want to have. http://www.xwiki.org/xwiki/bin/download/Main/ReleaseNotesXWikiEnterprise23M1... The options could partially hide the Selected Pages, because the user doesn't need them anymore, since he is in the final step (he already decided what he wants to export). I think nr.3 is my favorite option, since you wouldn't have to scroll to get to options, options are not mandatory for the search/select process, but would make a great difference to have them in context (on the same page, without changing the view, reloading the page). If more agree on nr.3 I could make a mockup to see how it looks.
2) List of documents and scalability
IMO, we should inspire the list of document from the livetable (not the tree) actually in AllDocs. We need to have it improved (also in AllDocs), but keeping the same look and feel between both of them will obviously helps both users and developers. The livetable in AllDocs already solve the scalability problem nicely, and users will be accustomed to it.
Maybe it's just me, but I don't want that every control in XWiki to be a livetable. When I first started thinking about the Selective Export, the main idea was to have something very similar to the current Importer. http://www.xwiki.org/xwiki/bin/download/Main/ReleaseNotesXWikiEnterprise22/i... http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MultiExport2Pro... And they should be similar because they are dual actions: export / import. Also the tree view for XAR files is optimal IMO.
What should be improved (in both place) ? - Allow filters on document contents or using the tagcloud. This will provide a mix with the search feature and the tag feature, but in a filter way (without sorting by relevance) - Allow customizing columns, since we might want to choose document based on creation date, modification date, authors, creators, presence of attachements, ... and not all of them could be proposed at once - Allow displaying hidden documents - Allow small popup document preview ?
if the names are links we don't need the preview
What should be added for export ? - A display of the selection status, probably near the name, on the left. - To allow user to select whole Space, why not list them in there own row, next to the documents, and provide a "type" filter to list only spaces, document or both. For spaces, the selection box could be three states, showing partially selected space. - "Add/remove all displayed item", "add/remove the whole filtered list", should be proposed for easy large selection/deselection. An undo option could be nice to have.
This UI version is doable, but I don't know if this is really the direction we want to take. More opinions would help. The selection would look something like Gmail or Yahoo.
3) List of selected documents / Spaces
To stay simple, this list should be very similar to the previous one (and influenced by the column customarily displayed in the previous step by the user). This is in fact a filtered view on the selection status. I would not mix it with the previous one, to provide a clear step by step way and a slightly different interface : - The selection status should be replace by a removal button. - Some external button should allow: - "Add Children" which will add one level of children of all selected page to the list - "Add All Children" which will add all children of selected page recursively to the list - "Add Linked Pages" which will add pages linked from currently selected page to the list - "Add All Linked Page" which will add pages linked from currently selected page recursively to the list - "Undo last addition" using one of the previous buttons which will return the list to its previous state - "Save current selection" which will allow saving the current selection for later use/reuse
If the export contains unselected children pages, or unselected linked pages. It may be useful to warn the user of that situation on this screen.
4) Export options
This last screen should allow the selection of the export format from a free list. After a deep refactoring, we should be able to easily implement new export format (using components) and this list of format should be dynamic. Obviously, the format options will be displayed depending of the chosen format (including custom interface by custom formats). But, these options should not change the list of exported pages in any way, this is confusing.
If we get more space for displaying Export Options, then I don't see any problem in having tabs for showing options. This scales.
5) What about the hierarchical views
IMO, we should stay away from them as much as we can since trees of large sets have a serious scalability issue (I means for the user, not only the computer). I have already provide some hints on how to provide children and link inclusion, but may be we can go one step further with reasonable complexity.
For each rows of both table describe above, we may have several expanding box (a "small" lightbox), that shows: - the list of direct children of the page/space - the list of all children of the page taken recursively - the list of linked page from the page - the list of all linked page from the page taken recursively These boxes will display a similar list to the current one (without further expanding boxes), allowing review/selection of additional pages
IMO trees are very good at reflecting hierarchy (space/page and parent/child). And this is the way users are organizing and browsing (also in WYSIWYG) their content inside XWiki, by using the breadcrumbs and by mentioning always the space (page creation, copy, searching). The reason I added the List View was to accomodate work already done for MultiPageExport application http://code.xwiki.org/xwiki/bin/view/Applications/MultiPageExportApplication How much from what is in MultiPageExport application can be reused for the "livetable" version? Also, the first version of Selective Export proposal received nice feedback. So I'm not sure we should rethink this UI. WDYT? Any other opinions? Thanks, Caty
Well, there is probably many adjustment that could be needed on the way to this interface, and I hope my remarks will be the source of inspiration for an even better solution. Thanks to those who have read me, this is a little bit long... I know.
Denis
On Mon, Jun 21, 2010 at 21:55, Ecaterina Valica <[email protected]> wrote:
Hi,
I've made Selective Export Proposal 2 (HTML + CSS)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposa...
This proposal follows more closely existing features from MultiPageExport application, like: + Search by title/name/space/tags + Ordering in the export list (important for HTML and PDF)
*Improvements* from Proposal 1 (
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
):
- separation of "Saved Packages" in another top tab - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed - Added: "reset to defaults" to export options values - Combined "Package Content" and "Export Options" under "Export documents as package" - Changed "Export" button position to top - Added deletion for saved packages + saving date
Also, this proposal has 3 modes for pages relationship visualization: Space/Page Tree, Parent/Child Tree, List View
Currently MultiPageExport application and XWiki WYSIWYG Search feature uses "List View" (page title + location) mode to display information. This should be the default mode to display information: less cryptic, with search you could find information that you don't know the location. Also the ordering (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries are independent.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3...
IMO, for export applications (XAR) "List View" is less usable and the the perfect candidate is "Space/Page Tree" view.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8...
Advanced users that will need "Space/Page Tree" or "Parent/Child Tree"
will
have to manually changed the display view and/or the export options, the others will relay on defaults.
For my comments, I use your convention, to avoid speaking about screen or part of screen (A) is the Search/Browse/Select pages functionality (B) is the See/Manage selected/saved pages functionality (C) is the Adjust Export Options functionality On Thu, Jun 24, 2010 at 23:33, Ecaterina Valica <[email protected]> wrote:
On Tue, Jun 22, 2010 at 14:32, Denis Gervalle <[email protected]> wrote:
Hi Caty,
I really apologize in advance for looking at this so late and also for my upcoming comments.... do not feel hurt please, but I do not feel that this interface will provide the nice export functionality we expect.
First, here is a resume of my main remarks:
- You need a big, large screen to see it properly, and at the same time, everything is small and concentrate. - There are too many choices at the same time, and this cause a real excess of complexity - Navigation in the list of document, and filtering, are absolutely different to what the user is accustomed to with LiveTable - Scalability issue increase the complexity in the document list, and choice of export format will not scale easily - Some export options (in the format box) change the list of document that will be exported after your initial choice
Let me now review this in more details.
1) Screen size and complexity
Putting together the 3 parts of this interface (full list, selected list and export options) make it complex and cluttered. IMO, there isn't several way to solve this. Each part should be in a separate screen. This will both decrease complexity, and allow more flexibility for composing each screen.
These screens could than be linked
together in a wizard like interface (Back/Next), and a direct access could also be provided using tabs or similar control. These tabs should also show the normal path of actions.
I don't agree having separate screens. The pattern for this case is Collected Selection: when you want to collect items in one place from multiple pages / sources / searches. You should be able to change your mind (delete, reselect) about a selected page, without the need to go back and forth across wizard pages.
Do you means that the way most eCommerce site works using a cart is so bad ? Moreover, from my understanding, deselection is available with (A). The main difference is that (A) is a filtered view over the whole wiki and (B) is a potentially filtered view over the upcoming package with some ordering features. For me (A) and (B) provide 2 really distinct functionality, this is why I have not merged them in a single table, but if (A) and (B) were only a selection feature, a single table would have been sufficient.
Also you can't see all the already selected pages in the "Select documents for export" (search), because you can always change that view state (make another search, go into tree view, etc). So separate screens would be disturbing my flow, relying on my memory in order to know what I've selected
Even if I can agree to some point for small package, you will always have to rely a little on your mind, since displaying the whole package content will not be always possible. Note that screen are not pages, and switching is fast. Apart from the complexity aspects, you should really consider that not every one has a 26" screen, and that all skins will not always allow such large display. During (A), you have also information displayed (B), so I do not really feel the need to have both together.
So "Select documents for export" and "Selected Pages / Package Content" need to stay together, in order for the actions (select/remove) to be natural and the user to feel in control about his selection.
The user can have more paths of completion:
1) (A) Search/Browse/Select pages -> (B) See/Manage selected/saved pages -> (C) Adjust Export Options -> (D) Export 2) (B) See/Manage saved pages -> (C) Adjust Export Options -> (D) Export 3) (B) See/Manage saved pages -> -> (D) Export (rely on defaults)
Export Options should be placed somewhere near the "Selected Pages", because they are part of the export process, but it's not mandatory to be on the same level.
I agree on that point, since (B) may have some ordering feature depending on the format, this implies knowing the format earlier. On the other side, I do not think (C) options should influence (B) and need to be side by side with it. (C) is detailled options, not selections.
So the process is something like (A) - (B) ; (B) - (C).
Not really, it could be (A) - (B) then (C), if (C) does not influence (B). In my proposal, I was putting option that influence (B), in (B), not (C).
Idea (nr.1) Now, when you resize the prototype is trying to fit and has relatives width, but we could do something like:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MultiExport2Pro... The options could float on the next level. In the case we have lots of pages we want to export, we need to provide a shortcut top link to options.
Another idea (nr.2) would be to have something like an vertical accordion that could expand/collapse elements that we don't need anymore. Something like "Hide Advertisement" http://www.nirmaltv.com/wp-content/uploads/2007/10/ads.gif done for hiding/showing search part "Select document for export" or done for "Export Option".
Accordion or slider could be a way to provide my separated view between (A) and (B), combined with your nr.3 below for (C) this could be a really nice interface. If we can provide a way for small screen and large screen to be used efficiently, I am really not against. But presenting the whole interface at once is IMO too complex for casual user, and some guidance is require anyway.
Idea nr.3 would be to have just "Select documents for export" + "Selected Pages" and when you press on "Export", it will happen something like when you press on "Annotation". An overlay would appear where you can select what options you want to have.
http://www.xwiki.org/xwiki/bin/download/Main/ReleaseNotesXWikiEnterprise23M1... The options could partially hide the Selected Pages, because the user doesn't need them anymore, since he is in the final step (he already decided what he wants to export).
I think nr.3 is my favorite option, since you wouldn't have to scroll to get to options, options are not mandatory for the search/select process, but would make a great difference to have them in context (on the same page, without changing the view, reloading the page).
If more agree on nr.3 I could make a mockup to see how it looks.
2) List of documents and scalability
IMO, we should inspire the list of document from the livetable (not the tree) actually in AllDocs. We need to have it improved (also in AllDocs), but keeping the same look and feel between both of them will obviously helps both users and developers. The livetable in AllDocs already solve the scalability problem nicely, and users will be accustomed to it.
Maybe it's just me, but I don't want that every control in XWiki to be a livetable. When I first started thinking about the Selective Export, the main idea was to have something very similar to the current Importer.
http://www.xwiki.org/xwiki/bin/download/Main/ReleaseNotesXWikiEnterprise22/i...
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MultiExport2Pro...
And they should be similar because they are dual actions: export / import. Also the tree view for XAR files is optimal IMO.
As you said, the importer is nice, because it manage only XAR files, and the tree view fits well. But don't be fooled, the importer is not so scalable (not only form the interface POV however), and with large XAR, it is very difficult to properly import part of a XAR. Selection is a pain, and can only be done based on very basic criteria. So this not a model to follow if we want to improve the functionality. On the other hand, the best UI should not use many different controls for the same final purpose. The LiveTable is the best solution we currently have for displaying lists, it is already scalable, has already an efficient navigation, already provide filters and tag cloud functionality, etc... it really fit the needs, so why use a less featured control ? especially one that user should be accustomed to.
What should be improved (in both place) ?
- Allow filters on document contents or using the tagcloud. This will provide a mix with the search feature and the tag feature, but in a filter way (without sorting by relevance) - Allow customizing columns, since we might want to choose document based on creation date, modification date, authors, creators, presence of attachements, ... and not all of them could be proposed at once - Allow displaying hidden documents - Allow small popup document preview ?
if the names are links we don't need the preview
My question mark was not innocent :)
What should be added for export ?
- A display of the selection status, probably near the name, on the left. - To allow user to select whole Space, why not list them in there own row, next to the documents, and provide a "type" filter to list only spaces, document or both. For spaces, the selection box could be three states, showing partially selected space. - "Add/remove all displayed item", "add/remove the whole filtered list", should be proposed for easy large selection/deselection. An undo option could be nice to have.
This UI version is doable, but I don't know if this is really the direction we want to take. More opinions would help. The selection would look something like Gmail or Yahoo.
I do not know what direction we want to take, but I know what I want to be able to do with export: - Export document matching a given name, tags, ... - Export a given set of spaces, - Export document created/changed since a given date - Export a whole set of document linked (hierarchicaly also) together - Export document (not) having attachements - Export (not) hidden document - Export the same set than last time - ... and a mix of all the above together. Do you think that what I expect are not valid use cases ? For the selection aspect, GMail is nice at selecting elements in large list. For search aspect, I have always find advanced Google search really cryptic.
3) List of selected documents / Spaces
To stay simple, this list should be very similar to the previous one (and influenced by the column customarily displayed in the previous step by the user). This is in fact a filtered view on the selection status. I would not mix it with the previous one, to provide a clear step by step way and a slightly different interface : - The selection status should be replace by a removal button. - Some external button should allow: - "Add Children" which will add one level of children of all selected page to the list - "Add All Children" which will add all children of selected page recursively to the list - "Add Linked Pages" which will add pages linked from currently selected page to the list - "Add All Linked Page" which will add pages linked from currently selected page recursively to the list - "Undo last addition" using one of the previous buttons which will return the list to its previous state - "Save current selection" which will allow saving the current selection for later use/reuse
If the export contains unselected children pages, or unselected linked pages. It may be useful to warn the user of that situation on this screen.
4) Export options
This last screen should allow the selection of the export format from a free list. After a deep refactoring, we should be able to easily implement new export format (using components) and this list of format should be dynamic. Obviously, the format options will be displayed depending of the chosen format (including custom interface by custom formats). But, these options should not change the list of exported pages in any way, this is confusing.
If we get more space for displaying Export Options, then I don't see any problem in having tabs for showing options. This scales.
If it scales, no problem for me, but I really dislike having more than one line of tabs, it generally produce confusing UI.
5) What about the hierarchical views
IMO, we should stay away from them as much as we can since trees of large sets have a serious scalability issue (I means for the user, not only the computer). I have already provide some hints on how to provide children and link inclusion, but may be we can go one step further with reasonable complexity.
For each rows of both table describe above, we may have several expanding box (a "small" lightbox), that shows: - the list of direct children of the page/space - the list of all children of the page taken recursively - the list of linked page from the page - the list of all linked page from the page taken recursively These boxes will display a similar list to the current one (without further expanding boxes), allowing review/selection of additional pages
IMO trees are very good at reflecting hierarchy (space/page and
parent/child). And this is the way users are organizing and browsing (also in WYSIWYG) their content inside XWiki, by using the breadcrumbs and by mentioning always the space (page creation, copy, searching).
I agree, but it does not scale, and this is probably an issue not only in the export. From my experience, selection in trees is always a pain, and really less efficient than lists and filters.
The reason I added the List View was to accomodate work already done for MultiPageExport application
http://code.xwiki.org/xwiki/bin/view/Applications/MultiPageExportApplication
How much from what is in MultiPageExport application can be reused for the "livetable" version?
Also, the first version of Selective Export proposal received nice feedback.
As I have said, I feel sorry coming so late with my comments. I am just wondering if all use cases have been properly taken into consideration.
So I'm not sure we should rethink this UI. WDYT? Any other opinions?
I am curious too, I may be wrong ;), but I am sure it could be improved ! Denis
Thanks, Caty
Well, there is probably many adjustment that could be needed on the way to this interface, and I hope my remarks will be the source of inspiration for an even better solution. Thanks to those who have read me, this is a little bit long... I know.
Denis
On Mon, Jun 21, 2010 at 21:55, Ecaterina Valica <[email protected]> wrote:
Hi,
I've made Selective Export Proposal 2 (HTML + CSS)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposa...
This proposal follows more closely existing features from
MultiPageExport
application, like: + Search by title/name/space/tags + Ordering in the export list (important for HTML and PDF)
*Improvements* from Proposal 1 (
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal
):
- separation of "Saved Packages" in another top tab - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed - Added: "reset to defaults" to export options values - Combined "Package Content" and "Export Options" under "Export documents as package" - Changed "Export" button position to top - Added deletion for saved packages + saving date
Also, this proposal has 3 modes for pages relationship visualization: Space/Page Tree, Parent/Child Tree, List View
Currently MultiPageExport application and XWiki WYSIWYG Search feature uses "List View" (page title + location) mode to display information. This should be the default mode to display information: less cryptic, with search you could find information that you don't know the location. Also the ordering (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries are independent.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3...
IMO, for export applications (XAR) "List View" is less usable and the
the
perfect candidate is "Space/Page Tree" view.
http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8...
Advanced users that will need "Space/Page Tree" or "Parent/Child Tree"
will
have to manually changed the display view and/or the export options, the others will relay on defaults.
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (8)
-
Arnaud bourree -
Denis Gervalle -
Ecaterina Valica -
Guillaume Lerouge -
Jean-Vincent Drean -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne