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 (
). 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
<jeremie.bousquet(a)gmail.com> wrote:
Hello all,
2013/7/31 Sergiu Dumitriu <sergiu(a)xwiki.com>
On 07/30/2013 05:32 PM, Vincent Massol wrote:
Hi Sergiu,
On Jul 30, 2013, at 6:47 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> 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 <enygma2002(a)gmail.com>
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 <vincent(a)massol.net>
wrote:
>>>
>>>>
>>>> On Jul 30, 2013, at 4:15 PM, Sergiu Dumitriu <sergiu(a)xwiki.com>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs