Comparisons to Confluence (was Minimalist MediaWiki? (was Re: Merge Vector extension into core))

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Comparisons to Confluence (was Minimalist MediaWiki? (was Re: Merge Vector extension into core))

David Gerard-2
On 6 February 2013 23:58, Tim Starling <[hidden email]> wrote:

> I think we can turn MediaWiki into a fully featured wiki engine which
> can compete with the likes of Confluence. I don't think it can ever
> compete with TiddlyWiki or UseModWiki in their respective niches.


(veering slightly off topic)

What in Confluence are you thinking of MediaWiki as lacking?

The main two in my experience are (1) firm access control (2) WYSIWYG
editor. (1) is just not something MW can promise to do securely unless
pretty much every developer cared and (2) is on the way (certainly
before the end of time). Any others of importance?

[ps: Confluence is horrible and its hardware requirements do in fact
make MediaWiki look lightweight.]


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Comparisons to Confluence (was Minimalist MediaWiki? (was Re: Merge Vector extension into core))

Tim Starling-2
On 07/02/13 11:05, David Gerard wrote:
> What in Confluence are you thinking of MediaWiki as lacking?
>
> The main two in my experience are (1) firm access control (2) WYSIWYG
> editor. (1) is just not something MW can promise to do securely unless
> pretty much every developer cared and (2) is on the way (certainly
> before the end of time). Any others of importance?

MediaWiki has internal interfaces which support fine-grained write
permissions right down to the level of individual pages edited by
individual users. Consider how fine-grained AbuseFilter is, for
example. These interfaces are old and are used by everything. So for
write permissions, any ACL model you can think of can be slapped on
top as an extension and will be robust.

For read permissions, the options are coarser, but whitelist read
wikis are reasonably secure, even in the presence of naively written
extensions, since the usual entry points (API, RL, action=ajax,
special pages) are restricted by default.

Wikimedia uses whitelist-read wikis for all sorts of sensitive data.
The usual approach is to separate private data with different
audiences into different wikis. That would be more feasible for small
sites if multi-wiki installation and management was easier.

So I don't think the situation with access control is as bad as people
make out.

For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation
with people who will care if corporate users are screwed over by a
change. It needs community management, so that the features needed by
corporate users will be discoverable and well-maintained, rather than
developed privately, over and over. And it needs the smallest nudge of
promotion, on top of what Wikipedia fans are doing for it. Say, a
nice-looking website aimed at this user base.

This is not something WMF is interested in doing, that has been made
extremely clear in the last year.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Comparisons to Confluence (was Minimalist MediaWiki? (was Re: Merge Vector extension into core))

Jeroen De Dauw-2
Hey,

For corporate adoption, the main thing MediaWiki needs is not some

> particular feature. It needs to be supported. It needs an organisation
> with people who will care if corporate users are screwed over by a
> change. It needs community management, so that the features needed by
> corporate users will be discoverable and well-maintained, rather than
> developed privately, over and over. And it needs the smallest nudge of
> promotion, on top of what Wikipedia fans are doing for it. Say, a
> nice-looking website aimed at this user base.
>
> This is not something WMF is interested in doing, that has been made
> extremely clear in the last year.
>

Agree, I also think this is the main issue, and know other people active
with MW outside WMF think the same.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

Mark A. Hershberger-2
In reply to this post by Tim Starling-2
(Added MW-Enterprise mailing list)

On 02/06/2013 10:00 PM, Tim Starling wrote:
> For corporate adoption, the main thing MediaWiki needs is not some
> particular feature. It needs to be supported. It needs an organisation
> with people who will care if corporate users are screwed over by a
> change. It needs community management, so that the features needed by
> corporate users will be discoverable and well-maintained, rather than
> developed privately, over and over. And it needs the smallest nudge of
> promotion, on top of what Wikipedia fans are doing for it. Say, a
> nice-looking website aimed at this user base.

Totally agreed.

I (along with a few other hardy volunteers) have been helping MW users
at [[mw:Project:Support desk]] and it seems clear that the focus most
developers have on the WMF use case has really made MW less usable for
other people.

