I agree completely with Boris about access control. Only with a combination of Two extensions: Lockdown and SemanticACL have I ever been able to get to a reasonable level of access control that I desired for my wikis.
I half disagree on the advanced user aspect. The freedom of design that advanced users have in designing their wiki is one of the great aspects of a wiki. However, like most things in the Mediawiki world, it comes with a big downside: a massive learning curve.
I think, however, the solution lies in a more effective and engrossing Mediaiwki site. Most website operators know Mediawiki has extensions, but how many know it has javascript and css snippets? Mediawiki.org should have more clear sections -- I suggest for a start: extensions, JS snippets, css snippets, templates (wikipedia templates, etc., posted by users with clear documentation of what they do). Each section should be searchable by the most important aspects (date, function, author, etc). Encourage users to post videos on the how, what, where of their extensions, templates, etc.,.
Have a section on Mediaiwki for developers looking for work and a place for users to post jobs. Other platforms have free licenses, but still allow developers to post software for a fee. I doubt the free software would disappear, but I'm sure new developers would flock in if they could charge $25 for a new extension. (Maybe even make it a benefit for Mediawiki with Mediawiki.org taking 10%). See Joomla for examples.
Mediawiki is a great platform and like other platforms (Wordpress, Joomla. Etc) developers should be taking it into all sorts of ways outside of the Wikipedia experience. I've seen Mediawiki used as a CMS, a social networking site, a blog, and even a commercial enterprise, but almost all of these uses were crafted by outsiders.
Mediawiki should also have packages of templates, forms (if it's a semantic form package), and extensions that users could grab to create x. Maybe a package for creating a copy of wikipedia, wikivoyage, or some other pre-defined package. Once again, it's all about making everything easy...
Sent from my iPad
On Jan 27, 2015, at 3:30 PM, Boris Steipe boris.steipe@utoronto.ca wrote:
Chris has made some excellent points and I agree emphatically with all but one:
IMO for the advanced user not all is good.
Maintaining and customizing a Wiki is a pain and always has been. Some of the pains have been listed by Chris, but consider: to be effective you need to have at least a working knowledge of
- wikiMarkup
- template syntax
- html
- css
- php
- javascript, and now
- lua
For those of us for whom administering Wikis is only a small part of our mission, this makes no sense. Moreover it's an increasingly significant barrier to introduce newcomers to the technology. For the last five years or so I have had my students author Wiki pages to introduce them to the benefits of a collaboration/documentation system. I am losing confidence that this is still an effective, modern approach with a reasonable ROI of their time.
And there is the old, old issue of access control. Whenever this comes up, we only hear: MW is not a CMS. Then why not make it one if the users need it? </rhetorical_question> Actually the question hasn't come up in a while, now that I think of it. Actually not many questions about day to day Wiki problems have come up recently at all anymore. This list has become pretty silent.
Maybe not a good sign.
Kind regards, Boris
On Jan 27, 2015, at 5:48 PM, chris tharp tharpenator@gmail.com wrote:
HI all,
As an entrepreneur who stumbled into a building a Mediawiki site here's my two cents.
Conceptually, I think, Mediawiki development should be guided by the following principle: is it easy? And that principle should be applied by reference to a hypothetical user at every level of interaction with Mediawiki. The levels of interaction I see are:
- Info seeker. To me that's hypothetical equal to someone searching Google.
For the info seeker Mediawiki should be easier to search. Modern users assume a "Google Like" experience, which the standard Mediawiki search function does not delivery.
- User. Someone who just adds data, text and media. Hypothetical equal to
a Facebook User.
Modern users don't expect to write in arcane wiki syntax. A Visual editor that allows editing by sections would be a needed first step (and hopefully one that could be used with Semantic Forms).
Media handling and placement is horrible for users. A user should have the experience that they're uploading into the page they're editing. Currently only the Semantic Forms extension and the Msupload extensions, to my knowledge, give the experience of uploading to the page one is editing. The interface for uploading files in Semantic Forms, however, is old. The Msupload experience is far better for the normal user, but has no way to set a license. After upload to the page one is editing the Visual editor should allow a drag and drop placement of media on the page.
Outside Media, such as videos from YouTube, is currently handled by a host of extensions all of which require using some form of wiki syntax, or knowing which section of a url to use. A modern user expects the "magic" of dropping the url address in a field and having it magically become a YouTube video, Soundcloud audio file, etc. (this is most likely outside of standard Mediawiki issues).
Communication -- talk pages are very confusing to modern users. Flow looks like it's heading in the right direction, but I would add the ability to "easily" add media files. A photo or video many times is much clearer to an end user than text. A button to add a photo or a video into the flow feed would be a great improvement.
Access Control -- Users should "own" their user pages (which can be done today via some extensions). Additionally users should control the moderation of their own talk pages with the ability to "block" users. (currently not possible with any Mediawiki extension that I know of)
- Advanced User. Someone who creates templates, writes lua modules,
structured data (Semantic Mediawiki & Cargo), javascript (via Common.js & NamespaceHTML extension), uses other scripting languages inside the wiki (Phptags extension for example). No hypothetical equal except for advanced Wikipedia and Mediawiki admin.
For the advanced user all is good.
- Website Management. Should be hypothetical equal to someone else running
a Wordpress site.
As someone else said composer is for nerds. Extension management is horrible inside Mediawiki. A GUI inside the wiki that checks the status of the extensions, uploads the extensions, uploads other depend software, and uninstalls extensions would be a great step in improving Mediawiki.
The Visual editor & Flow require node.js to be installed, which means the mass majority of wikis will never have them.
Could your average Wordpress owner set up a Mediawiki with a good search extension? For that matter could an average Wordpress owner set up the Pdf Handler extension?
How many Wikis are never updated, or have never had any maintenance scripts ran because it's too technical? How many use the crappy search function because it's too technical to install a good search extension?
Extension Management on Mediawiki.org is less an ideal. The Extension Matrix broke down a long time ago, but nothing has replaced it. To find a new extension either one hears about it somehow, or one stumbles across cross it in the sea of all extensions.
The world has gone Mobile, but Mediawiki really still hasn't. Mediawiki must become more responsive in it's design.
As I said in the beginning it all comes down to: Is it easy? It's hard to make things simple, but it is direction of the world. I would hate for Mediawiki to become the software equivalent to MySpace.
On Tue, Jan 27, 2015 at 10:45 AM, Koerner, Chris L Chris.Koerner@mercy.net wrote:
I’m a light Wikipedia (and related projects) editor, but help to maintain and support two decent sized (hundreds of contributors, thousands of pages) internal wikis in the healthcare industry. Our organization has been using (Semantic) MediaWiki for over 6 years. I’ve been maintaining it for over 3.
The first item we'd like to discuss with MediaWiki users is what should we actually focus on?
Out of the box experience - As I was putting together this list I thought about how many of the things I do when I setup the wikis. The default installation does include some handy tools, but almost everyone I’ve spoken to has their own brew of extensions they setup by default (I have upwards of 50).
I would love to see improved first-run experience and documentation (on mw.orghttp://mw.org) on what is included by default, what the extensions do, where do I go to get more, etc.
Editing - I think VisualEditor is the future of wiki editing. Wikitext is powerful and at the moment savvy editors can do more than VisualEditor, but that gap is closing. I’ll meet with many internal teams wanting to move away from email archives and Word docs for their documentation needs. I go over the philosophy of MediaWiki, explain it’s features (watchlists are magical!) and then I get to editing. Eww. People think it’s gross and backwards. People expect easy-to-use WYSIWYG editing - and they should have it. I’ve spent more time explaining and fixing wikitext errors than I’d care to admit.
Just in the past few months the VisualEditor team has improved support for things my co-workers care about - IE support and tables. I think Mediawiki should increase the push for use of VisualEditor in third-party wikis. I’ve been running it for a year now with great success.
More consistency in WMF extensions - There’s an inconsistency in documentation, UI/UX, and architecture requirements between WMF-backed projects.
One extension might lack documentation, another has a specific technical requirement, another uses a unique UI paradigm, another an entirely unique set of iconography (for similar actions!). I expect this when dealing with individual non-WMF extensions, but from the same organization?
An example: VisualEditor is great and I think it’s use will continue to grow. But holy cow is it a big requirement to have to install node.js on top of the LAMP stack. Another: MW core requires PHP 5.3.3, but Flow requires 5.3.6. PHP 5.3.3 is the default install for RedHat RHEL 6 - a common flavor found in many enterprise environments (like my own). Getting PHP updated is not only a technical challenge, but also an administrative one inside large organizations. The server team wants to stick with what is supported via the vendor, I want to use the latest innovative features. Conflict arises.
More consistency in extensions in general - There’s an opportunity to show a focused, collaborative, platform for the experience within MediaWiki - and extensions from all sources. Where’s the MediaWiki Style Guide for buttons, dropdowns, menus, etc? Some use bootstrap, some use jquery, some follow WMF’s designs. Developers from all walks are making cool things, but let’s make cool things like behave as part of something bigger. WordPress, while not perfect, is a great example of a robust ecosystem of 1st-party and 3rd-party extensions attempting some semblance of integration.
Updates - Composer is for nerds. I mean that in a positive way - I’m a self professed nerd (as shown by the length of this response). Composer, and the traditional installation/update methodology for extensions is cumbersome and yet another requirement. I want a one-click update button from a Special: page. It would alert met to available updates (from mediawiki.orghttp://mediawiki.org or git gerrit) and let me install them without touching a Terminal window. Yeah, I know that there’s a lot of crazy interdependencies between MW versions and extension version - and between extensions themselves. Maybe that’s telling? How do other open-source projects accomplish a much more unified install/updating experience?
WMF Extensions (or any really!) prepackaged with necessary templates - UploadWizard is a great extension that makes the uploading of images super easy and consistent. I love it. However, it requires numerous template files and images to work, none of which is documented or included. I don’t need to include every language and deep documentation for all those templates. Just the basics.
If you use MediaWiki for your own wiki, what sort of things do you think need more attention?
Uhh, I may have gotten carried away with the first question. See above? I think some of my thoughts touch on the cultural aspects of MediaWiki. We’re a diverse group without a lead on some of these things. How do we get big things done like improving extension documentation? How do we make the experience more consistent when there are hundreds of cooks in the kitchen? How can we encourage popular developers to lead by example? We’re a very technical community - more so than say (again) WordPress. There’s a large dev-focused community around that particular software, but there’s also a large group of people just using it! I think communication should be a bigger area we focus on.
How can we help you find out about things you need to know to run your wiki?
Documentation on mw.orghttp://mw.org. Regional (or online) hangouts - where I can see someone’s screen as they talk about something. Social Media
- twitter in particular. I feel like it’s hard to know about discussions
(like the removal of site stats) as they’re happening. I’m into MediaWiki developments, but not to the point where I read every Request for Comment (RfC). How do we bubble up that to more folks using MediaWiki?
--
Shameless Plug: If you’d like to share the work that you’re doing with a group of 3rd-party wiki folk, you should attend SMWCon Spring 2015: http://semantic-mediawiki.org/wiki/SMWCon_Spring_2015 . I’m the Local Chair for the conference and would love to see you there. I’d be happy to set aside some time on the third day to continue discussions like this one.
Nerd in Residence, Chris Koerner This electronic mail and any attached documents are intended solely for the named addressee(s) and contain confidential information. If you are not an addressee, or responsible for delivering this email to an addressee, you have received this email in error and are notified that reading, copying, or disclosing this email is prohibited. If you received this email in error, immediately reply to the sender and delete the message completely from your computer system. _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l