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 <[email protected]> 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 <[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 > _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
