On Thu, Apr 7, 2011 at 8:39 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> 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
devs(a)xwiki.org
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