One of my clients had an older (1.11) MediaWiki installation that they
are using to share information with their distributors world-wide.
Their first attempt to get the system to do what they wanted was a flop
since the Java developer they had working on the system really didn't
know that much about MW.  I was able to get the system upgraded to 1.19
and adapt MW to their infrastructure using hooks, ResourceLoader, and
pages they could update in the "MediaWiki" namespace.

So, yes, I think MediaWiki has a lot to offer corporate users, but we
haven't really made that clear or shown them how to do a lot of things
they want to do.

Tim has it right when he says MediaWiki "needs community management, so
that the features needed by corporate users will be discoverable and
well-maintained, rather than developed privately, over and over."

We've discussed this sort of thing over and over, but I think we're
actually beginning to make some headway now thanks especially to work by
Mariya Miteva.


--
http://hexmode.com/

There is no path to peace. Peace is the path.
   -- Mahatma Gandhi, "Non-Violence in Peace and War"

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

Dan Andreescu
On 02/06/2013 10:00 PM, Tim Starling wrote:

> > For corporate adoption, the main thing MediaWiki needs is not some
> > particular feature. It needs to be supported. It needs an organisation
> > with people who will care if corporate users are screwed over by a
> > change. It needs community management, so that the features needed by
> > corporate users will be discoverable and well-maintained, rather than
> > developed privately, over and over. And it needs the smallest nudge of
> > promotion, on top of what Wikipedia fans are doing for it. Say, a
> > nice-looking website aimed at this user base.
>

I was on the other side of this, albeit a while back.  We had to decide
between MediaWiki and Confluence to power Disney's ParentPedia:
The main reason we chose Confluence was lack of


> Totally agreed.
>
> I (along with a few other hardy volunteers) have been helping MW users
> at [[mw:Project:Support desk]] and it seems clear that the focus most
> developers have on the WMF use case has really made MW less usable for
> other people.
>
> One of my clients had an older (1.11) MediaWiki installation that they
> are using to share information with their distributors world-wide.
> Their first attempt to get the system to do what they wanted was a flop
> since the Java developer they had working on the system really didn't
> know that much about MW.  I was able to get the system upgraded to 1.19
> and adapt MW to their infrastructure using hooks, ResourceLoader, and
> pages they could update in the "MediaWiki" namespace.
>
> So, yes, I think MediaWiki has a lot to offer corporate users, but we
> haven't really made that clear or shown them how to do a lot of things
> they want to do.
>
> Tim has it right when he says MediaWiki "needs community management, so
> that the features needed by corporate users will be discoverable and
> well-maintained, rather than developed privately, over and over."
>
> We've discussed this sort of thing over and over, but I think we're
> actually beginning to make some headway now thanks especially to work by
> Mariya Miteva.
>
>
> --
> http://hexmode.com/
>
> There is no path to peace. Peace is the path.
>    -- Mahatma Gandhi, "Non-Violence in Peace and War"
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

Dan Andreescu
Sorry about that - Gmail reload glitch

On 02/06/2013 10:00 PM, Tim Starling wrote:

> > For corporate adoption, the main thing MediaWiki needs is not some
>> > particular feature. It needs to be supported. It needs an organisation
>> > with people who will care if corporate users are screwed over by a
>> > change. It needs community management, so that the features needed by
>> > corporate users will be discoverable and well-maintained, rather than
>> > developed privately, over and over. And it needs the smallest nudge of
>> > promotion, on top of what Wikipedia fans are doing for it. Say, a
>> > nice-looking website aimed at this user base.
>
>
I was on the other side of this, albeit a while back.  We had to decide
between MediaWiki and Confluence to power Disney's ParentPedia (which has
since been abandoned):

http://www.theregister.co.uk/2007/03/13/disney_eisner/
http://family.go.com/parenting/

The main reasons we chose Confluence:

* An easier to understand API.  This seems to not be a problem any more:
http://www.mediawiki.org/wiki/API:Client_code
* Easier setup on Windows:
http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly
made easier now by Bitnami: http://bitnami.org/stack/mediawiki

