On Sat, Jul 20, 2013 at 3:34 PM, Vincent Massol <[email protected]> wrote:

On Jul 20, 2013, at 3:20 PM, Denis Gervalle <[email protected]> wrote:

...

On Sat, Jul 20, 2013 at 2:33 PM, Vincent Massol <[email protected]> wrote:

...

Hi devs,

In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's this time:

" * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :) "

Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this.

The rationale is:

* It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it.

* XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop.

Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

Here's my +1

Thanks -Vincent

Hi Vincent,

I fully agree with your argument, and we need a solution for that. But I am concerned on not having this default integration causing difficulties with existing farm deployment. We should also be careful to not have that feature taking too much place when left unused.

Yes definitely. We need to address: * Support for both workspace mode and farm mode * Minimal visual addition when only 1 wiki is defined (IMO only a Add > New Wiki/Workspce menu entry in this case) * Make sure that upgrading an existing XWiki in farm mode will not cause any problem * Make sure that upgrading an existing XWiki in workspaces mode (i.e. XEM) will not cause any problem

...

Is there some mockup of our target or are you just expecting to make XEM to be XE ?

Caty is working on this investigation and needs to propose something very quickly now so that we can implement it in 5.2 (already started)… :)

What Caty has already done is available at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

...

What do you expect this will evolve when we introduce flavor ?

The Workspaces flavor, see http://xwiki.markmail.org/thread/n2yove6lr3rlzh6j

You're right, basically this means working on the Workspaces flavor in 5.2 since when we have flavors users can easily choose what they want to have.

+1 but we should agree on the implementation (UI + farm upgrade).

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]> wrote:

On 07/20/2013 07:33 AM, Vincent Massol wrote:

...

Hi devs,

In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's this time:

" * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :) "

Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this.

The rationale is:

* It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it.

* XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop.

Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

Here's my +1

This is a major shift in how first-time users perceive XWiki. Without multi-wiki features, it still looks like a wiki, but if the homepage changes from a "welcome to your wiki" page to a "here are your workspaces" portal, then suddenly XWiki "becomes" something else in the eyes of our users. I used quotes since nothing changes on the inside, the multiwiki feature has been there since the beginning, and the single wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

But this change in how XWiki is perceived has both advantages and disadvantages. On one hand, it clearly shows users that XWiki is a collaborative platform, not just a wiki, so people that need collaboration more than just a wiki will be able to see that XWiki isn't another boring wiki. On the other hand, people that are just looking for a wiki that's nice to use and "not-ugly", might be put off by yet another layer of complexity, and might drop XWiki from their list of candidates. In other words, it alienates even more the kind of users that already perceive XWiki as hard to use and overly complex.

So, are we willing to trade one type of users for the other? It would be in line with our vision of "enterprise collaboration", but I still think we shouldn't voluntarily alienate any kind of users.

An alternative is to wait for a real flavor, and then ask in the first step of the distribution manager what kind of usage do we want. In the meantime, we can still polish the pages that will go in the "workspaces" flavor.

So, -0 for switching to "workspaces only" in 5.2, unless we have really good backwards compatibility and a flavor for a simple wiki for textual collaboration.

I hope the above allays your fears :) Thanks -Vincent

On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <[email protected]> wrote:

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/20/2013 07:33 AM, Vincent Massol wrote:

...

Hi devs,

In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's this time:

" * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :) "

Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this.

The rationale is:

* It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it.

* XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop.

Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

Here's my +1

This is a major shift in how first-time users perceive XWiki. Without multi-wiki features, it still looks like a wiki, but if the homepage changes from a "welcome to your wiki" page to a "here are your workspaces" portal, then suddenly XWiki "becomes" something else in the eyes of our users. I used quotes since nothing changes on the inside, the multiwiki feature has been there since the beginning, and the single wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

Proposals: * Changes to the Menu http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu * Wiki/Workspace Creation http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... (please chose between Option A, B or C) Thanks, Caty

...

But this change in how XWiki is perceived has both advantages and disadvantages. On one hand, it clearly shows users that XWiki is a collaborative platform, not just a wiki, so people that need collaboration more than just a wiki will be able to see that XWiki isn't another boring wiki. On the other hand, people that are just looking for a wiki that's nice to use and "not-ugly", might be put off by yet another layer of complexity, and might drop XWiki from their list of candidates. In other words, it alienates even more the kind of users that already perceive XWiki as hard to use and overly complex.

So, are we willing to trade one type of users for the other? It would be in line with our vision of "enterprise collaboration", but I still think we shouldn't voluntarily alienate any kind of users.

An alternative is to wait for a real flavor, and then ask in the first step of the distribution manager what kind of usage do we want. In the meantime, we can still polish the pages that will go in the "workspaces" flavor.

So, -0 for switching to "workspaces only" in 5.2, unless we have really good backwards compatibility and a flavor for a simple wiki for textual collaboration.

I hope the above allays your fears :)

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, very nice mockups. On Tue, Jul 30, 2013 at 1:26 PM, Vincent Massol <[email protected]> wrote:

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:

...

On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/20/2013 07:33 AM, Vincent Massol wrote:

...

Hi devs,

In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's this time:

" * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's

going to

...

work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :)

...

...

"

Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this.

The rationale is:

* It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it.

* XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop.

Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

Here's my +1

This is a major shift in how first-time users perceive XWiki. Without multi-wiki features, it still looks like a wiki, but if the homepage changes from a "welcome to your wiki" page to a "here are your workspaces" portal, then suddenly XWiki "becomes" something else in the eyes of our users. I used quotes since nothing changes on the inside, the multiwiki feature has been there since the beginning, and the single wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

Proposals:

* Changes to the Menu http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level

Right now it's the administration of the Main wiki, which is the only place from which you can manage global users.

** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

What I like with "Home" is that users instinctively know that it's the top end of the solution, ie the place to go back to to find your way in case of doubt.

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

...

* Wiki/Workspace Creation

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

(please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

I think this debate has not been conducted to a satisfactory end yet. We should indeed keep just one type of sub-site (either wiki or workspace). I like the simplicity of A, where the user is asked to perform less choices. By the way, instead of "Empty wiki", maybe we should call that template "Default", again to help users make a choice if in doubt. What's a bit complicated is that "Workspaces" could be seen as a flavor for a whole wiki farm (including the main wiki and sub-wikis) with special behavior, for instance allowing only global users. Guillaume Thanks

-Vincent

...

Thanks, Caty

...

...

But this change in how XWiki is perceived has both advantages and disadvantages. On one hand, it clearly shows users that XWiki is a collaborative platform, not just a wiki, so people that need collaboration more than just a wiki will be able to see that XWiki

isn't

...

...

another boring wiki. On the other hand, people that are just looking for a wiki that's nice to use and "not-ugly", might be put off by yet another layer of complexity, and might drop XWiki from their list of candidates. In other words, it alienates even more the kind of users that already perceive XWiki as hard to use and overly complex.

So, are we willing to trade one type of users for the other? It would be in line with our vision of "enterprise collaboration", but I still think we shouldn't voluntarily alienate any kind of users.

An alternative is to wait for a real flavor, and then ask in the first step of the distribution manager what kind of usage do we want. In the meantime, we can still polish the pages that will go in the "workspaces" flavor.

So, -0 for switching to "workspaces only" in 5.2, unless we have really good backwards compatibility and a flavor for a simple wiki for textual collaboration.

I hope the above allays your fears :)

Thanks -Vincent

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 07/30/2013 08:28 AM, Vincent Massol wrote:

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an all-powerful collection of applications and pages that can do anything we want it to. But for users, a wiki is Wikipedia, where you can find documentation written by amateurs that's hasn't been proof-read by a real professional. It takes months or years of using a wiki to shift from the external viewer bad opinion to the internal collaborator good opinion of the term "wiki". So "wiki" is a bad name for users. I think "workspace" is a much better name than "wiki", although it's far from perfect. First of all because it creates confusion between a "space" and a "workspace (wiki)". So, what better word describes a "collaboration space" than "workspace"? Some random ideas, most of them bad: - node - workgroup - community - rename space to directory and we can use space or workspace for the current "wiki" - virtual server - environment - sandbox - appspace - office - location - rack - stack - instance - room - workroom - desk Let's not forget that some of the instances are customized so much that users don't even know they're using a wiki, so just seeing the word "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's internal Foobars application!". So it would be a good idea to make this term configurable. -- Sergiu Dumitriu http://purl.org/net/sergiu

Just my point of view on this point, since I keep seeing similar topics popping up once in a while... For me, the "wiki" is the entire environment (main wiki + all its subwikis), as a whole, by definition. Since they are all connected, it is wrong to say that we are creating new wikis (subwikis) when, in fact, we are just creating new "spaces"/"workspaces" (spaces where the user does/groups/catalogues his work). Also, this view is enforced by our new direction towards virtual by default and of making subwikis part of XWiki's data model (including the new model). Since we are currently lacking the hierarchy feature of the the new model, and we are faking it technically (and maybe this is where the confusion comes from) by using new wikis(subwikis) in new databases, the term "workspace" would, IMO, remain the best candidate. If we consider the fact that we want to make workspaces the default (as proven in practice), we find that the "corner" cases are actually the term "wiki" (actually "subwiki"), which occur only in farm deployments where, indeed, a subwiki is a fully fledged and generally isolated "wiki" from the point of view of the owner and its users. Also, in an enterprise environment, try explaining each time to the Accounting, Marketing, etc. departments that: - a "wiki" is "a set of pages that can be edited/modified by users with links between pages, using some syntax, etc."... - a "workspace" is "a/the space where you (do *your*) work/collaborate" +1 for "workspace" as first-class term being promoted to users +1 for "wiki" as technical term being mentioned in documentation to admins (specifically for farm deployments) Also, being an enterprise wiki, I`m not sure we want to be labelled as the company's "wiki" instead of the company's "collaboration tool" (or "tool used to get our work done"). Thanks, Eduard P.S.: As a technical/background note, just not to be misunderstood, indeed, a workspace is implemented as just a wiki right now with additional restrictions to satisfy its usecase. However, this is only due to our platform's limitations. Normally, a workspace should just be a space where a user can install apps, create other sub-spaces, and collaborate with others. The initial proposal (for the "Wiki 3.0" XWiki SAS research project) was to actually use spaces to implement workspaces, but since we could not install apps (among other things), we chose to use subwikis instead. On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol <[email protected]> wrote:

On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/30/2013 08:28 AM, Vincent Massol wrote:

...

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an all-powerful collection of applications and pages that can do anything we want it to. But for users, a wiki is Wikipedia, where you can find documentation written by amateurs that's hasn't been proof-read by a real professional. It takes months or years of using a wiki to shift from the external viewer bad opinion to the internal collaborator good opinion of the term "wiki".

So "wiki" is a bad name for users. I think "workspace" is a much better name than "wiki", although it's far from perfect. First of all because it creates confusion between a "space" and a "workspace (wiki)".

So, what better word describes a "collaboration space" than "workspace"?

Some random ideas, most of them bad: - node - workgroup - community - rename space to directory and we can use space or workspace for the current "wiki" - virtual server - environment - sandbox - appspace - office - location - rack - stack - instance - room - workroom - desk

I'm not sure this is needed. XWiki is all about the notion of wiki… even in its name. The generic name "wiki" seems a much better name to me than anything else: * it's a set of pages that can be edited/modified by users with links between pages, using some syntax, etc.

I don't think we need to change that. Any other name would be awkward IMO.

...

Let's not forget that some of the instances are customized so much that users don't even know they're using a wiki, so just seeing the word "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's internal Foobars application!". So it would be a good idea to make this term configurable.

If the instance is customized so much that it doesn't look like a wiki, then whoever did this customization can easily also customize the translation resources to pick whatever suit their needs! ;)

For example, if the wiki is used as a projects wiki and they want to have one project = one wiki, they could rename "Wiki" to "Projects".

We'll never be able to use a specialized name by default so we might as well stick with "wiki" which is the best name for what it is… a wiki ;-)

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Tue, Jul 30, 2013 at 7:15 PM, Vincent Massol <[email protected]> wrote:

On Jul 30, 2013, at 5:53 PM, Eduard Moraru <[email protected]> wrote:

...

Just my point of view on this point, since I keep seeing similar topics popping up once in a while...

For me, the "wiki" is the entire environment (main wiki + all its subwikis), as a whole, by definition. Since they are all connected, it is wrong to say that we are creating new wikis (subwikis) when, in fact, we are just creating new "spaces"/"workspaces" (spaces where the user does/groups/catalogues his work). Also, this view is enforced by our new direction towards virtual by default and of making subwikis part of XWiki's data model (including the new model).

In the future you'll be able to either: - create wikis, they are real wikis. - create nested spaces

So you'll be able to choose the way you want to organize yourself by either creating a (sub)wiki or a (nested)space.

The notion of "workspace" is not needed in either case: - for (sub)wikis, it matches with the notion of a wiki and flavors - for (nested)space, it matches with the notion of a space + space template (which I guess could also be implemented as a flavor in the future)

...

Since we are currently lacking the hierarchy feature of the the new model, and we are faking it technically (and maybe this is where the confusion comes from) by using new wikis(subwikis) in new databases, the term "workspace" would, IMO, remain the best candidate.

I don't agree. The "workspace" feature was done ad-hoc outside of the platform and as a consequence was thought as an add-on. Now, what we are doing and preparing for the future is to have the notion of subwiki at the core of XWiki. And this concept of workspace is no longer needed as something adhoc. It can be integrated in the platform.

What is a workspace: * it's a set of pages/applications * using existing users

Those 2 items can be done without the need for any new name/concept. A set of pages/applications is what we call a flavor. And the notion of users already exists (what we need to work on, is to have a config feature so that a subwiki can have or not have local users).

...

If we consider the fact that we want to make workspaces the default (as proven in practice), we find that the "corner" cases are actually the term "wiki" (actually "subwiki"), which occur only in farm deployments where, indeed, a subwiki is a fully fledged and generally isolated "wiki" from the point of view of the owner and its users.

Also, in an enterprise environment, try explaining each time to the Accounting, Marketing, etc. departments that: - a "wiki" is "a set of pages that can be edited/modified by users with links between pages, using some syntax, etc."...

missing "OR" between these 2 lines. It was a comparison of terms, put in an enterprise/user context. Thanks, Eduard

- a "workspace" is "a/the space where you (do *your*) work/collaborate"

I don't understand. Why have the 2 concepts? The idea of option B is to have only 1 concept: that of (sub)wikis.

...

+1 for "workspace" as first-class term being promoted to users +1 for "wiki" as technical term being mentioned in documentation to admins (specifically for farm deployments)

Also, being an enterprise wiki, I`m not sure we want to be labelled as the company's "wiki" instead of the company's "collaboration tool" (or "tool used to get our work done").

Thanks, Eduard

P.S.: As a technical/background note, just not to be misunderstood, indeed, a workspace is implemented as just a wiki right now with additional restrictions to satisfy its usecase. However, this is only due to our platform's limitations. Normally, a workspace should just be a space where a user can install apps, create other sub-spaces, and collaborate with others. The initial proposal (for the "Wiki 3.0" XWiki SAS research project) was to actually use spaces to implement workspaces, but since we could not install apps (among other things), we chose to use subwikis instead.

We still need the ability to "Add a new Wiki" in 5.2 so this doesn't change anything.

And if in the future we support nested spaces then users will also be able to use them + space templates with flavors.

So for me that makes it even more important to not introduce the notion of "workspaces" in 5.2 and to only have the notion of adding a (sub)wiki :)

Thanks -Vincent

...

On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/30/2013 08:28 AM, Vincent Massol wrote:

...

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much

simpler

...

for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

...

I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an all-powerful collection of applications and pages that can do anything we want it to. But for users, a wiki is Wikipedia, where you can find documentation written by amateurs that's hasn't been proof-read by a real professional. It takes months or years of using a wiki to shift from the external viewer bad opinion to the internal collaborator good opinion of the term "wiki".

So "wiki" is a bad name for users. I think "workspace" is a much better name than "wiki", although it's far from perfect. First of all because it creates confusion between a "space" and a "workspace (wiki)".

So, what better word describes a "collaboration space" than

"workspace"?

...

Some random ideas, most of them bad: - node - workgroup - community - rename space to directory and we can use space or workspace for the current "wiki" - virtual server - environment - sandbox - appspace - office - location - rack - stack - instance - room - workroom - desk

I'm not sure this is needed. XWiki is all about the notion of wiki… even in its name. The generic name "wiki" seems a much better name to me than anything else: * it's a set of pages that can be edited/modified by users with links between pages, using some syntax, etc.

I don't think we need to change that. Any other name would be awkward IMO.

...

Let's not forget that some of the instances are customized so much that users don't even know they're using a wiki, so just seeing the word "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's internal Foobars application!". So it would be a good idea to make this term configurable.

If the instance is customized so much that it doesn't look like a wiki, then whoever did this customization can easily also customize the translation resources to pick whatever suit their needs! ;)

For example, if the wiki is used as a projects wiki and they want to have one project = one wiki, they could rename "Wiki" to "Projects".

We'll never be able to use a specialized name by default so we might as well stick with "wiki" which is the best name for what it is… a wiki ;-)

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Sergiu, On Jul 30, 2013, at 6:47 PM, Sergiu Dumitriu <[email protected]> wrote:

Vincent, stop thinking so technical! You're describing the technical implementation of the current "workspace" feature, not the user friendly name that users can understand.

<joking> ok let's stop the xwiki project then! Because it contains the word "wiki" which our users don't understand…. I don't even understand how we get users since obviously they can't understand what xwiki is about… ;) Let's call it "stuff" which is a word that everyone understands surely… </joking>

No matter how much more accurate the term "wiki" is to what's happening inside, it means less than nothing to our target users. Less, because it's misleading instead of helpful.

So yes, on the inside we have __entities__ named documents, spaces and wikis, and this isn't about changing those. It's about adding names that end users can understand to the __concepts__ that those entities represent.

<joking> Yeah, let's rename "document" by "book page", "space" by "book" and "wiki" by "shelf". I"m sure users will understand better! </joking>

It is a wiki, but it lets users collaborate. Our users do their jobs in such a wiki, and for __our users__ that means much more than what "wiki" means to them.

http://lmgtfy.com/?q=define%3Awiki

You just proved that the wiki word is exactly the right word… :)

Remember the XWiki (SAS) mottos: work better together, the best way to organize information, free your knowledge... Users do their work collaboratively, they don't just write pages in a wiki. They write in a forum, write review, write press releases, vote, plan, review job candidates, take meeting notes, draw UML diagrams, etc. This is why "wiki" is WRONG for __end users__.

I think that this is not a technical decision, but a marketing/usability one, so it would be better to see what someone from marketing thinks.

I definitely don't agree, sorry… We're building a collaborative solution based on a wiki and as such I definitely don't agree to rename the base concepts of a wiki: pages, spaces, wiki, etc. Remember that we're talking here about the base platform. Then there are flavors and customizations done by our users which can be anything specific for their project if they want to hide the wiki concepts… I think you're confusing applications based on xwiki concepts with core concepts. A subwiki is a core concept in the same manner as a document or a space. What we're doing now is making the notion of subwiki part of the core concepts as it should have been a long time ago (this is why btw it's also in the new model). Again, on top of these core concepts you could create apps for specific uses cases. You could have a workspace app if you want although with the core concepts it's not required ATM since it doesn't add any additional feature... Thanks -Vincent PS: BTW you haven't proposed a good name so far IMO…. At least not one that is better for all use cases. Some might be better for a specific usage of xwiki but not generally speaking.

On 07/30/2013 12:15 PM, Vincent Massol wrote:

...

On Jul 30, 2013, at 5:53 PM, Eduard Moraru <[email protected]> wrote:

...

Just my point of view on this point, since I keep seeing similar topics popping up once in a while...

For me, the "wiki" is the entire environment (main wiki + all its subwikis), as a whole, by definition. Since they are all connected, it is wrong to say that we are creating new wikis (subwikis) when, in fact, we are just creating new "spaces"/"workspaces" (spaces where the user does/groups/catalogues his work). Also, this view is enforced by our new direction towards virtual by default and of making subwikis part of XWiki's data model (including the new model).

In the future you'll be able to either: - create wikis, they are real wikis. - create nested spaces

So you'll be able to choose the way you want to organize yourself by either creating a (sub)wiki or a (nested)space.

The notion of "workspace" is not needed in either case: - for (sub)wikis, it matches with the notion of a wiki and flavors - for (nested)space, it matches with the notion of a space + space template (which I guess could also be implemented as a flavor in the future)

...

Since we are currently lacking the hierarchy feature of the the new model, and we are faking it technically (and maybe this is where the confusion comes from) by using new wikis(subwikis) in new databases, the term "workspace" would, IMO, remain the best candidate.

I don't agree. The "workspace" feature was done ad-hoc outside of the platform and as a consequence was thought as an add-on. Now, what we are doing and preparing for the future is to have the notion of subwiki at the core of XWiki. And this concept of workspace is no longer needed as something adhoc. It can be integrated in the platform.

What is a workspace: * it's a set of pages/applications * using existing users

Those 2 items can be done without the need for any new name/concept. A set of pages/applications is what we call a flavor. And the notion of users already exists (what we need to work on, is to have a config feature so that a subwiki can have or not have local users).

...

If we consider the fact that we want to make workspaces the default (as proven in practice), we find that the "corner" cases are actually the term "wiki" (actually "subwiki"), which occur only in farm deployments where, indeed, a subwiki is a fully fledged and generally isolated "wiki" from the point of view of the owner and its users.

Also, in an enterprise environment, try explaining each time to the Accounting, Marketing, etc. departments that: - a "wiki" is "a set of pages that can be edited/modified by users with links between pages, using some syntax, etc."... - a "workspace" is "a/the space where you (do *your*) work/collaborate"

I don't understand. Why have the 2 concepts? The idea of option B is to have only 1 concept: that of (sub)wikis.

...

+1 for "workspace" as first-class term being promoted to users +1 for "wiki" as technical term being mentioned in documentation to admins (specifically for farm deployments)

Also, being an enterprise wiki, I`m not sure we want to be labelled as the company's "wiki" instead of the company's "collaboration tool" (or "tool used to get our work done").

Thanks, Eduard

P.S.: As a technical/background note, just not to be misunderstood, indeed, a workspace is implemented as just a wiki right now with additional restrictions to satisfy its usecase. However, this is only due to our platform's limitations. Normally, a workspace should just be a space where a user can install apps, create other sub-spaces, and collaborate with others. The initial proposal (for the "Wiki 3.0" XWiki SAS research project) was to actually use spaces to implement workspaces, but since we could not install apps (among other things), we chose to use subwikis instead.

We still need the ability to "Add a new Wiki" in 5.2 so this doesn't change anything.

And if in the future we support nested spaces then users will also be able to use them + space templates with flavors.

So for me that makes it even more important to not introduce the notion of "workspaces" in 5.2 and to only have the notion of adding a (sub)wiki :)

Thanks -Vincent

...

On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/30/2013 08:28 AM, Vincent Massol wrote:

...

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an all-powerful collection of applications and pages that can do anything we want it to. But for users, a wiki is Wikipedia, where you can find documentation written by amateurs that's hasn't been proof-read by a real professional. It takes months or years of using a wiki to shift from the external viewer bad opinion to the internal collaborator good opinion of the term "wiki".

So "wiki" is a bad name for users. I think "workspace" is a much better name than "wiki", although it's far from perfect. First of all because it creates confusion between a "space" and a "workspace (wiki)".

So, what better word describes a "collaboration space" than "workspace"?

Some random ideas, most of them bad: - node - workgroup - community - rename space to directory and we can use space or workspace for the current "wiki" - virtual server - environment - sandbox - appspace - office - location - rack - stack - instance - room - workroom - desk

I'm not sure this is needed. XWiki is all about the notion of wiki… even in its name. The generic name "wiki" seems a much better name to me than anything else: * it's a set of pages that can be edited/modified by users with links between pages, using some syntax, etc.

I don't think we need to change that. Any other name would be awkward IMO.

...

Let's not forget that some of the instances are customized so much that users don't even know they're using a wiki, so just seeing the word "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's internal Foobars application!". So it would be a good idea to make this term configurable.

If the instance is customized so much that it doesn't look like a wiki, then whoever did this customization can easily also customize the translation resources to pick whatever suit their needs! ;)

For example, if the wiki is used as a projects wiki and they want to have one project = one wiki, they could rename "Wiki" to "Projects".

We'll never be able to use a specialized name by default so we might as well stick with "wiki" which is the best name for what it is… a wiki ;-)

Thanks -Vincent

Hi Sergiu, On Jul 31, 2013, at 1:02 AM, Sergiu Dumitriu <[email protected]> wrote:

On 07/30/2013 05:32 PM, Vincent Massol wrote:

...

Hi Sergiu,

On Jul 30, 2013, at 6:47 PM, Sergiu Dumitriu <[email protected]> wrote:

...

Vincent, stop thinking so technical! You're describing the technical implementation of the current "workspace" feature, not the user friendly name that users can understand.

<joking> ok let's stop the xwiki project then! Because it contains the word "wiki" which our users don't understand…. I don't even understand how we get users since obviously they can't understand what xwiki is about… ;) Let's call it "stuff" which is a word that everyone understands surely… </joking>

Are you sure you want to go this way?

http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence

Yes I've been looking at those trends for a long time now and I'm watching them every few months too. "Confluence" is cheating because it's an English word so you get a lot of garbage with it… Try "atlassian confluence" and you'll see a different picture… I prefer this one though: http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence#q=wi... And yes I've also noticed that the "wiki" trend has been going down since july 2011. I don't have an explanation but we need to be careful with google trends and the way it works. Another problem is that they're all going down on google trends… I'm not sure which concepts are increasing. It would be interesting to find out. Anyway I think you're diverging from the initial topic of integrating the ability to create subwikis/workspace in the default distribution. I don't think our goal for XWiki 5.2 is to question the core existence of the XWiki project and to rename everything and obliterate the "wiki" name. I also would like to rename "XWiki" to something that doesn't contain the word "wiki" in it because I also think we've reached a stage where the "wiki" name might hamper us because "XWiki" is a lot more than a traditional wiki and being alone to push the concept of "application wiki" is hard (too bad google dropped jotspot). However I don't agree that this change should be done by being incoherent. We currently are a wiki at heart with code and concepts of a wiki. For XWiki 5.2 I'm convinced we need to keep this consistency. And having "page/document", "space" and "shelf" is not a good idea. In the wiki world the concepts are "page", "space", "wiki", "attachments", etc.

XWiki is almost unknown. XWiki doesn't get the volume of users that a mature and popular project usually gets. We've been struggling to market it as an application wiki, yet few users use it that way. How many high quality third party applications do we have in our repository?

I've seen more questions about migrating from Mediawiki than from Confluence, which is our direct competitor. And Confluence is only getting more popular.

The peak of Mediawiki popularity was also the peak of interest in plaintext wikis (Gartner's peak of inflated expectations). And unfortunately the decrease in popularity in Mediawiki is also reflected in the decrease in popularity in XWiki: http://www.google.com/trends/explore?q=xwiki (and twiki, dokuwiki, moinmoin, pmwiki, jspwiki).

Confluence seems to be the winner on the Gartner Hype Cycle.

We haven't even been able to overcome our precursor, TWiki, and I've considered TWiki almost dead for several years: http://www.google.com/trends/explore?q=xwiki%2C+twiki

So don't wonder how we even get users, because we almost don't.

That's why I'd like to set up my "active installs" extension to really know and measure that. I don't trust google trends at face value.

And I didn't say that users don't understand what "wiki" means, just that they misunderstand what XWiki is and what a wiki is in XWiki, because they already know what a wiki is in the traditional way. It's like calling a teleportation device a TCar because it gets you from one place to another, just like a car, but then users will expect all the things they have in a car. There's a reason why different products get different names, instead of just extending the base name: reusing the old name with a prefix causes confusion.

So +1 for choosing something better than "XWiki" as the name of the product, this one hasn't been lucky so far.

...

...

No matter how much more accurate the term "wiki" is to what's happening inside, it means less than nothing to our target users. Less, because it's misleading instead of helpful.

So yes, on the inside we have __entities__ named documents, spaces and wikis, and this isn't about changing those. It's about adding names that end users can understand to the __concepts__ that those entities represent.

<joking> Yeah, let's rename "document" by "book page", "space" by "book" and "wiki" by "shelf". I"m sure users will understand better! </joking>

Did I even mention "renaming"? I explicitly said that this isn't about changing our entity names, but about labeling for users. It's a marketing strategy.

But yes, even "document" and "space" have been occasionally misleading.

...

...

It is a wiki, but it lets users collaborate. Our users do their jobs in such a wiki, and for __our users__ that means much more than what "wiki" means to them.

http://lmgtfy.com/?q=define%3Awiki

You just proved that the wiki word is exactly the right word… :)

What exactly do you see? I see:

"A Web site developed collaboratively by a community of users, allowing any user to add and edit content"

So if this is indeed the correct term, adding a new subwiki, is... "creating a new website"? Do you even know what a "website" means for the average user? Or "content"?

...

...

Remember the XWiki (SAS) mottos: work better together, the best way to organize information, free your knowledge... Users do their work collaboratively, they don't just write pages in a wiki. They write in a forum, write review, write press releases, vote, plan, review job candidates, take meeting notes, draw UML diagrams, etc. This is why "wiki" is WRONG for __end users__.

I think that this is not a technical decision, but a marketing/usability one, so it would be better to see what someone from marketing thinks.

I definitely don't agree, sorry… We're building a collaborative solution based on a wiki and as such I definitely don't agree to rename the base concepts of a wiki: pages, spaces, wiki, etc.

Again, when did I ever said that we should rename them? I just said that it would be more intuitive for users to label a virtual wiki as a workspace.

Ok if all you're asking is for the user to be able to customize its UI and rename "page" to "A", "space" to "B" and "wiki" to "C" then we can think about how to achieve that but the core distribution that we deliver should contain the notion of page, space, wiki.

...

Remember that we're talking here about the base platform. Then there are flavors and customizations done by our users which can be anything specific for their project if they want to hide the wiki concepts…

