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 <[email protected]> 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: > > 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 <[email protected]> > 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.org<http://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.org<http://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.org<http://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