Do we have a place where people can talk through problems with corporate
adoption?  I suspect Tim's correct about the general case but that focusing
on specifics would drive adoption.

Dan
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

Maria Miteva
Hi Dan,

We have
http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion where
we've been discussing some MW user issues, but the dicussion was not
focused on corporate per se. We can use the same page or maybe set up a
subpage if you think it will be easier. There is also
https://www.mediawiki.org/wiki/Enterprise_hub. If anyone know of another
appropriate place, please share.

I would be glad to see such a space set up and discussion going on and
would be happy to assist with that.

Mariya

On Thu, Feb 7, 2013 at 7:06 PM, Dan Andreescu <[hidden email]>wrote:

> Sorry about that - Gmail reload glitch
>
> On 02/06/2013 10:00 PM, Tim Starling wrote:
>
> > > For corporate adoption, the main thing MediaWiki needs is not some
> >> > particular feature. It needs to be supported. It needs an organisation
> >> > with people who will care if corporate users are screwed over by a
> >> > change. It needs community management, so that the features needed by
> >> > corporate users will be discoverable and well-maintained, rather than
> >> > developed privately, over and over. And it needs the smallest nudge of
> >> > promotion, on top of what Wikipedia fans are doing for it. Say, a
> >> > nice-looking website aimed at this user base.
> >
> >
> I was on the other side of this, albeit a while back.  We had to decide
> between MediaWiki and Confluence to power Disney's ParentPedia (which has
> since been abandoned):
>
> http://www.theregister.co.uk/2007/03/13/disney_eisner/
> http://family.go.com/parenting/
>
> The main reasons we chose Confluence:
>
> * An easier to understand API.  This seems to not be a problem any more:
> http://www.mediawiki.org/wiki/API:Client_code
> * Easier setup on Windows:
> http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows,
> possibly
> made easier now by Bitnami: http://bitnami.org/stack/mediawiki
>
> Do we have a place where people can talk through problems with corporate
> adoption?  I suspect Tim's correct about the general case but that focusing
> on specifics would drive adoption.
>
> Dan
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

David Gerard-2
In reply to this post by Dan Andreescu
On 7 February 2013 17:06, Dan Andreescu <[hidden email]> wrote:

> I was on the other side of this, albeit a while back.  We had to decide
> between MediaWiki and Confluence to power Disney's ParentPedia (which has
> since been abandoned):
> The main reasons we chose Confluence:
> * An easier to understand API.  This seems to not be a problem any more:
> http://www.mediawiki.org/wiki/API:Client_code
> * Easier setup on Windows:
> http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly
> made easier now by Bitnami: http://bitnami.org/stack/mediawiki


yeah, I was speaking from my experience of MW vs Confluence, where the
deciders were (1) no WYSIWYG and slightly (2) none of the fancy ACL
stuff Confluence has. The ACLs were more a theoretical selling point
to the business decision maker, but WYSIWYG swung it I think. And the
users *hated* Confluence, but at least they didn't have to deal with
Wikitext.

(In my current job I'm happily spreading MediaWikis far and wide,
albeit with very little customisation. But I'm really keen to use the
Visual Editor as soon as it's in a tarball version.)


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OQ
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

OQ
On Thu, Feb 7, 2013 at 11:45 AM, David Gerard <[hidden email]> wrote:
> (In my current job I'm happily spreading MediaWikis far and wide,
> albeit with very little customisation. But I'm really keen to use the
> Visual Editor as soon as it's in a tarball version.)

Yes, that is the prime reason we're still on 1.17 at work, it's the
most recent version the FCKEditor extension works on. Soon as there's
something equivalent for current versions they *might* consider
upgrading.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

Thomas Gries

> Yes, that is the prime reason we're still on 1.17 at work, it's the
most recent version the FCKEditor extension works on.


@Admins who use FCKEditor:
please be reminded that be reminded, that FCKEditor has severe security
issues.




_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OQ
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

OQ
On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries <[hidden email]> wrote:
> @Admins who use FCKEditor:
> please be reminded that be reminded, that FCKEditor has severe security
> issues.

Yes, but as I mentioned until there is a suitable replacement, your
choices are: run an insecure wiki, not use mediawiki.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

Thomas Gries
Am 07.02.2013 21:46, schrieb OQ:
> On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries <[hidden email]> wrote:
>> @Admins who use FCKEditor:
>> please be reminded that be reminded, that FCKEditor has severe security
>> issues.
> Yes, but as I mentioned until there is a suitable replacement, your
> choices are: run an insecure wiki, not use mediawiki.
Use mediawiki, but do not use FCKEditor.
see
http://www.cvedetails.com/vulnerability-list/vendor_id-2724/Fckeditor.html
Multiple directory traversal vulnerabilities in FCKeditor before 2.6.4.1
allow remote attackers to create executable files in arbitrary
directories via directory traversal sequences in the input to
unspecified connector modules, as exploited in the wild for remote code
execution in July 2009, related to the file browser and the
editor/filemanager/connectors/ directory.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Corporate needs are different (RE: How can we help Corporations use MW?)

Daniel Barrett-3
In reply to this post by Mark A. Hershberger-2
Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system internally. 150,000+ topics, 1000+ active users across several continents, five years of history, and a fully supported team of developers to create extensions. (We are looking into open-sourcing some of them.)

The main requests from our corporate users are:

0. WYSIWIG editor. No surprise here.

1. A desire for a department to have "their own space" on the wiki. I'm not talking about access control, but (1) customized look & feel, and (2) ability to narrow searches to find articles only within that space.  The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax "NamespaceName:SearchString".  However, this is not a pleasant solution, because it's cumbersome to precede every article title with "NamespaceName: " when you create, link, and search.

If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level).  I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc.

Some way to search within categories reliably would also be a huge win.  Lucene provides "incategory:" but it misses all articles with transcluded category tags.

2. Hierarchy. Departments want not only "their own space," they want "subspaces" beneath it. For example, "Human Resources" wiki area with sub-areas of Payroll, Benefits, and Recruiting.  I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet.  MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it "goes" since the main namespace is flat.

I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it?

3. Tools for organizing large groups of articles. Categories and namespaces are great, and the DPL extension helps a lot. But when (say) the Legal department creates 700 articles that all begin with the words "Legal department" (e.g., "Legal department policies", "Legal department meeting 2012-07-01", "Legal department lunch", etc.), suddenly the AJAX auto-suggest search box becomes a real pain for finding Legal department articles. This is SO COMMON in a corporate environment with many departments, as people try to game the search box by titling all their articles with "Legal department"... until suddenly it doesn't scale and they're stuck. I'd like to see tools for easily retitling and recategorizing large numbers of articles at once.

4. Integration with popular corporate tools like MS Office, MS Exchange, etc. We've spent thousands of hours doing this: for example, an extension that embeds an Excel spreadsheet in a wiki page (read-only, using a $10,000 commercial Excel-to-HTML translator as a back-end), and we're looking at embedding Exchange calendars in wiki pages next.

5. Corporate reorganizations and article titles. In any company, the names and relationships of departments change. What do you do when 10,000 wiki links refer to the old department name?  Sure, you can move the article "Finance department" to "Global Finance department" and let redirects handle the rest: now your links work. But they still have the old department name, and global search-and-replace is truly scary when wikitext might get altered by accident. Also, there's the category called "Finance department". You can't rename categories easily. I know you can do it with Pywikipedia, but it's slow and risky (e.g., Pywikipedia used to have a bug that killed <noinclude> tags around categories it changed). Categories should be fully first-class so renames are as simple as article title changes.

Hope this was insightful/educational...
DanB
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Corporate needs are different (RE: How can we help Corporations use MW?)

Tyler Romeo
I don't mind these discussions, but can we please stop changing the
subject, because it's changed three times and it makes it difficult to keep
track of.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Corporate needs are different (RE: How can we help Corporations use MW?)

Jay Ashworth-2
In reply to this post by Daniel Barrett-3
----- Original Message -----
> From: "Daniel Barrett" <[hidden email]>

> 1. A desire for a department to have "their own space" on the wiki.
> I'm not talking about access control, but (1) customized look & feel,
> and (2) ability to narrow searches to find articles only within that
> space. The closest related concept in MediaWiki is the namespace,
> which can have its own CSS styling, and you can search within a
> namespace using Lucene with the syntax "NamespaceName:SearchString".
> However, this is not a pleasant solution, because it's cumbersome to
> precede every article title with "NamespaceName: " when you create,
> link, and search.
>
> If the *concept* of namespaces could be decoupled from its title
> syntax, this would be a big win for us. So a namespace would be a
> first-class property of an article (like it is in the database), and
> not a prefix of the article title (at the UI level). I've been
> thinking about writing an extension that provides this kind of UI when
> creating articles, searching for them, linking, etc.
>
> Some way to search within categories reliably would also be a huge
> win. Lucene provides "incategory:" but it misses all articles with
> transcluded category tags.
>
> 2. Hierarchy. Departments want not only "their own space," they want
> "subspaces" beneath it. For example, "Human Resources" wiki area with
> sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence
> supports this... but we decided against Confluence because you have to
> choose an article's area when you create it (at least when we
> evaluated Confluence years ago). This is a mental barrier to creating
> an article, if you don't know where you want to put it yet. MediaWiki
> is so much better in this regard -- if you want an article, just make
> it, and don't worry where it "goes" since the main namespace is flat.
>
> I've been thinking about writing an extension that superimposes a
> hierarchy on existing namespaces, and what the implications would be
> for the rest of the MediaWiki UI. It's an interesting problem. Anyone
> tried it?

