16 Oct
2009
16 Oct
'09
9:44 a.m.
Hi Anca,
On Thu, Oct 15, 2009 at 9:07 PM, Anca Luca <ancapaula.luca(a)xwiki.com> wrote:
to
I don't have a plan.
Good luck.
name)
Application with server side code, I don't know exactly how this would be
called.
XWiki
Ok. Sounds good given your above explanation about annotation definition in
a XClass.
Guillaume
a
not
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Hi Guillaume,
Guillaume Lerouge wrote:
far
Ok, thanks for the clarification :-)
Sounds good to me since it's not too complex for users but at the same time
addresses Scribo's needs (if I understood those correctly).
Hi Anca,
On Wed, Oct 14, 2009 at 10:03 PM, Anca Luca <ancapaula.luca(a)xwiki.com
wrote:
> Hello devs,
>
> The current state of the annotation feature in the sandbox can be
described
> by
> the following:
> * there is a single type of annotation which can be added, using a
specific
> javascript client backed by a rest service.
Such an annotation contains
an
> annotation text, the annotated content and
its position and this type is
> highly
> coupled in the plugin implementation
> * the backing annotation storage is based on components, currently with
an
> XWiki
> objects implementation but a different service can be easily created
(there
> is
> one implemented for Scribo annotations stored in RDF)
> * for the moment, only xwiki documents and feed entries fetched by the
> feedreader plugin can be used as targets for annotations (the annotated
> documents), with the restriction that the content of the document is
*not*
> generated using scripting. A component can be
implemented for a new type
of
> document but the current UI (the javascript
client) is *specific to
xwiki
> documents*
> * the javascript client (UI) is only in the state of a prototype: while
> proving
> that it works, it is not robust enough and the user experience is poor
> * annotation creation algorithm seems to perform well in practice, but
we
> should
> put it to more real-world test (by releasing).
>
> Some *requirements* in terms of functionality, in order to make this an
> extensible and flexible feature, would be to:
> * be able to have different types of annotations (one to be able to
easily
> specify fields for the annotations to add),
with storage as xwiki
objects.
> This
> needs to be flexible at all levels: UI and storage backend, preferably
> using
> xwiki scripting (no jars on the server side, or java coding) so that it
can
> be
> easily customized. Also, the annotation UI should be thought of as easy
to
customize
and create whatever forms and actions in a light manner.
I'm not sure I understand this one well. What exactly do you mean by
"different types of annotations"? From what I understand right now, this
means the following:
1. I select text and choose to annotate it
2. I select custom properties for my annotation (let's say additional
"city" & "country" fields)
3. I fill in those fields and save the annotation
4. My annotation is saved with those custom fields
If this is correct, I'm a bit afraid this will bring un-needed complexity
both to the UI and the backend implementation. From what I understood so it looks a bit like having the XClass editor each
time ones creates a new
annotation -> isn't that overkill?
An alternative solution I was thinking about was to use only 1 field with
a
semantic syntax & autosuggest (something
like: @city:Paris
@country:France).
Is that a possible option? Or maybe it
doesn't make sense in the context
or
your work?
Yet another option would be to offer a number of already configured types
to
select from in a list when adding a new
annotation.
Not exactly.
The idea was that an admin or a wiki programmer could configure the
annotation
application (such as setting an XWiki class as the annotation type) and
then
whenever a user adds an annotation, he will get, in the annotation
"bubble", a
form to edit an object from that class. Right now, to do that, you'd need
to
write a few java components & rewrite the js client. The idea is to have
that
easily configurable, "scriptable" from the wiki.
> * be able
to annotate any type of document (object inside such a
document),
> namely all or any number of text fields in
such an object. Preferably
this
should
also be doable only using xwiki scripting or configuration.
Sounds good.
I would like to propose the following road to perfect this feature:
> *Version 1.0* (somewhere in the timeframe of XE 2.1 RCs)
> The aim would be to take feature out of sandbox preserving its current
> features:
> allowing to add a specific type of annotation saved as XWiki object on a
> regular, non scripted XWiki Document. We should:
> - format, improve comments, generally clean up the current code sandbox > match
> XWiki coding styles
> - refactor packages and components to remove some dependencies issues
and
> increase flexibility
> - simplify flow, stripping out all code which is not strictly needed by
the
> targeted functionality (such as the Feed
entry handling code), and make
it
> easily implementable by a component in a
distinct jar (so that the
Scribo
requirements currently implemented can be preserved)
- finish the javascript client: robust user interaction, intuitive
interface,
cleaned up integration with XE
Do you plan on using GWT to achieve this? If not, what's the best way to
code it in a cross-browser, maintainable way? Using one of the JS library
already embedded in XWiki such as Prototype I guess? > - ensure
quality assurance process by a well setup battery of tests,
unit
and
functional
At this point I propose to have the annotation feature as an installable
plugin
but not included by default in XE, unless after a few bugfixing cycles.
Plugin or component? (maybe this is the same thing under a different
*Version 1.1* (somwhere in the timeframe of XE 2.2, at the beginning of
next
> year)
> * first iteration on the 2 desired features. At this point one should be
> able to
> configure the type of annotation to add, UI should be accomodate this
type,
> backing XWiki storage should be easy to
integrate with any annotation
> storage
> service (for Scribo requirements), and one should easily set a field in
a
> structured document which would support
annotations. (Note that this
might
require
heavy rewrite / refactor of the 1.0 version. We could decide to
skip it
and go straight to this version, but it would take longer.)
My personal point of view is that being able to annotate any part of a document is more important than being able to
configure the type of
annotation to add. Is there a hard requirement on the order from the
Scribo
research project on this?
No, it's not atm afaik, although Scribo could be implemented like that
(Scribo
annotations are structured, not only a piece of text, even if
"serializable" as
a text).
Actually this point is supposed to be an iteration in both directions (not
only
about typed annotations leaving behind the second requirement), and for the
annotation target I specified
> and one should easily set a field in a
> structured document which would support annotations.
* integration of Scribo requirements can be met at
this point by setting
the
configurations according to the Scribo annotation type and target
requirements.
At this point, if we find appropriate, we could make the decision of
including
the annotation feature in XE by default
I guess that will depend on its quality by this time. I think it would be great addition to XE's default feature set.
*Version 1.2* (future)
> * finish the 2 requirements, integration with Scribo would be done in
the
same
manner, by specific configuration and storage backend specific
implementation.
What do you think?
I think this can become a key differentiating feature of XWiki since I'm aware of any wiki that has them implemented yet.
MS Word's annotation
system
is widely used and I think XWiki annotation would
resonate positively
with
XWiki users coming from such text editors.
For the moment I will focus on version 1's tasks while finding a good
Thanks,
Anca
architecture to achieve the desired requirements,
converting, where
necessary,
the direction of the development towards that goal.
Thanks (for reading this very long mail),
:-)
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs