[xwiki-devs] [VOTE][UI] WYSIWYG Wiki Explorer
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details). After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu. I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs. Here's my +1 for 3) A). +1 for 3) with filter option.
From the implementation POV 3) is probably the most difficult proposal and 1) the simplest one. Widget 3) would need to be a reusable (and highly configurable) GWT component so that we could use it as our main navigation/reorganization tool in the future. This tree would replace our current treeview (Main.AllDocs) which is AFAIR the only page using the YUI library in XE.
Thanks, JV.
On Nov 25, 2008, at 5:05 PM, Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/ NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
+1 for 3) but provided we have a filter box above the tree to filter pages/attachments/spaces/wikis +1 for 3B or 3C. 3A doesn't scale with the number of pages.
From the implementation POV 3) is probably the most difficult proposal and 1) the simplest one. Widget 3) would need to be a reusable (and highly configurable) GWT component so that we could use it as our main navigation/reorganization tool in the future. This tree would replace our current treeview (Main.AllDocs) which is AFAIR the only page using the YUI library in XE.
+1 for replacing the current index treeview and have a single implementation (will require drag and drop for the index). Re GWT +1 provided we can find an easy way to do drag and drop (I hope it exists and that we won't have to rewrite it - Otherwise might be better to use another ajax fwk maybe?) Thanks -Vincent
On Tue, Nov 25, 2008 at 5:16 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:05 PM, Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/ NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
There's filter option at the bottom-right of the (pretty big) mockup :) JV.
On Nov 25, 2008, at 5:19 PM, Jean-Vincent Drean wrote:
On Tue, Nov 25, 2008 at 5:16 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:05 PM, Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/ NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
There's filter option at the bottom-right of the (pretty big) mockup :)
ok didn't see it... :) hmmm I think I'd put it above the tree as otherwise it's crowded and you run the risk of collision between the first line text and the filter box. Otherwise it's great. Thanks -Vincent
Hi, On Tue, Nov 25, 2008 at 5:26 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:19 PM, Jean-Vincent Drean wrote:
On Tue, Nov 25, 2008 at 5:16 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:05 PM, Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/ NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
I'm non-binding +1 for 3) B with the filter. Guillaume
There's filter option at the bottom-right of the (pretty big) mockup :)
ok didn't see it... :)
hmmm I think I'd put it above the tree as otherwise it's crowded and you run the risk of collision between the first line text and the filter box.
Otherwise it's great.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/
Hi, Guillaume Lerouge a écrit :
Hi,
On Tue, Nov 25, 2008 at 5:26 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:19 PM, Jean-Vincent Drean wrote:
On Tue, Nov 25, 2008 at 5:16 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:05 PM, Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/ NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
I'm non-binding +1 for 3) B with the filter.
Guillaume
+1 for 3) A) (+ filter if possible). I think that having to scroll and see the existing pages of a space (or spaces of a wiki, or attached documents of a page) before creating a new entry is not a bad thing. Thomas
There's filter option at the bottom-right of the (pretty big) mockup :)
ok didn't see it... :)
hmmm I think I'd put it above the tree as otherwise it's crowded and you run the risk of collision between the first line text and the filter box.
Otherwise it's great.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 25, 2008, at 5:35 PM, Thomas Eveilleau wrote:
Hi,
Guillaume Lerouge a écrit :
Hi,
On Tue, Nov 25, 2008 at 5:26 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:19 PM, Jean-Vincent Drean wrote:
On Tue, Nov 25, 2008 at 5:16 PM, Vincent Massol <[email protected]> wrote:
On Nov 25, 2008, at 5:05 PM, Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/ NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
I'm non-binding +1 for 3) B with the filter.
Guillaume
+1 for 3) A) (+ filter if possible). I think that having to scroll and see the existing pages of a space (or spaces of a wiki, or attached documents of a page) before creating a new entry is not a bad thing.
You should try doing this in the XWiki space on xwiki.org... then come back here :) There are 2 problems: 1) it won't work when there are a large number of documents (for ex, there are thousands of XWiki users on xwiki.org) 2) it's not intuitive at all since the user has to scroll to see the action. How will he know he has to do that to add a new page if that link is not visible? Thanks -Vincent
Thomas
There's filter option at the bottom-right of the (pretty big) mockup :)
ok didn't see it... :)
hmmm I think I'd put it above the tree as otherwise it's crowded and you run the risk of collision between the first line text and the filter box.
Otherwise it's great.
Thanks -Vincent
Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
+1 for 3A), despite the fact that user needs to scroll through all the pages to add his new one.There are 2 usecases for adding a new page: * the user hasn't found the page he's looking for -- in which case he'd need to see the whole list anyway (maybe with a search filter) * the user knows that the page does not exist and wants to put a link to it -- in which case I think he knows what he's doing and he'd use the "advanced input" anyway. I find the add option _at the end_ (A) more natural than _at the beginning_ (B, C), because you're supposed to add new things when you've explored all other possibilities and none suited your needs. Happy coding, Anca Luca
From the implementation POV 3) is probably the most difficult proposal and 1) the simplest one. Widget 3) would need to be a reusable (and highly configurable) GWT component so that we could use it as our main navigation/reorganization tool in the future. This tree would replace our current treeview (Main.AllDocs) which is AFAIR the only page using the YUI library in XE.
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Nov 25, 2008 at 5:45 PM, Anca Paula Luca <[email protected]> wrote:
+1 for 3A), despite the fact that user needs to scroll through all the pages to add his new one.There are 2 usecases for adding a new page: * the user hasn't found the page he's looking for -- in which case he'd need to see the whole list anyway (maybe with a search filter) * the user knows that the page does not exist and wants to put a link to it -- in which case I think he knows what he's doing and he'd use the "advanced input" anyway.
I find the add option _at the end_ (A) more natural than _at the beginning_ (B, C), because you're supposed to add new things when you've explored all other possibilities and none suited your needs.
Thanks for summarizing my thoughts on this :) JV.
On Nov 25, 2008, at 5:45 PM, Anca Paula Luca wrote:
Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
+1 for 3A), despite the fact that user needs to scroll through all the pages to add his new one.There are 2 usecases for adding a new page: * the user hasn't found the page he's looking for -- in which case he'd need to see the whole list anyway (maybe with a search filter) * the user knows that the page does not exist and wants to put a link to it -- in which case I think he knows what he's doing and he'd use the "advanced input" anyway.
I find the add option _at the end_ (A) more natural than _at the beginning_ (B, C), because you're supposed to add new things when you've explored all other possibilities and none suited your needs.
So to follow your strategy, if I want to add a page in the XWiki space, I'll have either to scroll by thousands of documents or enter some characters in the filter so that I know it won't return lots of matches so that I can then see the add page link... hmm... doesn't sound right to me. What am I missing (I'm asking since everyone seems to agree with A). Thanks -Vincent
Happy coding, Anca Luca
From the implementation POV 3) is probably the most difficult proposal and 1) the simplest one. Widget 3) would need to be a reusable (and highly configurable) GWT component so that we could use it as our main navigation/reorganization tool in the future. This tree would replace our current treeview (Main.AllDocs) which is AFAIR the only page using the YUI library in XE.
Thanks, JV.
Vincent Massol wrote: > On Nov 25, 2008, at 5:45 PM, Anca Paula Luca wrote: > >> Jean-Vincent Drean wrote: >>> In a previous thread we've discussed about how to add a link in the >>> WYSIWYG editor, and more generally, how to browse the wiki from a >>> WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn >>> for more details). >>> >>> After some thinking and a discussion with Laurent Lunati, I'd like to >>> suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced >>> tree menu. >>> >>> I've put the mockups and Pros/Cons on this wiki page : >>> http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer >>> This wiki explorer widget would be used in the link dialogs, image >>> dialogs, file (attachment) dialogs. >>> >>> Here's my +1 for 3) A). >>> +1 for 3) with filter option. >> +1 for 3A), despite the fact that user needs to scroll through all >> the pages to >> add his new one.There are 2 usecases for adding a new page: >> * the user hasn't found the page he's looking for -- in which case >> he'd need to >> see the whole list anyway (maybe with a search filter) >> * the user knows that the page does not exist and wants to put a >> link to it -- >> in which case I think he knows what he's doing and he'd use the >> "advanced input" >> anyway. >> >> I find the add option _at the end_ (A) more natural than _at the >> beginning_ (B, >> C), because you're supposed to add new things when you've explored >> all other >> possibilities and none suited your needs. > > So to follow your strategy, if I want to add a page in the XWiki > space, I'll have either to scroll by thousands of documents or enter > some characters in the filter so that I know it won't return lots of > matches so that I can then see the add page link... > > hmm... doesn't sound right to me. > > What am I missing (I'm asking since everyone seems to agree with A). I assumed that if you know _for sure_ that you want to add a page, then you know what you're doing, and adding your "path" in the input box on the right (wiki:space.newpage) would be the easier choice for you anyway. I admit my assumption might not hold, but I find it probable enough. > > Thanks > -Vincent > >> Happy coding, >> Anca Luca >> >>> From the implementation POV 3) is probably the most difficult >>> proposal >>> and 1) the simplest one. Widget 3) would need to be a reusable (and >>> highly configurable) GWT component so that we could use it as our >>> main >>> navigation/reorganization tool in the future. This tree would replace >>> our current treeview (Main.AllDocs) which is AFAIR the only page >>> using >>> the YUI library in XE. >>> >>> Thanks, >>> JV. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
On Nov 25, 2008, at 6:15 PM, Anca Paula Luca wrote: > Vincent Massol wrote: >> On Nov 25, 2008, at 5:45 PM, Anca Paula Luca wrote: >> >>> Jean-Vincent Drean wrote: >>>> In a previous thread we've discussed about how to add a link in the >>>> WYSIWYG editor, and more generally, how to browse the wiki from a >>>> WYSIWYG dialog box (See http://markmail.org/message/ >>>> tyxrcr24w3n6m2pn >>>> for more details). >>>> >>>> After some thinking and a discussion with Laurent Lunati, I'd >>>> like to >>>> suggest a 3rd way of browsing the wiki from the WYSIWYG: an >>>> enhanced >>>> tree menu. >>>> >>>> I've put the mockups and Pros/Cons on this wiki page : >>>> http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer >>>> This wiki explorer widget would be used in the link dialogs, image >>>> dialogs, file (attachment) dialogs. >>>> >>>> Here's my +1 for 3) A). >>>> +1 for 3) with filter option. >>> +1 for 3A), despite the fact that user needs to scroll through all >>> the pages to >>> add his new one.There are 2 usecases for adding a new page: >>> * the user hasn't found the page he's looking for -- in which case >>> he'd need to >>> see the whole list anyway (maybe with a search filter) >>> * the user knows that the page does not exist and wants to put a >>> link to it -- >>> in which case I think he knows what he's doing and he'd use the >>> "advanced input" >>> anyway. >>> >>> I find the add option _at the end_ (A) more natural than _at the >>> beginning_ (B, >>> C), because you're supposed to add new things when you've explored >>> all other >>> possibilities and none suited your needs. >> >> So to follow your strategy, if I want to add a page in the XWiki >> space, I'll have either to scroll by thousands of documents or enter >> some characters in the filter so that I know it won't return lots of >> matches so that I can then see the add page link... >> >> hmm... doesn't sound right to me. >> >> What am I missing (I'm asking since everyone seems to agree with A). > > I assumed that if you know _for sure_ that you want to add a page, > then you know > what you're doing, and adding your "path" in the input box on the > right > (wiki:space.newpage) would be the easier choice for you anyway. How would you upload a file with that input box? Thanks -Vincent > I admit my assumption might not hold, but I find it probable enough. > >> >> Thanks >> -Vincent >> >>> Happy coding, >>> Anca Luca >>> >>>> From the implementation POV 3) is probably the most difficult >>>> proposal >>>> and 1) the simplest one. Widget 3) would need to be a reusable (and >>>> highly configurable) GWT component so that we could use it as our >>>> main >>>> navigation/reorganization tool in the future. This tree would >>>> replace >>>> our current treeview (Main.AllDocs) which is AFAIR the only page >>>> using >>>> the YUI library in XE. >>>> >>>> Thanks, >>>> JV.
Vincent Massol wrote: > On Nov 25, 2008, at 6:15 PM, Anca Paula Luca wrote: > >> Vincent Massol wrote: >>> On Nov 25, 2008, at 5:45 PM, Anca Paula Luca wrote: >>> >>>> Jean-Vincent Drean wrote: >>>>> In a previous thread we've discussed about how to add a link in the >>>>> WYSIWYG editor, and more generally, how to browse the wiki from a >>>>> WYSIWYG dialog box (See http://markmail.org/message/ >>>>> tyxrcr24w3n6m2pn >>>>> for more details). >>>>> >>>>> After some thinking and a discussion with Laurent Lunati, I'd >>>>> like to >>>>> suggest a 3rd way of browsing the wiki from the WYSIWYG: an >>>>> enhanced >>>>> tree menu. >>>>> >>>>> I've put the mockups and Pros/Cons on this wiki page : >>>>> http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer >>>>> This wiki explorer widget would be used in the link dialogs, image >>>>> dialogs, file (attachment) dialogs. >>>>> >>>>> Here's my +1 for 3) A). >>>>> +1 for 3) with filter option. >>>> +1 for 3A), despite the fact that user needs to scroll through all >>>> the pages to >>>> add his new one.There are 2 usecases for adding a new page: >>>> * the user hasn't found the page he's looking for -- in which case >>>> he'd need to >>>> see the whole list anyway (maybe with a search filter) >>>> * the user knows that the page does not exist and wants to put a >>>> link to it -- >>>> in which case I think he knows what he's doing and he'd use the >>>> "advanced input" >>>> anyway. >>>> >>>> I find the add option _at the end_ (A) more natural than _at the >>>> beginning_ (B, >>>> C), because you're supposed to add new things when you've explored >>>> all other >>>> possibilities and none suited your needs. >>> So to follow your strategy, if I want to add a page in the XWiki >>> space, I'll have either to scroll by thousands of documents or enter >>> some characters in the filter so that I know it won't return lots of >>> matches so that I can then see the add page link... >>> >>> hmm... doesn't sound right to me. >>> >>> What am I missing (I'm asking since everyone seems to agree with A). >> I assumed that if you know _for sure_ that you want to add a page, >> then you know >> what you're doing, and adding your "path" in the input box on the >> right >> (wiki:space.newpage) would be the easier choice for you anyway. > > How would you upload a file with that input box? A very good qustion which brings the subject of references to unexisting objects from the "advanced users input". We could do some tricks (since we're providing file preview anyway) to have an upload box load in the place of the preview when the file does not exist, but I don't think I like this very much from an implementation standpoint (and a pretty crowded UI -- speaking of which, is this whole thing supposed to be displayed in a dialog / lightbox ?). C) could do the job still, but I don't like the idea of having "create new" options in the exploration tool _above_ all options, I think it eludes the concept of an exploration tool by encouraging the users to add new before search existing. > > Thanks > -Vincent > >> I admit my assumption might not hold, but I find it probable enough. >> >>> Thanks >>> -Vincent >>> >>>> Happy coding, >>>> Anca Luca >>>> >>>>> From the implementation POV 3) is probably the most difficult >>>>> proposal >>>>> and 1) the simplest one. Widget 3) would need to be a reusable (and >>>>> highly configurable) GWT component so that we could use it as our >>>>> main >>>>> navigation/reorganization tool in the future. This tree would >>>>> replace >>>>> our current treeview (Main.AllDocs) which is AFAIR the only page >>>>> using >>>>> the YUI library in XE. >>>>> >>>>> Thanks, >>>>> JV. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
Anca Paula Luca wrote: > Vincent Massol wrote: >> On Nov 25, 2008, at 6:15 PM, Anca Paula Luca wrote: >> >>> Vincent Massol wrote: >>>> On Nov 25, 2008, at 5:45 PM, Anca Paula Luca wrote: >>>> >>>>> Jean-Vincent Drean wrote: >>>>>> In a previous thread we've discussed about how to add a link in the >>>>>> WYSIWYG editor, and more generally, how to browse the wiki from a >>>>>> WYSIWYG dialog box (See http://markmail.org/message/ >>>>>> tyxrcr24w3n6m2pn >>>>>> for more details). >>>>>> >>>>>> After some thinking and a discussion with Laurent Lunati, I'd >>>>>> like to >>>>>> suggest a 3rd way of browsing the wiki from the WYSIWYG: an >>>>>> enhanced >>>>>> tree menu. >>>>>> >>>>>> I've put the mockups and Pros/Cons on this wiki page : >>>>>> http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer >>>>>> This wiki explorer widget would be used in the link dialogs, image >>>>>> dialogs, file (attachment) dialogs. >>>>>> >>>>>> Here's my +1 for 3) A). >>>>>> +1 for 3) with filter option. >>>>> +1 for 3A), despite the fact that user needs to scroll through all >>>>> the pages to >>>>> add his new one.There are 2 usecases for adding a new page: >>>>> * the user hasn't found the page he's looking for -- in which case >>>>> he'd need to >>>>> see the whole list anyway (maybe with a search filter) >>>>> * the user knows that the page does not exist and wants to put a >>>>> link to it -- >>>>> in which case I think he knows what he's doing and he'd use the >>>>> "advanced input" >>>>> anyway. >>>>> >>>>> I find the add option _at the end_ (A) more natural than _at the >>>>> beginning_ (B, >>>>> C), because you're supposed to add new things when you've explored >>>>> all other >>>>> possibilities and none suited your needs. >>>> So to follow your strategy, if I want to add a page in the XWiki >>>> space, I'll have either to scroll by thousands of documents or enter >>>> some characters in the filter so that I know it won't return lots of >>>> matches so that I can then see the add page link... >>>> >>>> hmm... doesn't sound right to me. >>>> >>>> What am I missing (I'm asking since everyone seems to agree with A). >>> I assumed that if you know _for sure_ that you want to add a page, >>> then you know >>> what you're doing, and adding your "path" in the input box on the >>> right >>> (wiki:space.newpage) would be the easier choice for you anyway. >> How would you upload a file with that input box? > > A very good qustion which brings the subject of references to unexisting objects > from the "advanced users input". > > We could do some tricks (since we're providing file preview anyway) to have an > upload box load in the place of the preview when the file does not exist, but I > don't think I like this very much from an implementation standpoint (and a > pretty crowded UI -- speaking of which, is this whole thing supposed to be > displayed in a dialog / lightbox ?). > > C) could do the job still, but I don't like the idea of having "create new" > options in the exploration tool _above_ all options, I think it eludes the > concept of an exploration tool by encouraging the users to add new before search > existing. also, all the placeholders I've seen were at the end of the lists, usually, but I'm not a HCI expert. On another hand, We can actually think of the reverse problem: users using the exploring tool to find the objects they need scroll through all the pages and realize their page is not there. They have to scroll back to the top to get the add link. Indeed, in this case, the users would rather use the search tool, which is slightly, a different paradigm, so maybe we should think about providing different interface for adding data than one embedded in the exploring tool. > >> Thanks >> -Vincent >> >>> I admit my assumption might not hold, but I find it probable enough. >>> >>>> Thanks >>>> -Vincent >>>> >>>>> Happy coding, >>>>> Anca Luca >>>>> >>>>>> From the implementation POV 3) is probably the most difficult >>>>>> proposal >>>>>> and 1) the simplest one. Widget 3) would need to be a reusable (and >>>>>> highly configurable) GWT component so that we could use it as our >>>>>> main >>>>>> navigation/reorganization tool in the future. This tree would >>>>>> replace >>>>>> our current treeview (Main.AllDocs) which is AFAIR the only page >>>>>> using >>>>>> the YUI library in XE. >>>>>> >>>>>> Thanks, >>>>>> JV. >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
+1 for 3. I would also like to see the number of child nodes for a parent node, without expanding it. This way I won't be surprised that expanding a node with >1000 child nodes takes so long (either because of the DB, network or DOM). Now, regarding the three proposed ways of adding new nodes: -1 for A and B since I'd like to be able to add a child node without expanding the parent (especially when I see it has >1000 child nodes already). How can I know that the name I want it's not taken? The UI (input dialog or filter) should tell me. I don't want to scroll through 1000 (not even 100) nodes to find that by myself. -0 for C since, although it seems scalable, it isn't. The problem is when the name of the parent node is really long and there are many actions on the right of it. So to me C seems better than A and B, but not perfect. Unfortunately I don't have a better solution.. thinking.. Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
From the implementation POV 3) is probably the most difficult proposal and 1) the simplest one. Widget 3) would need to be a reusable (and highly configurable) GWT component so that we could use it as our main navigation/reorganization tool in the future. This tree would replace our current treeview (Main.AllDocs) which is AFAIR the only page using the YUI library in XE.
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, See below, On Wed, Nov 26, 2008 at 8:30 AM, Marius Dumitru Florea < [email protected]> wrote:
+1 for 3.
I would also like to see the number of child nodes for a parent node, without expanding it. This way I won't be surprised that expanding a node with >1000 child nodes takes so long (either because of the DB, network or DOM).
Now, regarding the three proposed ways of adding new nodes:
-1 for A and B since I'd like to be able to add a child node without expanding the parent (especially when I see it has >1000 child nodes already). How can I know that the name I want it's not taken? The UI (input dialog or filter) should tell me. I don't want to scroll through 1000 (not even 100) nodes to find that by myself.
-0 for C since, although it seems scalable, it isn't. The problem is when the name of the parent node is really long and there are many actions on the right of it.
So to me C seems better than A and B, but not perfect. Unfortunately I don't have a better solution.. thinking..
I also think 3C is the best solution. It is almost similar with what I have in XWord. The difference is that I use a context popup menu for the actions applicable to the selected node. While pretty popular, the disadvantage of the contextual menu is that is not intuitive enough because the user has to right click to see it. To compensate, I created a syncrhonized buttons group in the Ribbon UI of Word. In other words that buttons group will show only the buttons with actions regarding the selected node in the tree. I dont think this is easily applicable on your web-based interface, but I sure need some feed-back on my implementation. I'll send you guys a screenshot of the latest build of XWord right away I have access to a machine that has one installed. It's really nice that XE, WebDav, XEclipse and XWord are convering to the same type of navigation.
Jean-Vincent Drean wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
I've put the mockups and Pros/Cons on this wiki page : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer This wiki explorer widget would be used in the link dialogs, image dialogs, file (attachment) dialogs.
Here's my +1 for 3) A). +1 for 3) with filter option.
From the implementation POV 3) is probably the most difficult proposal and 1) the simplest one. Widget 3) would need to be a reusable (and highly configurable) GWT component so that we could use it as our main navigation/reorganization tool in the future. This tree would replace our current treeview (Main.AllDocs) which is AFAIR the only page using the YUI library in XE.
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Nov 25, 2008 at 5:05 PM, Jean-Vincent Drean <[email protected]> wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
After some more thinking and discussion with Laurent Lunati I've made a mockup of a 4th wiki explorer : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#H429... It combines the best of the tree and wizard proposals : * Easy to use: users are guided throughout the process, one action at a time * The dialog size is fixed, action buttons are always at the same position on screen * The dialog doesn't looked oversized compared to the WYSIWYG * Small footprint: can be used even on low resolution displays * Since it's a wizard it's highly extensible * Scalable : we can have multiple wikis + spaces (even a space hierarchy) * Allow to display parent/child relationships between pages (thus allowing to handle a lot of pages in a space) * Allows the user to see where he is currently located in the wiki (default selection) Here's my +1 for 4). ps: I consider that the discussion about the position of the add page / add spaces buttons is not over. JV.
I don't understand option 4. - Why are there dialog boxes only for image insertion? How do I add a link to a page? - What is the order of screens? How does it work? - What is the difference between the first screen and the one below entitled '"optional steps"? Thanks -Vincent On Nov 27, 2008, at 7:37 PM, Jean-Vincent Drean wrote:
On Tue, Nov 25, 2008 at 5:05 PM, Jean-Vincent Drean <[email protected]> wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
After some more thinking and discussion with Laurent Lunati I've made a mockup of a 4th wiki explorer : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#H429...
It combines the best of the tree and wizard proposals :
* Easy to use: users are guided throughout the process, one action at a time * The dialog size is fixed, action buttons are always at the same position on screen * The dialog doesn't looked oversized compared to the WYSIWYG * Small footprint: can be used even on low resolution displays * Since it's a wizard it's highly extensible * Scalable : we can have multiple wikis + spaces (even a space hierarchy) * Allow to display parent/child relationships between pages (thus allowing to handle a lot of pages in a space) * Allows the user to see where he is currently located in the wiki (default selection)
Here's my +1 for 4).
ps: I consider that the discussion about the position of the add page / add spaces buttons is not over.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 27, 2008, at 7:49 PM, Vincent Massol wrote:
I don't understand option 4.
ok I think I understand now. I was expecting a mockup for link insertion.
- Why are there dialog boxes only for image insertion? How do I add a link to a page? - What is the order of screens? How does it work?
I understand this too now. I was misled by the fact that in the second row the node was selected where actually the user is supposed to click on "upload file" (which should be highlighted) Thanks -Vincent
- What is the difference between the first screen and the one below entitled '"optional steps"?
Thanks -Vincent
On Nov 27, 2008, at 7:37 PM, Jean-Vincent Drean wrote:
On Tue, Nov 25, 2008 at 5:05 PM, Jean-Vincent Drean <[email protected]> wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
After some more thinking and discussion with Laurent Lunati I've made a mockup of a 4th wiki explorer : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#H429...
It combines the best of the tree and wizard proposals :
* Easy to use: users are guided throughout the process, one action at a time * The dialog size is fixed, action buttons are always at the same position on screen * The dialog doesn't looked oversized compared to the WYSIWYG * Small footprint: can be used even on low resolution displays * Since it's a wizard it's highly extensible * Scalable : we can have multiple wikis + spaces (even a space hierarchy) * Allow to display parent/child relationships between pages (thus allowing to handle a lot of pages in a space) * Allows the user to see where he is currently located in the wiki (default selection)
Here's my +1 for 4).
ps: I consider that the discussion about the position of the add page / add spaces buttons is not over.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard. * What is the camera icon doing? Is it just an image? * How do I enter advanced parameters for images? Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for - it's one click less Re your arguments below we can have the same with option 3. But I would follow the others if everyone thinks 4 is better. Thanks -Vincent On Nov 27, 2008, at 7:37 PM, Jean-Vincent Drean wrote:
On Tue, Nov 25, 2008 at 5:05 PM, Jean-Vincent Drean <[email protected]> wrote:
In a previous thread we've discussed about how to add a link in the WYSIWYG editor, and more generally, how to browse the wiki from a WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced tree menu.
After some more thinking and discussion with Laurent Lunati I've made a mockup of a 4th wiki explorer : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#H429...
It combines the best of the tree and wizard proposals :
* Easy to use: users are guided throughout the process, one action at a time * The dialog size is fixed, action buttons are always at the same position on screen * The dialog doesn't looked oversized compared to the WYSIWYG * Small footprint: can be used even on low resolution displays * Since it's a wizard it's highly extensible * Scalable : we can have multiple wikis + spaces (even a space hierarchy) * Allow to display parent/child relationships between pages (thus allowing to handle a lot of pages in a space) * Allows the user to see where he is currently located in the wiki (default selection)
Here's my +1 for 4).
ps: I consider that the discussion about the position of the add page / add spaces buttons is not over.
JV.
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
Re your arguments below we can have the same with option 3.
I don't think so, actually that's why I came up with 4). JV.
I'm not a big fan of step wizards thus I'm more into proposal 3. See other comments below. Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
The user would be forced to use the mouse in order to see the preview.
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
The WYSIWYG addresses power users also.
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
What I find sometimes annoying is going back and forth through a wizard. I admit a wizard fills more secure the first few times it's being used, but for me it can get annoying the more I'm using it. So I'm more into proposal 3, but I'm not against 4. Thanks, Marius
Re your arguments below we can have the same with option 3.
I don't think so, actually that's why I came up with 4).
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I vote +1 for 4, and i don't consider 3 as a valid proposal Laurent Le 28 nov. 08 à 08:31, Marius Dumitru Florea a écrit :
I'm not a big fan of step wizards thus I'm more into proposal 3. See other comments below.
Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
The user would be forced to use the mouse in order to see the preview.
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
The WYSIWYG addresses power users also.
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
What I find sometimes annoying is going back and forth through a wizard. I admit a wizard fills more secure the first few times it's being used, but for me it can get annoying the more I'm using it.
So I'm more into proposal 3, but I'm not against 4.
Thanks, Marius
Re your arguments below we can have the same with option 3.
I don't think so, actually that's why I came up with 4).
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 28, 2008, at 9:45 AM, Laurent Lunati wrote:
I vote +1 for 4, and i don't consider 3 as a valid proposal
Could you explain why? Thanks -Vincent
Le 28 nov. 08 à 08:31, Marius Dumitru Florea a écrit :
I'm not a big fan of step wizards thus I'm more into proposal 3. See other comments below.
Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
The user would be forced to use the mouse in order to see the preview.
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
The WYSIWYG addresses power users also.
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
What I find sometimes annoying is going back and forth through a wizard. I admit a wizard fills more secure the first few times it's being used, but for me it can get annoying the more I'm using it.
So I'm more into proposal 3, but I'm not against 4.
Thanks, Marius
Re your arguments below we can have the same with option 3.
I don't think so, actually that's why I came up with 4).
JV.
Le 28 nov. 08 à 09:58, Vincent Massol a écrit :
On Nov 28, 2008, at 9:45 AM, Laurent Lunati wrote:
I vote +1 for 4, and i don't consider 3 as a valid proposal
Could you explain why?
yes, but it would take too much time to me to build an clear and argued answer. and I do not have this time. I thing i must find the right way for giving you all informations without having to rewrite them on each mail. i have to work on that... laurent
Thanks -Vincent
Le 28 nov. 08 à 08:31, Marius Dumitru Florea a écrit :
I'm not a big fan of step wizards thus I'm more into proposal 3. See other comments below.
Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
The user would be forced to use the mouse in order to see the preview.
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
The WYSIWYG addresses power users also.
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
What I find sometimes annoying is going back and forth through a wizard. I admit a wizard fills more secure the first few times it's being used, but for me it can get annoying the more I'm using it.
So I'm more into proposal 3, but I'm not against 4.
Thanks, Marius
Re your arguments below we can have the same with option 3.
I don't think so, actually that's why I came up with 4).
JV.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Nov 28, 2008 at 8:31 AM, Marius Dumitru Florea <[email protected]> wrote:
I'm not a big fan of step wizards thus I'm more into proposal 3. See other comments below.
The user would be forced to use the mouse in order to see the preview.
Yes and I don't see how it could be different in proposals 3) and 4), displaying images in the tree ?
- as a user I prefer to see all options to understand where I'll find
the feature I'm looking for
s/user/power user/
The WYSIWYG addresses power users also.
I'm just saying that Vincent is not exactly the average user here :)
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
What I find sometimes annoying is going back and forth through a wizard. I admit a wizard fills more secure the first few times it's being used,
See ! :)
but for me it can get annoying the more I'm using it.
Of course having a wizard with a lot of mandatory steps would be a pain but there's only 2 of them here. There's a "pro" I have forgotten in the list : Having those 2 steps is a good thing considering that we'll use the same dialog for insertion / deletion. When you'll edit a link/image/etc you'll first see the options dialog and won't have to load/see the wiki tree. Of course you'll be able to go back to the first step but in most of the cases (imo) you won't have to. JV.
Jean-Vincent Drean wrote:
On Fri, Nov 28, 2008 at 8:31 AM, Marius Dumitru Florea <[email protected]> wrote:
I'm not a big fan of step wizards thus I'm more into proposal 3. See other comments below.
The user would be forced to use the mouse in order to see the preview.
Yes and I don't see how it could be different in proposals 3) and 4), displaying images in the tree ?
I was thinking about navigating the tree using the keyboard. This is a nice thing to have. It can be done in both proposal 3 and 4.
- as a user I prefer to see all options to understand where I'll find
the feature I'm looking for s/user/power user/ The WYSIWYG addresses power users also.
I'm just saying that Vincent is not exactly the average user here :)
- it's one click less IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no. What I find sometimes annoying is going back and forth through a wizard. I admit a wizard fills more secure the first few times it's being used,
See ! :)
but for me it can get annoying the more I'm using it.
Of course having a wizard with a lot of mandatory steps would be a pain but there's only 2 of them here.
There's a "pro" I have forgotten in the list : Having those 2 steps is a good thing considering that we'll use the same dialog for insertion / deletion. When you'll edit a link/image/etc you'll first see the options dialog and won't have to load/see the wiki tree. Of course you'll be able to go back to the first step but in most of the cases (imo) you won't have to.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Marius Dumitru Florea a écrit :
Jean-Vincent Drean wrote:
On Fri, Nov 28, 2008 at 8:31 AM, Marius Dumitru Florea <[email protected]> wrote:
I'm not a big fan of step wizards thus I'm more into proposal 3. See other comments below.
The user would be forced to use the mouse in order to see the preview.
Yes and I don't see how it could be different in proposals 3) and 4), displaying images in the tree ?
I was thinking about navigating the tree using the keyboard. This is a nice thing to have. It can be done in both proposal 3 and 4.
Yes, clearly Marius. I'm +1 for proposition 4 ) since it's, for me, a good evolution of the proposition 3) Thomas
- as a user I prefer to see all options to understand where I'll find
the feature I'm looking for
s/user/power user/
The WYSIWYG addresses power users also.
I'm just saying that Vincent is not exactly the average user here :)
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
What I find sometimes annoying is going back and forth through a wizard. I admit a wizard fills more secure the first few times it's being used,
See ! :)
but for me it can get annoying the more I'm using it.
Of course having a wizard with a lot of mandatory steps would be a pain but there's only 2 of them here.
There's a "pro" I have forgotten in the list : Having those 2 steps is a good thing considering that we'll use the same dialog for insertion / deletion. When you'll edit a link/image/etc you'll first see the options dialog and won't have to load/see the wiki tree. Of course you'll be able to go back to the first step but in most of the cases (imo) you won't have to.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 27, 2008, at 9:14 PM, Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
Couldn't we show the images in the tree (as thumbnails)? In several wikis/CMS I've seen they use a media browser showing thumbnails of pictures and this looks a good way to select the picture to me. If I have to open all nodes to see the pictures below it might be hard to select the picture I want. It might be better to list all pictures found in a given space or wiki (still using a live grid so that performances are not penalized of course). Maybe a checkbox to switch from treeview to image browser?
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
Why do you say that? With your argument every user is dumb and would not be able to use a computer at all. Have you every seen a computer OS screen when there's only 1 button and wizards to go to the next step? Come on, look at your screen, and see all the buttons and places you can click (right now when typing this I can see at least 100 locations I can click and I'm on a Mac, reputed for being easy to use). Life is not just a wizard! :) I agree we should not make complex screen but there's a fine line between complex and useful. I even don't disagree with option 4 even though I don't think it's required (unless we wanted to make it work on mobile devices for ex but then it's a completely different skin that we would need and it would be pretty stupid to use a mobile device design on large screens since you'd loose lots of screen estate). Ok back to constructive comments: What about 2 buttons on the first screen: * Insert * More Options... If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc. It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :) WDYT?
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
I agree it's not a big deal. Still I'm unsure why we need 2 screens. The one argument that seems valid to me is screen estate but then I'm not sure it wouldn't fit (we need to have it work on 1024x768 and not lower since all our site is made to work on 1024x768). [snip] Thanks -Vincent
Hi, I'm non-binding +1 for 4) . I think the 2 most important reasons why I like it better are: * Easy to use: users are guided throughout the process, one action at a time 2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals. * The dialog size is fixed, action buttons are always at the same position on screen => this one is specifically important to me. 480*480 is a good medium ground between a generic, small-footprint dialog box size that can be used for most purposes (from a treeview to a file upload) and it would fit well on an EEEpc 900's screen (which is probably the lowest common denominator in terms of screen resolutions we should be able to support: 1024*600, especially given how ubiquitous small laptops are becoming these days). Having dialog boxes with a consistent look & feel (same location for buttons) is very important since it will make user expectations much easier to manage => the same kind of button always located at the same place will greatly improve usability. Guillaume On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
On Nov 27, 2008, at 9:14 PM, Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
Couldn't we show the images in the tree (as thumbnails)?
In several wikis/CMS I've seen they use a media browser showing thumbnails of pictures and this looks a good way to select the picture to me. If I have to open all nodes to see the pictures below it might be hard to select the picture I want. It might be better to list all pictures found in a given space or wiki (still using a live grid so that performances are not penalized of course).
Maybe a checkbox to switch from treeview to image browser?
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
Why do you say that? With your argument every user is dumb and would not be able to use a computer at all. Have you every seen a computer OS screen when there's only 1 button and wizards to go to the next step? Come on, look at your screen, and see all the buttons and places you can click (right now when typing this I can see at least 100 locations I can click and I'm on a Mac, reputed for being easy to use). Life is not just a wizard! :)
I agree we should not make complex screen but there's a fine line between complex and useful. I even don't disagree with option 4 even though I don't think it's required (unless we wanted to make it work on mobile devices for ex but then it's a completely different skin that we would need and it would be pretty stupid to use a mobile device design on large screens since you'd loose lots of screen estate).
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
WDYT?
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
I agree it's not a big deal. Still I'm unsure why we need 2 screens. The one argument that seems valid to me is screen estate but then I'm not sure it wouldn't fit (we need to have it work on 1024x768 and not lower since all our site is made to work on 1024x768).
[snip]
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/
On Nov 28, 2008, at 11:50 AM, Guillaume Lerouge wrote:
Hi,
I'm non-binding +1 for 4) .
I think the 2 most important reasons why I like it better are:
* Easy to use: users are guided throughout the process, one action at a time
2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks. Re the guided stuff just one comment: users just need to be guided on their first usage of it. Thereafter all they need is productivity.
* The dialog size is fixed, action buttons are always at the same position on screen
This would work too with option 3. The action button would always be at the same position. The second/right screen is not about action buttons, it's about choosing options.
=> this one is specifically important to me. 480*480 is a good medium ground between a generic, small-footprint dialog box size that can be used for most purposes (from a treeview to a file upload) and it would fit well on an EEEpc 900's screen (which is probably the lowest common denominator in terms of screen resolutions we should be able to support: 1024*600, especially given how ubiquitous small laptops are becoming these days).
Having dialog boxes with a consistent look & feel (same location for buttons) is very important since it will make user expectations much easier to manage => the same kind of button always located at the same place will greatly improve usability.
Yes, no doubt about this. That's why action buttons are always placed at the bottom of dialog screens. However having fixed size dialog boxes is another matter and I don't believe in it. We should do it when we can but it really depends on the content we need to display. Forcing a second screen in a wizard fashion is not always good. It's only good *IF* the second screen is mandatory, if it's not then a drawer or tabs is a better solution. In our case at hand the second screen is optional and this is why a wizard is not a good structure. Thanks -Vincent
Guillaume
On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
On Nov 27, 2008, at 9:14 PM, Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
Couldn't we show the images in the tree (as thumbnails)?
In several wikis/CMS I've seen they use a media browser showing thumbnails of pictures and this looks a good way to select the picture to me. If I have to open all nodes to see the pictures below it might be hard to select the picture I want. It might be better to list all pictures found in a given space or wiki (still using a live grid so that performances are not penalized of course).
Maybe a checkbox to switch from treeview to image browser?
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
Why do you say that? With your argument every user is dumb and would not be able to use a computer at all. Have you every seen a computer OS screen when there's only 1 button and wizards to go to the next step? Come on, look at your screen, and see all the buttons and places you can click (right now when typing this I can see at least 100 locations I can click and I'm on a Mac, reputed for being easy to use). Life is not just a wizard! :)
I agree we should not make complex screen but there's a fine line between complex and useful. I even don't disagree with option 4 even though I don't think it's required (unless we wanted to make it work on mobile devices for ex but then it's a completely different skin that we would need and it would be pretty stupid to use a mobile device design on large screens since you'd loose lots of screen estate).
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
WDYT?
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
I agree it's not a big deal. Still I'm unsure why we need 2 screens. The one argument that seems valid to me is screen estate but then I'm not sure it wouldn't fit (we need to have it work on 1024x768 and not lower since all our site is made to work on 1024x768).
[snip]
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote:
On Nov 28, 2008, at 11:50 AM, Guillaume Lerouge wrote:
Hi,
I'm non-binding +1 for 4) .
I think the 2 most important reasons why I like it better are:
* Easy to use: users are guided throughout the process, one action at a time
2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks.
Re the guided stuff just one comment: users just need to be guided on their first usage of it. Thereafter all they need is productivity.
See reply in my previous email.
* The dialog size is fixed, action buttons are always at the same position on screen
This would work too with option 3. The action button would always be at the same position. The second/right screen is not about action buttons, it's about choosing options.
=> this one is specifically important to me. 480*480 is a good medium ground between a generic, small-footprint dialog box size that can be used for most purposes (from a treeview to a file upload) and it would fit well on an EEEpc 900's screen (which is probably the lowest common denominator in terms of screen resolutions we should be able to support: 1024*600, especially given how ubiquitous small laptops are becoming these days).
Having dialog boxes with a consistent look & feel (same location for buttons) is very important since it will make user expectations much easier to manage => the same kind of button always located at the same place will greatly improve usability.
Yes, no doubt about this. That's why action buttons are always placed at the bottom of dialog screens. However having fixed size dialog boxes is another matter and I don't believe in it. We should do it when we can but it really depends on the content we need to display. Forcing a second screen in a wizard fashion is not always good. It's only good *IF* the second screen is mandatory, if it's not then a drawer or tabs is a better solution.
In our case at hand the second screen is optional and this is why a wizard is not a good structure.
Your proposal of having a "more options" button next to the "insert" one sounds like a great way to bridge both approaches. This way, the 2nd screen with complex options is not shown it not needed, which removes complexity. Guillaume
Thanks -Vincent
Guillaume
On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
On Nov 27, 2008, at 9:14 PM, Jean-Vincent Drean wrote:
On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[email protected]> wrote:
Re the image selection: * It would be much much better to see the images before choosing them (the preview comes too late). You cannot choose an image on its name alone that's too hard.
The only solution I see for this is to have a tooltip with a preview in the treeview.
Couldn't we show the images in the tree (as thumbnails)?
In several wikis/CMS I've seen they use a media browser showing thumbnails of pictures and this looks a good way to select the picture to me. If I have to open all nodes to see the pictures below it might be hard to select the picture I want. It might be better to list all pictures found in a given space or wiki (still using a live grid so that performances are not penalized of course).
Maybe a checkbox to switch from treeview to image browser?
* What is the camera icon doing? Is it just an image?
Yes.
* How do I enter advanced parameters for images?
This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal.
Apart from this it looks good to me but I still have a small preference for 3 since - as a user I prefer to see all options to understand where I'll find the feature I'm looking for
s/user/power user/
Why do you say that? With your argument every user is dumb and would not be able to use a computer at all. Have you every seen a computer OS screen when there's only 1 button and wizards to go to the next step? Come on, look at your screen, and see all the buttons and places you can click (right now when typing this I can see at least 100 locations I can click and I'm on a Mac, reputed for being easy to use). Life is not just a wizard! :)
I agree we should not make complex screen but there's a fine line between complex and useful. I even don't disagree with option 4 even though I don't think it's required (unless we wanted to make it work on mobile devices for ex but then it's a completely different skin that we would need and it would be pretty stupid to use a mobile device design on large screens since you'd loose lots of screen estate).
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
WDYT?
- it's one click less
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
I agree it's not a big deal. Still I'm unsure why we need 2 screens. The one argument that seems valid to me is screen estate but then I'm not sure it wouldn't fit (we need to have it work on 1024x768 and not lower since all our site is made to work on 1024x768).
[snip]
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote:
2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks.
See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMoc... I'm fine with this solution, Laurent WDYT of this one ? JV.
Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit :
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote:
2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks.
See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMoc...
I'm fine with this solution, Laurent WDYT of this one ?
JV.
it's not the right way for me, with a direct insert button common usage is : 1 - select 2 - insert 3 - Ho zut 4 - edit ? 5 - ho... am i on the right box ? 6- click on edit (or close the dialogue, in this case delete img and reclick on insert image) 7 - reselect img 8 - ok more options... 9 - ha... yes my image is too big 10 - change option 11 - insert if you have 2 steps on inserting dialogue always display all step, so that user always know where he is laurent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit :
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote:
2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks.
See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMoc...
I'm fine with this solution, Laurent WDYT of this one ?
JV.
it's not the right way for me, with a direct insert button common usage is :
Exactly my point! This is exactly why I've always thought it was better to show the second screen so that the user can see what the options are before clicking on insert (that's proposal 3). The more I think of this and the more I think it's wrong to use a wizard to *force* a second optional step for inserting an image (especially when in the second screen won't be used at all in most cases). Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature. The scenario by Laurent below simply shows that using a dialog box to resize an image is wrong. In order to know the correct size you need to see it in the page with the rest of the layout so it's way better to offer mouse handles to resize it inline IMO. Thanks -Vincent
1 - select 2 - insert 3 - Ho zut 4 - edit ? 5 - ho... am i on the right box ? 6- click on edit (or close the dialogue, in this case delete img and reclick on insert image) 7 - reselect img 8 - ok more options... 9 - ha... yes my image is too big 10 - change option 11 - insert
if you have 2 steps on inserting dialogue always display all step, so that user always know where he is
laurent
On Fri, Nov 28, 2008 at 2:12 PM, Vincent Massol <[email protected]> wrote:
Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature.
You won't lose it since it's actually a firefox feature (don't know about IE). JV.
Jean-Vincent Drean wrote:
On Fri, Nov 28, 2008 at 2:12 PM, Vincent Massol <[email protected]> wrote:
Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature.
You won't lose it since it's actually a firefox feature (don't know about IE).
Same in IE. You can even drag and drop the image within the edited document.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Le 28 nov. 08 à 14:12, Vincent Massol a écrit :
On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit :
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote:
2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks.
See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMoc...
I'm fine with this solution, Laurent WDYT of this one ?
JV.
it's not the right way for me, with a direct insert button common usage is :
Exactly my point! This is exactly why I've always thought it was better to show the second screen so that the user can see what the options are before clicking on insert (that's proposal 3).
The more I think of this and the more I think it's wrong to use a wizard to *force* a second optional step for inserting an image (especially when in the second screen won't be used at all in most cases).
Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature.
The scenario by Laurent below simply shows that using a dialog box to resize an image is wrong. In order to know the correct size you need to see it in the page with the rest of the layout so it's way better to offer mouse handles to resize it inline IMO.
I really don't know what to anser.... so starting here i stop to discuss. Thanks Laurent
Thanks -Vincent
1 - select 2 - insert 3 - Ho zut 4 - edit ? 5 - ho... am i on the right box ? 6- click on edit (or close the dialogue, in this case delete img and reclick on insert image) 7 - reselect img 8 - ok more options... 9 - ha... yes my image is too big 10 - change option 11 - insert
if you have 2 steps on inserting dialogue always display all step, so that user always know where he is
laurent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 28, 2008, at 2:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 14:12, Vincent Massol a écrit :
On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit :
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote:
2 steps do not seem excessive to me, it's still gonnna be real quick and it adapts well to the various use cases we are faced with (insert link, insert image etc). It has both the benefits from the wizard and the treeview. I think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks.
See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMoc...
I'm fine with this solution, Laurent WDYT of this one ?
JV.
it's not the right way for me, with a direct insert button common usage is :
Exactly my point! This is exactly why I've always thought it was better to show the second screen so that the user can see what the options are before clicking on insert (that's proposal 3).
The more I think of this and the more I think it's wrong to use a wizard to *force* a second optional step for inserting an image (especially when in the second screen won't be used at all in most cases).
Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature.
The scenario by Laurent below simply shows that using a dialog box to resize an image is wrong. In order to know the correct size you need to see it in the page with the rest of the layout so it's way better to offer mouse handles to resize it inline IMO.
I really don't know what to anser.... so starting here i stop to discuss.
I'm surprised by your reaction Laurent. JV is proposing to have a 2 step wizard for inserting an image. I comment that the second step is not necessary IMO since it only contains optional features that are not going to be used in the majority of cases (especially if we agree that resizing should be done inline and not in the dialog box - You didn't even answer that part, does it mean you think resizing should not be done inline?) and you end up the conversation saying that you don't know what to answer... I think you're missing the fact that a good discussion is always healthy. You might think that you're always right and that there's no point in discussing with others but that's simply not true. Look at your initial proposal with 5 wizard screens. This is what we would have now if we had blindly accepted your proposal. I'm glad we didn't since this has lead to thinking more about it and JV proposed the treeview solution which has had unanimous approval and is better according to everyone. OTOH maybe you're fed up discussing because you've already discussed all this with JV before. Fair enough but then none of us was involved and we can't know what was discussed. In addition I don't think we're far from having found our best solution. Once more my only remaining concern is to systematically force users to go through a second screen that they would not use. While this is ok the first time I think it would hamper usability after a few image insertions. Actually I have another concern which is how to use the treeview to efficiently choose an image. While choosing the image based on its name is possible I remember seeing other wikis that are doing better by showing image galleries to pick from. Hope you'll reconsider and continue discussing here. Thanks -Vincent
1 - select 2 - insert 3 - Ho zut 4 - edit ? 5 - ho... am i on the right box ? 6- click on edit (or close the dialogue, in this case delete img and reclick on insert image) 7 - reselect img 8 - ok more options... 9 - ha... yes my image is too big 10 - change option 11 - insert
if you have 2 steps on inserting dialogue always display all step, so that user always know where he is
laurent
Hi Laurent, [snip]
I really don't know what to anser.... so starting here i stop to discuss.
I'm surprised by your reaction Laurent.
JV is proposing to have a 2 step wizard for inserting an image. I comment that the second step is not necessary IMO since it only contains optional features that are not going to be used in the majority of cases (especially if we agree that resizing should be done inline and not in the dialog box - You didn't even answer that part, does it mean you think resizing should not be done inline?) and you end up the conversation saying that you don't know what to answer...
I think you're missing the fact that a good discussion is always healthy. You might think that you're always right and that there's no point in discussing with others but that's simply not true. Look at your initial proposal with 5 wizard screens. This is what we would have now if we had blindly accepted your proposal. I'm glad we didn't since this has lead to thinking more about it and JV proposed the treeview solution which has had unanimous approval and is better according to everyone.
OTOH maybe you're fed up discussing because you've already discussed all this with JV before. Fair enough but then none of us was involved and we can't know what was discussed.
I forgot to mention a few important things: * You are the expert in term of UI Design and Usability so we all want to learn from you (at least I do! :)) but I can't learn if you don't take the time to explain to me why my thinking is so wretched :) But once we understand a concept, we'll be the one to evangelize it and promote it so you won't be alone anymore. We'll also be able to do some new designs that are mostly ok without having to have lengthy discussions. * This is one of the first time you're interacting here so it's normal it's taking some time to get a common understanding. This is perfectly normal and is a process that takes some time. This is not something that can be rushed. Just wanted to make sure you understand how important it is that you continue discussing here and that we (I at least) really value your inputs (because I know you and I know you can bring a lot but you have to be a bit more patient ;)). Thanks -Vincent [snip]
Vincent Massol wrote:
On Nov 28, 2008, at 2:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 14:12, Vincent Massol a écrit :
On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit :
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote:
> 2 steps do not seem excessive to me, it's still gonnna be real > quick > and it > adapts well to the various use cases we are faced with (insert > link, > insert > image etc). It has both the benefits from the wizard and the > treeview. I > think it is a great middle ground between our various proposals. You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks.
See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMoc...
I'm fine with this solution, Laurent WDYT of this one ?
JV. it's not the right way for me, with a direct insert button common usage is : Exactly my point! This is exactly why I've always thought it was better to show the second screen so that the user can see what the options are before clicking on insert (that's proposal 3).
The more I think of this and the more I think it's wrong to use a wizard to *force* a second optional step for inserting an image (especially when in the second screen won't be used at all in most cases).
Most wizards I've seen in Excel have Next and Done buttons. A user can go through every step, or he can "be done" at any moment, leaving the defaults for the unexplored steps.
Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature.
The scenario by Laurent below simply shows that using a dialog box to resize an image is wrong. In order to know the correct size you need to see it in the page with the rest of the layout so it's way better to offer mouse handles to resize it inline IMO.
I really don't know what to anser.... so starting here i stop to discuss.
I'm surprised by your reaction Laurent.
JV is proposing to have a 2 step wizard for inserting an image. I comment that the second step is not necessary IMO since it only contains optional features that are not going to be used in the majority of cases (especially if we agree that resizing should be done inline and not in the dialog box - You didn't even answer that part, does it mean you think resizing should not be done inline?) and you end up the conversation saying that you don't know what to answer...
I think you're missing the fact that a good discussion is always healthy. You might think that you're always right and that there's no point in discussing with others but that's simply not true. Look at your initial proposal with 5 wizard screens. This is what we would have now if we had blindly accepted your proposal. I'm glad we didn't since this has lead to thinking more about it and JV proposed the treeview solution which has had unanimous approval and is better according to everyone.
OTOH maybe you're fed up discussing because you've already discussed all this with JV before. Fair enough but then none of us was involved and we can't know what was discussed.
In addition I don't think we're far from having found our best solution. Once more my only remaining concern is to systematically force users to go through a second screen that they would not use. While this is ok the first time I think it would hamper usability after a few image insertions. Actually I have another concern which is how to use the treeview to efficiently choose an image. While choosing the image based on its name is possible I remember seeing other wikis that are doing better by showing image galleries to pick from.
There's a difference. An image gallery works when the images are in one or few places, not when you have thousands of pages in hundreds of spaces (think Curriki), most of which are of no interest to you. TANSTAAFL. No UI is the best for all people and all use cases. We could have several ways of choosing an image: tree based, most recently used, media gallery collecting pictures from different sets of pages (current page, current space, all wiki, recently changed documents, recently uploaded images, ...). The user would choose the best for him, or the best for the given scenario. Sometimes I just want to link to a precise image, and I can go to it "with my eyes closed", sometimes I want to insert a bluey image, and sometimes I want to use an image I remember seeing a few days ago somewhere, can't remember where exactly, but somewhere in one of these 5 documents. We could use Google Gears to keep track of the last preferences, since cookies are too expensive, and serverside increases the storage needlessly. But that's for the future.
Hope you'll reconsider and continue discussing here.
Thanks -Vincent
1 - select 2 - insert 3 - Ho zut 4 - edit ? 5 - ho... am i on the right box ? 6- click on edit (or close the dialogue, in this case delete img and reclick on insert image) 7 - reselect img 8 - ok more options... 9 - ha... yes my image is too big 10 - change option 11 - insert
if you have 2 steps on inserting dialogue always display all step, so that user always know where he is
laurent
This is a scenario. A possible one. But not a frequent one, and most certainly not the most common. So a few users will have to loose some seconds a few times until they learn how to do it the right way. But it will also save a little time from everybody else EVERY time. A little bit every time versus a bit more on a few occasions is an obvious choice for me. Usually IT solutions are chosen and imposed in a company. If some guy or gal gets his little brain confused by the fact that more options are behind the "more options" button, he won't matter. Brainless secretaries don't make IT decisions. They are a big part of our users, but they are not the ones that decide what product to choose. I tend to believe that we are trying to develop a powerful wiki. XWiki has many features nobody else has (yet), and it is certainly not targeted as a Word replacer (Google Docs does a good job here). If users need power, they will choose XWiki. If they just need something to write notes on, then I personally wouldn't recommend XWiki to them to begin with. Yes, a few people chose something else because of the WYSIWYG, but not because it was a tad more difficult to use, because it was REALLY BUGGY, and I agree with them. Our TinyMCE editor is almost useless for anything more complex than writing a plain letter with a few bold words, and I never use it because of this. As long as we have as little bugs as possible, and it doesn't prove to be extremely complex, I say we're safe. More, if a client really needs a simple UI that can be used by a group of mentally retarded children, we can always do some custom development. It is important to have a configurable editor, not to have ONE interface that can satisfy everybody from hard-core hackers and 3-year youngsters. By the clickety current look of the WYSIWYG editor, I am pretty sure I'll stay away from it. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Nov 29, 2008, at 6:17 AM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
On Nov 28, 2008, at 2:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 14:12, Vincent Massol a écrit :
On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote:
Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit :
On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <[email protected]> wrote: >> 2 steps do not seem excessive to me, it's still gonnna be real >> quick >> and it >> adapts well to the various use cases we are faced with (insert >> link, >> insert >> image etc). It has both the benefits from the wizard and the >> treeview. I >> think it is a great middle ground between our various >> proposals. > You didn't comment on my proposal to be able to click insert on > the > first screen if you don't need any option applied to the > image. I > think it's reasonable and saves unnecessary clicks. > See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMoc...
I'm fine with this solution, Laurent WDYT of this one ?
JV. it's not the right way for me, with a direct insert button common usage is : Exactly my point! This is exactly why I've always thought it was better to show the second screen so that the user can see what the options are before clicking on insert (that's proposal 3).
The more I think of this and the more I think it's wrong to use a wizard to *force* a second optional step for inserting an image (especially when in the second screen won't be used at all in most cases).
Most wizards I've seen in Excel have Next and Done buttons. A user can go through every step, or he can "be done" at any moment, leaving the defaults for the unexplored steps.
Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature.
The scenario by Laurent below simply shows that using a dialog box to resize an image is wrong. In order to know the correct size you need to see it in the page with the rest of the layout so it's way better to offer mouse handles to resize it inline IMO.
I really don't know what to anser.... so starting here i stop to discuss.
I'm surprised by your reaction Laurent.
JV is proposing to have a 2 step wizard for inserting an image. I comment that the second step is not necessary IMO since it only contains optional features that are not going to be used in the majority of cases (especially if we agree that resizing should be done inline and not in the dialog box - You didn't even answer that part, does it mean you think resizing should not be done inline?) and you end up the conversation saying that you don't know what to answer...
I think you're missing the fact that a good discussion is always healthy. You might think that you're always right and that there's no point in discussing with others but that's simply not true. Look at your initial proposal with 5 wizard screens. This is what we would have now if we had blindly accepted your proposal. I'm glad we didn't since this has lead to thinking more about it and JV proposed the treeview solution which has had unanimous approval and is better according to everyone.
OTOH maybe you're fed up discussing because you've already discussed all this with JV before. Fair enough but then none of us was involved and we can't know what was discussed.
In addition I don't think we're far from having found our best solution. Once more my only remaining concern is to systematically force users to go through a second screen that they would not use. While this is ok the first time I think it would hamper usability after a few image insertions. Actually I have another concern which is how to use the treeview to efficiently choose an image. While choosing the image based on its name is possible I remember seeing other wikis that are doing better by showing image galleries to pick from.
There's a difference. An image gallery works when the images are in one or few places, not when you have thousands of pages in hundreds of spaces (think Curriki), most of which are of no interest to you.
TANSTAAFL. No UI is the best for all people and all use cases. We could have several ways of choosing an image: tree based, most recently used, media gallery collecting pictures from different sets of pages (current page, current space, all wiki, recently changed documents, recently uploaded images, ...). The user would choose the best for him, or the best for the given scenario.
+1. This is also what I was suggesting when I was proposing an option to switch from the treeview to an image gallery mode. I also would like to see inside the treeview a branch labelled "Last viewed pages/ images". Thanks -Vincent
Sometimes I just want to link to a precise image, and I can go to it "with my eyes closed", sometimes I want to insert a bluey image, and sometimes I want to use an image I remember seeing a few days ago somewhere, can't remember where exactly, but somewhere in one of these 5 documents.
We could use Google Gears to keep track of the last preferences, since cookies are too expensive, and serverside increases the storage needlessly.
But that's for the future.
Hope you'll reconsider and continue discussing here.
Thanks -Vincent
1 - select 2 - insert 3 - Ho zut 4 - edit ? 5 - ho... am i on the right box ? 6- click on edit (or close the dialogue, in this case delete img and reclick on insert image) 7 - reselect img 8 - ok more options... 9 - ha... yes my image is too big 10 - change option 11 - insert
if you have 2 steps on inserting dialogue always display all step, so that user always know where he is
laurent
This is a scenario. A possible one. But not a frequent one, and most certainly not the most common. So a few users will have to loose some seconds a few times until they learn how to do it the right way. But it will also save a little time from everybody else EVERY time. A little bit every time versus a bit more on a few occasions is an obvious choice for me.
Usually IT solutions are chosen and imposed in a company. If some guy or gal gets his little brain confused by the fact that more options are behind the "more options" button, he won't matter. Brainless secretaries don't make IT decisions. They are a big part of our users, but they are not the ones that decide what product to choose.
I tend to believe that we are trying to develop a powerful wiki. XWiki has many features nobody else has (yet), and it is certainly not targeted as a Word replacer (Google Docs does a good job here). If users need power, they will choose XWiki. If they just need something to write notes on, then I personally wouldn't recommend XWiki to them to begin with. Yes, a few people chose something else because of the WYSIWYG, but not because it was a tad more difficult to use, because it was REALLY BUGGY, and I agree with them. Our TinyMCE editor is almost useless for anything more complex than writing a plain letter with a few bold words, and I never use it because of this. As long as we have as little bugs as possible, and it doesn't prove to be extremely complex, I say we're safe.
More, if a client really needs a simple UI that can be used by a group of mentally retarded children, we can always do some custom development. It is important to have a configurable editor, not to have ONE interface that can satisfy everybody from hard-core hackers and 3-year youngsters. By the clickety current look of the WYSIWYG editor, I am pretty sure I'll stay away from it.
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
3 and 4 are interesting. But I think 4 is more easy for users so my vote is: +1 for 4 and +0 for 3 Thanks for your good job. -- View this message in context: http://n2.nabble.com/-VOTE--UI--WYSIWYG-Wiki-Explorer-tp1576940p1598053.html Sent from the XWiki- Dev mailing list archive at Nabble.com.
On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
Couldn't we show the images in the tree (as thumbnails)?
It's worth a try but I fear that we're not far from crossing the line between a tree explorer and a power-plant :)
Maybe a checkbox to switch from treeview to image browser?
This could be an evolution but I think we must agree on our generic way of browsing the wiki first :).
s/user/power user/
Why do you say that? With your argument every user is dumb and would not be able to use a computer at all. Have you every seen a computer OS screen when there's only 1 button and wizards to go to the next step? Come on, look at your screen, and see all the buttons and places you can click (right now when typing this I can see at least 100 locations I can click and I'm on a Mac, reputed for being easy to use). Life is not just a wizard! :)
XWiki is not an OS, being able to use an OS/Office suite is the result of hundreds of hours of self-training (believe it or not). Some computer users already had a hard time assimilating OSes UI paradigms. They did it because being able to use a computer is a matter of survival. On the other side they won't make any effort to learn how to use our product, they either will be able to use XWiki without thinking or they'll give up. I don't fear complex UIs myself but I won't assume it is the same for everyone. ps: you really should see beginners using XWiki during trainings.
I agree we should not make complex screen but there's a fine line between complex and useful. I even don't disagree with option 4 even though I don't think it's required (unless we wanted to make it work on mobile devices for ex but then it's a completely different skin that we would need and it would be pretty stupid to use a mobile device design on large screens since you'd loose lots of screen estate).
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
Yep, this sounds like a valid option, I'll make a mockup.
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
I agree it's not a big deal. Still I'm unsure why we need 2 screens. The one argument that seems valid to me is screen estate but then I'm not sure it wouldn't fit (we need to have it work on 1024x768 and not lower since all our site is made to work on 1024x768).
The 480x480px size is not arbitrary, it's nearly the maximum height we can have for a dialog on a 1024 screen. About width we can sure have 960x480px but this would mean that our dialog is taking the entire viewport (and it means that we'd have a dialog bigger than the wysiwyg itself). JV.
On Fri, Nov 28, 2008 at 12:13 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
Couldn't we show the images in the tree (as thumbnails)?
It's worth a try but I fear that we're not far from crossing the line between a tree explorer and a power-plant :)
Maybe a checkbox to switch from treeview to image browser?
This could be an evolution but I think we must agree on our generic way of browsing the wiki first :).
s/user/power user/
Why do you say that? With your argument every user is dumb and would not be able to use a computer at all. Have you every seen a computer OS screen when there's only 1 button and wizards to go to the next step? Come on, look at your screen, and see all the buttons and places you can click (right now when typing this I can see at least 100 locations I can click and I'm on a Mac, reputed for being easy to use). Life is not just a wizard! :)
XWiki is not an OS, being able to use an OS/Office suite is the result of hundreds of hours of self-training (believe it or not). Some computer users already had a hard time assimilating OSes UI paradigms. They did it because being able to use a computer is a matter of survival. On the other side they won't make any effort to learn how to use our product, they either will be able to use XWiki without thinking or they'll give up. I don't fear complex UIs myself but I won't assume it is the same for everyone.
ps: you really should see beginners using XWiki during trainings.
I agree with this. A typical user has a choice between 3 OSes and has to have one, therefore he had to learn how his favorite one worked. When it comes to wikis, there are 50+ options out there and since it's server-based it's really easy for an admin to change the wiki software used by a large population based on user feedback. If an user cannot use the tool the very first time he uses it, there will be not second time, thus the productivity argument really is conditional on the user being able to complete the action he wants to in the first place. The level 1 objective is action completion, productivity is a level 2 objective compared to it. Therefore, the easier it is to use the better it is. Re the productivity argument, it can be addressed using the additional "insert" / "more options" buttons Vincent suggested. Plus power users will keep using the wiki syntax => another option we might want to explore in the future being syntax autocompletion in the wiki editor, close to what IDEs (and XEclipse's latest release if I understand right) already do ;-)
I agree we should not make complex screen but there's a fine line between complex and useful. I even don't disagree with option 4 even though I don't think it's required (unless we wanted to make it work on mobile devices for ex but then it's a completely different skin that we would need and it would be pretty stupid to use a mobile device design on large screens since you'd loose lots of screen estate).
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
Yep, this sounds like a valid option, I'll make a mockup.
IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no.
I agree it's not a big deal. Still I'm unsure why we need 2 screens. The one argument that seems valid to me is screen estate but then I'm not sure it wouldn't fit (we need to have it work on 1024x768 and not lower since all our site is made to work on 1024x768).
The 480x480px size is not arbitrary, it's nearly the maximum height we can have for a dialog on a 1024 screen. About width we can sure have 960x480px but this would mean that our dialog is taking the entire viewport (and it means that we'd have a dialog bigger than the wysiwyg itself).
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/
On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
WDYT?
The more I think about this the more I'd prefer to stick with the inital 4) proposal. 1) Tree : Maintaining consistent navigation is important in helping users find the information they want. This tree could become the main navigation tool in the wiki. 2) "Rigid" wizard : Since the same dialogs are used for insertion and edition I think it's a good thing to make the option step mandatory, this way the user won't be surprised to see this dialog (options) when he edits the object (link, image, macro, etc). Also, we -- users -- hate mistakes, so I think that it's better to avoid the risk Laurent has described. 3)
On Dec 1, 2008, at 10:48 AM, Jean-Vincent Drean wrote:
On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
WDYT?
The more I think about this the more I'd prefer to stick with the inital 4) proposal.
1) Tree : Maintaining consistent navigation is important in helping users find the information they want. This tree could become the main navigation tool in the wiki. 2) "Rigid" wizard : Since the same dialogs are used for insertion and edition I think it's a good thing to make the option step mandatory, this way the user won't be surprised to see this dialog (options) when he edits the object (link, image, macro, etc). Also, we -- users -- hate mistakes, so I think that it's better to avoid the risk Laurent has described. 3)
I'm ok with 4 as well. My only comment is that maybe it would be best to have 2 buttons in the action list: one for the action (e.g. "Insert") and one for the next step ("Next"). For Link and image insertion we would have the "Insert" button active and for the Macro insertion it would be greyed out since we want to force the user to go to the second screen (since he needs to fill the macro parameters (for the mandatory ones) + the macro content. Thanks -Vincent
For me 4 is ok : +1and for section 6 : +1 for option A (the position of the position of the buttons at the bottom of the subentry) 2008/12/1 Vincent Massol <[email protected]>
On Dec 1, 2008, at 10:48 AM, Jean-Vincent Drean wrote:
On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol <[email protected]> wrote:
Ok back to constructive comments:
What about 2 buttons on the first screen: * Insert * More Options...
If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc.
It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :)
WDYT?
The more I think about this the more I'd prefer to stick with the inital 4) proposal.
1) Tree : Maintaining consistent navigation is important in helping users find the information they want. This tree could become the main navigation tool in the wiki. 2) "Rigid" wizard : Since the same dialogs are used for insertion and edition I think it's a good thing to make the option step mandatory, this way the user won't be surprised to see this dialog (options) when he edits the object (link, image, macro, etc). Also, we -- users -- hate mistakes, so I think that it's better to avoid the risk Laurent has described. 3)
I'm ok with 4 as well. My only comment is that maybe it would be best to have 2 buttons in the action list: one for the action (e.g. "Insert") and one for the next step ("Next").
For Link and image insertion we would have the "Insert" button active and for the Macro insertion it would be greyed out since we want to force the user to go to the second screen (since he needs to fill the macro parameters (for the mandatory ones) + the macro content.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (11)
-
Anca Paula Luca -
Florin Ciubotaru -
Guillaume Lerouge -
Jean-Vincent Drean -
Laurent Lunati -
Marius Dumitru Florea -
Sergiu Dumitriu -
stephane barbey -
stephanie pouliquen -
Thomas Eveilleau -
Vincent Massol