How to increase active installs of XWiki?

Help / Discuss
1

Dear XWiki users,

It would be great if you could help us with ideas on how we could improve our active installs. See http://www.xwiki.org/xwiki/bin/view/ActiveInstalls/ to see the numbers.

I’ve prepared a page at http://dev.xwiki.org/xwiki/bin/view/Drafts/IncreasingActiveInstalls/ to list some ideas.

You could help in different ways;

  • Help provide ideas how to get more people try XWiki
  • Help provide ideas as to why users stop using XWiki
  • Help provide ideas how we could keep users using XWiki longer
  • Tell us from the existing ideas, which ones you think would be the most effective

You can either register and edit the page at http://dev.xwiki.org/xwiki/bin/view/Drafts/IncreasingActiveInstalls/ or simply reply to this thread and I’ll merge your ideas/points in the page.

Thanks a lot of your help!
-Vincent

2 Likes
2

Hi @vmassol,

I compiled a list of random thoughts that came to my head. Some points may not be directly ideas and some of the points may be better in the usability pain points thread, which I, by the way, think you should “pin”.
A lot of these points are highly subjective.
I still hope that you find them useful.

Visibility: It is unfortunate that it’s pretty hard to get visibility on the big search engine(s) as every search phrase containing the word ‘wiki’ seems to contain mostly results pointing to wikipedia. I myself found it really hard to discover xwiki although I searched a lot for wiki and mediawiki related stuff in the last few years. And I kept searching for alternatives to mediawiki and evaluated and discarded a few before I found xwiki (finally :wink:)
Maybe a first step would be to review “all” the wiki comparisons and correct and complete them, if necessary (e.g. wikipedia or wikimatrix to name only two high ranked in my search results.)

Documentation I: There is a lot of documentation, which is good, yet it “feels” scattered. There are only few walkthroughs. To install xwiki with tomcat and mysql you need to read at least two or three documents just to get started. While I know this is considered the hardest way, it is currently the only way that I see to run xwiki in the companies I know.
Altough I really wanted to try out xwiki I did not feel really encouraged, because the installation documentation looked like a real hard piece of work. I guess if I had to evaluate xwiki it may have been out of the game at this point. This may be only me, but I became extremely maintenance and operations focused, so I try to avoid everything that “smells” like trouble and hard to read installation documents are the first sign of trouble for me.
Also the documentation is often sprinkled with hints for or references to old or “obsolete” versions. While they may serve a purpose for some, I found them distracting.

Documentation II: There are a lot of “weird” search results in the google search index. Especially when I searched for more advanced stuff I found myself a lot on PDF Export or history pages for articles. Maybe you can prevent google to index these?

Don’t fight Sharepoint, complement it: I digged up this Xwiki vs. Sharepoint comparison and while it is dated and has a lot of valid points I found that attacking Sharepoint is mostly fighting a losing battle. So it may be better to concentrate on the points where you can add value for a company alongside Sharepoint not trying to replace it. Maybe have an extension (if there is not any yet) that adds integration to sharepoint (export to sharepoint,…).

Get more enterprise “aware”:
Just one example: Asking for “grant all privileges on *.* to xwiki@localhost[…]” (see here) is nothing I could pull off easily in most companies I know.

Create tutorials:
Showcase the awesome features that xwiki has. Get users into xwiki fast so they feel it is fun and natural to use it. Suggest admins a good way to set-up and maintain xwiki. Show developers how to create small apps, establish xwiki as an extensible platform that helps them. Encourage contribution.

Focus on content editing:
Editing content is the bread and butter functionality of xwiki for me, so it should it be as easy as possible. So bugs in and enhancements for the editor should have a high priority (and no, I’m not at all, hinting towards, e.g. Loading... :wink:)

Documentation III: If you try to dive deeper, I found that the documentation is getting more incomplete and scarce. I found myself often on the source level, which I don’t mind, except that finding the source code is pretty hard, especially as the full API documentation is broken since at least months and the current 10.4 API doc is segmented in modules and spits out HTTP 400s for a lot modules (e.g. here and here and more).
And you may have guessed already: I’d really love if the development documentation would be way more like a walkthrough than it is currently. I’m still struggling to setup my dev-box. But maybe others will enjoy it too, if they felt more “welcomed” and supported as devs.