What you want, I think, is what Zope2 called "acquisition".  It's like
OO subclass inheritance, but it's *geographic* depending on where you
were in the tree; the old Mac Frontier system did something like it
too.

You want links to have a Search Path, that starts with whatever part/
subpart of the tree the current page is in, and then climbs the tree,
ending in the unadorned Main namespace, whenever a user clicks them.

That breaks the semantics of wikilinks some, but that's probably ok
for your use.  It *might* be generally useful; I'm trying to figure out
if there are any obvious common use cases that it breaks, and how you
tell where in the tree a page lives when it's created (and how you
would show that to users).

Cheers,
-- jra
--
Jay R. Ashworth                  Baylink                       [hidden email]
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: How can we help Corporations use MW? (Was Re: Comparisons to Confluence)

Quim Gil-2
In reply to this post by Mark A. Hershberger-2
On 02/07/2013 08:17 AM, Mark A. Hershberger wrote:

> (Added MW-Enterprise mailing list)
>
> On 02/06/2013 10:00 PM, Tim Starling wrote:
>> For corporate adoption, the main thing MediaWiki needs is not some
>> particular feature. It needs to be supported. It needs an organisation
>> with people who will care if corporate users are screwed over by a
>> change. It needs community management, so that the features needed by
>> corporate users will be discoverable and well-maintained, rather than
>> developed privately, over and over. And it needs the smallest nudge of
>> promotion, on top of what Wikipedia fans are doing for it. Say, a
>> nice-looking website aimed at this user base.
>
> Totally agreed.
>
> I (along with a few other hardy volunteers) have been helping MW users
> at [[mw:Project:Support desk]] and it seems clear that the focus most
> developers have on the WMF use case has really made MW less usable for
> other people.
>
> One of my clients had an older (1.11) MediaWiki installation that they
> are using to share information with their distributors world-wide.
> Their first attempt to get the system to do what they wanted was a flop
> since the Java developer they had working on the system really didn't
> know that much about MW.  I was able to get the system upgraded to 1.19
> and adapt MW to their infrastructure using hooks, ResourceLoader, and
> pages they could update in the "MediaWiki" namespace.
>
> So, yes, I think MediaWiki has a lot to offer corporate users, but we
> haven't really made that clear or shown them how to do a lot of things
> they want to do.
>
> Tim has it right when he says MediaWiki "needs community management, so
> that the features needed by corporate users will be discoverable and
> well-maintained, rather than developed privately, over and over."
>
> We've discussed this sort of thing over and over, but I think we're
> actually beginning to make some headway now thanks especially to work by
> Mariya Miteva.