I think you're confusing applications based on xwiki concepts with core concepts. A subwiki is a core concept in the same manner as a document or a space. What we're doing now is making the notion of subwiki part of the core concepts as it should have been a long time ago (this is why btw it's also in the new model). Again, on top of these core concepts you could create apps for specific uses cases. You could have a workspace app if you want although with the core concepts it's not required ATM since it doesn't add any additional feature...

Rerepeating myself, this isn't about the workspace feature. This isn't about the workspace feature. This is about the XWiki vision, and the XWiki marketing strategy. Is XWiki just a wiki? Or is it much more than that, with collaborative applications as the focus instead of just plain text.

I'm sorry but you weren't clear. The topic of your mail was :"How to call a workspace?"… I think you should have sent a mail entitled "The future of wikis and how XWiki can grow more". This is a very interesting topic indeed which I'd like to discuss too but I don't think it should affect our XWiki 5.2 discussion, it's something much larger. <side note> We're in a hurry for 5.2 because it's already started, GuillaumeD is responsible to implement this and is going on holiday in 3 days and will have little time when he's back, so I was hoping we could have a quick common agreement for 5.2 to make progress. </side note>

What is XWiki trying to be? How do we present it to our potential users? As a wiki? Or as a platform empowering collaboration? An intranet environment, where employees can do their work better.

Compared to first generation wikis, XWiki is like an atomic bomb next to a hand grenade. Let's not market XWiki as a Bigger Grenade.

And please, read more carefully what I'm actually saying.

I'm trying hard, believe me... Thanks -Vincent

...

Thanks -Vincent

PS: BTW you haven't proposed a good name so far IMO…. At least not one that is better for all use cases. Some might be better for a specific usage of xwiki but not generally speaking.

...

On 07/30/2013 12:15 PM, Vincent Massol wrote:

...

On Jul 30, 2013, at 5:53 PM, Eduard Moraru <[email protected]> wrote:

...

Just my point of view on this point, since I keep seeing similar topics popping up once in a while...

For me, the "wiki" is the entire environment (main wiki + all its subwikis), as a whole, by definition. Since they are all connected, it is wrong to say that we are creating new wikis (subwikis) when, in fact, we are just creating new "spaces"/"workspaces" (spaces where the user does/groups/catalogues his work). Also, this view is enforced by our new direction towards virtual by default and of making subwikis part of XWiki's data model (including the new model).

In the future you'll be able to either: - create wikis, they are real wikis. - create nested spaces

So you'll be able to choose the way you want to organize yourself by either creating a (sub)wiki or a (nested)space.

The notion of "workspace" is not needed in either case: - for (sub)wikis, it matches with the notion of a wiki and flavors - for (nested)space, it matches with the notion of a space + space template (which I guess could also be implemented as a flavor in the future)

...

Since we are currently lacking the hierarchy feature of the the new model, and we are faking it technically (and maybe this is where the confusion comes from) by using new wikis(subwikis) in new databases, the term "workspace" would, IMO, remain the best candidate.

I don't agree. The "workspace" feature was done ad-hoc outside of the platform and as a consequence was thought as an add-on. Now, what we are doing and preparing for the future is to have the notion of subwiki at the core of XWiki. And this concept of workspace is no longer needed as something adhoc. It can be integrated in the platform.

What is a workspace: * it's a set of pages/applications * using existing users

Those 2 items can be done without the need for any new name/concept. A set of pages/applications is what we call a flavor. And the notion of users already exists (what we need to work on, is to have a config feature so that a subwiki can have or not have local users).

...

If we consider the fact that we want to make workspaces the default (as proven in practice), we find that the "corner" cases are actually the term "wiki" (actually "subwiki"), which occur only in farm deployments where, indeed, a subwiki is a fully fledged and generally isolated "wiki" from the point of view of the owner and its users.

Also, in an enterprise environment, try explaining each time to the Accounting, Marketing, etc. departments that: - a "wiki" is "a set of pages that can be edited/modified by users with links between pages, using some syntax, etc."... - a "workspace" is "a/the space where you (do *your*) work/collaborate"

I don't understand. Why have the 2 concepts? The idea of option B is to have only 1 concept: that of (sub)wikis.

...

+1 for "workspace" as first-class term being promoted to users +1 for "wiki" as technical term being mentioned in documentation to admins (specifically for farm deployments)

Also, being an enterprise wiki, I`m not sure we want to be labelled as the company's "wiki" instead of the company's "collaboration tool" (or "tool used to get our work done").

Thanks, Eduard

P.S.: As a technical/background note, just not to be misunderstood, indeed, a workspace is implemented as just a wiki right now with additional restrictions to satisfy its usecase. However, this is only due to our platform's limitations. Normally, a workspace should just be a space where a user can install apps, create other sub-spaces, and collaborate with others. The initial proposal (for the "Wiki 3.0" XWiki SAS research project) was to actually use spaces to implement workspaces, but since we could not install apps (among other things), we chose to use subwikis instead.

We still need the ability to "Add a new Wiki" in 5.2 so this doesn't change anything.

And if in the future we support nested spaces then users will also be able to use them + space templates with flavors.

So for me that makes it even more important to not introduce the notion of "workspaces" in 5.2 and to only have the notion of adding a (sub)wiki :)

Thanks -Vincent

...

On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]> wrote:

> On 07/30/2013 08:28 AM, Vincent Massol wrote: >> Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only. > > I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an > all-powerful collection of applications and pages that can do anything > we want it to. But for users, a wiki is Wikipedia, where you can find > documentation written by amateurs that's hasn't been proof-read by a > real professional. It takes months or years of using a wiki to shift > from the external viewer bad opinion to the internal collaborator good > opinion of the term "wiki". > > So "wiki" is a bad name for users. I think "workspace" is a much better > name than "wiki", although it's far from perfect. First of all because > it creates confusion between a "space" and a "workspace (wiki)". > > So, what better word describes a "collaboration space" than "workspace"? > > Some random ideas, most of them bad: > - node > - workgroup > - community > - rename space to directory and we can use space or workspace for the > current "wiki" > - virtual server > - environment > - sandbox > - appspace > - office > - location > - rack > - stack > - instance > - room > - workroom > - desk

I'm not sure this is needed. XWiki is all about the notion of wiki… even in its name. The generic name "wiki" seems a much better name to me than anything else: * it's a set of pages that can be edited/modified by users with links between pages, using some syntax, etc.

I don't think we need to change that. Any other name would be awkward IMO.

> Let's not forget that some of the instances are customized so much that > users don't even know they're using a wiki, so just seeing the word > "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's > internal Foobars application!". So it would be a good idea to make this > term configurable.

If the instance is customized so much that it doesn't look like a wiki, then whoever did this customization can easily also customize the translation resources to pick whatever suit their needs! ;)

For example, if the wiki is used as a projects wiki and they want to have one project = one wiki, they could rename "Wiki" to "Projects".

We'll never be able to use a specialized name by default so we might as well stick with "wiki" which is the best name for what it is… a wiki ;-)

Thanks -Vincent

On Jul 31, 2013, at 10:45 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:

Problem: Drop the concept of workspace and use wiki

Short version: * 'wiki' is a confusing term generally associated with 'Wikipedia', representing the ability to write mostly documentation and not 'all-powerful collection of applications and pages that can do anything we want it to'

* 'workspace' is be a better name for normal users, since it's more descriptive and easy to digest (more familiar for non technical users)

* 'workspace' having just this term could lead to another confusion related to the hierarchy 'Workspace' - 'Space' - 'Page' : "Why a 'work'space can contain multiple spaces?"

* 'XWiki is all about the notion of wiki ... even in its name'

* 'workspaces' was implemented as a subwiki because of technical limitations having space in space concept

My conclusions: * I didn't liked the fact that workspace is a long term (very hard to make it fit in the UI), but this is irrelevant

* I do prefer simpler terms like 'wiki', 'space', 'page', but we should use them consistent [another problem we have is the usage between document and page (again technical vs. users perspective)]

* I also think is confusing having both terms 'wiki' and 'workspace' in the same UI because is very hard to explain what is the difference between them (because they seem to be on the same level of hierarchy, while conceptual they are not). Every time we try to describe them we just enumerate the technical differences: ** 'workspace' = subwiki + global users + ability to create other workspaces for normal users + ability to join a workspace + slim isolation (just grouping of applications and users) ** 'wiki' = subwiki + can have global or local users + they can be created only by admins + they can be completely isolated

* IMO Workgroup term is better than Workspace (it doesn't have the containing 'space' word in it, which could lead to confusions and is also descriptive). The Workgroup allows the user to group application and users and let them work on their project. A Workgroup can have multiple content spaces, that contain multiple pages. A Workgroup contains applications dedicated to a group of people.

I agree that "workgroup" or "group" for short is better than workspace. I'm still unsure if it's better than "(sub)wiki" though.

* The workgroup/workspace could be a specialization of a subwiki or a space/subspace, but the main idea is that it is a specialization of a core XWiki concept

For me we need just one concept, call it "wiki" or "group"/"workgroup". A "wiki"/"group"/"workgroup" can be configured though (allow local users, permissions to create them).

* So IMO we should just decide on the core concepts, define them and use them accordingly. If you try to find out what are the core concepts of XWiki I can find just http://enterprise.xwiki.org/xwiki/bin/view/GettingStarted/XWikiEnterpriseBas... http://platform.xwiki.org/xwiki/bin/view/Features/Spaces http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel but we don't clearly state what is the hierarchy

* Core concepts: wiki, space, page main wiki, wiki, space, page wiki, subwiki, space, page main wiki, subwiki, space, page main wiki, subwiki, space, nested space, page wiki, subwiki, space, subspace, page

:) we really need to decide how are we gonna call them and make a convention that describe consistent the hierarchy.

This is important indeed. In the new model for example we have ATM: Document, Space, Wiki, System.

Because right now we didn't have the sub/nested concept, in my mockups, I decide to use just the main/simple/basic concepts: home (main wiki) > wiki (subwiki) > space > page http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

Another variant would have been to use 'Subwiki' instead of 'Wiki' in the 'Add' menu (would have been more hierarchy correct).

* Regarding marketing and user terms: ideally there should be just one term that is self descriptive from a technical point of view and for users. The problem is that this is kind of hard to find.

I agree we need only 1 term and not two.

I would never agree to put a name like 'System' to describe the 'Main Wiki'. The other proposals were 'Portal', 'Farm', 'Home'. I've chosen 'Home' because it makes sense.

I think you missed the point. System is NOT the main wiki. The main wiki is … a wiki. System is above Wiki in the hierarchy. It represents the whole system (the whole farm). ATM there's no such notion and the system concepts are implemented in the main wiki which explains the confusion. Anyway, I agree that System/Farm (the concept of the whole system) is a bit too early ATM for XWiki 5.x.

So yes I agree that for some terms we could have 2 terms: one used from a technical perspective and the other for the users. If we would settle to a 'wiki > subwiki > space > subspace > page' hierarchy, than instead of 'Home' it would have been 'wiki'.

I don't have any problem with the 'wiki' naming. I consider it to be an idiom (a notion that the user learns and get used to it) and if we used it consistent it should not create any problems for the user.

I agree

Regarding XWiki vs. MediaWiki discussion etc. IMO we are 'X'Wiki from 'eXtensible'Wiki, so we already stating that we are more than a wiki.

But I don't think this mail should discuss the rename of Workspaces vs. Wiki. IMO they are 2 separate concepts, one is a specialization and the other is a core concept. The problem is the current implementation/model and we need to compromise on that.

I see them as the same thing, with just a configuration setting: the ability to have local users. The rest is similar.

Workspace is a specialization of the Wiki (right now, but can be changed later to nested spaces).

Indeed this is what I mentioned in reply to Edy: we don't need to make workspaces something different. This is very important for the future. Now: * If users want to work zones they'll create a workgroup/wiki/subwiki Future: * If users want to work zones they can create a workgroup/wiki/subwiki * Or they can create a subspace It'll be their choice. I still think that a subwiki should offer more isolation power (dedicated admin, skin, rights, etc) in order to differentiate it from a nested space but that's another discussion ;)

Having it in the Add menu means we promote this feature (not necessarily is a core concept). From a marketing point of view is better to have it separate and identified. Wiki can be created just by Admins, so normal users will not be able to create them, thus not see them in the Add menu, but in the Administration.

Why that? Why make the difference? What's so different?

This is Option A http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... If we change the implementation (from wiki to nested spaces) the Add menu will not change.

Option B is more generic and extensible, and of course is logical and simpler to choose it from a technical perspective http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... The Workspace term is not dropped, but presented as a subtype.

It should be dropped in option B and made as a simple checkbox: "Allow local users".

If we change the implementation (from wiki to nested spaces) instead of having it as an option in the wiki creation step, it would appear in the space creation step.

So choosing between OptionA and OptionB IMO is like choosing between Marketing and Tech.

Thanks for summarizing! :) -Vincent

Thanks, Caty

On Wed, Jul 31, 2013 at 10:51 AM, Vincent Massol <[email protected]> wrote:

...

Hi Sergiu,

On Jul 31, 2013, at 1:02 AM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/30/2013 05:32 PM, Vincent Massol wrote:

...

Hi Sergiu,

On Jul 30, 2013, at 6:47 PM, Sergiu Dumitriu <[email protected]> wrote:

...

Vincent, stop thinking so technical! You're describing the technical implementation of the current "workspace" feature, not the user friendly name that users can understand.

<joking> ok let's stop the xwiki project then! Because it contains the word "wiki" which our users don't understand…. I don't even understand how we get users since obviously they can't understand what xwiki is about… ;) Let's call it "stuff" which is a word that everyone understands surely… </joking>

Are you sure you want to go this way?

http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence

Yes I've been looking at those trends for a long time now and I'm watching them every few months too.

"Confluence" is cheating because it's an English word so you get a lot of garbage with it… Try "atlassian confluence" and you'll see a different picture…

I prefer this one though:

http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence#q=wi...

And yes I've also noticed that the "wiki" trend has been going down since july 2011. I don't have an explanation but we need to be careful with google trends and the way it works.

Another problem is that they're all going down on google trends… I'm not sure which concepts are increasing. It would be interesting to find out.

Anyway I think you're diverging from the initial topic of integrating the ability to create subwikis/workspace in the default distribution. I don't think our goal for XWiki 5.2 is to question the core existence of the XWiki project and to rename everything and obliterate the "wiki" name.

I also would like to rename "XWiki" to something that doesn't contain the word "wiki" in it because I also think we've reached a stage where the "wiki" name might hamper us because "XWiki" is a lot more than a traditional wiki and being alone to push the concept of "application wiki" is hard (too bad google dropped jotspot). However I don't agree that this change should be done by being incoherent. We currently are a wiki at heart with code and concepts of a wiki. For XWiki 5.2 I'm convinced we need to keep this consistency. And having "page/document", "space" and "shelf" is not a good idea. In the wiki world the concepts are "page", "space", "wiki", "attachments", etc.

...

XWiki is almost unknown. XWiki doesn't get the volume of users that a mature and popular project usually gets. We've been struggling to market it as an application wiki, yet few users use it that way. How many high quality third party applications do we have in our repository?

I've seen more questions about migrating from Mediawiki than from Confluence, which is our direct competitor. And Confluence is only getting more popular.

The peak of Mediawiki popularity was also the peak of interest in plaintext wikis (Gartner's peak of inflated expectations). And unfortunately the decrease in popularity in Mediawiki is also reflected in the decrease in popularity in XWiki: http://www.google.com/trends/explore?q=xwiki (and twiki, dokuwiki, moinmoin, pmwiki, jspwiki).

Confluence seems to be the winner on the Gartner Hype Cycle.

We haven't even been able to overcome our precursor, TWiki, and I've considered TWiki almost dead for several years: http://www.google.com/trends/explore?q=xwiki%2C+twiki

So don't wonder how we even get users, because we almost don't.

That's why I'd like to set up my "active installs" extension to really know and measure that. I don't trust google trends at face value.

...

And I didn't say that users don't understand what "wiki" means, just that they misunderstand what XWiki is and what a wiki is in XWiki, because they already know what a wiki is in the traditional way. It's like calling a teleportation device a TCar because it gets you from one place to another, just like a car, but then users will expect all the things they have in a car. There's a reason why different products get different names, instead of just extending the base name: reusing the old name with a prefix causes confusion.

So +1 for choosing something better than "XWiki" as the name of the product, this one hasn't been lucky so far.

...

...

No matter how much more accurate the term "wiki" is to what's happening inside, it means less than nothing to our target users. Less, because it's misleading instead of helpful.

So yes, on the inside we have __entities__ named documents, spaces and wikis, and this isn't about changing those. It's about adding names that end users can understand to the __concepts__ that those entities represent.

<joking> Yeah, let's rename "document" by "book page", "space" by "book" and "wiki" by "shelf". I"m sure users will understand better! </joking>

Did I even mention "renaming"? I explicitly said that this isn't about changing our entity names, but about labeling for users. It's a marketing strategy.

But yes, even "document" and "space" have been occasionally misleading.

...

...

It is a wiki, but it lets users collaborate. Our users do their jobs in such a wiki, and for __our users__ that means much more than what "wiki" means to them.

http://lmgtfy.com/?q=define%3Awiki

You just proved that the wiki word is exactly the right word… :)

What exactly do you see? I see:

"A Web site developed collaboratively by a community of users, allowing any user to add and edit content"

So if this is indeed the correct term, adding a new subwiki, is... "creating a new website"? Do you even know what a "website" means for the average user? Or "content"?

...

...

Remember the XWiki (SAS) mottos: work better together, the best way to organize information, free your knowledge... Users do their work collaboratively, they don't just write pages in a wiki. They write in a forum, write review, write press releases, vote, plan, review job candidates, take meeting notes, draw UML diagrams, etc. This is why "wiki" is WRONG for __end users__.

I think that this is not a technical decision, but a marketing/usability one, so it would be better to see what someone from marketing thinks.

I definitely don't agree, sorry… We're building a collaborative solution based on a wiki and as such I definitely don't agree to rename the base concepts of a wiki: pages, spaces, wiki, etc.

Again, when did I ever said that we should rename them? I just said that it would be more intuitive for users to label a virtual wiki as a workspace.

Ok if all you're asking is for the user to be able to customize its UI and rename "page" to "A", "space" to "B" and "wiki" to "C" then we can think about how to achieve that but the core distribution that we deliver should contain the notion of page, space, wiki.

...

...

Remember that we're talking here about the base platform. Then there are flavors and customizations done by our users which can be anything specific for their project if they want to hide the wiki concepts…

I think you're confusing applications based on xwiki concepts with core concepts. A subwiki is a core concept in the same manner as a document or a space. What we're doing now is making the notion of subwiki part of the core concepts as it should have been a long time ago (this is why btw it's also in the new model). Again, on top of these core concepts you could create apps for specific uses cases. You could have a workspace app if you want although with the core concepts it's not required ATM since it doesn't add any additional feature...

Rerepeating myself, this isn't about the workspace feature. This isn't about the workspace feature. This is about the XWiki vision, and the XWiki marketing strategy. Is XWiki just a wiki? Or is it much more than that, with collaborative applications as the focus instead of just plain text.

I'm sorry but you weren't clear. The topic of your mail was :"How to call a workspace?"…

I think you should have sent a mail entitled "The future of wikis and how XWiki can grow more". This is a very interesting topic indeed which I'd like to discuss too but I don't think it should affect our XWiki 5.2 discussion, it's something much larger.

<side note> We're in a hurry for 5.2 because it's already started, GuillaumeD is responsible to implement this and is going on holiday in 3 days and will have little time when he's back, so I was hoping we could have a quick common agreement for 5.2 to make progress. </side note>

...

What is XWiki trying to be? How do we present it to our potential users? As a wiki? Or as a platform empowering collaboration? An intranet environment, where employees can do their work better.

Compared to first generation wikis, XWiki is like an atomic bomb next to a hand grenade. Let's not market XWiki as a Bigger Grenade.

And please, read more carefully what I'm actually saying.

I'm trying hard, believe me...

Thanks -Vincent

...

...

Thanks -Vincent

PS: BTW you haven't proposed a good name so far IMO…. At least not one that is better for all use cases. Some might be better for a specific usage of xwiki but not generally speaking.

...

On 07/30/2013 12:15 PM, Vincent Massol wrote:

...

On Jul 30, 2013, at 5:53 PM, Eduard Moraru <[email protected]>

wrote:

...

> Just my point of view on this point, since I keep seeing similar

topics

...

> popping up once in a while... > > For me, the "wiki" is the entire environment (main wiki + all its > subwikis), as a whole, by definition. Since they are all connected, it is > wrong to say that we are creating new wikis (subwikis) when, in fact, we > are just creating new "spaces"/"workspaces" (spaces where the user > does/groups/catalogues his work). Also, this view is enforced by our new > direction towards virtual by default and of making subwikis part of XWiki's > data model (including the new model).

In the future you'll be able to either: - create wikis, they are real wikis. - create nested spaces

So you'll be able to choose the way you want to organize yourself by either creating a (sub)wiki or a (nested)space.

The notion of "workspace" is not needed in either case: - for (sub)wikis, it matches with the notion of a wiki and flavors - for (nested)space, it matches with the notion of a space + space template (which I guess could also be implemented as a flavor in the future)

> Since we are currently lacking the hierarchy feature of the the new model, > and we are faking it technically (and maybe this is where the confusion > comes from) by using new wikis(subwikis) in new databases, the term > "workspace" would, IMO, remain the best candidate.

I don't agree. The "workspace" feature was done ad-hoc outside of the platform and as a consequence was thought as an add-on. Now, what we are doing and preparing for the future is to have the notion of subwiki at the core of XWiki. And this concept of workspace is no longer needed as something adhoc. It can be integrated in the platform.

What is a workspace: * it's a set of pages/applications * using existing users

Those 2 items can be done without the need for any new name/concept. A set of pages/applications is what we call a flavor. And the notion of users already exists (what we need to work on, is to have a config feature so that a subwiki can have or not have local users).

> If we consider the fact > that we want to make workspaces the default (as proven in practice), we > find that the "corner" cases are actually the term "wiki" (actually > "subwiki"), which occur only in farm deployments where, indeed, a subwiki > is a fully fledged and generally isolated "wiki" from the point of view of > the owner and its users. > > Also, in an enterprise environment, try explaining each time to the > Accounting, Marketing, etc. departments that: > - a "wiki" is "a set of pages that can be edited/modified by users with > links between pages, using some syntax, etc."... > - a "workspace" is "a/the space where you (do *your*) work/collaborate"

I don't understand. Why have the 2 concepts? The idea of option B is to have only 1 concept: that of (sub)wikis.

> +1 for "workspace" as first-class term being promoted to users > +1 for "wiki" as technical term being mentioned in documentation to admins > (specifically for farm deployments) > > Also, being an enterprise wiki, I`m not sure we want to be labelled as the > company's "wiki" instead of the company's "collaboration tool" (or "tool > used to get our work done"). > > Thanks, > Eduard > > P.S.: As a technical/background note, just not to be misunderstood, indeed, > a workspace is implemented as just a wiki right now with additional > restrictions to satisfy its usecase. However, this is only due to our > platform's limitations. Normally, a workspace should just be a space where > a user can install apps, create other sub-spaces, and collaborate with > others. The initial proposal (for the "Wiki 3.0" XWiki SAS research > project) was to actually use spaces to implement workspaces, but since we > could not install apps (among other things), we chose to use subwikis > instead.

We still need the ability to "Add a new Wiki" in 5.2 so this doesn't change anything.

And if in the future we support nested spaces then users will also be able to use them + space templates with flavors.

So for me that makes it even more important to not introduce the notion of "workspaces" in 5.2 and to only have the notion of adding a (sub)wiki :)

Thanks -Vincent

> On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol <[email protected]> wrote: > >> >> On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]> wrote: >> >>> On 07/30/2013 08:28 AM, Vincent Massol wrote: >>>> Definitely +1 for B. I really think we need to drop the concept of >> workspaces and come back to the concept of wiki/subwiki. It's much simpler >> for the user. What we call "workspace" can be seen as a configuration for a >> wiki, i.e. the usage of global users only. >>> >>> I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an >>> all-powerful collection of applications and pages that can do anything >>> we want it to. But for users, a wiki is Wikipedia, where you can find >>> documentation written by amateurs that's hasn't been proof-read by a >>> real professional. It takes months or years of using a wiki to shift >>> from the external viewer bad opinion to the internal collaborator good >>> opinion of the term "wiki". >>> >>> So "wiki" is a bad name for users. I think "workspace" is a much better >>> name than "wiki", although it's far from perfect. First of all because >>> it creates confusion between a "space" and a "workspace (wiki)". >>> >>> So, what better word describes a "collaboration space" than "workspace"? >>> >>> Some random ideas, most of them bad: >>> - node >>> - workgroup >>> - community >>> - rename space to directory and we can use space or workspace for the >>> current "wiki" >>> - virtual server >>> - environment >>> - sandbox >>> - appspace >>> - office >>> - location >>> - rack >>> - stack >>> - instance >>> - room >>> - workroom >>> - desk >> >> I'm not sure this is needed. XWiki is all about the notion of wiki… even >> in its name. The generic name "wiki" seems a much better name to me than >> anything else: >> * it's a set of pages that can be edited/modified by users with links >> between pages, using some syntax, etc. >> >> I don't think we need to change that. Any other name would be awkward IMO. >> >>> Let's not forget that some of the instances are customized so much that >>> users don't even know they're using a wiki, so just seeing the word >>> "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's >>> internal Foobars application!". So it would be a good idea to make this >>> term configurable. >> >> If the instance is customized so much that it doesn't look like a wiki, >> then whoever did this customization can easily also customize the >> translation resources to pick whatever suit their needs! ;) >> >> For example, if the wiki is used as a projects wiki and they want to have >> one project = one wiki, they could rename "Wiki" to "Projects". >> >> We'll never be able to use a specialized name by default so we might as >> well stick with "wiki" which is the best name for what it is… a wiki ;-) >> >> Thanks >> -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Caty, Workspaces is more widely employed, but Workgroup sounds nice, as it helps eliminate the Space vs. Workspace confusion. Now let's hope people won't confuse it with a user group :) Thanks, Silvia On Wed, Jul 31, 2013 at 11:45 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:

Problem: Drop the concept of workspace and use wiki

Short version: * 'wiki' is a confusing term generally associated with 'Wikipedia', representing the ability to write mostly documentation and not 'all-powerful collection of applications and pages that can do anything we want it to'

* 'workspace' is be a better name for normal users, since it's more descriptive and easy to digest (more familiar for non technical users)

* 'workspace' having just this term could lead to another confusion related to the hierarchy 'Workspace' - 'Space' - 'Page' : "Why a 'work'space can contain multiple spaces?"

* 'XWiki is all about the notion of wiki ... even in its name'

* 'workspaces' was implemented as a subwiki because of technical limitations having space in space concept

My conclusions: * I didn't liked the fact that workspace is a long term (very hard to make it fit in the UI), but this is irrelevant

* I do prefer simpler terms like 'wiki', 'space', 'page', but we should use them consistent [another problem we have is the usage between document and page (again technical vs. users perspective)]

* I also think is confusing having both terms 'wiki' and 'workspace' in the same UI because is very hard to explain what is the difference between them (because they seem to be on the same level of hierarchy, while conceptual they are not). Every time we try to describe them we just enumerate the technical differences: ** 'workspace' = subwiki + global users + ability to create other workspaces for normal users + ability to join a workspace + slim isolation (just grouping of applications and users) ** 'wiki' = subwiki + can have global or local users + they can be created only by admins + they can be completely isolated

* IMO Workgroup term is better than Workspace (it doesn't have the containing 'space' word in it, which could lead to confusions and is also descriptive). The Workgroup allows the user to group application and users and let them work on their project. A Workgroup can have multiple content spaces, that contain multiple pages. A Workgroup contains applications dedicated to a group of people.

* The workgroup/workspace could be a specialization of a subwiki or a space/subspace, but the main idea is that it is a specialization of a core XWiki concept

* So IMO we should just decide on the core concepts, define them and use them accordingly. If you try to find out what are the core concepts of XWiki I can find just http://enterprise.xwiki.org/xwiki/bin/view/GettingStarted/XWikiEnterpriseBas... http://platform.xwiki.org/xwiki/bin/view/Features/Spaces http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel but we don't clearly state what is the hierarchy

* Core concepts: wiki, space, page main wiki, wiki, space, page wiki, subwiki, space, page main wiki, subwiki, space, page main wiki, subwiki, space, nested space, page wiki, subwiki, space, subspace, page

:) we really need to decide how are we gonna call them and make a convention that describe consistent the hierarchy. Because right now we didn't have the sub/nested concept, in my mockups, I decide to use just the main/simple/basic concepts: home (main wiki) > wiki (subwiki) > space > page http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

Another variant would have been to use 'Subwiki' instead of 'Wiki' in the 'Add' menu (would have been more hierarchy correct).

* Regarding marketing and user terms: ideally there should be just one term that is self descriptive from a technical point of view and for users. The problem is that this is kind of hard to find. I would never agree to put a name like 'System' to describe the 'Main Wiki'. The other proposals were 'Portal', 'Farm', 'Home'. I've chosen 'Home' because it makes sense.

So yes I agree that for some terms we could have 2 terms: one used from a technical perspective and the other for the users. If we would settle to a 'wiki > subwiki > space > subspace > page' hierarchy, than instead of 'Home' it would have been 'wiki'.

I don't have any problem with the 'wiki' naming. I consider it to be an idiom (a notion that the user learns and get used to it) and if we used it consistent it should not create any problems for the user.

Regarding XWiki vs. MediaWiki discussion etc. IMO we are 'X'Wiki from 'eXtensible'Wiki, so we already stating that we are more than a wiki.

But I don't think this mail should discuss the rename of Workspaces vs. Wiki. IMO they are 2 separate concepts, one is a specialization and the other is a core concept. The problem is the current implementation/model and we need to compromise on that.

Workspace is a specialization of the Wiki (right now, but can be changed later to nested spaces). Having it in the Add menu means we promote this feature (not necessarily is a core concept). From a marketing point of view is better to have it separate and identified. Wiki can be created just by Admins, so normal users will not be able to create them, thus not see them in the Add menu, but in the Administration. This is Option A http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... If we change the implementation (from wiki to nested spaces) the Add menu will not change.

Option B is more generic and extensible, and of course is logical and simpler to choose it from a technical perspective http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... The Workspace term is not dropped, but presented as a subtype. If we change the implementation (from wiki to nested spaces) instead of having it as an option in the wiki creation step, it would appear in the space creation step.

So choosing between OptionA and OptionB IMO is like choosing between Marketing and Tech.

Thanks, Caty

On Wed, Jul 31, 2013 at 10:51 AM, Vincent Massol <[email protected]> wrote:

...

Hi Sergiu,

On Jul 31, 2013, at 1:02 AM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/30/2013 05:32 PM, Vincent Massol wrote:

...

Hi Sergiu,

On Jul 30, 2013, at 6:47 PM, Sergiu Dumitriu <[email protected]> wrote:

...

Vincent, stop thinking so technical! You're describing the technical implementation of the current "workspace" feature, not the user friendly name that users can understand.

<joking> ok let's stop the xwiki project then! Because it contains the word "wiki" which our users don't understand…. I don't even understand how we get users since obviously they can't understand what xwiki is about… ;) Let's call it "stuff" which is a word that everyone understands surely… </joking>

Are you sure you want to go this way?

http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence

Yes I've been looking at those trends for a long time now and I'm watching them every few months too.

"Confluence" is cheating because it's an English word so you get a lot of garbage with it… Try "atlassian confluence" and you'll see a different picture…

I prefer this one though:

http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence#q=wi...

And yes I've also noticed that the "wiki" trend has been going down since july 2011. I don't have an explanation but we need to be careful with google trends and the way it works.

Another problem is that they're all going down on google trends… I'm not sure which concepts are increasing. It would be interesting to find out.

Anyway I think you're diverging from the initial topic of integrating the ability to create subwikis/workspace in the default distribution. I don't think our goal for XWiki 5.2 is to question the core existence of the XWiki project and to rename everything and obliterate the "wiki" name.

I also would like to rename "XWiki" to something that doesn't contain the word "wiki" in it because I also think we've reached a stage where the "wiki" name might hamper us because "XWiki" is a lot more than a traditional wiki and being alone to push the concept of "application wiki" is hard (too bad google dropped jotspot). However I don't agree that this change should be done by being incoherent. We currently are a wiki at heart with code and concepts of a wiki. For XWiki 5.2 I'm convinced we need to keep this consistency. And having "page/document", "space" and "shelf" is not a good idea. In the wiki world the concepts are "page", "space", "wiki", "attachments", etc.

...

XWiki is almost unknown. XWiki doesn't get the volume of users that a mature and popular project usually gets. We've been struggling to market it as an application wiki, yet few users use it that way. How many high quality third party applications do we have in our repository?

I've seen more questions about migrating from Mediawiki than from Confluence, which is our direct competitor. And Confluence is only getting more popular.

The peak of Mediawiki popularity was also the peak of interest in plaintext wikis (Gartner's peak of inflated expectations). And unfortunately the decrease in popularity in Mediawiki is also reflected in the decrease in popularity in XWiki: http://www.google.com/trends/explore?q=xwiki (and twiki, dokuwiki, moinmoin, pmwiki, jspwiki).

Confluence seems to be the winner on the Gartner Hype Cycle.

We haven't even been able to overcome our precursor, TWiki, and I've considered TWiki almost dead for several years: http://www.google.com/trends/explore?q=xwiki%2C+twiki

So don't wonder how we even get users, because we almost don't.

That's why I'd like to set up my "active installs" extension to really know and measure that. I don't trust google trends at face value.

...

And I didn't say that users don't understand what "wiki" means, just that they misunderstand what XWiki is and what a wiki is in XWiki, because they already know what a wiki is in the traditional way. It's like calling a teleportation device a TCar because it gets you from one place to another, just like a car, but then users will expect all the things they have in a car. There's a reason why different products get different names, instead of just extending the base name: reusing the old name with a prefix causes confusion.

So +1 for choosing something better than "XWiki" as the name of the product, this one hasn't been lucky so far.

...

...

No matter how much more accurate the term "wiki" is to what's happening inside, it means less than nothing to our target users. Less, because it's misleading instead of helpful.

So yes, on the inside we have __entities__ named documents, spaces and wikis, and this isn't about changing those. It's about adding names that end users can understand to the __concepts__ that those entities represent.

<joking> Yeah, let's rename "document" by "book page", "space" by "book" and "wiki" by "shelf". I"m sure users will understand better! </joking>

Did I even mention "renaming"? I explicitly said that this isn't about changing our entity names, but about labeling for users. It's a marketing strategy.

But yes, even "document" and "space" have been occasionally misleading.

...

...

It is a wiki, but it lets users collaborate. Our users do their jobs in such a wiki, and for __our users__ that means much more than what "wiki" means to them.

http://lmgtfy.com/?q=define%3Awiki

You just proved that the wiki word is exactly the right word… :)

What exactly do you see? I see:

"A Web site developed collaboratively by a community of users, allowing any user to add and edit content"

So if this is indeed the correct term, adding a new subwiki, is... "creating a new website"? Do you even know what a "website" means for the average user? Or "content"?

...

...

Remember the XWiki (SAS) mottos: work better together, the best way to organize information, free your knowledge... Users do their work collaboratively, they don't just write pages in a wiki. They write in a forum, write review, write press releases, vote, plan, review job candidates, take meeting notes, draw UML diagrams, etc. This is why "wiki" is WRONG for __end users__.

I think that this is not a technical decision, but a marketing/usability one, so it would be better to see what someone from marketing thinks.

I definitely don't agree, sorry… We're building a collaborative solution based on a wiki and as such I definitely don't agree to rename the base concepts of a wiki: pages, spaces, wiki, etc.

Again, when did I ever said that we should rename them? I just said that it would be more intuitive for users to label a virtual wiki as a workspace.

Ok if all you're asking is for the user to be able to customize its UI and rename "page" to "A", "space" to "B" and "wiki" to "C" then we can think about how to achieve that but the core distribution that we deliver should contain the notion of page, space, wiki.

...

...

Remember that we're talking here about the base platform. Then there are flavors and customizations done by our users which can be anything specific for their project if they want to hide the wiki concepts…

I think you're confusing applications based on xwiki concepts with core concepts. A subwiki is a core concept in the same manner as a document or a space. What we're doing now is making the notion of subwiki part of the core concepts as it should have been a long time ago (this is why btw it's also in the new model). Again, on top of these core concepts you could create apps for specific uses cases. You could have a workspace app if you want although with the core concepts it's not required ATM since it doesn't add any additional feature...

Rerepeating myself, this isn't about the workspace feature. This isn't about the workspace feature. This is about the XWiki vision, and the XWiki marketing strategy. Is XWiki just a wiki? Or is it much more than that, with collaborative applications as the focus instead of just plain text.

I'm sorry but you weren't clear. The topic of your mail was :"How to call a workspace?"…

I think you should have sent a mail entitled "The future of wikis and how XWiki can grow more". This is a very interesting topic indeed which I'd like to discuss too but I don't think it should affect our XWiki 5.2 discussion, it's something much larger.

<side note> We're in a hurry for 5.2 because it's already started, GuillaumeD is responsible to implement this and is going on holiday in 3 days and will have little time when he's back, so I was hoping we could have a quick common agreement for 5.2 to make progress. </side note>

...

What is XWiki trying to be? How do we present it to our potential users? As a wiki? Or as a platform empowering collaboration? An intranet environment, where employees can do their work better.

Compared to first generation wikis, XWiki is like an atomic bomb next to a hand grenade. Let's not market XWiki as a Bigger Grenade.

And please, read more carefully what I'm actually saying.

I'm trying hard, believe me...

Thanks -Vincent

...

...

Thanks -Vincent

PS: BTW you haven't proposed a good name so far IMO…. At least not one that is better for all use cases. Some might be better for a specific usage of xwiki but not generally speaking.

...

On 07/30/2013 12:15 PM, Vincent Massol wrote:

...

On Jul 30, 2013, at 5:53 PM, Eduard Moraru <[email protected]>

wrote:

...

> Just my point of view on this point, since I keep seeing similar

topics

...

> popping up once in a while... > > For me, the "wiki" is the entire environment (main wiki + all its > subwikis), as a whole, by definition. Since they are all connected, it is > wrong to say that we are creating new wikis (subwikis) when, in fact, we > are just creating new "spaces"/"workspaces" (spaces where the user > does/groups/catalogues his work). Also, this view is enforced by our new > direction towards virtual by default and of making subwikis part of XWiki's > data model (including the new model).

In the future you'll be able to either: - create wikis, they are real wikis. - create nested spaces

So you'll be able to choose the way you want to organize yourself by either creating a (sub)wiki or a (nested)space.

The notion of "workspace" is not needed in either case: - for (sub)wikis, it matches with the notion of a wiki and flavors - for (nested)space, it matches with the notion of a space + space template (which I guess could also be implemented as a flavor in the future)

> Since we are currently lacking the hierarchy feature of the the new model, > and we are faking it technically (and maybe this is where the confusion > comes from) by using new wikis(subwikis) in new databases, the term > "workspace" would, IMO, remain the best candidate.

I don't agree. The "workspace" feature was done ad-hoc outside of the platform and as a consequence was thought as an add-on. Now, what we are doing and preparing for the future is to have the notion of subwiki at the core of XWiki. And this concept of workspace is no longer needed as something adhoc. It can be integrated in the platform.

What is a workspace: * it's a set of pages/applications * using existing users

Those 2 items can be done without the need for any new name/concept. A set of pages/applications is what we call a flavor. And the notion of users already exists (what we need to work on, is to have a config feature so that a subwiki can have or not have local users).

> If we consider the fact > that we want to make workspaces the default (as proven in practice), we > find that the "corner" cases are actually the term "wiki" (actually > "subwiki"), which occur only in farm deployments where, indeed, a subwiki > is a fully fledged and generally isolated "wiki" from the point of view of > the owner and its users. > > Also, in an enterprise environment, try explaining each time to the > Accounting, Marketing, etc. departments that: > - a "wiki" is "a set of pages that can be edited/modified by users with > links between pages, using some syntax, etc."... > - a "workspace" is "a/the space where you (do *your*) work/collaborate"

I don't understand. Why have the 2 concepts? The idea of option B is to have only 1 concept: that of (sub)wikis.

> +1 for "workspace" as first-class term being promoted to users > +1 for "wiki" as technical term being mentioned in documentation to admins > (specifically for farm deployments) > > Also, being an enterprise wiki, I`m not sure we want to be labelled as the > company's "wiki" instead of the company's "collaboration tool" (or "tool > used to get our work done"). > > Thanks, > Eduard > > P.S.: As a technical/background note, just not to be misunderstood, indeed, > a workspace is implemented as just a wiki right now with additional > restrictions to satisfy its usecase. However, this is only due to our > platform's limitations. Normally, a workspace should just be a space where > a user can install apps, create other sub-spaces, and collaborate with > others. The initial proposal (for the "Wiki 3.0" XWiki SAS research > project) was to actually use spaces to implement workspaces, but since we > could not install apps (among other things), we chose to use subwikis > instead.

We still need the ability to "Add a new Wiki" in 5.2 so this doesn't change anything.

And if in the future we support nested spaces then users will also be able to use them + space templates with flavors.

So for me that makes it even more important to not introduce the notion of "workspaces" in 5.2 and to only have the notion of adding a (sub)wiki :)

Thanks -Vincent

> On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol <[email protected]> wrote: > >> >> On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]> wrote: >> >>> On 07/30/2013 08:28 AM, Vincent Massol wrote: >>>> Definitely +1 for B. I really think we need to drop the concept of >> workspaces and come back to the concept of wiki/subwiki. It's much simpler >> for the user. What we call "workspace" can be seen as a configuration for a >> wiki, i.e. the usage of global users only. >>> >>> I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an >>> all-powerful collection of applications and pages that can do anything >>> we want it to. But for users, a wiki is Wikipedia, where you can find >>> documentation written by amateurs that's hasn't been proof-read by a >>> real professional. It takes months or years of using a wiki to shift >>> from the external viewer bad opinion to the internal collaborator good >>> opinion of the term "wiki". >>> >>> So "wiki" is a bad name for users. I think "workspace" is a much better >>> name than "wiki", although it's far from perfect. First of all because >>> it creates confusion between a "space" and a "workspace (wiki)". >>> >>> So, what better word describes a "collaboration space" than "workspace"? >>> >>> Some random ideas, most of them bad: >>> - node >>> - workgroup >>> - community >>> - rename space to directory and we can use space or workspace for the >>> current "wiki" >>> - virtual server >>> - environment >>> - sandbox >>> - appspace >>> - office >>> - location >>> - rack >>> - stack >>> - instance >>> - room >>> - workroom >>> - desk >> >> I'm not sure this is needed. XWiki is all about the notion of wiki… even >> in its name. The generic name "wiki" seems a much better name to me than >> anything else: >> * it's a set of pages that can be edited/modified by users with links >> between pages, using some syntax, etc. >> >> I don't think we need to change that. Any other name would be awkward IMO. >> >>> Let's not forget that some of the instances are customized so much that >>> users don't even know they're using a wiki, so just seeing the word >>> "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's >>> internal Foobars application!". So it would be a good idea to make this >>> term configurable. >> >> If the instance is customized so much that it doesn't look like a wiki, >> then whoever did this customization can easily also customize the >> translation resources to pick whatever suit their needs! ;) >> >> For example, if the wiki is used as a projects wiki and they want to have >> one project = one wiki, they could rename "Wiki" to "Projects". >> >> We'll never be able to use a specialized name by default so we might as >> well stick with "wiki" which is the best name for what it is… a wiki ;-) >> >> Thanks >> -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, Without wanting to add more fire to the debate I'd like to make a few comments regarding the naming issue. Edi said above "For me, the "wiki" is the entire environment (main wiki + all its subwikis), as a whole, by definition." I was remembered of an old thread I read while googling "XWiki Workspaces" where a potential TWiki user was comparing options and he only used the term wiki in its singular form ( http://twiki.org/cgi-bin/view/Support/SID-00140 ). I agree that users tend to think of the whole environment as "the wiki". If I wasn't part of the XWiki community I'd probably be sharing their opinion :) I think the naming depends a lot on the message we are trying to transmit. Do we want the emphasis to be on the content, or are we looking to underline the collaboration aspect more? If we are trying to say XWiki should be used for: * Knowledge building > the term "wiki" is appropriate * Collaboration > "workspaces" sounds better IMO An argument in favor of workspaces would be avoiding the intimidation & fear factor: most users associate wikis with Wikipedia. Let's say I'm an HR manager and I need a place where I can store CVs, employee information and where I can discuss things with the HR team. Do I need Wikipedia to achieve this? Sounds a bit too much. Also I thought I already was on a wiki. Should I create a wiki in a wiki? Does that exist ("inception")? This sounds terribly complicated. What if I mess up the wiki?! Maybe I'll get a sys admin to help. Or maybe I'll just create a space somewhere since I don't want to mess up the wiki. Email and Excel I guess are not that bad in the end either. In conclusion I understand the arguments of both parties which makes it very hard to choose one of the names. In the end if I have to choose I prefer the notion of workspace, since to me this suggests a tool that's easy to use, that helps one get organized, but most of all collaborate more efficiently. I'm not -1 for wiki, I just like the workspace name better. Silvia On Wed, Jul 31, 2013 at 11:46 AM, Jeremie BOUSQUET <[email protected]> wrote:

Hello all,

2013/7/31 Sergiu Dumitriu <[email protected]>

...

On 07/30/2013 05:32 PM, Vincent Massol wrote:

...

Hi Sergiu,

On Jul 30, 2013, at 6:47 PM, Sergiu Dumitriu <[email protected]> wrote:

...

Vincent, stop thinking so technical! You're describing the technical implementation of the current "workspace" feature, not the user friendly name that users can understand.

<joking> ok let's stop the xwiki project then! Because it contains the word "wiki" which our users don't understand…. I don't even understand how we get users since obviously they can't understand what xwiki is about… ;) Let's call it "stuff" which is a word that everyone understands surely… </joking>

Are you sure you want to go this way?

http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence

XWiki is almost unknown. XWiki doesn't get the volume of users that a mature and popular project usually gets. We've been struggling to market it as an application wiki, yet few users use it that way. How many high quality third party applications do we have in our repository?

I've seen more questions about migrating from Mediawiki than from Confluence, which is our direct competitor. And Confluence is only getting more popular.

The peak of Mediawiki popularity was also the peak of interest in plaintext wikis (Gartner's peak of inflated expectations). And unfortunately the decrease in popularity in Mediawiki is also reflected in the decrease in popularity in XWiki: http://www.google.com/trends/explore?q=xwiki (and twiki, dokuwiki, moinmoin, pmwiki, jspwiki).

Confluence seems to be the winner on the Gartner Hype Cycle.

We haven't even been able to overcome our precursor, TWiki, and I've considered TWiki almost dead for several years: http://www.google.com/trends/explore?q=xwiki%2C+twiki

So don't wonder how we even get users, because we almost don't.

And I didn't say that users don't understand what "wiki" means, just that they misunderstand what XWiki is and what a wiki is in XWiki, because they already know what a wiki is in the traditional way. It's like calling a teleportation device a TCar because it gets you from one place to another, just like a car, but then users will expect all the things they have in a car. There's a reason why different products get different names, instead of just extending the base name: reusing the old name with a prefix causes confusion.

So +1 for choosing something better than "XWiki" as the name of the product, this one hasn't been lucky so far.

...

...

No matter how much more accurate the term "wiki" is to what's happening inside, it means less than nothing to our target users. Less, because it's misleading instead of helpful.

So yes, on the inside we have __entities__ named documents, spaces and wikis, and this isn't about changing those. It's about adding names that end users can understand to the __concepts__ that those entities represent.

<joking> Yeah, let's rename "document" by "book page", "space" by "book" and "wiki" by "shelf". I"m sure users will understand better! </joking>

Did I even mention "renaming"? I explicitly said that this isn't about changing our entity names, but about labeling for users. It's a marketing strategy.

But yes, even "document" and "space" have been occasionally misleading.

...

...

It is a wiki, but it lets users collaborate. Our users do their jobs in such a wiki, and for __our users__ that means much more than what "wiki" means to them.

http://lmgtfy.com/?q=define%3Awiki

You just proved that the wiki word is exactly the right word… :)

What exactly do you see? I see:

"A Web site developed collaboratively by a community of users, allowing any user to add and edit content"

So if this is indeed the correct term, adding a new subwiki, is... "creating a new website"? Do you even know what a "website" means for the average user? Or "content"?

...

...

Remember the XWiki (SAS) mottos: work better together, the best way to organize information, free your knowledge... Users do their work collaboratively, they don't just write pages in a wiki. They write in a forum, write review, write press releases, vote, plan, review job candidates, take meeting notes, draw UML diagrams, etc. This is why "wiki" is WRONG for __end users__.

I think that this is not a technical decision, but a marketing/usability one, so it would be better to see what someone from marketing thinks.

I definitely don't agree, sorry… We're building a collaborative solution based on a wiki and as such I definitely don't agree to rename the base concepts of a wiki: pages, spaces, wiki, etc.

Again, when did I ever said that we should rename them? I just said that it would be more intuitive for users to label a virtual wiki as a workspace.

I must say I somehow share this vision ... From the very start, I never had the same perception about sub-wikis and workspaces, even though I knew they mostly shared same technicals (and fundamentally it's the same thing). But in my mind (and it's totally irrationnal), "sub-wikis" are associated to wiki farms, something a bit huge, a bit difficult to put in place, something to host thousands of isolated wikis, something I never really envisaged to put in production for myself. While workspaces is a light collaborative concept, that can be installed from EM in a few clicks, that has a nice and easy UI, and that I started playing with nearly from the start and that I've put in production to manage distinct projects Mail Archives at my office with 5.1.

Of course it might seem stupid, but I can't help but feeling that going back to "wiki" (for naming those kind of subwikis) is like a step back. My users start to get used to seing that "Workspace directory" entry point. And I don't want them to consider these as "wikis", because I don't want them to edit anything (or add manually new pages) in these. Still, they are collaborative (thanks to ratings, comments, activity stream, page sharing, and thanks to its nature of mail archive). But I wouldn't want my users to imagine that it could be nice to add a Blog in this kind of workspace, or use any other wiki feature.

For example, seems the concept of "Space" is taken for granted as basic wiki feature, but maybe I didn't test much of them, but I never heard of this "Space" concept in any other wiki. The fact that it's called a "Space" (and not a group, or a workspace, or a folder, or just anything) is a choice done by XWiki from the start. IMHO, the choice to call a subwiki a "wiki" or a "workspace" is only your choice, and it should be more based on what you want XWiki to be than on what it currently is inside ...

What I can only say on my side, is that I love my XWiki with my workspaces (and eagerly wait for flavours), and I somewhat don't care at all about the wiki farm concept ... Maybe to explain better: - a wiki farm is a set of distinct full-fledged wikis, like a cluster of wikis, with a top-hat admin and container. The container itself has no real interest, apart from grouping things together and providing central navigation - the main wiki + workspaces is a full-fledged wiki, with specialized collaborative places for particular topics, projects, tools, documentation creation ... The main wiki is not just an entry point, it is THE wiki, THE knowledge base, with some satelites graviting around this central planet.

...

...

Remember that we're talking here about the base platform. Then there are flavors and customizations done by our users which can be anything specific for their project if they want to hide the wiki concepts…

I think you're confusing applications based on xwiki concepts with core concepts. A subwiki is a core concept in the same manner as a document or a space. What we're doing now is making the notion of subwiki part of the core concepts as it should have been a long time ago (this is why btw it's also in the new model). Again, on top of these core concepts you could create apps for specific uses cases. You could have a workspace app if you want although with the core concepts it's not required ATM since it doesn't add any additional feature...

Rerepeating myself, this isn't about the workspace feature. This isn't about the workspace feature. This is about the XWiki vision, and the XWiki marketing strategy. Is XWiki just a wiki? Or is it much more than that, with collaborative applications as the focus instead of just plain text.

What is XWiki trying to be? How do we present it to our potential users? As a wiki? Or as a platform empowering collaboration? An intranet environment, where employees can do their work better.

Compared to first generation wikis, XWiki is like an atomic bomb next to a hand grenade. Let's not market XWiki as a Bigger Grenade.

And please, read more carefully what I'm actually saying.

...

Thanks -Vincent

PS: BTW you haven't proposed a good name so far IMO…. At least not one that is better for all use cases. Some might be better for a specific usage of xwiki but not generally speaking.

...

On 07/30/2013 12:15 PM, Vincent Massol wrote:

...

On Jul 30, 2013, at 5:53 PM, Eduard Moraru <[email protected]>

wrote:

...

...

Just my point of view on this point, since I keep seeing similar

topics

...

...

popping up once in a while...

For me, the "wiki" is the entire environment (main wiki + all its subwikis), as a whole, by definition. Since they are all connected, it is wrong to say that we are creating new wikis (subwikis) when, in fact, we are just creating new "spaces"/"workspaces" (spaces where the user does/groups/catalogues his work). Also, this view is enforced by our new direction towards virtual by default and of making subwikis part of XWiki's data model (including the new model).

In the future you'll be able to either: - create wikis, they are real wikis. - create nested spaces

So you'll be able to choose the way you want to organize yourself by either creating a (sub)wiki or a (nested)space.

The notion of "workspace" is not needed in either case: - for (sub)wikis, it matches with the notion of a wiki and flavors - for (nested)space, it matches with the notion of a space + space template (which I guess could also be implemented as a flavor in the future)

...

Since we are currently lacking the hierarchy feature of the the new model, and we are faking it technically (and maybe this is where the confusion comes from) by using new wikis(subwikis) in new databases, the term "workspace" would, IMO, remain the best candidate.

I don't agree. The "workspace" feature was done ad-hoc outside of the platform and as a consequence was thought as an add-on. Now, what we are doing and preparing for the future is to have the notion of subwiki at the core of XWiki. And this concept of workspace is no longer needed as something adhoc. It can be integrated in the platform.

What is a workspace: * it's a set of pages/applications * using existing users

Those 2 items can be done without the need for any new name/concept. A set of pages/applications is what we call a flavor. And the notion of users already exists (what we need to work on, is to have a config feature so that a subwiki can have or not have local users).

...

If we consider the fact that we want to make workspaces the default (as proven in practice), we find that the "corner" cases are actually the term "wiki" (actually "subwiki"), which occur only in farm deployments where, indeed, a subwiki is a fully fledged and generally isolated "wiki" from the point of view of the owner and its users.

Also, in an enterprise environment, try explaining each time to the Accounting, Marketing, etc. departments that: - a "wiki" is "a set of pages that can be edited/modified by users with links between pages, using some syntax, etc."... - a "workspace" is "a/the space where you (do *your*) work/collaborate"

I don't understand. Why have the 2 concepts? The idea of option B is to have only 1 concept: that of (sub)wikis.

...

+1 for "workspace" as first-class term being promoted to users +1 for "wiki" as technical term being mentioned in documentation to admins (specifically for farm deployments)

Also, being an enterprise wiki, I`m not sure we want to be labelled as the company's "wiki" instead of the company's "collaboration tool" (or "tool used to get our work done").

Thanks, Eduard

P.S.: As a technical/background note, just not to be misunderstood, indeed, a workspace is implemented as just a wiki right now with additional restrictions to satisfy its usecase. However, this is only due to our platform's limitations. Normally, a workspace should just be a space where a user can install apps, create other sub-spaces, and collaborate with others. The initial proposal (for the "Wiki 3.0" XWiki SAS research project) was to actually use spaces to implement workspaces, but since we could not install apps (among other things), we chose to use subwikis instead.

We still need the ability to "Add a new Wiki" in 5.2 so this doesn't change anything.

And if in the future we support nested spaces then users will also be able to use them + space templates with flavors.

I was also eager to check out this nested spaces feature. But now that I've tasted the workspace/subwikis, I feel that this is really less "important". I even feel, it might bring much more complexity to XWiki, than what it could solve or help doing. Is it really comparable, defining a tree of spaces, and a subwiki/workspace ? In my own (enterprise) use-cases, I always felt that at least one additional level (above spaces) was missing, and I currently use workspaces also for that. But I feel bringing many additional levels + subwikis, might make things even more complex for end users and application writers ... But that's another topic.

...

...

...

...

So for me that makes it even more important to not introduce the

notion of "workspaces" in 5.2 and to only have the notion of adding a (sub)wiki :)

