Jason Bock works for a company called DSA, which primarily does IT Support for the US Department of Defense. He is responsible for milWiki, a military enterprise wiki started in 2008 to be an „online internal encyclopedia for the US Department of Defence“. Milwiki is one component of an overall suite of DoD social business tools called milSuite. The milWiki alone supports 400.000 users and contains more than 20.000 articles in more than 7.000 categories.
In 2010 Semantic MediaWiki and later Semantic Forms were introduced to milWiki, which had a major impact on the data integrity.
In his talk at the Enterprise MediaWiki Conference 2016 in New York Jason Bock informed about some social aspects they built into the system also implemented by the functions of Semantic Mediawiki.
Instead of „normal“ wiki user page there is a template/form with certain fields,
Minimum information of the user like name, foto, skills, location and some tags to match across users,
Alternatively, the PageNotice extension can add a template with information on acquired points or badges in the header or footer of the user page.
Customer wanted to have a rating tool like in TripAdvisor
Elected to go with the SemanticRating extension which places a form on any wiki page generating a subpage for the rating and the review.
Implemented an template which shows all ratings and reviews in a list attached to the article
Calculation from all the ratings on the subpages to get an average score of „stars“
Introduces elements of gamification to the wiki
Rewards users for creating, editing and gardening efforts
Special feature: points for users for each additional author who contributes to a page that user created
Point calculation shown in a sidebox on user page
Automated User Badges
Manually badges did not work,
Automated badging system like in Foursquare and ProjectNoah (National Geographic),
Rewards participation within specific topic areas,
Helps to identify the experts for certain topics,
Tap into Semantic Ratings effort to reward users who receive positive reviews on articles.
At the end of the talk Jason shows some very useful code examples concerning the mentioned social functions.
Communication and notification – the end of the classical discussion pages
Another MediaWiki construction site is delivering good news: The MediaWiki Communication System. This concerns the discussion pages. These will soon disappear, in the form we know them now. More precisely: The discussions pages will fundamentally change and merge with the notification system.
The reconstruction of the MediaWiki communications system will take place through two new extensions:
Echo allows the individual following of changes, gives an overview of the whole system and is a framework for a variety of communication services. Echo is already in Wikipedia as a new notification system.
Flow makes discussion easier. One can more easily follow discussion processes; answers are shown via Echo. And much more. The aim of these developments is to build up a modern discussion and collaboration system for all Wikimedia projects. An interactive prototype is already online.
Anyone who has written or improved Wikipedia articles in the last few years, already knows about the Visual Editor, which has now reached a certain maturity. (See the post by Nathalie Köpff on this subject). Creating such an editor is a big project. Unlike other web applications, an editor for Wikipedia must not only work with different languages (for example right to left languages), but also be able to process the multitude of wiki functions, the template system, the magic words and many more things besides. So for this, the wiki text parser Parsoid needed to get a totally new technological basis. As Wikipedia develops further through web standards (browsers, protocols, languages), the task will remain a complex one for a long time. However, it is also a rewarding project which has significance for the whole web community – as, for example, no commercial provider would develop an editor for over 100 languages and make it available for free.
Nevertheless, the project is still controversial in the Wikimedia community to this day. This is partly because the introduction of the editor has lead to significant complications. The editor was simply not ready to use when it was implemented for the first time.
The scepticism in the community towards the editor, however, also has to do with the fact that its increasing use allows for a wide reaching dropping of Wikitext. What, for some, is a good opportunity is, for others, a loss of design potential. As up to now, it was possible to build many small tools with the standard resources (for example templates or overview lists). Even simple formatting is significantly more efficient for experienced wiki text users.
However, over time, Wiki code, which should make editing easier, has almost had the opposite effect. Editing a wiki article needs a certain amount of experience and skill. This is, however, not sensible, as many hand-made functions can be done more elegantly with corresponding extensions.
A great deal of identity and a bit of wiki philosophy is attached to the transition to the visual editor. For some wiki authors, it may be a restriction, but for the wiki world outside Wikipedia, it is a great leap forward. The standard ways of using wikis have changed; most wikis work in much less complex ways than Wikipedia, which has always been a special case with its own particular demands. For this reason, a native visual editor is a long overdue step for many MediaWiki users. It is necessary so that wikis can be used to build up new free knowledge hubs on the web.
Simultaneous editing of texts
A further, very ambitious project was introduced at Wikimania 2014. The aim is to enable the simultaneous editing of texts, that one already knows from Google Docs. This has been considered for a long time. However, the necessary resources for the project were not there. Now, the Deputy Director of the Wikimedia Foundation, Erik Möller, has announced that the first prototype should already be available in a year. This is very exciting news.
Two points are not being discussed at the moment, but could become important in the future.
Speech2Text: Texts in wikis should be increasingly possible to dictate. “Speech2Text” is developing into a standard as the speech recognition software has made great strides in the last few years. We will see that speech-control can be performed in Google search.
Draft function: On top of this, a real draft function is needed for MediaWiki. Every trust and NGO with local groups needs to be able to develop texts for projects, for example. Up to now, they have been diverted to Google Docs or Etherpad. But these two applications are totally inappropriate for the public collection of knowledge for a number of reasons.
For this reason there should finally be the chance in MediaWikis to edit a first drafts with just a small circle of authors before the text is released generally.
Overall, we at Hallo Welt! see this development as very positive as MediaWiki will become more user friendly. Using it will be more intuitive and working with the editor more stable. Our enterprise distribution will take these developments on, customise them and make sure they are continually developed.
There is a lot happening for MediaWiki at the moment. Further development of the software has been getting recognisably bolder for more than a year. It is getting exciting! In 2015 we will see many changes which up to now have been being worked on in the background. In just a few years, the system will no longer be comparable with today’s MediaWiki. Both the technical architecture and the user guidance is being rethought and tailored to the new expectations of the users. We want to quickly introduce you to the newest development projects.
The new impulses in MediaWiki development come primarily from the Wikimedia Foundation (WMF), the operator of Wikipedia and its sister projects. The foundation sees its core task for the future as software development and is looking to build up its personnel in this area a great deal. The new executive director of the foundation, Lila Tretikov, announced in October 2014 that the majority of investment will flow into product development and software development. Within this, priority will go to building up mobile functionality (for more on this see the entry by James Temple). Continue Reading
WYSIWYG (What You See Is What You Get): The visual editor enables writing and formatting in your wiki without the use of wiki mark-up characters. You can often see the phrase “write just like in Word” in marketing texts even though, to be honest, this often gives the user false expectations. One should always keep in mind that this is and remains a browser-based system. Nevertheless, the visual editor makes writing and formatting in the wiki a great deal easier.
The wordsmiths in Wikipedia (which runs with the wiki engine “MediaWiki”) had to wait for such an aid for a long time. Despite many initiatives, Wikipedians have had to craft their knowledge into articles without a visual editor until very recently. Finally there is now a visual editor in the Wikimedia projects (Extension: VisualEditor) available as a beta. This is updated each week and can generally be activated when the user wants it.
We present three editors below. There are further editor extensions listed, for example on mediawiki.org, however, they have generally been discontinued or are at least no longer being followed up. (To see a larger version of a screenshot, simply click on it).
Extension: Wiki Editor
This extension is currently being deployed and is delivered with MediaWiki from Version 1.18 on, in order to make editing a little easier. The essential functionality is to insert wikicode characters at the touch of a button, which then only need to be edited. Therefore, one does not need to remember the code, but one still has to understand it. This means it only makes editing easier under some conditions and is not a real WYSIWYG editor.
Extension: Visual Editor
There is no visual editor currently being delivered with MediaWiki. However, on the development platform “mediawiki.org“, there is a developer initiative for a rich-text editor for MediaWiki. There has been an initial beta version on this platform itself since 2013 with some of the essential functions, which, however, is targeted specifically for use in the Wikimedia project “Wikipedia”. This editor is now also available on all versions of Wikipedia as a beta feature for all users who are logged in.
The editor makes a very good impression, even though it is still obviously a beta version, and some essential functions like, for example, the table function, are missing – which for me is one of the main reasons for having a WYSIWYG editor. Here is a little information on a few select functions which I need in my everyday work:
Inserting media is very easy here, as an initial selection of suitable pictures is filtered in advance from the system using the article title. This can be, but is not always, useful. Uploading pictures is just as laborious as before. One needs to change page, calling up the upload page which is separate.
This is rather annoying, particularly at the start. After time you get faster and keep the upload page constantly open in a separate tab, then you can save a lot of time with disconnected uploading. One can already insert templates via the visual editor presented on mediawiki.org.
This also seems very easy at first glance. Initially, only internal links are suggested, these being subdivided into new page, redirects, disambiguation pages and suchlike. What one does not see at first sight: if you enter the URL of an external page, this will be recognised and entered as an internal link.
If one begins to type a name in the field, but then interrupts this (for example by clicking outside the dialogue), then what you have typed will be accepted as what is known as a red link. You have to make sure that you remember to click on cancel in the dialogue.
Changing between WYSIWYG and code
Suppose I want to check or change something in the code and then carry on working in WYSIWYG. Then I have to save the page first and then reload it. I find this irksome.
Visual Editor from BlueSpice for MediaWiki
BlueSpice has come up with a fully developed WYSIWYG editor including table functions and business-specific adaptations. I am now writing a lot in Wikicode but the well-organized WYSIWYG editor is worth its weight in gold, especially when writing tables. Checkboxes and checklists can be inserted which is very helpful for company wikis with minutes and to-do lists. On top of this, the editor includes a spell checker from Version 2.22.2 on. You can also switch between WYSIWYG and wiki code whenever you like by pressing a button. For this reason we do not discuss this further here.
You can search for files you have uploaded in the dialogue for inserting pictures and other files. You can specify the size, link destination, borders, etc. before inserting a picture. Furthermore, there is an upload tool. This means you can upload a file, assign it a category, and insert it in two steps all on the same page. If you have the package [paste image], then images can even be pulled into the editor with drag and drop. The only annoying thing is that sometimes the picture you have inserted is not displayed with the right configuration immediately. However, one can see if everything looks right by going to the preview.
There is also a tool for inserting categories, like in the MediaWiki VisualEditor. However, in BlueSpice, this dialogue can also be called and used when in the reading view without having to change to the edit view.
The dialogue for inserting links is subdivided into several types of link. I can choose a namespace, article name, description, or enter one (for example when creating red links). If one chooses a namespace, then in the field underneath the pages will be automatically sorted for you to choose from. What is missing, in comparison to the MediaWiki editor is the differentiation for redirects and so forth. This, however, plays a much larger role in Wikipedia than in company wikis.
Working with tables
The number of rows and columns can be entered easily via the toolbar. If a table in the article is selected, then further table-specific functions are shown in the toolbar such as insert column or row.
The table can also be given a design (formatting), also just with a click in the toolbar. The table will then be given the correct properties, from colour or the possibility for the user to sort the contents to the properties of a normal contents table. As several designs can be used simultaneously, this can, however, sometimes lead to confusion.
Furthermore, the right mouse button lets you specify properties for the whole table, row, column or cell. You can also merge selected cells here. The width of columns can also be fixed, as a percentage of the browser width or as a number of pixels. However, be careful: it is not possible to define the column width for each row.
The table functions of this WYSIWYG editor are valuable when you need to create complex tables or for tables which need to be edited regularly (for example to-do lists).
The Wikimedia development team is on the right road. We (the development team at Hallo Welt! – Medienwerkstatt) are waiting eagerly for the day when we can switch to using the MediaWiki editor, as the development of a reliable editor is very time-consuming. At the moment, however, there is no way we could contemplate this. Directly comparing it with the visual editor from BlueSpice, we find that the BlueSpice editor has more of the important functions, particularly for enterprise wikis and came out of the beta phase a long time ago. Alongside this, the WYSIWYG editor from BlueSpice also works with Internet Explorer (IE 9 or higher). This is important for many companies, as the use of Internet Explorer is compulsory in many companies. IE compatibility is on the roadmap for the VisualEditor from MediaWiki, but it is not yet usable. The visual editor is initially not even activated in Internet Explorer.
BlueSpice for MediaWiki is a commercial project. The plan to develop an enterprise distribution for MediaWiki was driven by the aim of making a profit and creating jobs.
Nevertheless, it is time to say a few words about other aspects of the BlueSpice project. For BlueSpice is also a project that should push along the development of MediaWiki and the construction of free knowledge platforms on the Web.
I will consider three aspects here.
1. Wikis are society’s future repositories of knowledge and BlueSpice should make a contribution
An open society needs a place to gather knowledge, to organise it and to map it. In the future we will find society’s memory on the Web. Political Wikis show how important this memory is. Lobbypedia and its English predecessor powerbase from spinwatch are two good examples. NGOs collect information there about lobbyists, politicians and organisations making networks and strategies transparent and making the information available for research. Think Tank Network Research is a similar research project. I could go on and on with this list.
It is not just in politics that we need a central platform on the net where we can collect free knowledge centred on particular themes, but also areas like leisure, culture, sport, business and health. Regional and city wikis have already become the trailblazers here.
And there will be wikis which save content from other websites so that it can be further developed and worked upon.
There is no system better suited to such tasks as MediaWiki software. And MediaWiki has a special role because the software is available under a free licence and, being an integral part of the Wikimedia projects Wikipedia, Wikimedia Commons and Wiktionary, has the best outlook for development.
So that the operators of wikis can carry out their work with significantly less technical personnel and budget than Wikipedia, they need MediaWikis which can be expanded with inexpensive software packages fitting their needs.
So BlueSpice publishes its free version, not only for marketing purposes, but also so the software can make life easier for those involved in such projects.
2. MediaWiki is becoming a software framework and BlueSpice is a step on that road
More and more projects are starting using MediaWiki as a basis and putting further pieces of software on top. With MediaWiki, you can operate an online encyclopaedia. However, if you does not want to do that, you will need another user interface but you can continue to use the basic structure. This means that the basic system stays the same, MediaWiki, delivering authentication, rights management and categorisation. On top of this comes, for example, BlueSpice, making the system into a company wiki.
A couple of further examples:
Translatewiki extends MediaWiki into a collaborative translation management system.
There is an initiative in Germany, which builds on MediaWiki to safeguard the basic provisions for media. For this, MediaWiki needs a additional layer which can provide and manage films.
At Hallo Welt! we are doing something similar, working with the project LinkTank, a collaborative link directory, and with Musikwiki, a place for collecting musical score. In one project one edits music scores and on the other collects links related to a theme.
Wikimedia Commons also only needed to further develop the user interface to make a really attractive platform for a picture library beyond Wikipedia.
MediaWiki has a very special role in open source applications. The software is completely unrivalled as a framework for “collecting open knowledge”. WordPress would be comparable as a basis for communication and social networking solutions.
Thus, we see BlueSpice as one of many steps in the development of MediaWiki into a general framework for free knowledge. This process tests out new possibilities and builds up knowledge which can be useful for other projects.
3. MediaWiki needs an ecosystem and BlueSpice is a contribution to this
The most successful and innovative open source software projects have developed a vibrant ecosystem that putting together both non-profit and for-profit agents, each driving the development in different ways. A large circle of developers is created. The software can assert itself over propitiatory systems and even force them back.
MediaWiki has a very underdeveloped ecosystem compared to other software projects. This means that commercial development in the whole project can be put to good use. Many projects need, for example, a user management system in the backend. In this form, this is not necessary or possible for Wikipedia. All others, however, need exactly this extension. Now these were firstly developed for companies and are now available as free software. I could add many further examples from the development of BlueSpice.
We need, therefore, better general conditions and more energy for a MediaWiki ecosystem. It is true that the Wikimedia Foundation has recently invested more money and energy in software development. However, this will not be enough on its own. Even for sister-projects like Wikimedia Commons, the capabilities necessary are often not there. For this reason, the focus is on third party developers and one wants to support the development of a MediaWiki ecosystem.
This is a step in the right direction. The new initiatives from the Wikimedia Foundation, to develop MediaWiki further and to create a new economic setting is bringing new energy to the whole project. This will open up new vistas to free knowledge projects.
Here, BlueSpice is just one cog in the machine. But it can and will be the basis for completely new types of project.
The decision, in the end, will be made by the users and the community.
If you would like compare MediaWiki with other wikis, you can look at the masks at wikimatrix.org.
You can find innumerable small wikis and also the larger, more well known ones. Both open source and proprietary wikis are listed.
As well as the features of the wiki one also has suggestions for service providers which offer support for the system. A list of other wiki systems comparable to that chosen are also displayed. As far as features go, it should be said that only the standard functions of the software are considered. If a system can do more than this is not displayed on Wikimatrix.
This is the central page for all questions about the software. The site is in English and many articles are translated into other languages too. A quick tip: start by clicking on “your language” in the box at the bottom.
Mediawiki.org organises the information about the software MediaWiki into three areas:
Users: How do I use a MediaWiki? How do I write something in it?
Administration: How do I install MediaWiki? Which extensions are there? How can I adapt the system further?
Developers: Developers handbook and further help assistance
As Wikipedia is the biggest and most famous project in the world, it has innumerable help pages available. Many users look here first as the articles are very well written. And also because mediawiki.org can be too technical or simply too “English”.
However: MediaWiki is the software on which Wikipedia is based, not Wikipedia itself. People often ask us: I have seen this in Wikipedia, where is that in my MediaWiki? The answer is: Wikipedia uses a specially adapted form of MediaWiki with specific extensions, integrated templates and configurations, which do not come automatically with the standard software. For this reason there may be differences.
The help pages from Wikipedia give an overview of all sorts of different topics. The pages are organised under “Help:”, which is called a namespace. This means that everything which has something to do with the topic “help” is found in this “space”.
Help on editing: How do I add a new page? How do I format the text? How do I add pictures? and much much more.
Using templates: Text blocks like info boxes to copy and paste and further tips.
Guidelines for good articles and basic principles – really worth reading.
Explanation of the software’s features, like for example namespaces.
Anyone who is fairly new should definitely start by clicking on the links you can find there. This takes you to the relevant portal where you can find many more important links to take you further.
YouTube: Screencasts for differing themes (the good ones are generally in English)
On you tube you can find some introductory videos. However, these are often about installation. Like this one for example:
There are also some videos about working in MediaWiki – for example creating and editing with templates. There are many tutorials on various themes in English; for example the youtube user “Kristinpedia” has posted many.
Help for BlueSpice for MediaWiki
And last but not least, advice on BlueSpice for MediaWiki. As this distribution is set up on MediaWiki, all MediaWiki help is also valid for BlueSpice. If one has BlueSpice installed, one can see some changes which affect how the wiki handles. A great deal is simplified, for example uploading and inserting images. You can find your first help desk for BlueSpice at hilfe.blue-spice.org. As far as the free support for BlueSpice is concerned, we are still very much at the start. Thus for all who want to spread their knowledge: Join in and make articles, videos, screencasts and so on about working with BlueSpice.
There are lots of possibilities for exporting MediaWiki articles as PDF documents.
Some further developments I want to outline here:
Wiki as the central source of knowledge
There are many good reasons for supplying a Wiki with a PDF export facility:
Extracts, logs, check lists or short descriptions may be needed on paper or may need to be sent via e-mail.
Whole topics or areas of knowledge may need to be made into brochures or books so they can be available, for example, on the website for users, service providers and partners, or offline for field staff.
Intermediary versions of handbooks might need to be kept, for example, to supplement contracts and invitations to tender or as documents giving a basis for auditing.
Using a wiki as a central medium here has the obvious advantage that rather than having innumerable PDF documents flying around, the texts can be developed in the wiki and kept up to date. The PDF export function will then give out the most up to date version.
How to create my first PDF export
If you want to add a PDF export facility to a wiki, first work out whether you just want the readers to be able to export individual articles as PDFs or if you want to give them the opportunity to put together a selection of articles in a “book”. The second option is a more technologically complex.
Furthermore, decide whether the firm’s CI should be used and how far you want to go with providing the user templates. Will the PDFs always have the same layout? Do they have, for example, the same coversheet? As soon as this is decided you can get started.
MediaWiki has no PDF export facility in the standard software. However, you can find a whole set of PDF extensions at MediaWiki.org with individual installation instructions: Continue Reading
When businesses want to make use of professional wiki software, they come quickly to the question of whether they should choose MediaWiki or Confluence. Confluence is a wiki specially developed for the needs of businesses. The concept for MediaWiki is, on the other hand, for the huge online encyclopaedia Wikipedia. Having more than 750,000 downloads per year, MediaWiki has a decisive lead as the standard wiki software, in business too.
Fans of Confluence used to complain that MediaWiki was not really suitable for businesses. And one can find serious comparative studies which completely ignore the possibility to extend and adapt MediaWiki. However, the extendibility and adaptability of MediaWiki is an essential feature of the software. The project page MediaWiki.org alone lists more than 1,800 extensions.
And, since the publication of BlueSpice, there is a completely free enterprise distribution for commercial users, which can be extended to suit individual needs via modules.
To show how MediaWiki really is a solution for business, I have collected together the most common objections to MediaWiki and I comment on them below. Continue Reading
The structure and design of most wikis looks like Wikipedia, which is now over ten years old. It does not have to be like this. If you want to give your wiki a different look, you need to use a different skin. Changing the appearance of a MediaWiki (and also BlueSpice) installation also changes how it handles. I have collected together a few tips and ideas here and I also explain the steps planned for the BlueSpice skin.
Look at these wikimedia projects which all use the current “Vector” skin. Vector was developed in 2009 for MediaWiki 1.16+ as part of the Wikipedia Usability Initiative and improves on its predecessor Monobook, giving a clearer presentation and better usability. In addition, some special functions can be downloaded as vector extensions.
MediaWiki is already working on the further development of the standard skins. The next stage, the Athena skin, will support mobile devices, amongst other things. You can get a visual impression of Athena here. Continue Reading