I'm really happy to read this! Mireya is doing this work because Sumana,
myself and other WMF employees thought it would be good to have an
internship (funded by the WMF as well) dedicated to sort out the
panorama of MediaWiki vendors.

https://www.mediawiki.org/wiki/Outreach_Program_for_Women

I have proposed the use of MediaWiki Groups as a tool for 3rd party
developers, consultants, MW users etc to get organized. Creating a group
officially recognized by the Wikimedia movement is easy, there is almost
no overhead and it would increase your chances of pushing your agenda.

https://www.mediawiki.org/wiki/Groups

If someone doesn't feel like being inside Wikimedia then s/he can jump
to these groups as a Trojan. From a tactical point of view it seems
reasonable to think that using the Wikipedia / Wikimedia inertia for
your own good is more efficient than trying to jump away or swim
against. Many 3rd parties consider MediaWiki because it is used by
Wikipedia. The Wikimedia movement at large can also understand that a
healthier MediaWiki 3rd party community helps having healthier software
for Wikimedia projects.

About the "nice-looking website aimed at this user base", what is
mediawiki.org missing? And, more broadly, what is this community
missing? Tim made very good points in the paragraph above. The next step
is to define the tasks / projects needed and find the resources for each.

I'm happy helping in all these areas, but (needless to say) they must be
driven by 3rd parties. Mariya will be working full time on "MediaWiki
vendors" 7-8 weeks more. It would be great to use as much of her time
and energies to build a minimum level of concretion and coordination. So
far many of you have done a great job helping her to help you.  :)

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Corporate needs are different (RE: How can we help Corporations use MW?)

planetenxin
In reply to this post by Daniel Barrett-3
Hi Dan,

thanks a lot for the insights to the vistaprint MediaWiki ecosystem.

Did you give Semantic MediaWiki a try?

/Alexander

Am 07.02.2013 22:31, schrieb Daniel Barrett:

> Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system internally. 150,000+ topics, 1000+ active users across several continents, five years of history, and a fully supported team of developers to create extensions. (We are looking into open-sourcing some of them.)
>
> The main requests from our corporate users are:
>
> 0. WYSIWIG editor. No surprise here.
>
> 1. A desire for a department to have "their own space" on the wiki. I'm not talking about access control, but (1) customized look&  feel, and (2) ability to narrow searches to find articles only within that space.  The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax "NamespaceName:SearchString".  However, this is not a pleasant solution, because it's cumbersome to precede every article title with "NamespaceName: " when you create, link, and search.
>
> If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level).  I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc.
>
> Some way to search within categories reliably would also be a huge win.  Lucene provides "incategory:" but it misses all articles with transcluded category tags.
>
> 2. Hierarchy. Departments want not only "their own space," they want "subspaces" beneath it. For example, "Human Resources" wiki area with sub-areas of Payroll, Benefits, and Recruiting.  I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet.  MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it "goes" since the main namespace is flat.
>
> I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it?
>
> 3. Tools for organizing large groups of articles. Categories and namespaces are great, and the DPL extension helps a lot. But when (say) the Legal department creates 700 articles that all begin with the words "Legal department" (e.g., "Legal department policies", "Legal department meeting 2012-07-01", "Legal department lunch", etc.), suddenly the AJAX auto-suggest search box becomes a real pain for finding Legal department articles. This is SO COMMON in a corporate environment with many departments, as people try to game the search box by titling all their articles with "Legal department"... until suddenly it doesn't scale and they're stuck. I'd like to see tools for easily retitling and recategorizing large numbers of articles at once.
>
> 4. Integration with popular corporate tools like MS Office, MS Exchange, etc. We've spent thousands of hours doing this: for example, an extension that embeds an Excel spreadsheet in a wiki page (read-only, using a $10,000 commercial Excel-to-HTML translator as a back-end), and we're looking at embedding Exchange calendars in wiki pages next.
>
> 5. Corporate reorganizations and article titles. In any company, the names and relationships of departments change. What do you do when 10,000 wiki links refer to the old department name?  Sure, you can move the article "Finance department" to "Global Finance department" and let redirects handle the rest: now your links work. But they still have the old department name, and global search-and-replace is truly scary when wikitext might get altered by accident. Also, there's the category called "Finance department". You can't rename categories easily. I know you can do it with Pywikipedia, but it's slow and risky (e.g., Pywikipedia used to have a bug that killed<noinclude>  tags around categories it changed). Categories should be fully first-class so renames are as simple as article title changes.
>
> Hope this was insightful/educational...
> DanB
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


