Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-07 Thread 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 | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-07 Thread Jay Ashworth
- Original Message -
> From: "Daniel Barrett" 

> 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   j...@baylink.com
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread planetenxin

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  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
Wikitech-l@lists.wikimedia.org
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread vitalif

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 $1 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  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread Daniel Barrett
vita...@yourcmc.ru 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 $1 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread Sumana Harihareswara
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread bawolff
On 2013-02-08 2:28 PM, "Sumana Harihareswara"  wrote:
>
> 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
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I know nothing of smw, but surely using an rdf store backend ( which from
what i understand has been supported for quite some time) would be more
efficient than a relational db backend, no matter how optimized that
backend might be.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread Jeroen De Dauw
Hey,

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.
>

You _can_ abuse SMW in a way that it will kill performance on your wiki. If
you use it in a sane fashion, it does not greatly affect performance. Sure
there is room for improvement in some places, though it is certainly
nowhere near being unusable due to performance issues, as i clearly
demonstrated by many people using it very effectively. So though such
stories due have a kernel of truth, they tend to be propagated by people
not really knowing what they are talking about and tend to portray things
bleaker then they actually are.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread Lee Worden

On 02/08/2013 10:23 AM, Daniel Barrett wrote:

O_O $1 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."


As an aside, you could almost certainly do this cheaper with 
WorkingWiki.  If you can write a make rule to retrieve the Excel file 
from the network drive and make it into html and image files (and maybe 
a little wikitext to format the page), you're done.


LW

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-08 Thread vitalif

In practice, we have found this doesn't work well for us (with
thousands of employees).


Yeah, our company doesn't have thousands of employees :-)


Each department winds up writing its own wiki page about the same
topic (say, Topic X), and they're all different.


So it means most of your departments work on something very similar?
Probably we don't have this problem because our departments and 
projects strongly differ, so everyone just writes their specific 
articles to their own wikis and general information to the primary 
"CustisWiki".

We have ~7 wikis for the whole company (~200 employees).


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.


Just an idea - you can also setup the replication process between wikis 
to ease fighting



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!


Such examples of course are much harder, but if there is not much 
chaos, you can handle it with regexps... Not a task for an average user, 
but he can ask someone who knows regexps to do it :-)


With our extension, the Excel spreadsheet is rendered "live" in the 
wiki page.


Ooh, I see, of course it's a big feature!
Also another question - didn't you try to use some automation using 
excel itself to save xls as an html?


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.


As someone already said, it should not affect performance noticeably if 
you don't abuse it.
And also, even if use abuse it - it has a very good feature: "concept 
caching", i.e. caching of semantic query results with correct 
invalidation (as I understand it has some limitations though). 
(http://semantic-mediawiki.org/wiki/Help:Concept_caching)


Overall, it's very nice to see that a big company like yours has 
successful MediaWiki usage experience (I assume it's successful, yeah? 
:))


Do you have any extensions or modifications that you would like to make 
public & free & open source? Or maybe you even already did it with 
something? :-)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-09 Thread Antoine Musso
Le 08/02/13 21:51, Lee Worden a écrit :
> 
> As an aside, you could almost certainly do this cheaper with
> WorkingWiki.  If you can write a make rule to retrieve the Excel file
> from the network drive and make it into html and image files (and maybe
> a little wikitext to format the page), you're done.

In big companies, 10 000$ is cheap. Plus I bet they get a support
contract coming in.  Overall, that is probably cheaper than paying an
internal software developer to integrate and then maintain the
WorkingWiki solution.

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-09 Thread Platonides
On 08/02/13 21:51, Lee Worden wrote:
> As an aside, you could almost certainly do this cheaper with
> WorkingWiki.  If you can write a make rule to retrieve the Excel file
> from the network drive and make it into html and image files (and maybe
> a little wikitext to format the page), you're done.
> 
> LW

You could do it with openoffice.org/libreoffice, although I agree that
getting all the dependencies right for running in the server is a bit
tedious. You can also use Excel itself for that (eg. COM automation), as
suggested by vitalif, supposing you are using a Windows server.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-09 Thread David Gerard
On 9 February 2013 23:00, Platonides  wrote:

> You could do it with openoffice.org/libreoffice, although I agree that
> getting all the dependencies right for running in the server is a bit
> tedious. You can also use Excel itself for that (eg. COM automation), as
> suggested by vitalif, supposing you are using a Windows server.


