10 Mar
2008
10 Mar
'08
3:40 p.m.
Vincent,
We'd like to see:
* An improved WYSIWYG editor with the following features:
- cut and paste from Word and web pages easily i.e. without having to go
back and adjust the formatting of what's been pasted onto an XWiki page
- cut and paste images without attaching first (i.e. when you cut and paste
images are automatically attached the page)
- can the appearance of table be made better and used to layout the page so
text can be grouped in columns and boxes more easily?
- don't think being able to flip between WYSIWYG and the wiki editor makes
sense - when flipping from WYSIWYG editor and the wiki editor the markup
isn't very readable or editable and a lot of errors seem to get introduced.
I guess the wiki markup editor allows you to enter code easily so a wiki
editor is still useful, but maybe the WYSIWYG editor could allow editing of
text WYSIWYG style BUT also allow wiki editing of sections of the page, so
that way you hide the awful WYSIWYG markup layout but allow wiki markups and
code in defined sections of a page. These wiki/code sections in the WYSIWYG
editor could then be marked by boxes containing the wiki markup and code -
do you know what I mean? So you get rid of the wiki editor and have one
editor the WYSIWYG editor that allows you to use wiki markup and code in
user defined areas of a page.
- if some wiki markup or code on a page could muckup the layout of the menu
bars, etc can XWiki catch it and prevent it from doing that?
I think how useful and useable the WYSIWYG editor is effects the users
experience and whether they'like and want to use XWiki.
* A way of sending emails to XWiki so they can be stored, archived and
referenced from a wiki page.
Hope that helps.
Richard
-----Original Message-----
From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org]On Behalf
Of Vincent Massol
Sent: 10 March 2008 14:10
To: XWiki Developers; XWiki Users
Subject: [xwiki-users] Roadmap for XE 1.4
Hi everyone,
I'd like everyone's input for defining the XE 1.4 roadmap both on the
general objectives and specific features/bugs to implement/fix.
Here's my first take below. Please comment on it and add other stuff.
This is a brainstorming session. Then we can start assigning
committers/contributors to goals/issues.
General Goals:
============
* Bug fixes
** Go from 240 in JIRA for Core down to 180 on XE 1.4 release date
* Better performance
** Run XE with a profiler and find bottlenecks
** Reduce number of database calls
** Improved page loading (JV)
** Make Stats usable on xwiki.org (ThomasM)
* More automated tests
** More selenium tests
** Add tests on Tomcat 6.x as part of the CI build
** Add tests on Windows and with IE6 and IE7 as part of the CI build
* No new features in general
Of course there are some goals that are always valid irrelevant on any
release and that we should keep in mind:
* More tests
* Better javadoc
* More documentation on xwiki.org
* Code cleanup/refactoring
* Extract more plugins from core into plugins proper
Specific issues to implement/fix
========================
* Add support for removing class properties
(http://jira.xwiki.org/jira/browse/XWIKI-99
)
* (optional - depending on availability) - New rendering rewrite
(http://jira.xwiki.org/jira/browse/XWIKI-654
)
* (optional - depending on availability) - Interface extensions
(http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions
)
* Add any other critical issue here
Thanks
-Vincent
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Thales UK Ltd (Wells) DISCLAIMER: The information contained in this e-mail
is confidential. It may also be legally privileged. It is intended only for
the stated addressee(s) and access to it by any other person is
unauthorised. If you are not an addressee, you must not disclose, copy,
circulate or in any other way use or rely on the information contained in
this e-mail. Such unauthorised use may be unlawful. We may monitor all
e-mail communications through our networks. If you have received this e-mail
in error, please inform us immediately on +44 (0) 1749 672081 and delete it
and all copies from your system. We accept no responsibility for changes to
any e-mail which occur after it has been sent. Attachments to this e-mail
may contain software viruses which could damage your system. We therefore
recommend you virus-check all attachments before opening. A business of
Thales UK Ltd. Registered Office: 2 Dashwood Lang Road, The Bourne Business
Park, Addlestone, Weybridge, Surrey KT15 2NX Registered in England No.
868273
10 Mar
10 Mar
4:02 p.m.
New subject: [xwiki-users] Roadmap for XE 1.4
Hi Richard,
On Mar 10, 2008, at 3:40 PM, goldring, richard wrote:
Vincent,
We'd like to see:
* An improved WYSIWYG editor with the following features:
- cut and paste from Word and web pages easily i.e. without having
to go
back and adjust the formatting of what's been pasted onto an XWiki
page
- cut and paste images without attaching first (i.e. when you cut
and paste
images are automatically attached the page)
- can the appearance of table be made better and used to layout the
page so
text can be grouped in columns and boxes more easily?
- don't think being able to flip between WYSIWYG and the wiki editor
makes
sense - when flipping from WYSIWYG editor and the wiki editor the
markup
isn't very readable or editable and a lot of errors seem to get
introduced.
I guess the wiki markup editor allows you to enter code easily so a
wiki
editor is still useful, but maybe the WYSIWYG editor could allow
editing of
text WYSIWYG style BUT also allow wiki editing of sections of the
page, so
that way you hide the awful WYSIWYG markup layout but allow wiki
markups and
code in defined sections of a page. These wiki/code sections in the
WYSIWYG
editor could then be marked by boxes containing the wiki markup and
code -
do you know what I mean? So you get rid of the wiki editor and have
one
editor the WYSIWYG editor that allows you to use wiki markup and
code in
user defined areas of a page.
- if some wiki markup or code on a page could muckup the layout of
the menu
bars, etc can XWiki catch it and prevent it from doing that?
I think how useful and useable the WYSIWYG editor is effects the users
experience and whether they'like and want to use XWiki.
Yes this is a big thorn in our side. We've refrained from touching it
recently because we don't believe in the underlying architecture based
on TinyMCE. Instead some committers have started working on a new
WYSIWYG component based on GWT.
That said, if anyone wants to send patches for the current WYSIWYG
editor, I'll gladly apply them.
* A way of sending emails to XWiki so they can be
stored, archived and
referenced from a wiki page.
Yep, I remember some talking about this.
BTW I wonder if XWiki Watch could be used for this? We'd just need to
hook a mailbox + a POP module (or a mailing list archive reader) and
it should work just fine I think.
Jerome/Anca, WDYT?
Thanks
-Vincent
Hope that helps.
Richard
-----Original Message-----
From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org]On
Behalf
Of Vincent Massol
Sent: 10 March 2008 14:10
To: XWiki Developers; XWiki Users
Subject: [xwiki-users] Roadmap for XE 1.4
Hi everyone,
I'd like everyone's input for defining the XE 1.4 roadmap both on the
general objectives and specific features/bugs to implement/fix.
Here's my first take below. Please comment on it and add other stuff.
This is a brainstorming session. Then we can start assigning
committers/contributors to goals/issues.
General Goals:
============
* Bug fixes
** Go from 240 in JIRA for Core down to 180 on XE 1.4 release date
* Better performance
** Run XE with a profiler and find bottlenecks
** Reduce number of database calls
** Improved page loading (JV)
** Make Stats usable on xwiki.org (ThomasM)
* More automated tests
** More selenium tests
** Add tests on Tomcat 6.x as part of the CI build
** Add tests on Windows and with IE6 and IE7 as part of the CI build
* No new features in general
Of course there are some goals that are always valid irrelevant on any
release and that we should keep in mind:
* More tests
* Better javadoc
* More documentation on xwiki.org
* Code cleanup/refactoring
* Extract more plugins from core into plugins proper
Specific issues to implement/fix
========================
* Add support for removing class properties
(http://jira.xwiki.org/jira/browse/XWIKI-99
)
* (optional - depending on availability) - New rendering rewrite
(http://jira.xwiki.org/jira/browse/XWIKI-654
)
* (optional - depending on availability) - Interface extensions
(http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions
)
* Add any other critical issue here
Thanks
-Vincent
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Thales UK Ltd (Wells) DISCLAIMER: The information contained in this
e-mail
is confidential. It may also be legally privileged. It is intended
only for
the stated addressee(s) and access to it by any other person is
unauthorised. If you are not an addressee, you must not disclose,
copy,
circulate or in any other way use or rely on the information
contained in
this e-mail. Such unauthorised use may be unlawful. We may monitor all
e-mail communications through our networks. If you have received
this e-mail
in error, please inform us immediately on +44 (0) 1749 672081 and
delete it
and all copies from your system. We accept no responsibility for
changes to
any e-mail which occur after it has been sent. Attachments to this
e-mail
may contain software viruses which could damage your system. We
therefore
recommend you virus-check all attachments before opening. A business
of
Thales UK Ltd. Registered Office: 2 Dashwood Lang Road, The Bourne
Business
Park, Addlestone, Weybridge, Surrey KT15 2NX Registered in England No.
868273
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
5:01 p.m.
New subject: [xwiki-users] Roadmap for XE 1.4
Hi,
* An improved WYSIWYG editor with the following
features:
Thanks for these numerous suggestions. Richard, could you please add them to
the http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorBasedOnGwtpage
so that we can take them into account while working on the editor's
new
version ? There's indeed a lot to do and to think about in terms of how to
display code & wiki syntax in the WYSIWYG editor.
- cut and paste from Word and web pages easily
i.e. without having
to go
back and adjust the formatting of what's been pasted onto an XWiki
page
<snip...>
> - if some wiki markup or code on a page could muckup the layout of
> the menu
> bars, etc can XWiki catch it and prevent it from doing that? I think how useful and useable the WYSIWYG editor is
effects the users
> experience and whether they'like and want to use XWiki.
Agreed. Which is why we're working on its specification in order to start
its implementation ASAP. User feedback during this process would be more
than welcome.
* A way of sending emails to XWiki so they can be
stored, archived and
referenced from a wiki page.
Yep, I remember some talking about this.
BTW I wonder if XWiki Watch could be used for this? We'd just need to
hook a mailbox + a POP module (or a mailing list archive reader) and
it should work just fine I think.
I'm not sure this is the most relevant way to do it. I'd rather see an email
archive application that would work this way -> you send an email to a given
address (say emailarchive(a)yourxwikiserver.com) .
The email is converted into a wiki page with an unique identifier based on
its subject, sender, date etc. The page metadata uses the email info to fill
in the author & creation date. A check would probably be needed for
protected page (add the email only if the sender's email adresses matches
the one of an user who has rights on that page).
An index page lists all the email and allows filtering & searching them.
A macro allows to quote a mail in a page (could be done with #includeTopic(
MailArchive.UniqueEmailIdentifier) actually)
Anyway more discussions would be needed to decide whether that application
would be worth making it into XE 1.4 (though I'd be glad to have it).
Here is some additional feedback I gathered :
- *Migration*
- Make the migration between 2 versions of XWiki even easier
than it is now (some bugs remain, making upgrades a chore on many
occasions).
- *Applications*
- Remove unfinished applications (such as the calendar & the
photo album) from the default distribution and put them as XARs on
XWiki.org instead
- *Translations*
- Replace all text in the default wiki with $msg.get() calls and
update the translation file to include EN & FR translations for
all of them.
- *Administration*
- Add a select box to the language selection field
- Add explanations next to each field to explain what they do
- Groups : add a button "Add a member to this group" on group
pages (below the list of group members)
- *Space Administration*
- Add the ability to customize the color of a space easily in
Toucan
- Add the possibility to use the Panel Wizard for a space
- *Autosuggest*
- Generalize the autosuggest feature to most input fields on the
wiki
I'll try to post some more once I've received it.
Guillaume
15 Mar
15 Mar
10:21 a.m.
New subject: [xwiki-users] Roadmap for XE 1.4
Hi,
Currently, Watch can read any mail archive that is published through an
RSS so it can integrate content from mails provided that there is an
intermediary tool to do this 'translation'.
As for directly reading a mailbox and a mail archive, here's how we could
do it: apart from the feed reader plugin, we can have a mailreader plugin
to handle this job (and just the same, a lot of other reader plugins to
handle various types of content). It seems the right way of adding extra
content fetching powers to Watch so this is, in the end, not a Watch
specific job but more like a plugins one.
Having Watch read emails and giving the user the possibility of 'mailing'
content to Watch sounds like a good feature...
* An improved WYSIWYG editor with the following
features:
Thanks for these numerous suggestions. Richard, could you please add them
to
the
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorBasedOnGwtpage
so that we can take them into account while working on the editor's
new
version ? There's indeed a lot to do and to think about in terms of how to
display code & wiki syntax in the WYSIWYG editor.
- cut and paste from Word and web pages easily
i.e. without having
to go
back and adjust the formatting of what's been pasted onto an XWiki
page
<snip...>
> - if some wiki markup or code on a page could muckup the layout of
> the menu
> bars, etc can XWiki catch it and prevent it from doing that? I think how useful and useable the WYSIWYG editor
is effects the users
> experience and whether they'like and want to use XWiki.
Agreed. Which is why we're working on its specification in order to start
its implementation ASAP. User feedback during this process would be more
than welcome.
* A way of sending emails to XWiki so they can be
stored, archived and
referenced from a wiki page.
Yep, I remember some talking about this.
BTW I wonder if XWiki Watch could be used for this? We'd just need to
hook a mailbox + a POP module (or a mailing list archive reader) and
it should work just fine I think.
I'm not sure this is the most relevant way to do it. I'd rather see an
email
archive application that would work this way -> you send an email to a
given
address (say emailarchive(a)yourxwikiserver.com) .
The email is converted into a wiki page with an unique identifier based on
its subject, sender, date etc. The page metadata uses the email info to
fill
in the author & creation date. A check would probably be needed for
protected page (add the email only if the sender's email adresses matches
the one of an user who has rights on that page).
An index page lists all the email and allows filtering & searching them.
A macro allows to quote a mail in a page (could be done with
#includeTopic(
MailArchive.UniqueEmailIdentifier) actually)
Anyway more discussions would be needed to decide whether that application
would be worth making it into XE 1.4 (though I'd be glad to have it).
Here is some additional feedback I gathered :
- *Migration*
- Make the migration between 2 versions of XWiki even easier
than it is now (some bugs remain, making upgrades a chore on many
occasions).
- *Applications*
- Remove unfinished applications (such as the calendar & the
photo album) from the default distribution and put them as XARs on
XWiki.org instead
- *Translations*
- Replace all text in the default wiki with $msg.get() calls and
update the translation file to include EN & FR translations for
all of them.
- *Administration*
- Add a select box to the language selection field
- Add explanations next to each field to explain what they do
- Groups : add a button "Add a member to this group" on group
pages (below the list of group members)
- *Space Administration*
- Add the ability to customize the color of a space easily in
Toucan
- Add the possibility to use the Panel Wizard for a space
- *Autosuggest*
- Generalize the autosuggest feature to most input fields on the
wiki
I'll try to post some more once I've received it.
Guillaume
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
11:30 a.m.
New subject: [xwiki-users] Managing emails in XWiki (was Re: Roadmap for XE 1.4)
On Mar 10, 2008, at 5:01 PM, Guillaume Lerouge wrote:
[snip]
I don't agree. What you have in mind is a simple email storage/search
facility. However leverage watch we get much more:
* The ability to tag/filter interesting mails. Since the problem with
mails is that the information is scattered a bit everywhere, I think
it's useful to be able to say that such email is flagged as containing
interesting information for example.
* The ability to reuse an existing interface with all its niceness
* Emails are just a source of information. I recall Ludovic saying
that Watch was designed to allow different input sources. For example
for AFP we had discussed using Watch to read their existing documents
and presenting them in Watch.
* The Watch Email plugin would be easily plugged onto a mailing list
(by having a watch user subscribed to the list for example). Another
plugin would be one that plugs on the email list manager (and thus can
request past emails, etc).
* When Watch gets new features added our email feature also gets
features added automatically.
* Watch can be seen as a generic tool for managing information source
feeds.
* A way of
sending emails to XWiki so they can be stored, archived
and
referenced from a wiki page.
Yep, I remember some talking about this.
BTW I wonder if XWiki Watch could be used for this? We'd just need to
hook a mailbox + a POP module (or a mailing list archive reader) and
it should work just fine I think.
I'm not sure this is the most relevant way to do it. I'd rather see an email archive application that
would work this way
-> you send an email to a given address (say emailarchive(a)yourxwikiserver.com
) .
There's another option. Create a forum application to manage mails in
the same as Jive is doing it with their forum:
http://www.jivesoftware.com/products/forums/featuretour.jsp
They also support plugging in their forum onto an existing mailing
list which is great.
IMO going the Watch route would be a good thing to try as a POC or as
a GSOC since it shouldn't be too hard to do.
The email is converted into a wiki page with an unique
identifier
based on its subject, sender, date etc.
This is true with Watch too.
The page metadata uses the email info to fill in the
author &
creation date. A check would probably be needed for protected page
(add the email only if the sender's email adresses matches the one
of an user who has rights on that page).
An index page lists all the email and allows filtering & searching
them.
A macro allows to quote a mail in a page (could be done with
#includeTopic(MailArchive.UniqueEmailIdentifier) actually)
Anyway more discussions would be needed to decide whether that
application would be worth making it into XE 1.4 (though I'd be glad
to have it).
[snip]
Thanks
-Vincent
11:51 a.m.
New subject: [xwiki-users] Managing emails in XWiki (was Re: Roadmap for XE 1.4)
[snip]
Indeed. In the end, Watch is a tool that basically allows for collaborative
filtering of any kind of information as long as it can get in under the form
of ordered items (articles, messages, posts...).
My point was not so much that Watch cannot do email management (I'm
convinced that it could indeed bring a lot of value to the process of email
filtering, for instance by allowing a team of salespeople to filter &
classify incoming contact mails), but rather than its features set might be
an overkill for people with basic email archiving needs.
* A way of
sending emails to XWiki so they can be stored, archived and
referenced from a wiki page.
Yep, I remember some talking about this.
BTW I wonder if XWiki Watch could be used for this? We'd just need to
hook a mailbox + a POP module (or a mailing list archive reader) and
it should work just fine I think.
I'm not sure this is the most relevant way to do it.
I don't agree. What you have in mind is a simple email storage/search
facility. However leverage watch we get much more:
* The ability to tag/filter interesting mails. Since the problem with
mails is that the information is scattered a bit everywhere, I think it's
useful to be able to say that such email is flagged as containing
interesting information for example.
* The ability to reuse an existing interface with all its niceness
* Emails are just a source of information. I recall Ludovic saying that
Watch was designed to allow different input sources. For example for AFP we
had discussed using Watch to read their existing documents and presenting
them in Watch.
* The Watch Email plugin would be easily plugged onto a mailing list (by
having a watch user subscribed to the list for example). Another plugin
would be one that plugs on the email list manager (and thus can request past
emails, etc).
* When Watch gets new features added our email feature also gets features
added automatically.
* Watch can be seen as a generic tool for managing information source
feeds.
I'd rather see an email archive application that
would work this way ->
you send an email to a given address (say emailarchive(a)yourxwikiserver.com)
.
There's another option. Create a forum application to manage mails in the
same as Jive is doing it with their forum:
http://www.jivesoftware.com/products/forums/featuretour.jsp
They also support plugging in their forum onto an existing mailing list
which is great.
Since the way a forum works is very similar to the way a mailing list does,
this can be an interesting idea too : let users post from either the forum &
the mailing list, and have emails automatically generate forum entries &
forum entries being sent as emails to the list. In the end the user doesn't
care where to post from, like what Nabble offers
IMO going the Watch route would be a good thing to try as a POC or as a GSOC
since it shouldn't be too hard to do.
+1 for making this a PoC / GSoC project.
As for how to do all this, I think Anca proposed a sound way to do it :
"As for directly reading a mailbox and a mail archive, here's how we could
do it: apart from the feed reader plugin, we can have a mailreader plugin
to handle this job (and just the same, a lot of other reader plugins to
handle various types of content). It seems the right way of adding extra
content fetching powers to Watch so this is, in the end, not a Watch
specific job but more like a plugins one."
-> We could write a mail plugin (in fact I think there's already some kind
of a mail API in XWiki, coming from the mail-1.4.jar plugin, but we could
also use something like James -> http://james.apache.org/) that would
receive email and then process it towards either Watch, the Forum or any
other application (maybe using something such as this :
http://james.apache.org/mailet/index.html), to allow for maximum
flexibility.
[snip]
Guillaume
9:19 p.m.
New subject: [xwiki-users] Managing emails in XWiki (was Re: Roadmap for XE 1.4)
[snip]
Indeed. In the end, Watch is a tool that basically allows for
collaborative
filtering of any kind of information as long as it can get in under the
form
of ordered items (articles, messages, posts...).
My point was not so much that Watch cannot do email management (I'm
convinced that it could indeed bring a lot of value to the process of
email
filtering, for instance by allowing a team of salespeople to filter &
classify incoming contact mails), but rather than its features set might
be
an overkill for people with basic email archiving needs.
Content fetching enhancement is proposed as a GSoC project, we just need
to edit it and specify that we also want emails:
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Improvedcontentfetch…
* A way
of sending emails to XWiki so they can be stored, archived and
referenced from a wiki page.
Yep, I remember some talking about this.
BTW I wonder if XWiki Watch could be used for this? We'd just need to
hook a mailbox + a POP module (or a mailing list archive reader) and
it should work just fine I think.
I'm not sure this is the most relevant way to do it.
I don't agree. What you have in mind is a simple email storage/search
facility. However leverage watch we get much more:
* The ability to tag/filter interesting mails. Since the problem with
mails is that the information is scattered a bit everywhere, I think
it's
useful to be able to say that such email is flagged as containing
interesting information for example.
* The ability to reuse an existing interface with all its niceness
* Emails are just a source of information. I recall Ludovic saying that
Watch was designed to allow different input sources. For example for AFP
we
had discussed using Watch to read their existing documents and
presenting
them in Watch.
* The Watch Email plugin would be easily plugged onto a mailing list (by
having a watch user subscribed to the list for example). Another plugin
would be one that plugs on the email list manager (and thus can request
past
emails, etc).
* When Watch gets new features added our email feature also gets
features
added automatically.
* Watch can be seen as a generic tool for managing information source
feeds.
I'd rather see an email archive application
that would work this way ->
you send an email to a given address (say
emailarchive(a)yourxwikiserver.com)
.
There's another option. Create a forum application to manage mails in
the
same as Jive is doing it with their forum:
http://www.jivesoftware.com/products/forums/featuretour.jsp
They also support plugging in their forum onto an existing mailing list
which is great.
Since the way a forum works is very similar to the way a mailing list
does,
this can be an interesting idea too : let users post from either the forum
&
the mailing list, and have emails automatically generate forum entries &
forum entries being sent as emails to the list. In the end the user
doesn't
care where to post from, like what Nabble offers
IMO going the Watch route would be a good thing to try as a POC or as a
GSOC
since it shouldn't be too hard to do.
+1 for making this a PoC / GSoC project.
As for how to do all this, I think Anca proposed a sound way to do it :
"As for directly reading a mailbox and a mail archive, here's how we could
do it: apart from the feed reader plugin, we can have a mailreader plugin
to handle this job (and just the same, a lot of other reader plugins to
handle various types of content). It seems the right way of adding extra
content fetching powers to Watch so this is, in the end, not a Watch
specific job but more like a plugins one."
-> We could write a mail plugin (in fact I think there's already some kind
of a mail API in XWiki, coming from the mail-1.4.jar plugin, but we could
also use something like James -> http://james.apache.org/) that would
receive email and then process it towards either Watch, the Forum or any
other application (maybe using something such as this :
http://james.apache.org/mailet/index.html), to allow for maximum
flexibility.
[snip]
Guillaume
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
6033
days inactive
6038
days old
6 comments
4 participants
participants (4)
-
ancapaula.luca＠xwiki.com -
goldring, richard -
Guillaume Lerouge -
Vincent Massol