--
________________________________________________
semantic::apps by gesinn.it
Business Applications with Semantic Mediawiki.
http://semantic-apps.com

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Corporate needs are different (RE: How can we help Corporations use MW?)

vitalif
In reply to this post by Daniel Barrett-3
> 1. A desire for a department to have "their own space" on the wiki.

In our organisation (CUSTIS, Russia) we easily solve it by creating one
primary wiki + separate ones for different departments.
It's just a normal wiki family with shared code.
Very simple solution without any extensions.
The main disadvantage is inability to search on all wikis with a single
search request, but in practice I've had very little requests for this
feature. So it's probably not that oftenly needed.

> I'm not talking about access control

And we also have IntraACL for access control (forked from HaloACL).
Still not an ideal solution, but we'll probably improve it more.

> 2. Hierarchy. Departments want not only "their own space," they want
> "subspaces" beneath it. For example, "Human Resources" wiki area with
> sub-areas of Payroll, Benefits, and Recruiting.  I realize Confluence
> supports this... but we decided against Confluence because you have
> to
> choose an article's area when you create it (at least when we
> evaluated Confluence years ago). This is a mental barrier to creating
> an article, if you don't know where you want to put it yet.  
> MediaWiki
> is so much better in this regard -- if you want an article, just make
> it, and don't worry where it "goes" since the main namespace is flat.
>
> I've been thinking about writing an extension that superimposes a
> hierarchy on existing namespaces, and what the implications would be
> for the rest of the MediaWiki UI. It's an interesting problem. Anyone
> tried it?

> 3. Tools for organizing large groups of articles. Categories and
> namespaces are great, and the DPL extension helps a lot. But when
> (say) the Legal department creates 700 articles that all begin with
> the words "Legal department" (e.g., "Legal department policies",
> "Legal department meeting 2012-07-01", "Legal department lunch",
> etc.), suddenly the AJAX auto-suggest search box becomes a real pain
> for finding Legal department articles. This is SO COMMON in a
> corporate environment with many departments, as people try to game
> the
> search box by titling all their articles with "Legal department"...
> until suddenly it doesn't scale and they're stuck. I'd like to see
> tools for easily retitling and recategorizing large numbers of
> articles at once.

Recategorising is very simple with global search-and-replace.
Our implementation is called BatchEditor
https://github.com/mediawiki4intranet/BatchEditor

> 4. Integration with popular corporate tools like MS Office, MS
> Exchange, etc. We've spent thousands of hours doing this: for
> example,
> an extension that embeds an Excel spreadsheet in a wiki page
> (read-only, using a $10,000 commercial Excel-to-HTML translator as a
> back-end), and we're looking at embedding Exchange calendars in wiki
> pages next.

