[xwiki-devs] Proposal "Auto Completion in Content Editors" has been refined
Thanks for Sergiu's advices, I have refined my proposal in two aspect: 1. Add "bonding" period in my timeline from April 22th to May 22th 2. Details the technologies of ajax used in front end in both editors, as suggested by Sergiu, in xwiki editor, the ajax for communicating with server side could be implement by prototype, and the code should also be used in WYSIWYG editor by using GWT JSNI to invoke in the GWT code. -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University
Hi James, A few remarks: (1) It's not clear what page suggestions you show initially before the user types any text. Recently modified? (2) It's not clear what happens when the user types after the suggest panel is displayed. Do you filter the visible list or retrieve new suggestions based on the typed text? Search makes more sense. (3) Then if typing = search, the user has to know where each suggested attachment and images is located. Images with the same name could be attached to different pages. Note that the location is displayed for suggested pages. (4) Attachment suggestions should be triggered by Space.Page@ in the context of a link as it happens for images. (5) You generate [[Space.Page]] when the user selects a page. Wouldn't make much sense to generate [[Page Title>>Space.Page]] ? (6) It's not clear what macro suggestions you show initially, before the user types any text. (7) The category icon and the category name are a bit redundant. I prefer only a graphic icon. Also, wouldn't be useful to display a substring of macro description below the macro name? (8) "required" takes too much space, a better way to mark required parameters is needed (9) I'm afraid you can't bypass required parameters or required content when you insert a macro. You can skip the edit macro parameters dialog only if the macro doesn't have required parameters nor required content. (10) If you don't implement the server side as GWT-RPC services (using XWiki components), then you need to propose something else. There are a few options: REST resources, XWiki actions, wiki page, separate servlet. You don't have many details about the server side part. (11) Using !! to trigger image suggestions is problematic. The issue is that XWiki 2.0 syntax is not very auto-complete friendly because [[ is used for both links and images. It's confusing to write !! and then get [[ in the end after you select the image. You need to thing of a better solution. One would be to merge link with image but I'm not sure it's better. Regarding the planning, I noticed that you placed the testing after the implementation. It's best to write tests as early as possible, both unit and functional (Selenium). Hope this helps, Marius On 04/07/2011 10:34 AM, 许凌志(Jamesxu) wrote:
Thanks for Sergiu's advices, I have refined my proposal in two aspect: 1. Add "bonding" period in my timeline from April 22th to May 22th 2. Details the technologies of ajax used in front end in both editors, as suggested by Sergiu, in xwiki editor, the ajax for communicating with server side could be implement by prototype, and the code should also be used in WYSIWYG editor by using GWT JSNI to invoke in the GWT code.
-- Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong University
Thank you Marius for your advices, I will refine my proposal as soon as possible~~~ On Thu, Apr 7, 2011 at 8:39 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi James,
A few remarks:
(1) It's not clear what page suggestions you show initially before the user types any text. Recently modified?
(2) It's not clear what happens when the user types after the suggest panel is displayed. Do you filter the visible list or retrieve new suggestions based on the typed text? Search makes more sense.
(3) Then if typing = search, the user has to know where each suggested attachment and images is located. Images with the same name could be attached to different pages. Note that the location is displayed for suggested pages.
(4) Attachment suggestions should be triggered by Space.Page@ in the context of a link as it happens for images.
(5) You generate [[Space.Page]] when the user selects a page. Wouldn't make much sense to generate [[Page Title>>Space.Page]] ?
(6) It's not clear what macro suggestions you show initially, before the user types any text.
(7) The category icon and the category name are a bit redundant. I prefer only a graphic icon. Also, wouldn't be useful to display a substring of macro description below the macro name?
(8) "required" takes too much space, a better way to mark required parameters is needed
(9) I'm afraid you can't bypass required parameters or required content when you insert a macro. You can skip the edit macro parameters dialog only if the macro doesn't have required parameters nor required content.
(10) If you don't implement the server side as GWT-RPC services (using XWiki components), then you need to propose something else. There are a few options: REST resources, XWiki actions, wiki page, separate servlet. You don't have many details about the server side part.
(11) Using !! to trigger image suggestions is problematic. The issue is that XWiki 2.0 syntax is not very auto-complete friendly because [[ is used for both links and images. It's confusing to write !! and then get [[ in the end after you select the image. You need to thing of a better solution. One would be to merge link with image but I'm not sure it's better.
Regarding the planning, I noticed that you placed the testing after the implementation. It's best to write tests as early as possible, both unit and functional (Selenium).
Hope this helps, Marius
On 04/07/2011 10:34 AM, 许凌志(Jamesxu) wrote:
Thanks for Sergiu's advices, I have refined my proposal in two aspect: 1. Add "bonding" period in my timeline from April 22th to May 22th 2. Details the technologies of ajax used in front end in both editors, as suggested by Sergiu, in xwiki editor, the ajax for communicating with server side could be implement by prototype, and the code should also be used in WYSIWYG editor by using GWT JSNI to invoke in the GWT code.
-- Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong University
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University
On Thu, Apr 7, 2011 at 8:39 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi James,
A few remarks:
Thanks Marius for your advices, here are my answers, and I will refine my proposal based on Marius comments
(1) It's not clear what page suggestions you show initially before the user types any text. Recently modified?
IMO, the initial suggestions for link could be the user recent changes as the link widget does now in WYSIWYG for attachment, the initial suggestions should be the attachments in current page user are editing. see: http://farm6.static.flickr.com/5268/5599744930_ff65ddfdc3_z.jpg(for xwiki editor), http://farm6.static.flickr.com/5064/5599169943_752045455d_z.jpg(for wysiwyg) for image, the initial suggestions should be the images in current page too. see:http://farm6.static.flickr.com/5308/5599193455_0e02a9a950_z.jpg(for xwiki edior), http://farm6.static.flickr.com/5261/5599185003_7efc5d16c9_z.jpg(for wysiwyg) for macro, the initial suggestions should be all macro names available with their category. see: http://farm6.static.flickr.com/5107/5599145959_7c3ae5bfaf_z.jpg(for xwiki editor),http://farm6.static.flickr.com/5142/5599758474_86cbab2881_z.jpg(for wysiwyg)
(2) It's not clear what happens when the user types after the suggest panel is displayed. Do you filter the visible list or retrieve new suggestions based on the typed text? Search makes more sense.
I will search for suggestion according to user input when they keep typing , sending user input to the server side as the input of suggestion algorithm, then return the suggestion list generated by the algorithm to users.
(3) Then if typing = search, the user has to know where each suggested attachment and images is located. Images with the same name could be attached to different pages. Note that the location is displayed for suggested pages.
Yes, this a problem, I have refine the design mockups, in the suggestion results for images and attachments, the path for images and attachemtns will be shown to identify them if some of them have the same names. see the attachments part in : http://farm6.static.flickr.com/5268/5599744930_ff65ddfdc3_z.jpg see the images part in: http://farm6.static.flickr.com/5308/5599193455_0e02a9a950_z.jpg
(4) Attachment suggestions should be triggered by Space.Page@ in the context of a link as it happens for images.
Yes, it is true, I have noticed that, I have refined it, and consider the space.page@ for images see new process:http://www.gliffy.com/publish/2579843/
(5) You generate [[Space.Page]] when the user selects a page. Wouldn't make much sense to generate [[Page Title>>Space.Page]] ?
I have refined it, see the new process: http://www.gliffy.com/publish/2579834/
(6) It's not clear what macro suggestions you show initially, before the user types any text.
Please refer to the answer of question 1
(7) The category icon and the category name are a bit redundant. I prefer only a graphic icon. Also, wouldn't be useful to display a substring of macro description below the macro name?
Refined now, remove the category name and the macro description see: http://farm6.static.flickr.com/5107/5599145959_7c3ae5bfaf_z.jpg
(8) "required" takes too much space, a better way to mark required parameters is needed
Refined now, see: http://farm6.static.flickr.com/5107/5599145959_7c3ae5bfaf_z.jpg
(9) I'm afraid you can't bypass required parameters or required content when you insert a macro. You can skip the edit macro parameters dialog only if the macro doesn't have required parameters nor required content.
Yes, this problem has been mentioned by Sergiu too. I designed two solutions, the first one is shown on the bottom of the image(see here<http://www.gliffy.com/pubdoc/2596804/L.png>) which navigate to the macro editor widget for users, user can edit their; the second one is shown on the top which embed the macro editor widget in the suggestion box IMO, I prefer the first one, it is more easy and less duplicate coding. What do you think?
(10) If you don't implement the server side as GWT-RPC services (using XWiki components), then you need to propose something else. There are a few options: REST resources, XWiki actions, wiki page, separate servlet. You don't have many details about the server side part.
I will try to use REST for server side, so that it is can be a service re-used for auto-suggestion in other scenario.
(11) Using !! to trigger image suggestions is problematic. The issue is that XWiki 2.0 syntax is not very auto-complete friendly because [[ is used for both links and images. It's confusing to write !! and then get [[ in the end after you select the image. You need to thing of a better solution. One would be to merge link with image but I'm not sure it's better.
I had discussion with Marius, but we all have no better idea for triggering images for both editors, so I decide to use !! for my proposal, and keep thinking and discussion
Regarding the planning, I noticed that you placed the testing after the implementation. It's best to write tests as early as possible, both unit and functional (Selenium).
Refined now. please see the new timeline in my proposal
Hope this helps, Marius
On 04/07/2011 10:34 AM, 许凌志(Jamesxu) wrote:
Thanks for Sergiu's advices, I have refined my proposal in two aspect: 1. Add "bonding" period in my timeline from April 22th to May 22th 2. Details the technologies of ajax used in front end in both editors, as suggested by Sergiu, in xwiki editor, the ajax for communicating with server side could be implement by prototype, and the code should also be used in WYSIWYG editor by using GWT JSNI to invoke in the GWT code.
-- Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong University
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University
participants (2)
-
Marius Dumitru Florea -
许凌志(Jamesxu)