...

Thanks -Vincent

...

On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol <[email protected]>

wrote:

...

...

> > On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

> >> On 07/30/2013 08:28 AM, Vincent Massol wrote: >>> Definitely +1 for B. I really think we need to drop the concept of > workspaces and come back to the concept of wiki/subwiki. It's much simpler > for the user. What we call "workspace" can be seen as a configuration for a > wiki, i.e. the usage of global users only. >> >> I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an >> all-powerful collection of applications and pages that can do anything >> we want it to. But for users, a wiki is Wikipedia, where you can find >> documentation written by amateurs that's hasn't been proof-read by a >> real professional. It takes months or years of using a wiki to shift >> from the external viewer bad opinion to the internal collaborator good >> opinion of the term "wiki". >> >> So "wiki" is a bad name for users. I think "workspace" is a much better >> name than "wiki", although it's far from perfect. First of all because >> it creates confusion between a "space" and a "workspace (wiki)". >> >> So, what better word describes a "collaboration space" than "workspace"? >> >> Some random ideas, most of them bad: >> - node >> - workgroup >> - community >> - rename space to directory and we can use space or workspace for the >> current "wiki" >> - virtual server >> - environment >> - sandbox >> - appspace >> - office >> - location >> - rack >> - stack >> - instance >> - room >> - workroom >> - desk > > I'm not sure this is needed. XWiki is all about the notion of wiki… even > in its name. The generic name "wiki" seems a much better name to me than > anything else: > * it's a set of pages that can be edited/modified by users with links > between pages, using some syntax, etc. > > I don't think we need to change that. Any other name would be awkward IMO. > >> Let's not forget that some of the instances are customized so much that >> users don't even know they're using a wiki, so just seeing the word >> "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's >> internal Foobars application!". So it would be a good idea to make this >> term configurable. > > If the instance is customized so much that it doesn't look like a wiki, > then whoever did this customization can easily also customize the > translation resources to pick whatever suit their needs! ;)

It's not only about customization, even not customized at all, a subwiki might not be used (at all, or partly) as a standard wiki because of its flavour. XWiki is more than just a wiki. Subwikis are more than just subwikis. Still, the "wiki" features are fundamental to XWiki (I believe that), but I'm not sure it's (always/mandatorily) the case for subwikis use-cases.

Maybe that's only resistance to change ;-)

...

...

...

...

...

> > For example, if the wiki is used as a projects wiki and they want to have > one project = one wiki, they could rename "Wiki" to "Projects". > > We'll never be able to use a specialized name by default so we might as > well stick with "wiki" which is the best name for what it is… a wiki ;-) > > Thanks > -Vincent

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

2013/7/31 Vincent Massol <[email protected]>

BTW from a marketing POV it's better to say that "XWiki is a wiki farm solution" than "XWiki is a wiki" since it differentiates us from other solutions such as Confluence, TWiki, Mediawiki, etc.

If you say that with XWiki you can create work spaces, then so does confluence. You can create as many spaces as you wish with Confluence. But Confluence doesn't support multi tenancy.

It's probably the only real differentiator of XWiki vs other wikis. You're trying to make this difference disappear while I'm trying to make it surface. That's probably one of the reasons of non-agreement.

Is it really ? What drew me into XWiki at (almost) the very beginning, was that killer-feature of exposing an XClass model right into wiki pages, and ability to create applications through scripting and structured data without any server-side coding or custom database schema creation ... To me it's still the core originality of XWiki compared to others, and that's the 'X'. I don't think any other wiki does that, but many of them propose various solutions to organize content, whatever the name. Components are nice (to build additional/structured/stable/maintanable/documented APIs) but it's not original at all, as Extensions (sometimes called "plugin" elsewhere, as in old xwiki system). Multi-tenancy is also a killer feature in its kind, but I'm not sure it's very exposed (so, here, going in the same direction as you, naming these "wiki" or better "sub-wiki" versus "workspace" may be a way to promote this, but "workgroup" does not add any information more than "workspace" when it comes to multi-tenancy), nor does it interest the same category of people. "workgroup" or "group" makes me think about a team and its members, but not at a subwiki at all. Typically, the sentence may be "A workgroup uses a dedicated [workspace|wiki|sub-wiki] [to work collaboratively|to share] on a specific subject". I think the term "(work)group" is even more generic (and less meaningful) than workspace can be ... The confusion between "space" and "workspace" may even be a good thing, as even you consider both can fulfill almost same needs when nested spaces will be implemented (by the way, why having 2 different ways to do almost exactly the same thing, and how could this make xwiki easier for end users, while their main issue to add content to a wiki is that they are lost understanding what is correct location to put the information ...). Anyway I think "sub-wiki" is far better and clearer than "wiki" even if longer.

Thanks -Vincent

On Jul 31, 2013, at 10:57 AM, Silvia Rusu <[email protected]> wrote:

...

Hi,

Without wanting to add more fire to the debate I'd like to make a few comments regarding the naming issue. Edi said above "For me, the "wiki" is the entire environment (main wiki + all its subwikis), as a whole, by definition." I was remembered of an old thread I read while googling "XWiki Workspaces" where a potential TWiki user was comparing options and he only used the term wiki in its singular form ( http://twiki.org/cgi-bin/view/Support/SID-00140 ). I agree that users tend to think of the whole environment as "the wiki". If I wasn't part of the XWiki community I'd probably be sharing their opinion :)

I think the naming depends a lot on the message we are trying to transmit. Do we want the emphasis to be on the content, or are we looking to underline the collaboration aspect more? If we are trying to say XWiki should be used for: * Knowledge building > the term "wiki" is appropriate * Collaboration > "workspaces" sounds better IMO

An argument in favor of workspaces would be avoiding the intimidation & fear factor: most users associate wikis with Wikipedia. Let's say I'm an HR manager and I need a place where I can store CVs, employee information and where I can discuss things with the HR team. Do I need Wikipedia to achieve this? Sounds a bit too much. Also I thought I already was on a wiki. Should I create a wiki in a wiki? Does that exist ("inception")? This sounds terribly complicated. What if I mess up the wiki?! Maybe I'll get a sys admin to help. Or maybe I'll just create a space somewhere since I don't want to mess up the wiki. Email and Excel I guess are not that bad in the end either.

In conclusion I understand the arguments of both parties which makes it very hard to choose one of the names. In the end if I have to choose I prefer the notion of workspace, since to me this suggests a tool that's easy to use, that helps one get organized, but most of all collaborate more efficiently. I'm not -1 for wiki, I just like the workspace name better.

Silvia

On Wed, Jul 31, 2013 at 11:46 AM, Jeremie BOUSQUET <[email protected]> wrote:

...

Hello all,

2013/7/31 Sergiu Dumitriu <[email protected]>

...

On 07/30/2013 05:32 PM, Vincent Massol wrote:

...

Hi Sergiu,

On Jul 30, 2013, at 6:47 PM, Sergiu Dumitriu <[email protected]> wrote:

...

Vincent, stop thinking so technical! You're describing the technical implementation of the current "workspace" feature, not the user friendly name that users can understand.

<joking> ok let's stop the xwiki project then! Because it contains the word "wiki" which our users don't understand…. I don't even understand how we get users since obviously they can't understand what xwiki is about… ;) Let's call it "stuff" which is a word that everyone understands surely… </joking>

Are you sure you want to go this way?

http://www.google.com/trends/explore?q=xwiki%2C+mediawiki%2C+confluence

...

XWiki is almost unknown. XWiki doesn't get the volume of users that a mature and popular project usually gets. We've been struggling to

market

...

it as an application wiki, yet few users use it that way. How many high quality third party applications do we have in our repository?

I've seen more questions about migrating from Mediawiki than from Confluence, which is our direct competitor. And Confluence is only getting more popular.

The peak of Mediawiki popularity was also the peak of interest in plaintext wikis (Gartner's peak of inflated expectations). And unfortunately the decrease in popularity in Mediawiki is also reflected in the decrease in popularity in XWiki: http://www.google.com/trends/explore?q=xwiki (and twiki, dokuwiki, moinmoin, pmwiki, jspwiki).

Confluence seems to be the winner on the Gartner Hype Cycle.

We haven't even been able to overcome our precursor, TWiki, and I've considered TWiki almost dead for several years: http://www.google.com/trends/explore?q=xwiki%2C+twiki

So don't wonder how we even get users, because we almost don't.

And I didn't say that users don't understand what "wiki" means, just that they misunderstand what XWiki is and what a wiki is in XWiki, because they already know what a wiki is in the traditional way. It's like calling a teleportation device a TCar because it gets you from one place to another, just like a car, but then users will expect all the things they have in a car. There's a reason why different products get different names, instead of just extending the base name: reusing the old name with a prefix causes confusion.

So +1 for choosing something better than "XWiki" as the name of the product, this one hasn't been lucky so far.

...

...

No matter how much more accurate the term "wiki" is to what's happening inside, it means less than nothing to our target users. Less, because it's misleading instead of helpful.

So yes, on the inside we have __entities__ named documents, spaces and wikis, and this isn't about changing those. It's about adding names that end users can understand to the __concepts__ that those entities represent.

<joking> Yeah, let's rename "document" by "book page", "space" by "book" and "wiki" by "shelf". I"m sure users will understand better! </joking>

Did I even mention "renaming"? I explicitly said that this isn't about changing our entity names, but about labeling for users. It's a marketing strategy.

But yes, even "document" and "space" have been occasionally misleading.

...

...

It is a wiki, but it lets users collaborate. Our users do their jobs in such a wiki, and for __our users__ that means much more than what "wiki" means to them.

http://lmgtfy.com/?q=define%3Awiki

You just proved that the wiki word is exactly the right word… :)

What exactly do you see? I see:

"A Web site developed collaboratively by a community of users, allowing any user to add and edit content"

So if this is indeed the correct term, adding a new subwiki, is... "creating a new website"? Do you even know what a "website" means for the average user? Or "content"?

...

...

Remember the XWiki (SAS) mottos: work better together, the best way to organize information, free your knowledge... Users do their work collaboratively, they don't just write pages in a wiki. They write in a forum, write review, write press releases, vote, plan, review job candidates, take meeting notes, draw UML diagrams, etc. This is why "wiki" is WRONG for __end users__.

I think that this is not a technical decision, but a marketing/usability one, so it would be better to see what someone from marketing thinks.

I definitely don't agree, sorry… We're building a collaborative solution based on a wiki and as such I definitely don't agree to rename the base concepts of a wiki: pages, spaces, wiki, etc.

Again, when did I ever said that we should rename them? I just said that it would be more intuitive for users to label a virtual wiki as a workspace.

I must say I somehow share this vision ... From the very start, I never had the same perception about sub-wikis and workspaces, even though I knew they mostly shared same technicals (and fundamentally it's the same thing). But in my mind (and it's totally irrationnal), "sub-wikis" are associated to wiki farms, something a bit huge, a bit difficult to put in place, something to host thousands of isolated wikis, something I never really envisaged to put in production for myself. While workspaces is a light collaborative concept, that can be installed from EM in a few clicks, that has a nice and easy UI, and that I started playing with nearly from the start and that I've put in production to manage distinct projects Mail Archives at my office with 5.1.

Of course it might seem stupid, but I can't help but feeling that going back to "wiki" (for naming those kind of subwikis) is like a step back. My users start to get used to seing that "Workspace directory" entry point. And I don't want them to consider these as "wikis", because I don't want them to edit anything (or add manually new pages) in these. Still, they are collaborative (thanks to ratings, comments, activity stream, page sharing, and thanks to its nature of mail archive). But I wouldn't want my users to imagine that it could be nice to add a Blog in this kind of workspace, or use any other wiki feature.

For example, seems the concept of "Space" is taken for granted as basic wiki feature, but maybe I didn't test much of them, but I never heard of this "Space" concept in any other wiki. The fact that it's called a "Space" (and not a group, or a workspace, or a folder, or just anything) is a choice done by XWiki from the start. IMHO, the choice to call a subwiki a "wiki" or a "workspace" is only your choice, and it should be more based on what you want XWiki to be than on what it currently is inside ...

What I can only say on my side, is that I love my XWiki with my workspaces (and eagerly wait for flavours), and I somewhat don't care at all about the wiki farm concept ... Maybe to explain better: - a wiki farm is a set of distinct full-fledged wikis, like a cluster of wikis, with a top-hat admin and container. The container itself has no real interest, apart from grouping things together and providing central navigation - the main wiki + workspaces is a full-fledged wiki, with specialized collaborative places for particular topics, projects, tools, documentation creation ... The main wiki is not just an entry point, it is THE wiki, THE knowledge base, with some satelites graviting around this central planet.

...

...

Remember that we're talking here about the base platform. Then there

are

...

flavors and customizations done by our users which can be anything specific for their project if they want to hide the wiki concepts…

...

I think you're confusing applications based on xwiki concepts with

core concepts. A subwiki is a core concept in the same manner as a document or a space. What we're doing now is making the notion of subwiki part of the core concepts as it should have been a long time ago (this is why btw it's also in the new model). Again, on top of these core concepts you could create apps for specific uses cases. You could have a workspace app if you want although with the core concepts it's not required ATM since it doesn't add any additional feature...

Rerepeating myself, this isn't about the workspace feature. This isn't about the workspace feature. This is about the XWiki vision, and the XWiki marketing strategy. Is XWiki just a wiki? Or is it much more than that, with collaborative applications as the focus instead of just plain text.

What is XWiki trying to be? How do we present it to our potential users? As a wiki? Or as a platform empowering collaboration? An intranet environment, where employees can do their work better.

Compared to first generation wikis, XWiki is like an atomic bomb next to a hand grenade. Let's not market XWiki as a Bigger Grenade.

