In an ideal world, what features would the ideal Wiki Software have, and what would it be like?
If we can answer this question, developmental direction is made clear. It is easy to develop MediaWiki with view to improving it, streamlining it, ironing out bugs - but much more difficult to look beyond it; for the future of Wikimedia projects and general wiki success, new software must emerge that caters for the new functions required by modern wiki users.
What functions would set MediaWiki well above all other wiki engines for years to come? What features would make it the most efficient wiki engine? **What would the software be like if it generated maximal wiki success?**
To discuss this (what I find an interesting) question, I've set up a page at http://meta.wikimedia.org/wiki/MediaWiki_Ideal
Obviously the answers to these questions won't necessarily be possible to implement; but it would be interesting to know the answers nonetheless.
Look forward to some bright ideas :)
Virgil Ierubino wrote:
In an ideal world, what features would the ideal Wiki Software have, and what would it be like?
If we can answer this question, developmental direction is made clear. It is easy to develop MediaWiki with view to improving it, streamlining it, ironing out bugs - but much more difficult to look beyond it; for the future of Wikimedia projects and general wiki success, new software must emerge that caters for the new functions required by modern wiki users.
What functions would set MediaWiki well above all other wiki engines for years to come? What features would make it the most efficient wiki engine? **What would the software be like if it generated maximal wiki success?**
To discuss this (what I find an interesting) question, I've set up a page at http://meta.wikimedia.org/wiki/MediaWiki_Ideal
Obviously the answers to these questions won't necessarily be possible to implement; but it would be interesting to know the answers nonetheless.
Look forward to some bright ideas :) _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Faster loading time
M.M.
On 23/01/07, Virgil Ierubino virgil.ierubino@gmail.com wrote:
In an ideal world, what features would the ideal Wiki Software have, and what would it be like?
I have outlined some of my hopes for the future of MediaWiki in file/image management (ie. the Commons) in comments on this bug: http://bugzilla.wikimedia.org/show_bug.cgi?id=3712
I dream of a MediaWiki II that is actually designed to manage media - like the name implies. :)
Vastly improved and more flexible search would also benefit all wikis. There is a hella lotta potential for improving options when working with categories, too (for example, I envisage a drop-down list with options for the sort key - date page created, date added to category, page name (alphabetical - current default), date page was last edited. etc.
cheers, Brianna user:pfctdayelise
Speaking from the technical side, there is a hurdle with the "vastly improved searches" that are requested, at least on one aspect. The way MediaWiki currently stores its data is in InnoDB tables, which allow for simultaneous reads and writes with high efficiency and low lag. However, these do not contain a full-text search index; MyISAM tables do. The search index table is the only MyISAM table on the database, due to precisely that limitation. Currently, every edit has to be copied to the search table, usually by a script, and those take a while to run and consume precious system resources. Ideas as to how to make that process better are greatly recommended at Wikitech-l.
As for categories: date of page creation is not stored in the tables right now; that would be ideally something for the page table. The time a page included in a category is already stored (or at least, there is room for it), so that may be easier to do in the future. Dynamic sort tables have issues with older browsers, but maybe a sortby can be done by the server as well. These things do require a considerable amount of coding and testing, though.
Titoxd.
Titoxd.
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of Brianna Laugher Sent: Monday, January 22, 2007 11:05 PM To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] The Ideal Wiki Software
On 23/01/07, Virgil Ierubino virgil.ierubino@gmail.com wrote:
In an ideal world, what features would the ideal Wiki Software have, and what would it be like?
I have outlined some of my hopes for the future of MediaWiki in file/image management (ie. the Commons) in comments on this bug: http://bugzilla.wikimedia.org/show_bug.cgi?id=3712
I dream of a MediaWiki II that is actually designed to manage media - like the name implies. :)
Vastly improved and more flexible search would also benefit all wikis. There is a hella lotta potential for improving options when working with categories, too (for example, I envisage a drop-down list with options for the sort key - date page created, date added to category, page name (alphabetical - current default), date page was last edited. etc.
cheers, Brianna user:pfctdayelise
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi, What is great about MediaWiki is its capability for localisation. This is what sets it apart from other wiki-engines. There is however room for improvement. It would help the smaller projects if much of the maintenance where drastically improved. The long awaited integration of the "BetaWiki" functionality in MediaWiki proper and its integration in the Incubator is part of it. Some responsiveness for localisation issues like with the Marathi projects is another.
When a new recognised language is to be considered for MediaWiki, the first thing to do is to make the appropriate language file and be able to distribute it.
Thanks, GerardM
Virgil Ierubino schreef:
In an ideal world, what features would the ideal Wiki Software have, and what would it be like?
If we can answer this question, developmental direction is made clear. It is easy to develop MediaWiki with view to improving it, streamlining it, ironing out bugs - but much more difficult to look beyond it; for the future of Wikimedia projects and general wiki success, new software must emerge that caters for the new functions required by modern wiki users.
What functions would set MediaWiki well above all other wiki engines for years to come? What features would make it the most efficient wiki engine? **What would the software be like if it generated maximal wiki success?**
To discuss this (what I find an interesting) question, I've set up a page at http://meta.wikimedia.org/wiki/MediaWiki_Ideal
Obviously the answers to these questions won't necessarily be possible to implement; but it would be interesting to know the answers nonetheless.
Look forward to some bright ideas :)
On 23/01/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Speaking from the technical side, there is a hurdle with the "vastly improved searches" that are requested, at least on one aspect.
Retrieving the results is one thing. Improving how they are displayed is something that could be improved on too. For example we lack a gallery-based search. (Special:Newimages only searches on image titles. The functionality is there, so why not extend it to image descriptions?)
As for categories: date of page creation is not stored in the tables right now; that would be ideally something for the page table. The time a page included in a category is already stored (or at least, there is room for it), so that may be easier to do in the future. Dynamic sort tables have issues with older browsers, but maybe a sortby can be done by the server as well. These things do require a considerable amount of coding and testing, though.
Well, that's why it's my vision, and not my requests for next week. ;)
cheers, Brianna
Many of these have already been mentioned, but just to sum it up:
* Better search functionality (esp. with images, some kind of gallery view), maybe on the basis of tagging or category keywords. * A more user-friendly editing interface. This might need some serious interaction models to avoid a WYSIWYG interface that doesn't quite work. Having a nifty AJAX editing interface might be pretty cool, but it will probably need some serious work to make it as responsive as Writely / Google Docs. However, it could really enable less tech-savvy people to write more and better formatted texts. * A simpler system for templates/themes. Maybe not necessary for Wikimedia-related projects (because they are all using Monobook anyway), but for customization of other users a template system such as in Wordpress ( www.wordpress.org) would be handy.
-- Hay Kranen / [[User:Husky]]
On 1/23/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 23/01/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Speaking from the technical side, there is a hurdle with the "vastly improved searches" that are requested, at least on one aspect.
Retrieving the results is one thing. Improving how they are displayed is something that could be improved on too. For example we lack a gallery-based search. (Special:Newimages only searches on image titles. The functionality is there, so why not extend it to image descriptions?)
As for categories: date of page creation is not stored in the tables
right
now; that would be ideally something for the page table. The time a page included in a category is already stored (or at least, there is room for
it), so that may be easier to do in the future. Dynamic sort tables have issues with older browsers, but maybe a sortby can be done by the server
as
well. These things do require a considerable amount of coding and
testing,
though.
Well, that's why it's my vision, and not my requests for next week. ;)
cheers, Brianna
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Ironically, I'm currently in the process of developing a full-text (i.e., image titles and descriptions) gallery-based search engine for images on Commons. The code and interface has been there since December, it just needs frequent updating of the index and moving to the toolserver, and a few more tweaks. Although I can't make any promises, I expect the tool to be up and running by mid-February.
As an alternative, you can try Duesentrieb's highly versatile MediaSearch http://tools.wikimedia.de/~daniel/WikiSense/MediaSearch.php, which searches inside categories and can filter by license, type, and image size, etc. , but doesn't do full-text description searches.
Cheers,
Tangotango
-----Original Message----- From: Husky [mailto:huskyr@gmail.com] Sent: Tuesday, January 23, 2007 11:32 PM To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] The Ideal Wiki Software
Many of these have already been mentioned, but just to sum it up:
- Better search functionality (esp. with images, some kind of gallery
view), maybe on the basis of tagging or category keywords.
- A more user-friendly editing interface. This might need some serious
interaction models to avoid a WYSIWYG interface that doesn't quite work. Having a nifty AJAX editing interface might be pretty cool, but it will probably need some serious work to make it as responsive as Writely / Google Docs. However, it could really enable less tech-savvy people to write more and better formatted texts.
- A simpler system for templates/themes. Maybe not necessary for
Wikimedia-related projects (because they are all using Monobook anyway), but for customization of other users a template system such as in Wordpress ( www.wordpress.org) would be handy.
-- Hay Kranen / [[User:Husky]]
On 1/23/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 23/01/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Speaking from the technical side, there is a hurdle with the
"vastly
improved searches" that are requested, at least on one aspect.
Retrieving the results is one thing. Improving how they are displayed is something that could be improved on too. For example we lack a gallery-based search. (Special:Newimages only searches on image titles. The functionality is there, so why not extend it to image descriptions?)
As for categories: date of page creation is not stored in the
tables
right
now; that would be ideally something for the page table. The time a
page
included in a category is already stored (or at least, there is
room for
it), so that may be easier to do in the future. Dynamic sort tables
have
issues with older browsers, but maybe a sortby can be done by the
server
as
well. These things do require a considerable amount of coding and
testing,
though.
Well, that's why it's my vision, and not my requests for next
week. ;)
cheers, Brianna
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 24/01/07, Tangotango tangotango@wikignome.net wrote:
Ironically, I'm currently in the process of developing a full-text (i.e., image titles and descriptions) gallery-based search engine for images on Commons. The code and interface has been there since December, it just needs frequent updating of the index and moving to the toolserver, and a few more tweaks. Although I can't make any promises, I expect the tool to be up and running by mid-February.
A lot of attention suddenly. :) Any chance you could make it a full-blown extension rather than a toolserver job? ( http://bugzilla.wikimedia.org/show_bug.cgi?id=8738 )
We already have a lot of super-useful/critical tools relying on the toolserver, and as we can well see, it's not always so reliable...anything super-useful/critical is best off ultimately as part of MediaWiki.
Wait, that was the original point to my post! ;)
Anyway I and the other Commoners will await such developments with interest.
cheers, Brianna
Although I didn't have any plans to make the image search into a MediaWiki extension (the original concept was rather different), your proposal is certainly interesting and useful (not to mention not too outlandish), so I will keep it in mind.
The reliability of the toolserver is a real issue, but one of the strengths of coding a standalone toolserver tool versus coding a MediaWiki extension is that developers get more freedom tweaking and improving the code (sometimes on a whim), which means new features can suddenly crop up overnight. With MediaWiki, you have to make sure the thing actually works ;)
Cheers,
Tangotango
-----Original Message----- From: Brianna Laugher [mailto:brianna.laugher@gmail.com] Sent: Thursday, January 25, 2007 6:12 PM To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] The Ideal Wiki Software
A lot of attention suddenly. :) Any chance you could make it a full-blown extension rather than a toolserver job? ( http://bugzilla.wikimedia.org/show_bug.cgi?id=8738 )
We already have a lot of super-useful/critical tools relying on the toolserver, and as we can well see, it's not always so reliable...anything super-useful/critical is best off ultimately as part of MediaWiki.
Wait, that was the original point to my post! ;)
Anyway I and the other Commoners will await such developments with interest.
cheers, Brianna
wikimedia-l@lists.wikimedia.org