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 <[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
