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.
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:
1. 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.
2. 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)
3. 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.
4. 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
A system that that checks and automatically / semi-automatically update installed extensions (either per a set schedule or at the time of a MediaWiki update) would be fantastic, as chris tharp states
*Mlpearc* Founder Everything Food & Drink.org everythingfoodanddrink.org http://www.everythingfoodanddrink.org/w/index.php/Main_Page
On Tue, Jan 27, 2015 at 2: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
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
well since you asked.... 1. make all common templates & extensions interchangeable in a manner like the media from $wgUseInstantCommons = true;. i.e write or update & they work in all enabled sites like photos do. 2. be able to set all scripting languages to be used as needed in a manner like $wgScriptExtension = ".php"; $wgScriptExtension = ".lua";$wgScriptExtension = ".js";$wgScriptExtension = ".pl"; 3. Do away with external extensions for scripting make mediawiki aware of and able to use any installed scripting language.
I'll likely think of more but for now these would be welcomed changes.
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
I second that, just because Wikipedia is open to all editors does mean our installations have to be.
*Mlpearc* Founder Everything Food & Drink.org everythingfoodanddrink.org http://www.everythingfoodanddrink.org/w/index.php/Main_Page
On Tue, 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
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
On Tue Jan 27 2015 at 3:41:12 PM Mlpearc mlpearc@everythingfoodanddrink.org wrote:
I second that, just because Wikipedia is open to all editors does mean our installations have to be.
Perhaps MediaWiki is the wrong tool for you then?
-Chad
Chad -- why would Mediawiki be the wrong tool if someone wanted to exercise some form of access control? Considering the number of extensions that have created for different types of access control it seems to be a very popular desire. Just because someone desires access control doesn't mean that they don't want the wiki experience elsewhere in their website -- they just don't want it on every page. (Implicitly Mediawiki developers agree with this philosophy since all Mediawiki Namespace pages on every wiki have access control). Strangely the only type of access control build into Mediawiki is a top-down centralized type of access control, which is strange when you think about it. Everyone agrees some type of access control needs to build into the software, but Mediawiki, out of the package, only allows a top-down centralized approach. Others just want more varied types of access control than the off-the-shelf model presented inside a standard Mediawiki.
On Tue, Jan 27, 2015 at 5:30 PM, Chad innocentkiller@gmail.com wrote:
On Tue Jan 27 2015 at 3:41:12 PM Mlpearc < mlpearc@everythingfoodanddrink.org> wrote:
I second that, just because Wikipedia is open to all editors does mean
our
installations have to be.
Perhaps MediaWiki is the wrong tool for you then?
-Chad _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Tue Jan 27 2015 at 6:17:35 PM chris tharp tharpenator@gmail.com wrote:
Chad -- why would Mediawiki be the wrong tool if someone wanted to exercise some form of access control? Considering the number of extensions that have created for different types of access control it seems to be a very popular desire. Just because someone desires access control doesn't mean that they don't want the wiki experience elsewhere in their website -- they just don't want it on every page.
There's lots of extensions. Doesn't mean they're all good ideas ;-) Wikis are meant to be open and all pages in a namespace should be equal. When they're not, that's what protection is for.
(Implicitly Mediawiki developers agree with this philosophy since all Mediawiki Namespace pages on every wiki have access control).
Sure, per-namespace edit permissions make sense. Because not all namespaces are equal. NS_MEDIAWIKI can damage the site so it's restricted by default. I totally could respect an argument for a wiki protected NS_TEMPLATE or NS_MODULE in the same manner.
Strangely the only type of access control build into Mediawiki is a top-down centralized type of access control, which is strange when you think about it. Everyone agrees some type of access control needs to build into the software, but Mediawiki, out of the package, only allows a top-down centralized approach. Others just want more varied types of access control than the off-the-shelf model presented inside a standard Mediawiki.
Sure, access controls make sense for different actions or namespaces (see above). I just think per-page ACLs are incompatible with the idea of a wiki and there are other tools better suited for the job.
-Chad
Agree to disagree. As far as per-page ACL what else makes sense in the User space? Additionally many other wiki software packages offer per-page ACL so clearly a lot of people don't see per-page access control as being incompatible with the idea of wiki. Yes there are other tools, but those tools are not Mediawiki (Extension like the Semantic Mediawiki and now Cargo I have never seen with other software tools) Many people, as measured by extensions, desire access control and don't see it as incompatible with the idea of a wiki or Mediawiki. (Personally I find the SemanticACL extension to be great when I want to restrict access on a per-page basis)
I would agree with you that per-page ACL is incompatible with a wiki if the "default" position was to change to restricted access on all pages. But this not what anyone is seeking. All the best to you.
On Tue, Jan 27, 2015 at 6:30 PM, Chad innocentkiller@gmail.com wrote:
On Tue Jan 27 2015 at 6:17:35 PM chris tharp tharpenator@gmail.com wrote:
Chad -- why would Mediawiki be the wrong tool if someone wanted to
exercise
some form of access control? Considering the number of extensions that
have
created for different types of access control it seems to be a very
popular
desire. Just because someone desires access control doesn't mean that
they
don't want the wiki experience elsewhere in their website -- they just don't want it on every page.
There's lots of extensions. Doesn't mean they're all good ideas ;-) Wikis are meant to be open and all pages in a namespace should be equal. When they're not, that's what protection is for.
(Implicitly Mediawiki developers agree with this philosophy since all Mediawiki Namespace pages on every wiki have access control).
Sure, per-namespace edit permissions make sense. Because not all namespaces are equal. NS_MEDIAWIKI can damage the site so it's restricted by default. I totally could respect an argument for a wiki protected NS_TEMPLATE or NS_MODULE in the same manner.
Strangely the only type of access control build into Mediawiki is a top-down centralized type of access control, which is strange when you think about it. Everyone agrees some type of access control needs to build into the software, but Mediawiki, out of the package, only allows a top-down centralized approach. Others just want
more
varied types of access control than the off-the-shelf model presented inside a standard Mediawiki.
Sure, access controls make sense for different actions or namespaces (see above). I just think per-page ACLs are incompatible with the idea of a wiki and there are other tools better suited for the job.
-Chad _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
See - that's exactly the kind of argument I mean. Chad - you just happen to be the one expressing this "idea of a wiki"; there's this odd underlying sentiment in the community that the tool comes with a philosophy. Many of us have our own, professional, very valid reasons why we need it to work differently, so we embrace all manners of kludges to make do. Yes, perhaps you are right and we should all move to other tools. Is that what the MW developer community wants? I'm not sure. There's such a huge amount of development that went into the project, it would be sad to slowly see it fade from relevance.
With respect, Boris
On Jan 27, 2015, at 9:30 PM, Chad innocentkiller@gmail.com wrote:
On Tue Jan 27 2015 at 6:17:35 PM chris tharp tharpenator@gmail.com wrote:
Chad -- why would Mediawiki be the wrong tool if someone wanted to exercise some form of access control? Considering the number of extensions that have created for different types of access control it seems to be a very popular desire. Just because someone desires access control doesn't mean that they don't want the wiki experience elsewhere in their website -- they just don't want it on every page.
There's lots of extensions. Doesn't mean they're all good ideas ;-) Wikis are meant to be open and all pages in a namespace should be equal. When they're not, that's what protection is for.
(Implicitly Mediawiki developers agree with this philosophy since all Mediawiki Namespace pages on every wiki have access control).
Sure, per-namespace edit permissions make sense. Because not all namespaces are equal. NS_MEDIAWIKI can damage the site so it's restricted by default. I totally could respect an argument for a wiki protected NS_TEMPLATE or NS_MODULE in the same manner.
Strangely the only type of access control build into Mediawiki is a top-down centralized type of access control, which is strange when you think about it. Everyone agrees some type of access control needs to build into the software, but Mediawiki, out of the package, only allows a top-down centralized approach. Others just want more varied types of access control than the off-the-shelf model presented inside a standard Mediawiki.
Sure, access controls make sense for different actions or namespaces (see above). I just think per-page ACLs are incompatible with the idea of a wiki and there are other tools better suited for the job.
-Chad _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
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
On Tue, Jan 27, 2015 at 5:26 PM, Chris Tharp tharpenator@gmail.com wrote:
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.
Chris, other than the User page protections you mentioned, are there any other specific use cases? We're reworking some of the authorization right now, and I'd like to support as many of the needs of our stakeholders as we can.
HI Chris
I was supporting a general position of Boris about the validity of some needing access control. I currently use SemanticACL so I can use restrict access on a per-page basis to a self-defined group within a page. It makes project management easier and it helps when that "page" group doesn't arise to the level of being a permanent user group.
On a boarder scope, which may be way outside the grounds of comfort, I support the wiki principle of trust the user. The page creator, if the admin of the site agrees, should be able to restrict access to themselves, a self-defined group of users, a user group, or public. Additionally the admin of the site should be to set the access control rights per Namespace. So maybe a main namespace page could never be restricted if the admin set it up that way, but a custom namespace could have creator access control.Of course, sysops should be able to over-ride the author's preference if it's a problem and additionally be able to reset the access rights (where access rights are allowed) how they think is right.
Those are my quick thoughts on access group.
Possible use cases:
1. User Space 2.Project Management -- self-defined page projects 3. Drafts 4.Portal Management 5. Encourage engagement by allowing an individual or group to "own" a page.
I think of more if need be, but hopefully you understand my logic; even if you disagree that Mediawiki should support it. All the best to you
On Wed, Jan 28, 2015 at 10:29 AM, Chris Steipp csteipp@wikimedia.org wrote:
On Tue, Jan 27, 2015 at 5:26 PM, Chris Tharp tharpenator@gmail.com wrote:
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.
Chris, other than the User page protections you mentioned, are there any other specific use cases? We're reworking some of the authorization right now, and I'd like to support as many of the needs of our stakeholders as we can.
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org