"Plug" SimplicityDoes anybody really need all those links and functions?
Sometimes, I'm not so sure, and some wiki software is far more bare-bones, much prettier to look at. GetWiki is certainly simple to use, but in developing "Plug", the application now running rimric.com for free book reviews and news/discussion of small press titles, I'm now looking at how to simplify GetWiki even more, and get away from the bloat (and let's face it, the baggage) associated with "wiki".
- having "talk" pages, especially when they have to be wikied, is quite useless and confusing - why not just have comments at the bottom of an article, like a blog or news site?
- maze-like lists of pages, images, their sizes and cross-links, and other features are also far less useful when the application is simpler (and...when the "culture" is not about policing people unnecessarily).
- at a technical level, the MediaWiki guts GetWiki inherited are very convoluted, with lots of very slow, high server load processing, and un-normalized database tables (articles are stored in three separate tables, recent changes in two, and lots of info is stored in more than one way).
The only real difference now between a blog and a wiki is that the article can be edited by others, right? Why is "blog" considered "fun" and "cool", while "wiki" is considered "pedantic", "dorky", "cumbersome", and "authoritarian"? Aside from adding features from GetWiki to Plug, like the (Wiki:Index|Index), and the Atom (Wiki:Feed|Feed), I'll also look to possibly gut GetWiki of some of the last remaining bloat (handed down from The Pseudopedia). It would simplify the interface and remove the last of their slow, GPL code. Any thoughts?? -proteus 09:59, 11 Mar 2008 (EDT)
As I've worked on other big projects recently (production design on my new book releases, for example), I've reflected on this. rimric.com, running "Plug", has none of the problems associated with "wiki", and now has two features GetWiki doesn't have: Internal private messages (not just forwarded email) and also friends (and "foaf") connections (with no privacy problems). Along with the true BB-style threaded discussion forums, that makes three major features - four, if you count the true classification feature already present in GetWiki 2.0, which would update the way GetWiki works... -proteus 13:23, 6 Jul 2008 (EDT)
Metadata Classification (Categories/Facets)I've long been researching this "categories" thing, and once again, the way it's done on Wikipedia is close, but not very sophisticated. They now have so many categories, and category pages, that they've resorted to manual indexing of those categories (defeating the purpose), not to mention that the database and "recent changes" is polluted with all those "category namespace pages", which are not really pages, but which have to be managed as such. Metadata about articles on a GetWiki Wiki is important, and I've long wanted a solution to this, but I did not want to simply follow a WP-style category scheme. While WP's is both a "Forward Index" and a "Reverse Index", it is a method which gets in the way and creates another mess which has to be further classified itself. That's why GetWiki has not had "categories" before now.
Two very clever approaches are out there (linked below), and doing them both (doing them both without creating endless extra pages about pages, etc), seems very, very interesting:
- Hierarchical Classification (see Wikka): Assign a single category to every page via a separate interface (similar to "what links here"), and the default category is "uncategorized". Every category can have a parent
and secondary parent, but top-level categories are primary "trees in the forest", like Philosophy, Science, or Art. This would work just as WP's "2-Dimensional" categories, such as "all topics in Philosophy", except there would be no pesky category namespace pages to keep up with, manage, or misuse (as is now the problem on WP), and single-parent categorization will be far simpler, or "1-Dimensional". e160bc2eab7e92ddedd0b4c6d1c16d8c markup in the articles would, as now, be ignored.
- Faceted Classification (see IAwiki): Assign Author, Subject, Type and Origin "facets" to every page. The Author part is already in the database, viewable on the history of each page. The Subject part is similar to a top-level category, and other Type and Origin data can be easily added to describe pages. This method allows searching in a "2-Dimensional" way, such as "all Philosophy pages edited by Proteus".
Every page would have Breadcrumb Navigation as well as Facet Navigation displayed (breadcrumbs along the top, with facets just below), all making for a "3-Dimensional" classification scheme on the full set of real classifiable pages (not talk, user or system pages). A reader can follow the links of her choice and browse the various collections.
So, we would, as a result, have a quite simple method. Have a "classify this page" link on classifiable pages. Possibly, this page would only be changeable by Sysops, but regular Editors could "add" categories?? The page would show the Metadata in dropdowns/checkboxes that can be changed. These bits of Metadata count as categories and facets at the same time, for example with Dynamism:
- Category ("Philosophy")
- Subject ("Systems Theories")
- Type ("Wiki")
- Origin ("Imported")
- Author(s) are in the page history (perhaps pruned of blocked spammers), or limited to the most recent Author?
I'm working on this now-ish (got other things going on) and it's coming right along on the (Blah:Main_Page|test wiki), and it's pretty complex. Adding Metadata to a page is easy, probably with added fields to each page in the database, or adding a Metadata table, but getting it all together in a simple, intuitive way takes time. I'm on the fence about whether changing categories/topics and changing a page's Metadata should be sysop-only. It would be all-too-easy to mess up the system by a malicious user, but maybe regular Editors should be allowed to add (where it is missing or incomplete), but not change, categories/topics?? Or, if regular Editors can change Metadata, perhaps it can be added to the "revert" mechanism, if abused??
This "3D" method would not be part of recent changes as so many minor changes to each page, unless it is logged separately at GetWiki:Classify Log. The whole idea of categories is that they are Metadata, and should not also be "reverse linked" namespace pages to manage, watch or overuse. The thing about Faceted Classification is that many areas, such as the Humanities, benefit from a Hiearchical approach - why not have both and still keep it simple?? -proteus 13:59, 18 Apr 2007 (EDT) (updated: -proteus 16:44, 24 Apr 2007 (EDT))
This is mostly finished, and at the same time, there were many changes to the subtle parts of the "skin" (see the Water Cooler for more). There are now breadcrumb links and facet links at the top of the pages (in place of redundant links before). The classifcation of articles (except talk, user, and special pages) is done completely separately from the editing of articles (for many reasons). The new "classify this page" link on allowed pages leads directly to the Classification of that page, and can be immediately changed (all changes are logged at GetWiki:Classify Log). Everything is geared toward keeping Categories simple, broad, and few in number, while allowing a wide range of Facet "tags" per article. Sysops see a couple of extra layers on the classify page, allowing the moving and editing of categories in a simple manner. There are no Category or Facet "pages", as they are done, correctly, within the relational database. I've still got to get the "browse" function together...feedback on any/all is appreciated. -proteus 16:56, 25 Apr 2007 (EDT)
Atom/RSS Import/ExportPerhaps GetWiki could (a) export its recent changes or new articles, or both, via Atom/RSS, and (b) also provide a MSG-like import functionality to aggregate several other GetWiki feeds onto a single page? Is this something useful, or is "RSS" overhyped?? -proteus 12:14, 19 Mar 2004 (EST)
I'm working on an Atom feed of editor's picks. I think feeding recent changes or new pages is highly boring to the people we would want to attract to a wiki. -proteus 12:43, 4 Apr 2007 (EDT)
This is done now, and the hopefully useful feed is visible on all GetWiki pages. Rather than hitting newcomers with more recent changes, it shows featured articles. Rather than pushing recent changes into a noisy feed which few would care about, it bridges blog-styles and wiki-styles. The feed could be anything, in fact. Most of the settings will be editable in the "local settings". -proteus 13:15, 10 Apr 2007 (EDT)
Multiple Wiki ImportsThe basic possibilities of multiple importing can be explored through several configurable options, which may be included in a possible new version of GetWiki. Multiple imports could be used as comparisons and selections for wikis importing articles. -proteus 12:14, 19 Mar 2004 (EST)
This may very well be a default feature of enacting multiple wiki importing. If GetWiki:2.0 can do multiple imports, that would include any wiki running GetWiki 1.0+/MediaWiki 1.1.0+, as long as the XML schemas are consistent. This would mean a wiki running GetWiki 2.0 could auto-import from the language Wikipedias, Wiktionary, Wikinfo, GetMeta, or whatever. I'll have to research the sister projects to ensure their output XML is available and consistent. -proteus 23:53, 10 Sep 2004 (EDT)
Re-ImportingOn Wikinfo, we've found it necessary to occassionally "re-sync" articles imported, but could really use a quick way to do something like a "diff" with the current version, especially those with an edit history on Wikinfo. This could also be tied into the suggestions above, for multiple imports. -proteus 18:49, 22 Mar 2005 (EST)
Custom User RightsInstead of hard-coded user's rights, as "developer", "sysop" and "admin" in GetWiki 1.0, "developer", "sysop", "bureaucrat" in MediaWiki 1.2.0+, why not allow that different wikis will be better served with different names for these rights, that "bureaucrat" or "sysop" may not suit all wikis? Wikinfo could use editing titles (ie. editor-in-chief, managing editor, etc), while a filmmaking wiki could use filmmaking titles (ie. Producer, Director, etc), and so on. GetWiki 2.0 could offer these user rights as simple categories and allow their names to be changed in LocalSettings.php.
There could be one "benevolent dictator" type of user as a default (currently "GetWiki Sysop"), who alone can grant users (a) "bureaucrat" rights, who likewise can grant "sysop" rights, and (b) "developer" rights. Everything would be logged in "GetWiki:Grant_log" using the titles selected in LocalSettings.php.
Editors' extra rights have been added in 1.0 to their user/user_talk pages, in the upper right corner. The "admin" right has been added recently, too. Admins can promote/demote any user and view other user information not available to sysops. The powers of the 3 administrative categories, therefore, do not overlap. In 2.0, the 3 will be changed to numbers, so that the text names of the categories can be changed, as desired. -proteus 21:00, 30 Jan 2005 (EST)
Multiple Wikitext SupportNot all wikis use MediaWiki, and currently, few use GetWiki. Why not provide an upgrade path for those wikis using PhpWiki, UseMod, and so on, some of which use a slightly different wikisyntax than we do? Could they not benefit from the features GetWiki offers?? -proteus 23:43, 20 Jan 2005 (EST)
© 2008-2008, 2004-2018 M.R.M. PARROTT | ALL RIGHTS RESERVED