To sum it up: These are a few points that I’d like to see improved and that I guess may be liked by others too and maybe answers your questions. I hope you find them helpful.

rbr

1 Like
3

Thanks for spending time on this and providing some ideas. I’m sure that will help a lot. Now I’d like to go over them one by one and see what we can do for real.

Let’s start with this point above.

Right now we update several places where there are wikis mentioned and we even update them whenever we release XWiki. For example in the release plan for XWiki 10.5RC1: http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlan10.5RC1

You can see that we update the following:

In addition XWiki is also mentioned in other places that don’t require an update when we release a new version. For example:

Do you have an idea of places that we would have missed and where we could advertise for XWiki?

Thanks

4

If we can agree on some key facts I’ll happily search for german pages and try to update them.

I’ll try to extract as much as possible from sites you mentioned above, yet the wiki comparison mentions a GWT based editor (under Features 2), which puzzles me, I thought you were “full CKEditor” now?

5

That’s correct, the pages were not up to date. I’ve fixed all places where I could notice GWT. Let me know (or edit them) if you see other places.

Awesome!

6

There are several topics here:

  • General documentation
  • Guides/Tutorials
  • Obsolete parts
  • Installation guides
  • Supported versions

Let me try to reply with the thoughts it evokes in me so that we can try to find what we can do about it.

Actually that’s not fully correct. There’s only a single document listing all steps you have to perform for the WAR install (I assume this is the one you’re referring to): http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/

Ofc we can’t guess what servlet container or what DB the user wants to use so the user has to click on the right link but they’re all listed.

7 servlet containers on 8 databases that’s 56 combinations :slight_smile:

