In this two-part article, we give a detailed comparison of the wiki top dog MediaWiki and Confluence.
We already wrote a few words about MediaWiki and Confluence some years ago. At that time, we wrote about the main objections to MediaWiki.
That article is still worth reading and remains largely valid. Ultimately the key argument then was that the choice of tool did not depend only on features, but also on the concept behind the software. This is a timeless truth.
However, MediaWiki does not need to fear a direct feature comparison. Importantly, the enterprise distribution BlueSpice has already decided the feature question in my view. This can be seen on our newest internal feature-comparison table, published here and offered for free download:
Administering several individual wikis is technically intricate because all too often, a confusing “wiki chaos” develops, which is difficult to take care of. In this area there is already a concept which has proved itself: the wiki farm.
Several wikis can be created, archived or deleted quickly and easily by using a wiki farm. When creating wikis, the user has the option to create an empty wiki or to clone what is known as a “master wiki”. Such a master wiki can be already filled with content (e.g. handbooks), or contain files and configuration data, all of which can be transferred and supplied.
From a technical point of view, by using the farm concept, one can provide several wikis with just one wiki installation. The wiki software is only installed and saved once on the server and all the wikis use this installation together.
We have had an increasing number of enquiries from customers over the last few years for whom the best possible solution is provided by a wiki farm. Many have the problem that a single wiki is no longer sufficient, because they need to reflect the most differing topics, languages and permissions concepts. In such cases, we always recommend the use of several wikis via our wiki farm solution.
It is that time again: we are very pleased to announce the new BlueSpice release 2.27.1, and it is difficult to believe that this is only a patch release.
When we consider the new features, Version 2.27.1 is right at the forefront. The first release of this year focuses on the optimisation of usability and applications in quality management, alongside bug-fixes.
The installation of wikis and quality control of the wiki software is still generally done by hand. Obviously, this increases the costs for the customers. And the software producers do not find this repetitive work much fun either. Continue Reading
With BlueSpice 3, we replace the previous VisualEditor with the MediaWiki VisualEditor, which some people will already know from Wikipedia. This leads to questions, for example: Why are we changing now? What potential does the editor have? And what is the situation with real-time editing? Continue Reading
Everything used to be simple: database queries for structured data and full-text search functions were conceived separately. But that is now history. In new search engines, metadata can be searched for much more selectively. These new possibilities blur the distinction between a database query and a search function. What does this mean for the technological development of wikis? Continue Reading
We are currently fitting out the new Version 3 of BlueSpice with a new search engine. So this is a good opportunity to explain what actually happens in a search engine and why we have decided to make this change. Continue Reading
I can hardly believe it: the current version of BlueSpice, BlueSpice 2, will be four years old this year. It feels like just a few months ago that we announced Version 2. Anyway, it is now time to start thinking about a new version and to continue writing the road map.
At Hallo Welt! we have spent the last months collecting ideas, and checking and weighting requirements.
At our yearly strategy meeting, Markus Glaser presented his technical plan. So now it is official that we will publish a new BlueSpice Version 3 in the first quarter of 2018. The road map for our new MediaWiki distribution contains essential innovations and improvements we have wanted for a long time. BlueSpice 3 will achieve a new level of stability and flexibility. Continue Reading
Our focus: quality assurance, usability and farming.
We proudly announce today’s stable release of the new BlueSpice for MediaWiki 2.27.0. It is our second release this year and brings new features and numerous optimizations. Above all, it is fully compatible with the long-time support version MediaWiki 1.27.
The Wikipedia software MediaWiki is a well known solution for collaborative knowledge platforms. It is less popular, but not less ideal, for the development of prototypes and new platforms.
At this year’s Semantic-MediaWiki-Konferenz (SMWCon) in Frankfurt, our Hallo Welt! Technical Manager Markus Glaser talked about this connection between MediaWiki and prototyping. Here are the slides of his presentation.
Markus Glaser started his presentation explaining different forms of prototyping. His introduction was followed by showing MediaWikis richness of functionalities. By combining and expanding these functionalities, you can develop new and very specific applications. MediaWiki already provides a large toolkit, which allows quick adjustments without having to program completely new functions.
The semantic MediaWiki extension packages, which can be used to capture and query metadata, are certainly worth mentioning. Those are very useful, if for example data models are being modeled or user interfaces and operating elements still have to be positioned. Of course BlueSpice for MediaWiki supplies a wide range of options. Responsive skins like Chameleon are the basis for stylish surfaces. And with Lua you have a script language, with which the construction of a page can be designed very dynamically.
That means MediaWiki is an ideal base to build agile new knowledge platforms. The flexibility of MediaWiki means a great advantage in time. You don‘t have to be a programmer to build these prototypes, because a lot of these things can already be done with the integrated tools of MediaWiki. Like this you get a working system at an early stage, with which you can gather important experiences.
Nevertheless users should be aware that, despite the variety of integrated tools, developing a new knowledge platform is always complex and cost-intensive: planning, meetings and adjustments take time. After the development of an alpha or beta version, individual functionalities have to be professionalized and programmed independently.
You might say that the development of a stable productive system takes as much time as the development of the beta version for the first test users. However, the time and the risks of development are significantly reduced with the prototyping based on MediaWiki.