You can in fact automate OO/LO in this manner. We do this at work (an
application that has to turn RTF and DOC into PDFs; if you want a
fighting chance of rendering Word files, you need something of
comparable size to Word). Not fast (and we never could get daemon mode
working) so cache your results.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-09 Thread Lee Worden

On 02/09/2013 03:00 PM, Platonides wrote:

On 08/02/13 21:51, Lee Worden wrote:

As an aside, you could almost certainly do this cheaper with
WorkingWiki.  If you can write a make rule to retrieve the Excel file
from the network drive and make it into html and image files (and maybe
a little wikitext to format the page), you're done.

LW


You could do it with openoffice.org/libreoffice, although I agree that
getting all the dependencies right for running in the server is a bit
tedious. You can also use Excel itself for that (eg. COM automation), as
suggested by vitalif, supposing you are using a Windows server.


Yes, something like that is what I had in mind.

On 02/09/2013 11:06 AM, Antoine Musso wrote:
> In big companies, 10 000$ is cheap. Plus I bet they get a support
> contract coming in.  Overall, that is probably cheaper than paying an
> internal software developer to integrate and then maintain the
> WorkingWiki solution.
>
> -- Antoine "hashar" Musso

True.  Others who operate less formally might find it a welcome option, 
OTOH.

LW

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-11 Thread Daniel Barrett
Platonides (and others) offered comments like:
>You could do [Excel to HTML] with openoffice.org/libreoffice,
>although I agree that getting all the dependencies right for running in the 
>server is a bit tedious.
>You can also use Excel itself for that (eg. COM automation), as suggested by 
>vitalif...

My team investigated several Excel-to-HTML solutions, including openoffice.org, 
Excel itself, a free converter on Google Code, etc. The clear winner was Aspose 
(www.aspose.com), running under Mono, for ease of automation with MediaWiki and 
quality of results. Relatively expensive but it works great.

DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-11 Thread Daniel Barrett
>> Each department winds up writing its own wiki page about the same
>> topic (say, Topic X), and they're all different.

>So it means most of your departments work on something very similar?

Not exactly. Each team treats its wiki as "The" wiki, and they create 
general-purpose articles like "How to request a day off from your manager" and 
"Where is the company cafeteria" that apply to the whole company. Individual 
writers do not think about the big picture, that general-purpose articles might 
belong a different, general-purpose wiki. They just want to get their job done 
quickly.  So these kinds of articles get written in the wrong wiki, or in 
several wikis at once, and they drift out of sync.  With a single, central 
wiki, this is much less likely.

Imagine if Wikipedia had a separate wiki for every city in the world. The same 
problem would result.

>Do you have any extensions or modifications that you would like to make public 
>& free & open source?
>Or maybe you even already did it with something? :-)

Indeed, we are working out a way to open-source some of our extensions.

DanB

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-11 Thread .
The bad thing about corporate users is that have special needs, the
good thing is that are willing to pay for a service. Maybe somebody
should start selling that service (in the form of a "package",
"mediawiki distro", or other mode).

My company uses GoogleDocs, but we are developers, so we don't have
the mindset of the people that share photos inside .doc files.
Apparently you can embed googledocs in html.
http://en.support.wordpress.com/google-docs/

It would be natural for us to find a way to embed google docs in a
wiki,... but we don't need to, because a simple link is enough.


-- 
--
ℱin del ℳensaje.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-11 Thread S Page
On Thu, Feb 7, 2013 at 1:31 PM, Daniel Barrett  wrote:
> ...
> 1. A desire for a department to have "their own space" on the wiki.

I assume you looked at enabling subpages in the main namespace?[1]
That way Human Resources/Payroll/Show_me_the_money gets a nice
breadcrumb up to Payroll and Human Resources landing pages.  You can
encourage people to create subpages rather than making yet another
top-level page by putting [Create page] forms on landing pages  that
use a local template[2] and prepend the local hierarchy.

> 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.

(1) Code could infer subpage hierarchy and apply CSS from a
corresponding CSS hierarchy.

(2) Add prefix: to the searches to search subpages, you can make a
form for it[3].  Also Special:PrefixIndex can be helpful, e.g. just
listing all subpages of the current landing page:
  == Subpages of {{FULLPAGENAME}}==
  {{Special:PrefixIndex/{{FULLPAGENAME}}/}}


