Hi,
I'd also like to propose to release RC1 tomorrow (and note have
colibri as the default skin in it), and continue fixing colibri in
RC1, and release RC2 as planned on the 17th of sep, hoping that
there's no RC3.
This will allow people to start testing RC1 since it's an RC for
everything except the new skin.
Here's my +1
Thanks
-Vincent
Hi devs,
I get some anxiety about two facts I noticed. I'm wondering if I
should. Maybe you can give me advices ?
Points are :
- UX design can be faster than dev. Especially when UX design is made
upon rapid expertise according to the UX designer experience.
- Open source devs sometime dev for them own fun. People want UX
advice, which can also easily transform in a list of a bunch of things
to do.
Well, even when UX goes faster than dev, a brainstorming period let
ideas mature, fork, merge, jump to new ones... So it is not important
if the UX specifications is not implemented immediatly as it mature
among analysis & dev iterations.
UX designers may have to explore various dimensions too detect the
major points. This process can reveal also bunches of minor points
that could be capitalised for later.
What amaze me is when a UX analysis create to too many potential dev
work, I'm always afraid of the risk of stressing and discouraging devs
that code on them free time.
This is quite the same as making user tests, or a vote, so this
already exists. The result is a list of points to work on, with
intrinsic relative importance evaluation. This could be a good point
for classifing things, yet I'm amways affraid that some devs can feel
less fun if this look like a pile of things to do (beacause I may feel
it, that's why). Also when this is user advices, the dev is making is
own classification by analysing the comments. So it is his
classification. I know that, for my part, this sort of thing can be
key in my motication. The fact may be that when asking an expert
advice this is a bit different. The advice come directly from one
person so if the dev consider the UX designer as an authority advice
this may not be anymore his own classification.
An approach that may be interesting could be that if the UX designer
act as a consultant. I mean he transfert his knowledge to the dev by
giving the details on how he makes his analysis and detect UX
implications. So that the dev can take himself the decision of
classifing the by mixing UX and Dev priorities according to the
importance he gives to each single point. This means the dev has a
will in entering the UX process details and gaining skills.
Also this could be interesting for the UX designer because it let him
share the brainstorming with devs and other UX designers before the
decision is taken by project manager, community or the main dev.
Iterations is always good in the UX design process.
So this an approach. There may be others ones better, or adaptated
among each cases.
I would love to have feedbacks on this points, to be able to
understand how people are felling about this.
Thanks !
Thibaut.
Hi,
Let's vote on how to handle the title behavior for the 2.0 final
release so that we're all on the same page.
After talking to several people here's what I propose:
1) We remove the top level H1 only if the title compat flag is on and
the title H1 is the same as the top level H1
2) The compat flag is off by default in our distributions
3) We modify the Toucan and Albatross skins to display the title (same
as Colibri)
4) We modify the Default XE XAR to have titles for all its pages (and
remove the header 1 in page content)
This should cover both user upgrades and new behavior. Note that user
custom skin will still work in most cases since they're not normally
touching the contentview.vm file.
Here's my +1
Thanks
-Vincent
Hi,
Even though we're relasing XE 2.0 final along with a finalized XWiki
Syntax 2.0 there are still several improvements we'd like to bring to
the syntax.
To name a few:
* Fix 2 passes done for wiki context inside links which requires
escaping some chars in link labels.
* Add support for comments - http://jira.xwiki.org/jira/browse/XWIKI-4027
* Mixed list syntax - http://jira.xwiki.org/jira/browse/XWIKI-3133
* Add format parameters support for macros - http://jira.xwiki.org/jira/browse/XWIKI-3237
* Add support for list item parameters in XWiki syntax - http://jira.xwiki.org/jira/browse/XWIKI-3132
* Complete advanced table syntax for XWiki 2.0 rendering - http://jira.xwiki.org/jira/browse/XWIKI-2658
(still to be decided)
* XWiki Syntax 2.0 should ignore spaces before any "standalone block"
syntax - http://jira.xwiki.org/jira/browse/XWIKI-3214
* Add support for relative paths in Link and Image XWiki Syntax 2.0 - http://jira.xwiki.org/jira/browse/XWIKI-3611
* ... and a lot more...
Any of these changes are potentially breaking for existing content.
For example if some current content uses the same syntax as the one
we'll use for comments it's going to break the content.
Thus the solution Thomas and I are proposing is to evolve the syntax
by creating a XWiki Syntax 2.1 version:
* Start working on it in XE 2.1 timeframe
* Define precisely the changes we want to bring for this evolution
* Let's name it something like "XWiki 2.1 (dev)" to show that it's not
final and rename it to "XWiki 2.1" when it's finished and frozen
For end users they'll be able to switch from any current syntax to the
2.1 syntax very easily simply by converting page by page (or by
running a converter to convert a whole wiki). The conversion should be
perfect.
Let's this vote be also about freezing the XWiki 2.0 syntax with the
2.0 final release. This will mean we're forbidden to modify it and all
changes should go in the XWiki Syntax 2.1.
Here's my +1 to have a XWiki Syntax 2.1 in some not too far future and
+1 to freeze the current 2.0 syntax with the XE 2.0 release.
Thanks
-Vincent
Hi everyone,
With Colibri we've started to display the doc title as the document's
rendered title. This is a big change that not only affects Colibri but
in general the way people write documents.
Here's what I suggest:
1) Display doc titles with <div>
2) Display document content headers using <h1>-<h6>
3) Display doc titles with a larger font size than h1 (or h1 with a
smaller font size)
4) Force cursor to be in the title field when editing a new document.
Force cursor in the content field when editing an existing document.
This is to make it easy using the keyboard only to enter doc titles
(since it's currently dead easy, we need something close in easiness)
5) Modify all our existing skins: Toucan, Albatross, Finch and Dodo so
that they use they display the doc title, similarly to Colibri
6) Have a title compatibility flag in xwiki.cfg. When active, use a
Javascript to do this: if there's no title specified for a page and if
the first content is a H1 then use it as the page's title.
We need at least 1), 3), 6) to be able to release the Colibri skin for
2.0 final IMO.
WDYT?
Thanks
-Vincent
Could you merge the changes for menuview.vm to the colibri skin?
On Tue, Sep 8, 2009 at 18:09, jvdrean<platform-notifications(a)xwiki.org> wrote:
> Author: jvdrean
> Date: 2009-09-08 18:09:29 +0200 (Tue, 08 Sep 2009)
> New Revision: 23347
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties
> platform/web/trunk/standard/src/main/webapp/templates/menuview.vm
> platform/web/trunk/standard/src/main/webapp/templates/watch.vm
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEvent.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEventMatcher.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java
> Log:
> XWIKI-4298 : Add watch/unwatch wiki in the Watch menu
> XPWATCHLIST-60 : Watch List should support registering for user activity
>
> The API is now complete. The backend for the future "follow user activity" is implemented and can be used through the object editor.
--
http://purl.org/net/sergiu