Talk:Shifti UI Revamp

From Shifti
Jump to navigation Jump to search

Enhancements, part 1:

Most of these features are available in other Wiki's but not MediaWiki. Might be possible to get these working with extensions.
Page ownership might be possible to track via an extra database table cross-linking page-name and page-creator, though we could co-opt a parser-extension to flag the owner based on page-contents.
Classification and categorization is possible through the existing semantic tags and category tags but this system is not fine-grained enough to keep most people happy.
Other meta-data is possible via new database tables and parser-tags
We've tried various feed-back extensions in the past and seen them used to bypass the spam-protections we have in place. The suggestion is a good one, though...
Categorization for all pages will be tough, since there are some authors that raised concerns over forced-categorization that could reveal a twist in the story or the punchline of a humorous story... This led to the "leave the categorization up to the authors" decision early on.
Metadata formatting is a hard one, since the fully-parsed metadata is not available to the user at page creation time and metadata links are generated by the parser separately.

Enhancements, part 2:

Shiftimin needs fixing bad - there are bits that I passed-up on implementing because the sites default is Monobook.
It needs a lot of re-organization work for various bits
It relies on some JS to make certain features function in versions of IE prior to IE8 (which has full CSS 2.1 support - which was needed)
Current menu format is relied upon by other skins. If we manage to get a customized skin that works well on all major browser versions used by Shifti's visitors then it could be changed.
Shiftimin contains hacks where it reads the current format and builds its own structure from it

Enhancements, part 3:

Semantic system can be extended to fill this role
Custom category pages should be possible

Enhancements, part 4:

There are a number of alternative editors available for MediaWiki.
The revisions system would be good...
Current editor selectively uses Javascript. WYSIWYG replacements would rely heavily on JavaScript. Any 'revisions' system would rely on AJAX for communicating revisions back to the server for storage.

Enhancements, part 5:

Massive amounts of documentation are required anyway. We currently point people to primary MediaWiki documentation for basic markup help and to places like the Semantic MediaWiki home for help with the Semantic system.

Basically the idea is good, but will require many, many changes to the core code and some ideas go against principles in others. I'll conditionally condone this one.

-- ShadowWolf 20:30, 17 August 2009 (UTC)


On part 1: As I see it, the vast majority of those features would be implemented via the Semantic MediaWiki extension. All it really entails is having a single common template that acts as a front end for a Semantic MediaWiki metadata scheme that we more or less standardize across the wiki. This would theoretically allow us to implement such things without forking the MediaWiki codebase. Going with a template that hooks in metadata just makes sense to me. Not only does it make creating a front-end a hell of a lot more easy (see: part 4), it also makes things much much easier for the quasi-Luddites who are perfectly happy with WikiText. ;)
In particular re: "ownership" - I'm trying to codify ownership of the content, not necessarily the page it's on. I think existing protection mechanisms can be used for preventing editing issues just fine - but that does nothing for copyright. Copyright is important metadata that should be included and tracked.
On part 2: I have a few books I plan on buying and reading such that I can try and roll my own, honestly - I recognize this is kind of an ugly job that I'm going to be very twitchy on, and since I have the opportunity to make it My Problem I intend to do so. ;) I just like the branding work done with ShiftiMin, and so in anything I do I'd probably steal it. The menu structure, tho, obviously needs work - I thought drop-downs would actually work out for once and... well... they don't. :)
On part 3: It sure can. That's the idea. :D That's also why I want a Common Template - because that way we can be assured folks are hooked into the semantic metadata system, and thus their stories will get included. Some hacks to existing templates might be necessary until such time as we can make things work ourselves, but you've already started on that so it's all good.
On part 4: Frankly, I don't know how to implement such a thing. It came to me as an idea only because I know you've experimented with AJAX WYSIWYG editors before, and so that means we have somebody on the team who at least has a vague idea of what this would entail. The meat of this issue, tho, is basically integrating a front-end to our Basic Page Template into the editor. (Obviously that means the template has to be done first!)
On part 5: I'd write more, except I want to make this happen! ;D
Hope this helps! --Viqsi 22:05, 17 August 2009 (UTC)