Cheers,

[1] http://www.mediawiki.org/wiki/Manual:$wgNamespacesWithSubpages

[2] something like

type=create
preload=Template:Human Resources meeting
buttonlabel=Create a new page for a Human Resources meeting
default=Human Resources/Meetings/{{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY}}
width=40
bgcolor=#f0f0ff


[3] http://en.wikipedia.org/wiki/Template:Search_box and similar.

--
=S Page  software engineer on Editor Engagement Experiments

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-11 Thread Brian Wolff
On 2013-02-12 12:55 AM, "S Page"  wrote:
>
> On Thu, Feb 7, 2013 at 1:31 PM, Daniel Barrett 
wrote:
> > ...
> > 1. A desire for a department to have "their own space" on the wiki.
>
> I assume you looked at enabling subpages in the main namespace?[1]
> That way Human Resources/Payroll/Show_me_the_money gets a nice
> breadcrumb up to Payroll and Human Resources landing pages.  You can
> encourage people to create subpages rather than making yet another
> top-level page by putting [Create page] forms on landing pages  that
> use a local template[2] and prepend the local hierarchy.
>
> > 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.
>
> (1) Code could infer subpage hierarchy and apply CSS from a
> corresponding CSS hierarchy.
>
> (2) Add prefix: to the searches to search subpages, you can make a
> form for it[3].

It should be noted that that doesnt work out of the box but needs
lucene/MWSearch extension.

For subpages to really fill this use case I think the page title would have
to show only (or primarily emphasize) the subpage name instead of the full
page name.

Also it sounds like in such a use case, one would want links to be relative
to the current path first. If on page a/b/c you would want [[foo]] to link
to a/b/foo if it exists and link to just foo if that page does not exist.

I think a good take away from this thread is that mediawiki has a lot of
featuters that almost fit the bill but don't quite fully.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-12 Thread Platonides
On 12/02/13 06:26, Brian Wolff wrote:
> For subpages to really fill this use case I think the page title would have
> to show only (or primarily emphasize) the subpage name instead of the full
> page name.

I think it has been brought up in the past, there may be an extension
doing that.


> Also it sounds like in such a use case, one would want links to be relative
> to the current path first. If on page a/b/c you would want [[foo]] to link
> to a/b/foo if it exists and link to just foo if that page does not exist.

And where should the red-link send you to?
That may be more confusing for some users.

We have ../ links, perhaps add also ./ ?



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-12 Thread Daniel Barrett
I wished for:
>> 1. A desire for a department to have "their own space" on the wiki.

S Page asked:
>I assume you looked at enabling subpages in the main namespace?[1]
>That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up 
>to Payroll
>and Human Resources landing pages.

Interesting idea, but I think subpages also bring penalties that are pretty 
significant. I discuss these in my book 
(http://shop.oreilly.com/product/9780596519681.do):

- Linking to subpages is quite cumbersome. The names get very long, and you 
wind up doing lots of [[foo/bar/blat/a/b/c | alt text]] links which add 
complexity to editing the page.  We find that this discourages people from 
adding links to pages.

- When you enable subpages for a large community, they start using them instead 
of categories.  In other words, users now have a choice between putting 
"Benefits" in the Human Resources category, or creating "Human 
Resources/Benefits." As a result, some Benefits pages end up in the Benefits 
category while others end up as subpages, making the "Benefits" category 
incomplete.  An incomplete category can be worse than no category at all, 
because people look in it, don't find what they want, and assume it doesn't 
exist. Also, I'd rather have a category with 200 members than a page with 200 
subpages.

- MediaWiki's UI does not indicate whether a page has subpages. There are 
extensions to solve this, but I haven't found one that integrates seamlessly 
into the user's daily experience the way (say) category links do.

For our large wiki, we decided that subpages in the main namespace are not 
worth these disadvantages.

Hope this was interesting,
DanB

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-12 Thread Mark A. Hershberger
On 02/11/2013 11:25 AM, Daniel Barrett wrote:
> Imagine if Wikipedia had a separate wiki for every city in the world. The 
> same problem would result.

I find it is easier to imagine what would happen if each language had a
separate Wikipedia.  We would end up with slightly different facts
maintained on each wiki.

Imagine the chaos!

;)

-- 
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-13 Thread Marco Fleckinger



On 02/12/2013 05:30 PM, Mark A. Hershberger wrote:

On 02/11/2013 11:25 AM, Daniel Barrett wrote:

Imagine if Wikipedia had a separate wiki for every city in the world. The same 
problem would result.


I find it is easier to imagine what would happen if each language had a
separate Wikipedia.  We would end up with slightly different facts
maintained on each wiki.

Come on, this will be a similar discussion of what is the NPOV 
concerning the Falkland island on the English and the Spanish Wikipedia. 
IMHO each community should organize his wiki on it's own. Meta, 
Mediawiki, Commons and Wikidata already have interlanguage-communities 
and I think this doesn't work bad.


Wikidata will be a bit different because it will integrate itself into 
the wikis' structures. Therefore I think that there will be discussion. 
So it's really great that the developers let the consumers the choice if 
they wanted to use wikidata or not.


Cheers

Marco

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-13 Thread Brian Wolff
On 2013-02-13 11:27 AM, "Marco Fleckinger" 
wrote:
>
>
>
> On 02/12/2013 05:30 PM, Mark A. Hershberger wrote:
>>
>> On 02/11/2013 11:25 AM, Daniel Barrett wrote:
>>>
>>> Imagine if Wikipedia had a separate wiki for every city in the world.
The same problem would result.
>>
>>
>> I find it is easier to imagine what would happen if each language had a
>> separate Wikipedia.  We would end up with slightly different facts
>> maintained on each wiki.
>>
> Come on, this will be a similar discussion of what is the NPOV concerning
the Falkland island on the English and the Spanish Wikipedia. IMHO each
community should organize his wiki on it's own. Meta, Mediawiki, Commons
and Wikidata already have interlanguage-communities and I think this
doesn't work bad.
>
> Wikidata will be a bit different because it will integrate itself into
the wikis' structures. Therefore I think that there will be discussion. So
it's really great that the developers let the consumers the choice if they
wanted to use wikidata or not.
>
> Cheers
>
> Marco
>
>

I think you missed the point of the previous email.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-14 Thread Maria Miteva
Hi everyone,

I guess this would not directly solve any of the problems listed, but would
it be helpful to bring back to life
https://www.mediawiki.org/wiki/Enterprise_hub ? It was started by somebody
an year or two ago but seems to have been abandoned at a draft stage. I am
thinking if everybody adds some information about extensions/pages they
find particularly useful in the enterprise world, it will help future users
but also help current enterprise wikis exchange experience.  Does this seem
worthwhile?

Mariya

On Wed, Feb 13, 2013 at 11:38 PM, Brian Wolff  wrote:

> On 2013-02-13 11:27 AM, "Marco Fleckinger" 
> wrote:
> >
> >
> >
> > On 02/12/2013 05:30 PM, Mark A. Hershberger wrote:
> >>
> >> On 02/11/2013 11:25 AM, Daniel Barrett wrote:
> >>>
> >>> Imagine if Wikipedia had a separate wiki for every city in the world.
> The same problem would result.
> >>
> >>
> >> I find it is easier to imagine what would happen if each language had a
> >> separate Wikipedia.  We would end up with slightly different facts
> >> maintained on each wiki.
> >>
> > Come on, this will be a similar discussion of what is the NPOV concerning
> the Falkland island on the English and the Spanish Wikipedia. IMHO each
> community should organize his wiki on it's own. Meta, Mediawiki, Commons
> and Wikidata already have interlanguage-communities and I think this
> doesn't work bad.
> >
> > Wikidata will be a bit different because it will integrate itself into
> the wikis' structures. Therefore I think that there will be discussion. So
> it's really great that the developers let the consumers the choice if they
> wanted to use wikidata or not.
> >
> > Cheers
> >
> > Marco
> >
> >
>
> I think you missed the point of the previous email.
>
> -bawolff
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-14 Thread vitalif
I guess this would not directly solve any of the problems listed, but 
would

it be helpful to bring back to life
https://www.mediawiki.org/wiki/Enterprise_hub ? It was started by 
somebody
an year or two ago but seems to have been abandoned at a draft stage. 
I am
thinking if everybody adds some information about extensions/pages 
they
find particularly useful in the enterprise world, it will help future 
users
but also help current enterprise wikis exchange experience.  Does 
this seem

worthwhile?


IMHO there are so much useful extensions that I think it can be a 
little much for that page.


For example if I edited that article I would put almost all extensions 
from our distribution there... so I'm documenting them on 
http://wiki.4intra.net/Category:Mediawiki4Intranet_extensions :-)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-14 Thread Dmitriy Sintsov

On 14.02.2013 21:14, vita...@yourcmc.ru wrote:
I guess this would not directly solve any of the problems listed, but 
would

it be helpful to bring back to life
https://www.mediawiki.org/wiki/Enterprise_hub ? It was started by 
somebody
an year or two ago but seems to have been abandoned at a draft stage. 
I am

thinking if everybody adds some information about extensions/pages they
find particularly useful in the enterprise world, it will help future 
users
but also help current enterprise wikis exchange experience. Does this 
seem

worthwhile?


IMHO there are so much useful extensions that I think it can be a 
little much for that page.


For example if I edited that article I would put almost all extensions 
from our distribution there... so I'm documenting them on 
http://wiki.4intra.net/Category:Mediawiki4Intranet_extensions :-)


The question is, how much they are stable and secure. MediaWiki is 
high-quality software that should not be impaired by low-quality 
extension. Also, when extension is unmaintained, it's stability and 
security becomes questional as well.
Also, I remember for major MW extensions scalability is the big problem. 
Efficient SQL queries, using APC / Memcached cache, not invalidating 
parser cache too often. For example my own Extension:QPoll is not 
well-scaling requiring some major rewrites. That applies to many of 
another extensions as well.

Dmitriy


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-15 Thread Maria Miteva
Hi,

There are so many extensions useful to the enterprise but probably also so
many which are not useful at all or not maintained and if I wanted to start
a corporate wiki right now I would probably be very lost what to look at
and how people do things, so it seemed like a good idea to list the
extensions that ARE actually used. Also, I guess one team solved a certain
problem one way, while another solved it differenty, using a different
extension or set of extensions, so writing this out might help everybody
get new ideas/ avoid reinventing the wheel. But I guess I either asked on
the wrong list or there is not much interest at all.

Mariya

On Thu, Feb 14, 2013 at 9:06 PM, Dmitriy Sintsov  wrote:

> On 14.02.2013 21:14, vita...@yourcmc.ru wrote:
>
>> I guess this would not directly solve any of the problems listed, but
>>> would
>>> it be helpful to bring back to life
>>> https://www.mediawiki.org/**wiki/Enterprise_hub?
>>>  It was started by somebody
>>> an year or two ago but seems to have been abandoned at a draft stage. I
>>> am
>>> thinking if everybody adds some information about extensions/pages they
>>> find particularly useful in the enterprise world, it will help future
>>> users
>>> but also help current enterprise wikis exchange experience. Does this
>>> seem
>>> worthwhile?
>>>
>>
>> IMHO there are so much useful extensions that I think it can be a little
>> much for that page.
>>
>> For example if I edited that article I would put almost all extensions
>> from our distribution there... so I'm documenting them on
>> http://wiki.4intra.net/**Category:Mediawiki4Intranet_**extensions:-)
>>
>>  The question is, how much they are stable and secure. MediaWiki is
> high-quality software that should not be impaired by low-quality extension.
> Also, when extension is unmaintained, it's stability and security becomes
> questional as well.
> Also, I remember for major MW extensions scalability is the big problem.
> Efficient SQL queries, using APC / Memcached cache, not invalidating parser
> cache too often. For example my own Extension:QPoll is not well-scaling
> requiring some major rewrites. That applies to many of another extensions
> as well.
> Dmitriy
>
>
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-15 Thread vitalif
There are so many extensions useful to the enterprise but probably 
also so
many which are not useful at all or not maintained and if I wanted to 
start
a corporate wiki right now I would probably be very lost what to look 
at

and how people do things, so it seemed like a good idea to list the
extensions that ARE actually used. Also, I guess one team solved a 
certain
problem one way, while another solved it differenty, using a 
different
extension or set of extensions, so writing this out might help 
everybody
get new ideas/ avoid reinventing the wheel. But I guess I either 
asked on

the wrong list or there is not much interest at all.


So, you're talking about some "basic set" of extensions that are 
thought to be definitely useful for ALL people?


It may be useful, but I think that it anyway may require testing of a 
complete distribution (MW version X + all these extensions) to recommend 
it to companies... And this returns us to the idea of a "pre-built" 
distribution like our one :-))


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l