Now the reality is that the majority of users will want Tomcat and MySQL (see http://www.xwiki.org/xwiki/bin/view/ActiveInstalls/).

Do you really believe that the issue is that you need to click on links in the current documentation?

What we could do but I’m really not sure it’s worth the cost would be to develop a small app for this. Looks overkill to me. WDYT?

Regarding installation, I think that one potential issue is that users will jump to the manual WAR install (which is the most complex one) when sometimes they could use the DEB or Docker installs for example. Do you think that’s true? I’ve tried to reword a bit http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#HInstallationMethods to put the WAR install as the last one.

You said:

So the apt-get way is not good in your cases?

I’ve read again http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/ and it didn’t look that bad. Do you have specific examples of things that we could improve? I just had one idea when reading it which is to move some stuff in a section at the bottom, for example for the Security Manager thing.

One thing that is apparently not working so well is that the documentation is a wiki and everyone is encouraged to help out and reword things, move things around, etc. :slight_smile:

I agree with this one. Actually our rule is simple: we only support 3 branches in the documentation, see https://www.xwiki.org/xwiki/bin/view/Main/Support#HSupportedVersions So normally anything older than 9.11.x should get cleaned/removed.

7

I have already used XWiki for 4 years and i have a lot to say:

  1. Usually only geeks make PR for this product. especially in languages other than English.
  2. XWiki has a few information/groups at social networks and Youtube.
  3. Information like “HOW TO” at xwiki.org sometimes too old, sometimes not usefull
  4. There are some problems, which worsen the mood, for example, then u use filesystem to hold the files the path consist of the letters from page titles and if u use windows u have the problem with the long names
  5. Extensions. There are a lot of usefull extensions, but some of them do not support with new versions of XWiki, another - payed applications. As for me - i need for individual wiki links to files at PC filesystem, without uploading to base - but i cannot do this without another ftp/http file server.
  6. The complexity and pitfalls during installation with Glassfish, JBoss, Tomcat. Yes, portative XWiki is usefull, but not the best chouse for production.
  7. XWiki do not integrate to Bitnami and many other free servers

what should we do? Spending the time to PR, support, actualizing information, translate and write new guide, making the videos “How to us XWiki at/as…” Man-hours require investment and altruism. But this is only part of a whole. If u know that u want - u always follow the nessesary way.
I wrote 2 articles about XWiki, but this is not enought.

8

Added some stuff, especially looking at https://snapcraft.io could be interesting. It’s by default on Ubuntu since 16.04 and the snap client is available in most Linux distributions standard repositories as far as I can see.

1 Like
9

That’s actually fine (for me). I reviewed the tomcat guide again and it still feels “jumpy”. Allow me to give only one exampe: The second bullet point is already a link again give enough memory to Java. I’d prefer to have reasonable default here and a “for more info see memory settings section” link. Which could then also be referenced to by the current OOM error debug section.
This may cause a little redundancy but should be better for most. And if one gets surprised be the very high popularity of your xwiki installation (which I wish for every xwiki installation :wink:) one may need to adjust. If you run a “special needs” installation, like high volume or high availibity demands, you know it normally and plan ahead accordingly.

This could be nice, actually I liked the wizard for remi’s php repository, which admittedly covers a way simpler topic. I don’t know if this is “worth” it, maybe it is the detail that signs the deal, maybe it’s just a little sugar on the top.
Maybe it could be used for some new cool dynamic page type in our wikis too, wouldn’t that be awesome?
A cheaper and faster option is to dedicate a special section for user contributed howtos, where you see very concrete descriptions of installations, like installing “xwiki 9.x on centos 7.x with tomcat 8.x and mysql 5.x”. I see a lot of benefits from this: First that would encourage users to edit documentation, second you as a user may find “your” required walkthrough already “readymade” and third there may be nice little tricks and hints to get “inspired” even for the official documentation.

That may be possible, but it may be also the case that it is some kind of “catch-all” configuration, when you you don’t have docker or debian available. So it is somewhat natural that you see quite a lot of installations for this configuration.
Getting more complex stuff out of sight is always a good idea. I’d also propose to move the docker method to the production ready methods yet maybe below the debs. I also like the docker-hub description a lot.

Writing good documentation is a tough craft, writing great documentation is an art. So sadly this is somewhat expected. Yet I’ll try now and then…

If your only option is RHEL, no.

If I’ll find one, I’ll delete it.

10

A nice alternative/addition may be https://packager.io/ or https://openbuildservice.org/ to create packages for us poor RHEL/SLES/Centos using souls.

11

Note that Fedora is listed on https://snapcraft.io/ so I guess RHEL is not far and from what I understood work is in progress for other distributions (there is already some alpha builds for Centos being tested as far as I can see on Install snapd on CentOS - #25 by zyga-snapd - snapd - snapcraft.io).

I know packager.io but what is interesting about snaps packages is that you actually have the client available in all those distributions and an already known central repository (store), with package.io you have to add a new repository for each application you want to install.

12

Just added a new entry on http://dev.xwiki.org/xwiki/bin/view/Drafts/IncreasingActiveInstalls/ about advertising releases on new web sites. I’ve added one:

Please add some more!

13

It might be also worth to look into importing content into and exporting content from xwiki. Because these are two topics, I found, that you just can’t avoid. And everyone expects near perfect results. Unfortunately this is not the case for what I tested so far.
I just reevaluted the Streams Filter Application again to import some MediaWiki pages but it feels pretty rough to use currently. I’ll open a new thread for this in special.
The good thing is the conversion mediawiki->xwiki 2.1 syntax is working incredibly well for manual conversion even for crazy long and complicated pages, yet not for bulk operations.

14

Couple of little suggestions:

1/ ensure this information is up-to-date and accurate (this is where I first went looking for information on wikis)

It was last edited recently, so someone is doing that. Check for accuracy just in case it was not you.

2/ Have you updated your information at Infogalactic and Wikipedia recently? If not, do so.

3/ When I was first playing with xwiki, I had lots of problems getting everything to work - so much so that I abandoned it and went with Confluence for several years. I only tried again because the much improved features.

The install was still a bit of a pain and it took a couple of attempts, plus some problem solving to get java/tomcat playing nicely - maybe hosting a repository with prepackaged builds that “just work” for common distributions.

4/ is your features page up to date? Last edited Sept 2017.

15

List of websites where we advertise XWiki already:

List of websites where we’re not advertising XWiki and where we should:

Please edit and add to the list to help out! :slight_smile:

16

Hi @pdwalker. Yes we do that at each release (it’s done by us). It’s part of our release plan. If you want to see all the places we edit, check the last release for example: http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlan10.5

Interesting, first time I’m hearing about this site. What is it? Why does it have some old copy of wikipedia pages? Shouldn’t it be their job to do the sync? We do update all the page links you mentioned but on wikipedia, not on infogalactic.com. Seems like a pain to have to do it in both places and seems weird, no?

That’s an interesting feedback, thanks for mentioning it. So this shows we’re progressing, nice :slight_smile:

It’s good that you came back because one of my worries is that when someone tries a software and doesn’t like it for whatever reason, the person usually doesn’t come back to it, or at least for a very long time.

That’s one of the reasons I/we’ve been pushing for usability improvements and especially first minutes usability improvements.

On this topic, if you see things we should improve for the first 5 minutes experience please let us know.

Yeah I’d love if we could have it even smoother. Please send ideas about what we should improve on the install/upgrade process from your POV.

Yes it’s up to date :slight_smile:

The page is mostly automated and all extensions that are automatically bundled in XWiki Standard and present on extensions.xwiki.org are listed :wink: There’s only the Base Features part that is manual and that doesn’t change over time since everything new is done as an extension now.

Thanks, keep the ideas coming!

17

1/ You’ve got that covered. Excellent.

2/ --opinion-- Wikipedia has become a site toxic to anyone with a non "progressive" or "liberal" viewpoint. Infogalactic was founded as a fork of Wikipedia where they would leave out the politics and politically correct views which is damaging the quality of some of the wikipedia content. --/opinion--

While it has not yet gotten the popularity of Wikipedia, it’s rapidly growing.

Anyway, if you’re updating wikipedia, that should be good enough for now, so that’s not really an issue.

Oh, suggestion: use the SVG version of your logo rather than the low resolution PNG. It’s much nicer (I see someone has already done that for Infogalactic)

3/ re: improved features - I am not sure which features made me come back and reevaluate xwiki. App Within Minutes, and the custom databases you could do? Maybe, I don't remember exactly now. And funnily enough, in the end I didn't develop the database type app - just stuck with a quick "app within minutes" type app for some of the larger listings I had to deal with.

The usability of the wiki within the first couple of minutes is almost instantly obvious to me. I had no issues with that. (one minor annoyance which I will detail in a later post - which is not necessarily an xwiki problem as it is with my expectations)

3a/ Installation - I forget all the little things I had to do, and the number of attempts I needed until I was happy with my initial installation. I'll redo an installation somewhere else and then see if any of those annoyances/problems are actually an issue or not. By now, I've forgotten what I did to install it, so it should be just doing it from scratch again.

Ages past, when installing software under Unix/Linux, I’d have to do the whole compile everything from source after first making sure that I had all the necessary libraries and prerequisites. These days, I’m completely spoiled with the {yum|apt} install commands and I have to confess to getting mentally lazy.

So in the spirit of that laziness, the install should be as easy as one of those package installation commands for one of the supported platforms. I suspect that will take a good deal of work, so the other possibility is preparing a self contained, prebuilt XWiki appliance that some one interested in evaluating the software can just download, and run under their hypervisor of choice.

Depending on how you build it, you may be able to have just one version that can be imported to run under KVM/ESXi or VirtualBox.

You could even keep a current version, and a previous version. The previous version could be used by someone to test the upgrade process.

4/ wonderful - you're aware of all that.

Please note that my installation memories my be incorrect, or I may have been just doing something silly. When I do a new install, I’ll actually pay attention and write down anything that actually is a real difficulty.

18

I think we’re already doing that. We have 2 of them ATM:

What we’d like to add is a RPM one in the future but we’re lacking someone in the dev team using RPM. If someone could contribute and maintain one that would be the best FTM.

Do you have anything else in mind?

19

an update after your last post.

20

@rbr: do you have an example so that I can see what’s wrong and what would need to be changed?

Thanks