O_O $10000 excel-to-html? O_OOO
Why not just copy-paste into for example wikEd (google://wikEd)? :-)))
Not that beautiful, but it works.

> 5. Corporate reorganizations and article titles. In any company, the
> names and relationships of departments change. What do you do when
> 10,000 wiki links refer to the old department name?  Sure, you can
> move the article "Finance department" to "Global Finance department"
> and let redirects handle the rest: now your links work. But they
> still
> have the old department name, and global search-and-replace is truly
> scary when wikitext might get altered by accident. Also, there's the
> category called "Finance department". You can't rename categories
> easily. I know you can do it with Pywikipedia, but it's slow and
> risky
> (e.g., Pywikipedia used to have a bug that killed <noinclude> tags
> around categories it changed). Categories should be fully first-class
> so renames are as simple as article title changes.

Mass editing tool = BatchEditor, as I've already said.
But I agree that Mediawiki needs better mass editing, page selection
and page exchanging (import/export) tools.

In our distribution (mediawiki4intranet) we partially solve it by
implementing selection on Special:Export. BatchEditor uses this
implementation when it's available. (you can see examples at
http://wiki.4intra.net/Special:Export and
http://wiki.4intra.net/Special:BatchEditor)
(also we have an improved import/export functionality but unfortunately
it's a code bomb and reworking to get it in trunk will take a lot of
time...)

But it's only a partial solution, because it has no standard interface.
So we also have a variation of DPL, also we have SemanticMediaWiki. And
all of them has partially the same - but not totally the same -
functionality. And it would be good if there existed a single,
standartized, optimised and cacheable method of page selection.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Corporate needs are different (RE: How can we help Corporations use MW?)

Daniel Barrett-3
[hidden email] writes:
>In our organisation (CUSTIS, Russia) we easily solve it by creating one primary wiki + separate ones for different departments.

In practice, we have found this doesn't work well for us (with thousands of employees).
Each department winds up writing its own wiki page about the same topic (say, Topic X), and they're all different.
Users don't know which one is the "real" or "right" article.
We find it better to have one central wiki with one definitive article per topic.
No redundancy, no coupling, and no version skew between wikis.

>Recategorising is very simple with global search-and-replace.
>Our implementation is called BatchEditor https://github.com/mediawiki4intranet/BatchEditor

Thanks, I'll check it out. Categorization can get very complicated on a MediaWiki system though.
Consider this fairly simple template example:

{{#if:{{{department|}}} | [[Category:{{{department}}} projects]]}}

I would be amazed if any global search-and-replace could handle this!

>O_O $10000 excel-to-html? O_OOO
>Why not just copy-paste into for example wikEd (google://wikEd)? :-))) Not that beautiful, but it works.
       
Now, I will demonstrate what I mean by "Corporate needs are different." :-)

With our extension, the Excel spreadsheet is rendered "live" in the wiki page.
So if somebody updates the spreadsheet (on a network drive), the wiki page is
automatically and instantly up to date!  This is totally different from a one-time
copy-and-paste, and much more maintainable. (And it's pretty fast too, with AJAX and good caching.)

Even better, if your spreadsheet generates a graph or chart, the image gets embedded
in the wiki page too, and is automatically kept up to date.  And if your spreadsheet
calls out to a database for its data, to generate the chart, then the wiki is updated
when the database changes too! Suddenly, MediaWiki has all the charting capability of
Excel + SQL.  This is very powerful and definitely worth $10K for a highly analytical
company like ours.

We've had this feature for about 2 months, and so far we have 350+ articles with
embedded spreadsheets, updated "live."

> also we have SemanticMediaWiki.

We started looking into Semantic MediaWiki - it has impressive features.
But we got scared off by stories that it slows down the
wiki too much. Maybe we should give it another look.

DanB
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Corporate needs are different (RE: How can we help Corporations use MW?)

Sumana Harihareswara-2
On 02/08/2013 01:23 PM, Daniel Barrett wrote:
>> also we have SemanticMediaWiki.
>
> We started looking into Semantic MediaWiki - it has impressive features.
> But we got scared off by stories that it slows down the
> wiki too much. Maybe we should give it another look.
>
> DanB

A recent improvement in SMW is the new database structure for Semantic
MediaWiki, SMWSQLStore3 -- this makes SMW faster and more efficient.

http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.8

It got released 2 December 2012.  So yeah, check it out.

(Shout-out to Nischay Nahata who led that work as his 2012 Summer of
Code project.)

--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123