And please, read more carefully what I'm actually saying.

...

Thanks -Vincent

PS: BTW you haven't proposed a good name so far IMO…. At least not one that is better for all use cases. Some might be better for a specific usage of xwiki but not generally speaking.

...

On 07/30/2013 12:15 PM, Vincent Massol wrote: > > On Jul 30, 2013, at 5:53 PM, Eduard Moraru <[email protected]> wrote: > >> Just my point of view on this point, since I keep seeing similar topics >> popping up once in a while... >> >> For me, the "wiki" is the entire environment (main wiki + all its >> subwikis), as a whole, by definition. Since they are all connected, it is >> wrong to say that we are creating new wikis (subwikis) when, in fact, we >> are just creating new "spaces"/"workspaces" (spaces where the user >> does/groups/catalogues his work). Also, this view is enforced by our new >> direction towards virtual by default and of making subwikis part of XWiki's >> data model (including the new model). > > In the future you'll be able to either: > - create wikis, they are real wikis. > - create nested spaces > > So you'll be able to choose the way you want to organize yourself by either creating a (sub)wiki or a (nested)space. > > The notion of "workspace" is not needed in either case: > - for (sub)wikis, it matches with the notion of a wiki and flavors > - for (nested)space, it matches with the notion of a space + space template (which I guess could also be implemented as a flavor in the future) > >> Since we are currently lacking the hierarchy feature of the the new model, >> and we are faking it technically (and maybe this is where the confusion >> comes from) by using new wikis(subwikis) in new databases, the term >> "workspace" would, IMO, remain the best candidate. > > I don't agree. The "workspace" feature was done ad-hoc outside of the platform and as a consequence was thought as an add-on. Now, what we are doing and preparing for the future is to have the notion of subwiki at the core of XWiki. And this concept of workspace is no longer needed as something adhoc. It can be integrated in the platform. > > What is a workspace: > * it's a set of pages/applications > * using existing users > > Those 2 items can be done without the need for any new name/concept. A set of pages/applications is what we call a flavor. And the notion of users already exists (what we need to work on, is to have a config feature so that a subwiki can have or not have local users). > >> If we consider the fact >> that we want to make workspaces the default (as proven in practice), we >> find that the "corner" cases are actually the term "wiki" (actually >> "subwiki"), which occur only in farm deployments where, indeed, a subwiki >> is a fully fledged and generally isolated "wiki" from the point of view of >> the owner and its users. >> >> Also, in an enterprise environment, try explaining each time to the >> Accounting, Marketing, etc. departments that: >> - a "wiki" is "a set of pages that can be edited/modified by users with >> links between pages, using some syntax, etc."... >> - a "workspace" is "a/the space where you (do *your*) work/collaborate" > > I don't understand. Why have the 2 concepts? The idea of option B is to have only 1 concept: that of (sub)wikis. > >> +1 for "workspace" as first-class term being promoted to users >> +1 for "wiki" as technical term being mentioned in documentation to admins >> (specifically for farm deployments) >> >> Also, being an enterprise wiki, I`m not sure we want to be labelled as the >> company's "wiki" instead of the company's "collaboration tool" (or "tool >> used to get our work done"). >> >> Thanks, >> Eduard >> >> P.S.: As a technical/background note, just not to be misunderstood, indeed, >> a workspace is implemented as just a wiki right now with additional >> restrictions to satisfy its usecase. However, this is only due to our >> platform's limitations. Normally, a workspace should just be a space where >> a user can install apps, create other sub-spaces, and collaborate with >> others. The initial proposal (for the "Wiki 3.0" XWiki SAS research >> project) was to actually use spaces to implement workspaces, but since we >> could not install apps (among other things), we chose to use subwikis >> instead. > > We still need the ability to "Add a new Wiki" in 5.2 so this doesn't change anything. > > And if in the future we support nested spaces then users will also be able to use them + space templates with flavors.

I was also eager to check out this nested spaces feature. But now that I've tasted the workspace/subwikis, I feel that this is really less "important". I even feel, it might bring much more complexity to XWiki, than what it could solve or help doing. Is it really comparable, defining a tree of spaces, and a subwiki/workspace ? In my own (enterprise) use-cases, I always felt that at least one additional level (above spaces) was missing, and I currently use workspaces also for that. But I feel bringing many additional levels + subwikis, might make things even more complex for end users and application writers ... But that's another topic.

...

...

...

> > So for me that makes it even more important to not introduce the notion of "workspaces" in 5.2 and to only have the notion of adding a (sub)wiki :) > > Thanks > -Vincent > >> On Tue, Jul 30, 2013 at 5:29 PM, Vincent Massol < [email protected]> wrote: >> >>> >>> On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <[email protected]> wrote: >>> >>>> On 07/30/2013 08:28 AM, Vincent Massol wrote: >>>>> Definitely +1 for B. I really think we need to drop the concept of >>> workspaces and come back to the concept of wiki/subwiki. It's much simpler >>> for the user. What we call "workspace" can be seen as a configuration for a >>> wiki, i.e. the usage of global users only. >>>> >>>> I disagree. For us XWiki veterans it's obvious that an XWiki wiki is an >>>> all-powerful collection of applications and pages that can do anything >>>> we want it to. But for users, a wiki is Wikipedia, where you can find >>>> documentation written by amateurs that's hasn't been proof-read by a >>>> real professional. It takes months or years of using a wiki to shift >>>> from the external viewer bad opinion to the internal collaborator good >>>> opinion of the term "wiki". >>>> >>>> So "wiki" is a bad name for users. I think "workspace" is a much better >>>> name than "wiki", although it's far from perfect. First of all because >>>> it creates confusion between a "space" and a "workspace (wiki)". >>>> >>>> So, what better word describes a "collaboration space" than "workspace"? >>>> >>>> Some random ideas, most of them bad: >>>> - node >>>> - workgroup >>>> - community >>>> - rename space to directory and we can use space or workspace for the >>>> current "wiki" >>>> - virtual server >>>> - environment >>>> - sandbox >>>> - appspace >>>> - office >>>> - location >>>> - rack >>>> - stack >>>> - instance >>>> - room >>>> - workroom >>>> - desk >>> >>> I'm not sure this is needed. XWiki is all about the notion of wiki… even >>> in its name. The generic name "wiki" seems a much better name to me than >>> anything else: >>> * it's a set of pages that can be edited/modified by users with links >>> between pages, using some syntax, etc. >>> >>> I don't think we need to change that. Any other name would be awkward IMO. >>> >>>> Let's not forget that some of the instances are customized so much that >>>> users don't even know they're using a wiki, so just seeing the word >>>> "wiki" might cause confusion: "Wiki? What wiki? I'm using our company's >>>> internal Foobars application!". So it would be a good idea to make this >>>> term configurable. >>> >>> If the instance is customized so much that it doesn't look like a wiki, >>> then whoever did this customization can easily also customize the >>> translation resources to pick whatever suit their needs! ;)

It's not only about customization, even not customized at all, a subwiki might not be used (at all, or partly) as a standard wiki because of its flavour. XWiki is more than just a wiki. Subwikis are more than just subwikis. Still, the "wiki" features are fundamental to XWiki (I believe that), but I'm not sure it's (always/mandatorily) the case for subwikis use-cases.

Maybe that's only resistance to change ;-)

...

...

...

>>> >>> For example, if the wiki is used as a projects wiki and they want to have >>> one project = one wiki, they could rename "Wiki" to "Projects". >>> >>> We'll never be able to use a specialized name by default so we might as >>> well stick with "wiki" which is the best name for what it is… a wiki ;-) >>> >>> Thanks >>> -Vincent

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]> wrote:

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:

...

On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 07/20/2013 07:33 AM, Vincent Massol wrote:

...

Hi devs,

In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's this time:

" * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :) "

Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this.

The rationale is:

* It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it.

* XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop.

Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

Here's my +1

This is a major shift in how first-time users perceive XWiki. Without multi-wiki features, it still looks like a wiki, but if the homepage changes from a "welcome to your wiki" page to a "here are your workspaces" portal, then suddenly XWiki "becomes" something else in the eyes of our users. I used quotes since nothing changes on the inside, the multiwiki feature has been there since the beginning, and the single wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

Proposals:

* Changes to the Menu http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level ** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

...

* Wiki/Workspace Creation http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... (please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

BTW for me the notion of workspaces should not exist at all and it should not be a template. A template is just a set of pages. For me the choice for the user is just an option, i.e. whether he'd like his users to be managed locally or only globally. Thanks -Vincent

Thanks -Vincent

...

Thanks, Caty

...

...

But this change in how XWiki is perceived has both advantages and disadvantages. On one hand, it clearly shows users that XWiki is a collaborative platform, not just a wiki, so people that need collaboration more than just a wiki will be able to see that XWiki isn't another boring wiki. On the other hand, people that are just looking for a wiki that's nice to use and "not-ugly", might be put off by yet another layer of complexity, and might drop XWiki from their list of candidates. In other words, it alienates even more the kind of users that already perceive XWiki as hard to use and overly complex.

So, are we willing to trade one type of users for the other? It would be in line with our vision of "enterprise collaboration", but I still think we shouldn't voluntarily alienate any kind of users.

An alternative is to wait for a real flavor, and then ask in the first step of the distribution manager what kind of usage do we want. In the meantime, we can still polish the pages that will go in the "workspaces" flavor.

So, -0 for switching to "workspaces only" in 5.2, unless we have really good backwards compatibility and a flavor for a simple wiki for textual collaboration.

I hope the above allays your fears :)

Thanks -Vincent

Hi everyone! I vote for B. I think we should completely *drop the notion of workspaces* and *only have the notion of "subwikis"*. During the creation wizard, we just add an option "use the global users only" that the user can enable or not (it should be enabled by default). So there is no type. Then we drop the WikiManager and the WorkspaceManager UIs, and we create *a new unified one to manage all the subwikis*. On the wiki index, we could show all the wikis where the user have the "view" right. All others wikis will be hidden for him (I think it is the use case of myxwiki.org). In this way, everything is more simple and both the use case of current wiki farm and workspaces are supported. Thanks, Louis-Marie 2013/7/30 Vincent Massol <[email protected]>

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]> wrote:

...

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

...

On 07/20/2013 07:33 AM, Vincent Massol wrote:

...

Hi devs,

In the Roadmap proposal I've sent for XWiki 5.2 some days ago,

there's

...

this time:

...

...

" * Have Workspace by default in XE + improved home page - Caty +

Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :)

...

"

Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this.

The rationale is:

* It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it.

* XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop.

Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

Here's my +1

This is a major shift in how first-time users perceive XWiki. Without multi-wiki features, it still looks like a wiki, but if the homepage changes from a "welcome to your wiki" page to a "here are your workspaces" portal, then suddenly XWiki "becomes" something else in the eyes of our users. I used quotes since nothing changes on the inside, the multiwiki feature has been there since the beginning, and the single wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

Proposals:

* Changes to the Menu http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level ** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

After more thoughts I think it's ok for a first version to have the new "Home" menu entry to represent the main wiki. However all subwikis menu entries should have the same entries except for "Wiki Index" which should only be in "Home".

In the future though, in the new model, we'll have a notion of System (farm of wikis) and maybe we'll implement it differently than in a wiki. But we can take care of this at that time… ;)

Right now the more important for me is to agree that we have only 1 concept: the notion of "Wiki" and to replace the notion of "Workspace" just by a checkbox in the wiki creation wizard: "Allow creating local users" (which is unchecked by default).

Note that we'll also need in 5.3+ a new right IMO: the right of creating a new wiki. For 5.2 we could just have a check in the wiki creation wizard page (for example on the user having Admin rights on the main wiki). If an Admin wants to change that to allow everyone to create a wiki he could edit that page and change the check.

WDYT?

Thanks -Vincent

...

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

...

* Wiki/Workspace Creation

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

(please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

Thanks -Vincent

...

Thanks, Caty

...

...

But this change in how XWiki is perceived has both advantages and disadvantages. On one hand, it clearly shows users that XWiki is a collaborative platform, not just a wiki, so people that need collaboration more than just a wiki will be able to see that XWiki

isn't

...

...

another boring wiki. On the other hand, people that are just looking for a wiki that's nice to use and "not-ugly", might be put off by yet another layer of complexity, and might drop XWiki from their list of candidates. In other words, it alienates even more the kind of users that already perceive XWiki as hard to use and overly complex.

So, are we willing to trade one type of users for the other? It would be in line with our vision of "enterprise collaboration", but I still think we shouldn't voluntarily alienate any kind of users.

An alternative is to wait for a real flavor, and then ask in the first step of the distribution manager what kind of usage do we want. In the meantime, we can still polish the pages that will go in the "workspaces" flavor.

So, -0 for switching to "workspaces only" in 5.2, unless we have really good backwards compatibility and a flavor for a simple wiki for textual collaboration.

I hope the above allays your fears :)

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

BTW, I also need to know if we only integrate "Workspaces" in XE, or if we integrate the whole XEM in XE (workspace + wiki-manager + app manager)? Do we want to keep XEM in our base products or do we want to have only one product (XE)? 2013/7/31 Guillaume "Louis-Marie" Delhumeau <[email protected]>

I am not again to see the "wiki" term as the whole system and to call subwikis "workspaces" (if it is a better word), as long as we do not have both concepts of subwikis and workspaces.

Please send your votes ;)

Louis-Marie

2013/7/30 Guillaume "Louis-Marie" Delhumeau <[email protected]>

...

Hi everyone!

I vote for B.

I think we should completely *drop the notion of workspaces* and *only have the notion of "subwikis"*. During the creation wizard, we just add an option "use the global users only" that the user can enable or not (it should be enabled by default). So there is no type.

Then we drop the WikiManager and the WorkspaceManager UIs, and we create *a new unified one to manage all the subwikis*.

On the wiki index, we could show all the wikis where the user have the "view" right. All others wikis will be hidden for him (I think it is the use case of myxwiki.org).

In this way, everything is more simple and both the use case of current wiki farm and workspaces are supported.

Thanks,

Louis-Marie

2013/7/30 Vincent Massol <[email protected]>

...

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]> wrote:

...

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

> On 07/20/2013 07:33 AM, Vincent Massol wrote: >> Hi devs, >> >> In the Roadmap proposal I've sent for XWiki 5.2 some days ago,

there's

...

this time: >> >> " >> * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :) >> " >> >> Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this. >> >> The rationale is: >> >> * It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it. >> >> * XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop. >> >> Caty started working on the home page/UI improvements required to integrate this by default: >> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki >> >> Here's my +1 >> > > This is a major shift in how first-time users perceive XWiki. Without > multi-wiki features, it still looks like a wiki, but if the homepage > changes from a "welcome to your wiki" page to a "here are your > workspaces" portal, then suddenly XWiki "becomes" something else in the > eyes of our users. I used quotes since nothing changes on the inside, > the multiwiki feature has been there since the beginning, and the single > wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

Proposals:

* Changes to the Menu http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level ** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

After more thoughts I think it's ok for a first version to have the new "Home" menu entry to represent the main wiki. However all subwikis menu entries should have the same entries except for "Wiki Index" which should only be in "Home".

In the future though, in the new model, we'll have a notion of System (farm of wikis) and maybe we'll implement it differently than in a wiki. But we can take care of this at that time… ;)

Right now the more important for me is to agree that we have only 1 concept: the notion of "Wiki" and to replace the notion of "Workspace" just by a checkbox in the wiki creation wizard: "Allow creating local users" (which is unchecked by default).

Note that we'll also need in 5.3+ a new right IMO: the right of creating a new wiki. For 5.2 we could just have a check in the wiki creation wizard page (for example on the user having Admin rights on the main wiki). If an Admin wants to change that to allow everyone to create a wiki he could edit that page and change the check.

WDYT?

Thanks -Vincent

...

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

...

* Wiki/Workspace Creation

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

(please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

Thanks -Vincent

...

Thanks, Caty

...

> But this change in how XWiki is perceived has both advantages and > disadvantages. On one hand, it clearly shows users that XWiki is a > collaborative platform, not just a wiki, so people that need > collaboration more than just a wiki will be able to see that XWiki

isn't

...

> another boring wiki. On the other hand, people that are just looking for > a wiki that's nice to use and "not-ugly", might be put off by yet > another layer of complexity, and might drop XWiki from their list of > candidates. In other words, it alienates even more the kind of users > that already perceive XWiki as hard to use and overly complex. > > So, are we willing to trade one type of users for the other? It would be > in line with our vision of "enterprise collaboration", but I still think > we shouldn't voluntarily alienate any kind of users. > > An alternative is to wait for a real flavor, and then ask in the first > step of the distribution manager what kind of usage do we want. In the > meantime, we can still polish the pages that will go in the "workspaces" > flavor. > > So, -0 for switching to "workspaces only" in 5.2, unless we have really > good backwards compatibility and a flavor for a simple wiki for textual > collaboration.

I hope the above allays your fears :)

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Jul 31, 2013, at 10:34 AM, Vincent Massol <[email protected]> wrote:

On Jul 31, 2013, at 10:19 AM, Guillaume Louis-Marie Delhumeau <[email protected]> wrote:

...

BTW, I also need to know if we only integrate "Workspaces" in XE, or if we integrate the whole XEM in XE (workspace + wiki-manager + app manager)? Do we want to keep XEM in our base products or do we want to have only one product (XE)?

One product (XE) for sure.

BTW note that one product (ie one distribution) doesn't mean that we include everything in XE, they could be extensions. For me what we need to do is integrate the creation of subwikis in XE (both myxwiki.org and xwiki.org use cases). Thanks -Vincent

Thanks -Vincent

...

2013/7/31 Guillaume "Louis-Marie" Delhumeau <[email protected]>

...

I am not again to see the "wiki" term as the whole system and to call subwikis "workspaces" (if it is a better word), as long as we do not have both concepts of subwikis and workspaces.

Please send your votes ;)

Louis-Marie

2013/7/30 Guillaume "Louis-Marie" Delhumeau <[email protected]>

...

Hi everyone!

I vote for B.

I think we should completely *drop the notion of workspaces* and *only have the notion of "subwikis"*. During the creation wizard, we just add an option "use the global users only" that the user can enable or not (it should be enabled by default). So there is no type.

Then we drop the WikiManager and the WorkspaceManager UIs, and we create *a new unified one to manage all the subwikis*.

On the wiki index, we could show all the wikis where the user have the "view" right. All others wikis will be hidden for him (I think it is the use case of myxwiki.org).

In this way, everything is more simple and both the use case of current wiki farm and workspaces are supported.

Thanks,

Louis-Marie

2013/7/30 Vincent Massol <[email protected]>

...

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]> wrote:

...

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

> On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <[email protected]> wrote: > >> >> On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]> wrote: >> >>> On 07/20/2013 07:33 AM, Vincent Massol wrote: >>>> Hi devs, >>>> >>>> In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's >> this time: >>>> >>>> " >>>> * Have Workspace by default in XE + improved home page - Caty + >> Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to >> work full time on XWiki development and especially on UI aspects from now >> on. Welcome aboard Guillaume, we need you! :) >>>> " >>>> >>>> Denis told me he didn't know about the proposal of having Workspaces >> integrated in the default XAR. Thus I'm sending this email to ensure we all >> agree about this. >>>> >>>> The rationale is: >>>> >>>> * It would be nice that when our users download XWiki (standalone >> version or install the default XAR) they get to see the power of XWiki. One >> of the very important differentiator of XWiki vs other wikis/solutions is >> our multi-tenancy feature and most of people downloading and installing >> XWiki don't see it. >>>> >>>> * XEM/Wiki Manager are lacking polishing because the committers mostly >> polish the default which doesn't include those. The UIs of XEM/Wiki Manager >> need polishing. Having them in default will ensure that we take them into >> account and make them first class citizens when we develop. >>>> >>>> Caty started working on the home page/UI improvements required to >> integrate this by default: >>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki >>>> >>>> Here's my +1 >>>> >>> >>> This is a major shift in how first-time users perceive XWiki. Without >>> multi-wiki features, it still looks like a wiki, but if the homepage >>> changes from a "welcome to your wiki" page to a "here are your >>> workspaces" portal, then suddenly XWiki "becomes" something else in the >>> eyes of our users. I used quotes since nothing changes on the inside, >>> the multiwiki feature has been there since the beginning, and the single >>> wiki mode can still be used. >> >> This isn't the plan as I mentioned in my previous emails. The plan is that >> the home page doesn't change. All that changes for a first time user >> installing XWiki is that the Add menu will have more entries (Add Workspace >> or Add Wiki or both, Caty is still working on the proposal). >> > > Proposals: > > * Changes to the Menu > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level ** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

After more thoughts I think it's ok for a first version to have the new "Home" menu entry to represent the main wiki. However all subwikis menu entries should have the same entries except for "Wiki Index" which should only be in "Home".

In the future though, in the new model, we'll have a notion of System (farm of wikis) and maybe we'll implement it differently than in a wiki. But we can take care of this at that time… ;)

Right now the more important for me is to agree that we have only 1 concept: the notion of "Wiki" and to replace the notion of "Workspace" just by a checkbox in the wiki creation wizard: "Allow creating local users" (which is unchecked by default).

Note that we'll also need in 5.3+ a new right IMO: the right of creating a new wiki. For 5.2 we could just have a check in the wiki creation wizard page (for example on the user having Admin rights on the main wiki). If an Admin wants to change that to allow everyone to create a wiki he could edit that page and change the check.

WDYT?

Thanks -Vincent

...

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

> * Wiki/Workspace Creation > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... > (please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

Thanks -Vincent

> Thanks, > Caty > > > >> >>> But this change in how XWiki is perceived has both advantages and >>> disadvantages. On one hand, it clearly shows users that XWiki is a >>> collaborative platform, not just a wiki, so people that need >>> collaboration more than just a wiki will be able to see that XWiki isn't >>> another boring wiki. On the other hand, people that are just looking for >>> a wiki that's nice to use and "not-ugly", might be put off by yet >>> another layer of complexity, and might drop XWiki from their list of >>> candidates. In other words, it alienates even more the kind of users >>> that already perceive XWiki as hard to use and overly complex. >>> >>> So, are we willing to trade one type of users for the other? It would be >>> in line with our vision of "enterprise collaboration", but I still think >>> we shouldn't voluntarily alienate any kind of users. >>> >>> An alternative is to wait for a real flavor, and then ask in the first >>> step of the distribution manager what kind of usage do we want. In the >>> meantime, we can still polish the pages that will go in the "workspaces" >>> flavor. >>> >>> So, -0 for switching to "workspaces only" in 5.2, unless we have really >>> good backwards compatibility and a flavor for a simple wiki for textual >>> collaboration. >> >> I hope the above allays your fears :) >> >> Thanks >> -Vincent

On Tue, Jul 30, 2013 at 5:22 PM, Vincent Massol <[email protected]> wrote:

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]> wrote:

...

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

...

On 07/20/2013 07:33 AM, Vincent Massol wrote:

...

Hi devs,

In the Roadmap proposal I've sent for XWiki 5.2 some days ago,

there's

...

this time:

...

...

" * Have Workspace by default in XE + improved home page - Caty +

Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :)

...

"

Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this.

The rationale is:

* It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it.

* XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop.

Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki

Here's my +1

This is a major shift in how first-time users perceive XWiki. Without multi-wiki features, it still looks like a wiki, but if the homepage changes from a "welcome to your wiki" page to a "here are your workspaces" portal, then suddenly XWiki "becomes" something else in the eyes of our users. I used quotes since nothing changes on the inside, the multiwiki feature has been there since the beginning, and the single wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

Proposals:

* Changes to the Menu http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level ** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

After more thoughts I think it's ok for a first version to have the new "Home" menu entry to represent the main wiki. However all subwikis menu entries should have the same entries except for "Wiki Index" which should only be in "Home".

In the future though, in the new model, we'll have a notion of System (farm of wikis) and maybe we'll implement it differently than in a wiki. But we can take care of this at that time… ;)

Right now the more important for me is to agree that we have only 1 concept: the notion of "Wiki" and to replace the notion of "Workspace" just by a checkbox in the wiki creation wizard: "Allow creating local users" (which is unchecked by default).

I've created the 'Option D' proposal http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... - used 'subwiki' term instead of 'wiki' - used 'users isolation' checkbox to replace the notion of workspace Thanks, Caty

Note that we'll also need in 5.3+ a new right IMO: the right of creating a new wiki. For 5.2 we could just have a check in the wiki creation wizard page (for example on the user having Admin rights on the main wiki). If an Admin wants to change that to allow everyone to create a wiki he could edit that page and change the check.

WDYT?

Thanks -Vincent

...

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

...

* Wiki/Workspace Creation

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

(please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

Thanks -Vincent

...

Thanks, Caty

...

...

But this change in how XWiki is perceived has both advantages and disadvantages. On one hand, it clearly shows users that XWiki is a collaborative platform, not just a wiki, so people that need collaboration more than just a wiki will be able to see that XWiki

isn't

...

...

another boring wiki. On the other hand, people that are just looking for a wiki that's nice to use and "not-ugly", might be put off by yet another layer of complexity, and might drop XWiki from their list of candidates. In other words, it alienates even more the kind of users that already perceive XWiki as hard to use and overly complex.

So, are we willing to trade one type of users for the other? It would be in line with our vision of "enterprise collaboration", but I still think we shouldn't voluntarily alienate any kind of users.

An alternative is to wait for a real flavor, and then ask in the first step of the distribution manager what kind of usage do we want. In the meantime, we can still polish the pages that will go in the "workspaces" flavor.

So, -0 for switching to "workspaces only" in 5.2, unless we have really good backwards compatibility and a flavor for a simple wiki for textual collaboration.

I hope the above allays your fears :)

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

I vote for D (not B anymore). 2013/8/1 Guillaume Lerouge <[email protected]>

Hi,

I like this option. Waiting for further agreement on the sister thread about workspaces, I think this is a good solution for XE 5.2.

The downside is that we lose a bit of simplicity, but it's a tough topic.

Guillaume

On Wed, Jul 31, 2013 at 4:31 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Tue, Jul 30, 2013 at 5:22 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]>

wrote:

...

...

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <

[email protected]>

...

wrote:

...

...

...

On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

...

> On 07/20/2013 07:33 AM, Vincent Massol wrote: >> Hi devs, >> >> In the Roadmap proposal I've sent for XWiki 5.2 some days ago,

there's

...

this time: >> >> " >> * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :) >> " >> >> Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this. >> >> The rationale is: >> >> * It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it. >> >> * XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop. >> >> Caty started working on the home page/UI improvements required to integrate this by default: >> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki >> >> Here's my +1 >> > > This is a major shift in how first-time users perceive XWiki. Without > multi-wiki features, it still looks like a wiki, but if the homepage > changes from a "welcome to your wiki" page to a "here are your > workspaces" portal, then suddenly XWiki "becomes" something else in the > eyes of our users. I used quotes since nothing changes on the inside, > the multiwiki feature has been there since the beginning, and the single > wiki mode can still be used.

This isn't the plan as I mentioned in my previous emails. The plan is that the home page doesn't change. All that changes for a first time user installing XWiki is that the Add menu will have more entries (Add Workspace or Add Wiki or both, Caty is still working on the proposal).

Proposals:

* Changes to the Menu http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level ** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

After more thoughts I think it's ok for a first version to have the new "Home" menu entry to represent the main wiki. However all subwikis menu entries should have the same entries except for "Wiki Index" which should only be in "Home".

In the future though, in the new model, we'll have a notion of System (farm of wikis) and maybe we'll implement it differently than in a wiki. But we can take care of this at that time… ;)

Right now the more important for me is to agree that we have only 1 concept: the notion of "Wiki" and to replace the notion of "Workspace" just by a checkbox in the wiki creation wizard: "Allow creating local users" (which is unchecked by default).

I've created the 'Option D' proposal

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

- used 'subwiki' term instead of 'wiki' - used 'users isolation' checkbox to replace the notion of workspace

Thanks, Caty

...

Note that we'll also need in 5.3+ a new right IMO: the right of

creating a

...

new wiki. For 5.2 we could just have a check in the wiki creation wizard page (for example on the user having Admin rights on the main wiki). If an Admin wants to change that to allow everyone to create a wiki he could edit that page and change the check.

WDYT?

Thanks -Vincent

...

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

...

* Wiki/Workspace Creation

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

...

...

...

(please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

Thanks -Vincent

...

Thanks, Caty

...

> But this change in how XWiki is perceived has both advantages and > disadvantages. On one hand, it clearly shows users that XWiki is a > collaborative platform, not just a wiki, so people that need > collaboration more than just a wiki will be able to see that XWiki

isn't

...

> another boring wiki. On the other hand, people that are just looking for > a wiki that's nice to use and "not-ugly", might be put off by yet > another layer of complexity, and might drop XWiki from their list of > candidates. In other words, it alienates even more the kind of users > that already perceive XWiki as hard to use and overly complex. > > So, are we willing to trade one type of users for the other? It would be > in line with our vision of "enterprise collaboration", but I still think > we shouldn't voluntarily alienate any kind of users. > > An alternative is to wait for a real flavor, and then ask in the first > step of the distribution manager what kind of usage do we want. In the > meantime, we can still polish the pages that will go in the "workspaces" > flavor. > > So, -0 for switching to "workspaces only" in 5.2, unless we have really > good backwards compatibility and a flavor for a simple wiki for textual > collaboration.

I hope the above allays your fears :)

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi developers! I'm back from holidays. I have read all your messages this morning, and this is what I propose for the next 2 weeks (until M2): (it is based on the proposal D from Caty: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...) * We use the term 'subwiki' instead of 'wiki'. * We add an option in the subwiki creation ui called 'users isolation', that enable local users for the new subwiki. * We add a new right called 'subwiki creation right'. * We add a new right called 'users isolation rights', which enable or not if the user has the right to use the 'users isolation' option while he is creating a new subwiki. * We drop the notion of 'workspaces' and 'farm', since you can have the same behaviour with the good set of settings. Now, I quote Guillaume Lerouge who has explained several use cases, and I'll say how to handle it with this proposal: 1. *Large organization where various groups want to have independent wikis for their knowledge bases:* no local users, wiki creation restricted to admins to avoid duplication of KBs --> SOLUTION: 'subwiki creation right' only given to admins, 'user isolation rights' given to nobody. 2. *"Pure" wiki farm as on myxwiki.org:* you only want admins to be able to create new wikis to prevent spam. Each wiki has its local users. --> SOLUTION: 'subwiki creation right' only given to admins, 'user isolation rights' given to admin too. Each time a new subwiki is created, the admin select the option 'users isolation'. 3. *Large organization where people want to work on projects with sub-contractors (some wikis act as an extranet):* local users allowed, anyone can create a wiki --> SOLUTION: 'subwiki creation right' given to all users, 'user isolation rights' given to all users. 4. *Company where people want to work on internal projects:* local users not allowed, anyone can create a wiki --> SOLUTION: 'subwiki creation right' given to all users, 'user isolation rights' given to nobody. As you can see, all the well-knowned use cases are handled by my proposal. I would like to to say if you agree with it. We only have 2 weeks to achieve this, and I work only 4 days a week. WDYT? Regards, Louis-Marie 2013/8/2 Jean Coury <[email protected]>

Hello,

Firstly I couldn't read everything because there is a lot of off topics so forgive me if some of the following should not be here. If you have no time go the last line directly.

I've been struggling with client with all those terms wich look like the same (e.g. Main wiki, sub-wiki and then Workspace, Space) and the fact that Workspace have "Work" into it and so is not really friendly to the client's users. My first proposal would have been "Portal > Wiki > Space > Page" in order to keep the basics and to find an easy way to describe the main wiki. Then I read multiple threads and have a look to the competitors and find-out that Home as a first term would be great and less technical than Portal. Moreover Portal is full of connotations and do not show the possibility to customize it.

"There is no place like Home" don't you think? Proposal : Home > Wiki > Space > Page

Then I looked at the proposal made by Cathy on

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... I would have picked B but I strongly dislike the fact that the product can be two things at a time and so* => I vote for* *D*.

Regards,

2013/8/1 Guillaume "Louis-Marie" Delhumeau <[email protected]>

...

I vote for D (not B anymore).

2013/8/1 Guillaume Lerouge <[email protected]>

...

Hi,

I like this option. Waiting for further agreement on the sister thread about workspaces, I think this is a good solution for XE 5.2.

The downside is that we lose a bit of simplicity, but it's a tough topic.

Guillaume

On Wed, Jul 31, 2013 at 4:31 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Tue, Jul 30, 2013 at 5:22 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]>

wrote:

...

...

Hi Caty,

See below.

On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

> On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <

[email protected]>

...

wrote:

...

> >> >> On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu < [email protected]> wrote: >> >>> On 07/20/2013 07:33 AM, Vincent Massol wrote: >>>> Hi devs, >>>> >>>> In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's >> this time: >>>> >>>> " >>>> * Have Workspace by default in XE + improved home page - Caty + >> Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to >> work full time on XWiki development and especially on UI aspects from now >> on. Welcome aboard Guillaume, we need you! :) >>>> " >>>> >>>> Denis told me he didn't know about the proposal of having Workspaces >> integrated in the default XAR. Thus I'm sending this email to ensure we all >> agree about this. >>>> >>>> The rationale is: >>>> >>>> * It would be nice that when our users download XWiki (standalone >> version or install the default XAR) they get to see the power of XWiki. One >> of the very important differentiator of XWiki vs other wikis/solutions is >> our multi-tenancy feature and most of people downloading and installing >> XWiki don't see it. >>>> >>>> * XEM/Wiki Manager are lacking polishing because the committers mostly >> polish the default which doesn't include those. The UIs of XEM/Wiki Manager >> need polishing. Having them in default will ensure that we take them into >> account and make them first class citizens when we develop. >>>> >>>> Caty started working on the home page/UI improvements required to >> integrate this by default: >>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki >>>> >>>> Here's my +1 >>>> >>> >>> This is a major shift in how first-time users perceive XWiki. Without >>> multi-wiki features, it still looks like a wiki, but if the homepage >>> changes from a "welcome to your wiki" page to a "here are your >>> workspaces" portal, then suddenly XWiki "becomes" something else in the >>> eyes of our users. I used quotes since nothing changes on the inside, >>> the multiwiki feature has been there since the beginning, and the single >>> wiki mode can still be used. >> >> This isn't the plan as I mentioned in my previous emails. The plan is that >> the home page doesn't change. All that changes for a first time user >> installing XWiki is that the Add menu will have more entries (Add Workspace >> or Add Wiki or both, Caty is still working on the proposal). >> > > Proposals: > > * Changes to the Menu > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu

* "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right?

* "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: ** Administration. I don't even know what it means at the global portal/system level ** All documents. Currently we don't have a LT that displays all docs from all wikis ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed ** Note: Users index should list all global users * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

After more thoughts I think it's ok for a first version to have the new "Home" menu entry to represent the main wiki. However all subwikis menu entries should have the same entries except for "Wiki Index" which should only be in "Home".

In the future though, in the new model, we'll have a notion of System (farm of wikis) and maybe we'll implement it differently than in a wiki. But we can take care of this at that time… ;)

Right now the more important for me is to agree that we have only 1 concept: the notion of "Wiki" and to replace the notion of "Workspace" just by a checkbox in the wiki creation wizard: "Allow creating local users" (which is unchecked by default).

I've created the 'Option D' proposal

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

...

...

- used 'subwiki' term instead of 'wiki' - used 'users isolation' checkbox to replace the notion of workspace

Thanks, Caty

...

Note that we'll also need in 5.3+ a new right IMO: the right of

creating a

...

new wiki. For 5.2 we could just have a check in the wiki creation wizard page (for example on the user having Admin rights on the main wiki). If an Admin wants to change that to allow everyone to create a wiki he could edit that page and change the check.

WDYT?

Thanks -Vincent

...

* "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki

> * Wiki/Workspace Creation >

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

...

...

...

...

> (please chose between Option A, B or C)

Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only.

Thanks -Vincent

> Thanks, > Caty > > > >> >>> But this change in how XWiki is perceived has both advantages and >>> disadvantages. On one hand, it clearly shows users that XWiki is a >>> collaborative platform, not just a wiki, so people that need >>> collaboration more than just a wiki will be able to see that XWiki isn't >>> another boring wiki. On the other hand, people that are just looking for >>> a wiki that's nice to use and "not-ugly", might be put off by yet >>> another layer of complexity, and might drop XWiki from their list of >>> candidates. In other words, it alienates even more the kind of users >>> that already perceive XWiki as hard to use and overly complex. >>> >>> So, are we willing to trade one type of users for the other? It would be >>> in line with our vision of "enterprise collaboration", but I still think >>> we shouldn't voluntarily alienate any kind of users. >>> >>> An alternative is to wait for a real flavor, and then ask in the first >>> step of the distribution manager what kind of usage do we want. In the >>> meantime, we can still polish the pages that will go in the "workspaces" >>> flavor. >>> >>> So, -0 for switching to "workspaces only" in 5.2, unless we have really >>> good backwards compatibility and a flavor for a simple wiki for textual >>> collaboration. >> >> I hope the above allays your fears :) >> >> Thanks >> -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Jean Coury _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Mon, Aug 26, 2013 at 1:50 PM, Vincent Massol <[email protected]> wrote:

Hi Guillaume,

On Aug 26, 2013, at 12:30 PM, Guillaume Louis-Marie Delhumeau < [email protected]> wrote:

...

Hi developers!

I'm back from holidays. I have read all your messages this morning, and this is what I propose for the next 2 weeks (until M2):

(it is based on the proposal D from Caty:

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... )

...

* We use the term 'subwiki' instead of 'wiki'.

I'm not very sure of this. Although is very logical, it will produce lots of problems with the documentation and also with our way of referring to wikis. In theory I agree with it, I'm just worried :) I prefer 'wiki' instead of 'subwiki' and 'home' instead of 'wiki'. Although we are simplifying by removing workspace notion, we add another layer of confusion between subwikis vs. wikis.

...

* We add an option in the subwiki creation ui called 'users isolation', that enable local users for the new subwiki. * We add a new right called 'subwiki creation right'. * We add a new right called 'users isolation rights', which enable or not if the user has the right to use the 'users isolation' option while he is creating a new subwiki.

When I proposed D, 'users isolation' was the first thing that came to mind, but I guess can be confusing. I tried to read your proposal and every time I read 'User isolation right' I transformed it to 'Local users creation right', so maybe that's a better name and is on the same direction with the other one: * subwiki - creation right * local users - creation right 'Users isolation' can still be used as a label in the creation step. And having it just as a label will be also much more easy to rename it than adding it as a right name in our core. Regarding the 'creation right' suffix, should we replace it with 'manage right'? I mean right now we don't have a very fined grained palette of rights, but maybe in the future we will want to have 'create comment', 'edit comment', 'delete comment' rights. This mean we could also have something like 'create subwiki' and 'delete subwiki'. The 'subwiki manage right' would imply 'create+edit+delete'. I'm not sure if the namings are good, but since we are starting to add new rights, maybe we should define a naming standard for them.

...

* We drop the notion of 'workspaces' and 'farm', since you can have the same behaviour with the good set of settings.

Now, I quote Guillaume Lerouge who has explained several use cases, and I'll say how to handle it with this proposal:

1. *Large organization where various groups want to have independent wikis for their knowledge bases:* no local users, wiki creation restricted to admins to avoid duplication of KBs --> SOLUTION: 'subwiki creation right' only given to admins, 'user isolation rights' given to nobody.

2. *"Pure" wiki farm as on myxwiki.org:* you only want admins to be able to create new wikis to prevent spam. Each wiki has its local users. --> SOLUTION: 'subwiki creation right' only given to admins, 'user isolation rights' given to admin too. Each time a new subwiki is created, the admin select the option 'users isolation'.

3. *Large organization where people want to work on projects with sub-contractors (some wikis act as an extranet):* local users allowed, anyone can create a wiki --> SOLUTION: 'subwiki creation right' given to all users, 'user isolation rights' given to all users.

4. *Company where people want to work on internal projects:* local users not allowed, anyone can create a wiki --> SOLUTION: 'subwiki creation right' given to all users, 'user isolation rights' given to nobody.

As you can see, all the well-knowned use cases are handled by my proposal. I would like to to say if you agree with it. We only have 2 weeks to achieve this, and I work only 4 days a week.

WDYT?

I'm +1 to this proposal, with the 'wiki' and 'local users creation right' rename observations

All sounds good to me, it covers all use cases I know too.

Just a minor detail: when you say above "given to all users", this can be replaced by "given to users of a specific group" in some cases.

The only issue I can see is the addition of 2 new rights in the current Rights UI for 5.2 final. How do you envision this?

I guess there are 4 quick solutions (that do not entail a full Rights UI rewrite): A - allow horizontal scrolling to see all rights. While this is not perfect from a UI POV at least it allows us to progress and improve the Rights UI in the near future. B - modify a bit the Rights UI but without a full rewrite (for example by putting the rights in a select box and the users selects the right to display). Again this would be a quick fix while waiting for the full Rights UI rewrite. C - add a SubWiki Admin section in the Admin page and put those 2 new rights in there FTM. When we do the Rights UI rewrite, we can then move them there (or not). D - have 2 special pages with a Rights Object attached to them to represent the who's allowed to add a subwiki and use users isolation and have the subwiki creation wizard use thoses pages. This would be while waiting for the new Rights UI rewrite and/or the addition of those 2 new rights.

My preference goes to either A, C or D. I think C might be the best one even on the longer term since it clearly creates a section proper for subwiki administration.

WDYT?

My preference goes to A or C. My first reaction was clearly A, but then I've seen what long names the new rights have :) We surely need to remake the Rights UI, but this is not a priority this release. I will go with option C because the 2 new rights are related mostly to the main wiki, will be changed by a very selected hand of people (so they are not 'global interest' rights, so doesn't make sense to affect all the rights tables) and I think is much more easy to implement this way (by adding a new Administration category). The downside is that we split related functionality. The new Rights UI need to consider the scalability aspect. Thanks, Caty

Thanks -Vincent

...

Regards,

Louis-Marie

2013/8/2 Jean Coury <[email protected]>

...

Hello,

Firstly I couldn't read everything because there is a lot of off topics so forgive me if some of the following should not be here. If you have no time go the last line directly.

I've been struggling with client with all those terms wich look like the same (e.g. Main wiki, sub-wiki and then Workspace, Space) and the fact that Workspace have "Work" into it and so is not really friendly to the client's users. My first proposal would have been "Portal > Wiki > Space > Page" in order to keep the basics and to find an easy way to describe the main wiki. Then I read multiple threads and have a look to the competitors and find-out that Home as a first term would be great and less technical than Portal. Moreover Portal is full of connotations and do not show the possibility to customize it.

"There is no place like Home" don't you think? Proposal : Home > Wiki > Space > Page

Then I looked at the proposal made by Cathy on

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

I would have picked B but I strongly dislike the fact that the product can be two things at a time and so* => I vote for* *D*.

Regards,

2013/8/1 Guillaume "Louis-Marie" Delhumeau <[email protected]>

...

I vote for D (not B anymore).

2013/8/1 Guillaume Lerouge <[email protected]>

...

Hi,

I like this option. Waiting for further agreement on the sister thread about workspaces, I think this is a good solution for XE 5.2.

The downside is that we lose a bit of simplicity, but it's a tough topic.

Guillaume

On Wed, Jul 31, 2013 at 4:31 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Tue, Jul 30, 2013 at 5:22 PM, Vincent Massol <[email protected]> wrote:

> > On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]> wrote: > >> Hi Caty, >> >> See below. >> >> On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: >> >>> On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol < [email protected]> > wrote: >>> >>>> >>>> On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu < [email protected]> > wrote: >>>> >>>>> On 07/20/2013 07:33 AM, Vincent Massol wrote: >>>>>> Hi devs, >>>>>> >>>>>> In the Roadmap proposal I've sent for XWiki 5.2 some days ago, > there's >>>> this time: >>>>>> >>>>>> " >>>>>> * Have Workspace by default in XE + improved home page - Caty + >>>> Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's > going to >>>> work full time on XWiki development and especially on UI aspects from > now >>>> on. Welcome aboard Guillaume, we need you! :) >>>>>> " >>>>>> >>>>>> Denis told me he didn't know about the proposal of having Workspaces >>>> integrated in the default XAR. Thus I'm sending this email to ensure > we all >>>> agree about this. >>>>>> >>>>>> The rationale is: >>>>>> >>>>>> * It would be nice that when our users download XWiki (standalone >>>> version or install the default XAR) they get to see the power of > XWiki. One >>>> of the very important differentiator of XWiki vs other wikis/solutions > is >>>> our multi-tenancy feature and most of people downloading and installing >>>> XWiki don't see it. >>>>>> >>>>>> * XEM/Wiki Manager are lacking polishing because the committers > mostly >>>> polish the default which doesn't include those. The UIs of XEM/Wiki > Manager >>>> need polishing. Having them in default will ensure that we take them > into >>>> account and make them first class citizens when we develop. >>>>>> >>>>>> Caty started working on the home page/UI improvements required to >>>> integrate this by default: >>>>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki >>>>>> >>>>>> Here's my +1 >>>>>> >>>>> >>>>> This is a major shift in how first-time users perceive XWiki. Without >>>>> multi-wiki features, it still looks like a wiki, but if the homepage >>>>> changes from a "welcome to your wiki" page to a "here are your >>>>> workspaces" portal, then suddenly XWiki "becomes" something else in > the >>>>> eyes of our users. I used quotes since nothing changes on the inside, >>>>> the multiwiki feature has been there since the beginning, and the > single >>>>> wiki mode can still be used. >>>> >>>> This isn't the plan as I mentioned in my previous emails. The plan is > that >>>> the home page doesn't change. All that changes for a first time user >>>> installing XWiki is that the Add menu will have more entries (Add > Workspace >>>> or Add Wiki or both, Caty is still working on the proposal). >>>> >>> >>> Proposals: >>> >>> * Changes to the Menu >>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu >> >> * "Add menu". I think you forgot to update the 3rd screenshots which the > colibri skin, right? >> >> * "Home Menu". For 5.2 I don't think we should have the following since > we don't have any UI for them: >> ** Administration. I don't even know what it means at the global > portal/system level >> ** All documents. Currently we don't have a LT that displays all docs > from all wikis >> ** Applications Index. I don't see what you would do in this one. > Listing all apps for all wikis for quick navigation? Not sure it's needed >> ** Note: Users index should list all global users >> * I don't like very much "Home" as the menu name since that represents a > single wiki (the main wiki). We already have a menu entry to represent the > current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, > i.e. something that represents the whole system and have only system-wide > actions in it. > > After more thoughts I think it's ok for a first version to have the new > "Home" menu entry to represent the main wiki. However all subwikis menu > entries should have the same entries except for "Wiki Index" which should > only be in "Home". > > In the future though, in the new model, we'll have a notion of System > (farm of wikis) and maybe we'll implement it differently than in a wiki. > But we can take care of this at that time… ;) > > Right now the more important for me is to agree that we have only 1 > concept: the notion of "Wiki" and to replace the notion of "Workspace" just > by a checkbox in the wiki creation wizard: > "Allow creating local users" (which is unchecked by default). >

I've created the 'Option D' proposal

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

...

...

...

- used 'subwiki' term instead of 'wiki' - used 'users isolation' checkbox to replace the notion of workspace

Thanks, Caty

> > Note that we'll also need in 5.3+ a new right IMO: the right of creating a > new wiki. For 5.2 we could just have a check in the wiki creation wizard > page (for example on the user having Admin rights on the main wiki). If an > Admin wants to change that to allow everyone to create a wiki he could edit > that page and change the check. > > WDYT? > > Thanks > -Vincent > >> * "Wiki Menu". Should be the same as now + Users Index for listing all > local users of the current wiki + Application Index for all apps of the > current wiki, i.e. all actions that you can do on the current wiki >> >>> * Wiki/Workspace Creation >>> >

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

...

...

...

>>> (please chose between Option A, B or C) >> >> Definitely +1 for B. I really think we need to drop the concept of > workspaces and come back to the concept of wiki/subwiki. It's much simpler > for the user. What we call "workspace" can be seen as a configuration for a > wiki, i.e. the usage of global users only. >> >> Thanks >> -Vincent >> >>> Thanks, >>> Caty >>> >>> >>> >>>> >>>>> But this change in how XWiki is perceived has both advantages and >>>>> disadvantages. On one hand, it clearly shows users that XWiki is a >>>>> collaborative platform, not just a wiki, so people that need >>>>> collaboration more than just a wiki will be able to see that XWiki > isn't >>>>> another boring wiki. On the other hand, people that are just looking > for >>>>> a wiki that's nice to use and "not-ugly", might be put off by yet >>>>> another layer of complexity, and might drop XWiki from their list of >>>>> candidates. In other words, it alienates even more the kind of users >>>>> that already perceive XWiki as hard to use and overly complex. >>>>> >>>>> So, are we willing to trade one type of users for the other? It would > be >>>>> in line with our vision of "enterprise collaboration", but I still > think >>>>> we shouldn't voluntarily alienate any kind of users. >>>>> >>>>> An alternative is to wait for a real flavor, and then ask in the first >>>>> step of the distribution manager what kind of usage do we want. In the >>>>> meantime, we can still polish the pages that will go in the > "workspaces" >>>>> flavor. >>>>> >>>>> So, -0 for switching to "workspaces only" in 5.2, unless we have > really >>>>> good backwards compatibility and a flavor for a simple wiki for > textual >>>>> collaboration. >>>> >>>> I hope the above allays your fears :) >>>> >>>> Thanks >>>> -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Guillaume, On Aug 26, 2013, at 12:30 PM, Guillaume Louis-Marie Delhumeau <[email protected]> wrote:

Hi developers!

I'm back from holidays. I have read all your messages this morning, and this is what I propose for the next 2 weeks (until M2):

(it is based on the proposal D from Caty: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...)

* We use the term 'subwiki' instead of 'wiki'. * We add an option in the subwiki creation ui called 'users isolation', that enable local users for the new subwiki. * We add a new right called 'subwiki creation right'. * We add a new right called 'users isolation rights', which enable or not if the user has the right to use the 'users isolation' option while he is creating a new subwiki. * We drop the notion of 'workspaces' and 'farm', since you can have the same behaviour with the good set of settings.

Now, I quote Guillaume Lerouge who has explained several use cases, and I'll say how to handle it with this proposal:

1. *Large organization where various groups want to have independent wikis for their knowledge bases:* no local users, wiki creation restricted to admins to avoid duplication of KBs --> SOLUTION: 'subwiki creation right' only given to admins, 'user isolation rights' given to nobody.

2. *"Pure" wiki farm as on myxwiki.org:* you only want admins to be able to create new wikis to prevent spam. Each wiki has its local users. --> SOLUTION: 'subwiki creation right' only given to admins, 'user isolation rights' given to admin too. Each time a new subwiki is created, the admin select the option 'users isolation'.

3. *Large organization where people want to work on projects with sub-contractors (some wikis act as an extranet):* local users allowed, anyone can create a wiki --> SOLUTION: 'subwiki creation right' given to all users, 'user isolation rights' given to all users.

4. *Company where people want to work on internal projects:* local users not allowed, anyone can create a wiki --> SOLUTION: 'subwiki creation right' given to all users, 'user isolation rights' given to nobody.

As you can see, all the well-knowned use cases are handled by my proposal. I would like to to say if you agree with it. We only have 2 weeks to achieve this, and I work only 4 days a week.

WDYT?

All sounds good to me, it covers all use cases I know too. Just a minor detail: when you say above "given to all users", this can be replaced by "given to users of a specific group" in some cases. The only issue I can see is the addition of 2 new rights in the current Rights UI for 5.2 final. How do you envision this? I guess there are 4 quick solutions (that do not entail a full Rights UI rewrite): A - allow horizontal scrolling to see all rights. While this is not perfect from a UI POV at least it allows us to progress and improve the Rights UI in the near future. B - modify a bit the Rights UI but without a full rewrite (for example by putting the rights in a select box and the users selects the right to display). Again this would be a quick fix while waiting for the full Rights UI rewrite. C - add a SubWiki Admin section in the Admin page and put those 2 new rights in there FTM. When we do the Rights UI rewrite, we can then move them there (or not). D - have 2 special pages with a Rights Object attached to them to represent the who's allowed to add a subwiki and use users isolation and have the subwiki creation wizard use thoses pages. This would be while waiting for the new Rights UI rewrite and/or the addition of those 2 new rights. My preference goes to either A, C or D. I think C might be the best one even on the longer term since it clearly creates a section proper for subwiki administration. WDYT? Thanks -Vincent

Regards,

Louis-Marie

2013/8/2 Jean Coury <[email protected]>

...

Hello,

Firstly I couldn't read everything because there is a lot of off topics so forgive me if some of the following should not be here. If you have no time go the last line directly.

I've been struggling with client with all those terms wich look like the same (e.g. Main wiki, sub-wiki and then Workspace, Space) and the fact that Workspace have "Work" into it and so is not really friendly to the client's users. My first proposal would have been "Portal > Wiki > Space > Page" in order to keep the basics and to find an easy way to describe the main wiki. Then I read multiple threads and have a look to the competitors and find-out that Home as a first term would be great and less technical than Portal. Moreover Portal is full of connotations and do not show the possibility to customize it.

"There is no place like Home" don't you think? Proposal : Home > Wiki > Space > Page

Then I looked at the proposal made by Cathy on

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme... I would have picked B but I strongly dislike the fact that the product can be two things at a time and so* => I vote for* *D*.

Regards,

2013/8/1 Guillaume "Louis-Marie" Delhumeau <[email protected]>

...

I vote for D (not B anymore).

2013/8/1 Guillaume Lerouge <[email protected]>

...

Hi,

I like this option. Waiting for further agreement on the sister thread about workspaces, I think this is a good solution for XE 5.2.

The downside is that we lose a bit of simplicity, but it's a tough topic.

Guillaume

On Wed, Jul 31, 2013 at 4:31 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Tue, Jul 30, 2013 at 5:22 PM, Vincent Massol <[email protected]> wrote:

...

On Jul 30, 2013, at 1:26 PM, Vincent Massol <[email protected]>

wrote:

...

> Hi Caty, > > See below. > > On Jul 30, 2013, at 1:10 PM, Ecaterina Moraru (Valica) < [email protected]> wrote: > >> On Mon, Jul 22, 2013 at 10:24 PM, Vincent Massol <

[email protected]>

...

wrote: >> >>> >>> On Jul 22, 2013, at 10:16 PM, Sergiu Dumitriu < [email protected]> wrote: >>> >>>> On 07/20/2013 07:33 AM, Vincent Massol wrote: >>>>> Hi devs, >>>>> >>>>> In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's >>> this time: >>>>> >>>>> " >>>>> * Have Workspace by default in XE + improved home page - Caty + >>> Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to >>> work full time on XWiki development and especially on UI aspects from now >>> on. Welcome aboard Guillaume, we need you! :) >>>>> " >>>>> >>>>> Denis told me he didn't know about the proposal of having Workspaces >>> integrated in the default XAR. Thus I'm sending this email to ensure we all >>> agree about this. >>>>> >>>>> The rationale is: >>>>> >>>>> * It would be nice that when our users download XWiki (standalone >>> version or install the default XAR) they get to see the power of XWiki. One >>> of the very important differentiator of XWiki vs other wikis/solutions is >>> our multi-tenancy feature and most of people downloading and installing >>> XWiki don't see it. >>>>> >>>>> * XEM/Wiki Manager are lacking polishing because the committers mostly >>> polish the default which doesn't include those. The UIs of XEM/Wiki Manager >>> need polishing. Having them in default will ensure that we take them into >>> account and make them first class citizens when we develop. >>>>> >>>>> Caty started working on the home page/UI improvements required to >>> integrate this by default: >>>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki >>>>> >>>>> Here's my +1 >>>>> >>>> >>>> This is a major shift in how first-time users perceive XWiki. Without >>>> multi-wiki features, it still looks like a wiki, but if the homepage >>>> changes from a "welcome to your wiki" page to a "here are your >>>> workspaces" portal, then suddenly XWiki "becomes" something else in the >>>> eyes of our users. I used quotes since nothing changes on the inside, >>>> the multiwiki feature has been there since the beginning, and the single >>>> wiki mode can still be used. >>> >>> This isn't the plan as I mentioned in my previous emails. The plan is that >>> the home page doesn't change. All that changes for a first time user >>> installing XWiki is that the Add menu will have more entries (Add Workspace >>> or Add Wiki or both, Caty is still working on the proposal). >>> >> >> Proposals: >> >> * Changes to the Menu >> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/HomeMenu > > * "Add menu". I think you forgot to update the 3rd screenshots which the colibri skin, right? > > * "Home Menu". For 5.2 I don't think we should have the following since we don't have any UI for them: > ** Administration. I don't even know what it means at the global portal/system level > ** All documents. Currently we don't have a LT that displays all docs from all wikis > ** Applications Index. I don't see what you would do in this one. Listing all apps for all wikis for quick navigation? Not sure it's needed > ** Note: Users index should list all global users > * I don't like very much "Home" as the menu name since that represents a single wiki (the main wiki). We already have a menu entry to represent the current wiki. I'd prefer to have a "System" or "Portal" or "Farm" or …, i.e. something that represents the whole system and have only system-wide actions in it.

After more thoughts I think it's ok for a first version to have the new "Home" menu entry to represent the main wiki. However all subwikis menu entries should have the same entries except for "Wiki Index" which should only be in "Home".

In the future though, in the new model, we'll have a notion of System (farm of wikis) and maybe we'll implement it differently than in a wiki. But we can take care of this at that time… ;)

Right now the more important for me is to agree that we have only 1 concept: the notion of "Wiki" and to replace the notion of "Workspace" just by a checkbox in the wiki creation wizard: "Allow creating local users" (which is unchecked by default).

I've created the 'Option D' proposal

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

...

...

- used 'subwiki' term instead of 'wiki' - used 'users isolation' checkbox to replace the notion of workspace

Thanks, Caty

...

Note that we'll also need in 5.3+ a new right IMO: the right of

creating a

...

new wiki. For 5.2 we could just have a check in the wiki creation wizard page (for example on the user having Admin rights on the main wiki). If an Admin wants to change that to allow everyone to create a wiki he could edit that page and change the check.

WDYT?

Thanks -Vincent

> * "Wiki Menu". Should be the same as now + Users Index for listing all local users of the current wiki + Application Index for all apps of the current wiki, i.e. all actions that you can do on the current wiki > >> * Wiki/Workspace Creation >>

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImproveme...

...

...

...

...

>> (please chose between Option A, B or C) > > Definitely +1 for B. I really think we need to drop the concept of workspaces and come back to the concept of wiki/subwiki. It's much simpler for the user. What we call "workspace" can be seen as a configuration for a wiki, i.e. the usage of global users only. > > Thanks > -Vincent > >> Thanks, >> Caty >> >> >> >>> >>>> But this change in how XWiki is perceived has both advantages and >>>> disadvantages. On one hand, it clearly shows users that XWiki is a >>>> collaborative platform, not just a wiki, so people that need >>>> collaboration more than just a wiki will be able to see that XWiki isn't >>>> another boring wiki. On the other hand, people that are just looking for >>>> a wiki that's nice to use and "not-ugly", might be put off by yet >>>> another layer of complexity, and might drop XWiki from their list of >>>> candidates. In other words, it alienates even more the kind of users >>>> that already perceive XWiki as hard to use and overly complex. >>>> >>>> So, are we willing to trade one type of users for the other? It would be >>>> in line with our vision of "enterprise collaboration", but I still think >>>> we shouldn't voluntarily alienate any kind of users. >>>> >>>> An alternative is to wait for a real flavor, and then ask in the first >>>> step of the distribution manager what kind of usage do we want. In the >>>> meantime, we can still polish the pages that will go in the "workspaces" >>>> flavor. >>>> >>>> So, -0 for switching to "workspaces only" in 5.2, unless we have really >>>> good backwards compatibility and a flavor for a simple wiki for textual >>>> collaboration. >>> >>> I hope the above allays your fears :) >>> >>> Thanks >>> -Vincent