On 3/10/07, Joerg Baach lists@baach.de wrote:

I hope to have some simple form of prototype running on my server by then (will be ugly, though). No promise, though.

Saw the first code going in .. more coming?

NB: You may want to keep the branch you are making of the MW trunk separate from the extension, which doesn't need a branch and can just be committed directly into the extensions/ folder on svn.wikimedia.org. The extensions/ directory in the phase3 module is meant to remain empty. Ideally there should only be minimal changes in the branch (new hooks etc.) and these can maybe even be merged into trunk quite a while before the main extension is ready.

2007/3/14, Joerg Baach lists@baach.de:

Ah, there is an instance on

http://baach.de/phase3, running the extension.

Aha! So the database now allows for mutiple flags and these can be set. Is the process already logged in some way?

Cheers,

Philipp

2007/3/14, Joerg Baach lists@baach.de:

Logged - as in writen to some logging facility? Not yet, but I went down the users can override option (could be disabled in the ui later on), and store every change anyhow.

Yes, for transparency reasons, almost everything is logged or stored somehow. Thus, there is the version history, but also the log, which is accessible via Special:Log. However, I just see that we did not specifically include this in phase I. So this should probably be a part of phase II?

Bye,

Philipp

On Wednesday 14 March 2007 17:01:29 Joerg Baach wrote:

Ah, there is an instance on

http://baach.de/phase3, running the extension.

Thanks a lot for the update. However I am bit concerned on interface issues with the drop down lists and with too many different flags (and to many quality scales for exach flag).

In Wikipedia article changes quickly get quite huge (much more than one screen page, worst case in that respect are systematical typo and comma corrections in an article) it is better to place the flagging buttons in between the difference and the text, like in this mockup here:

http://commons.wikimedia.org/wiki/Image:Mockup-sighted-version-diff.png

Otherwise people either tend to skip reading parts of the diff or have to scroll again up after they did fully read it.

The drop down boxes: They need two mouse clicks, you can't grasp them without exploring them and drop down lists are prone to wrong selections. So a button like feature (or a button like link like the infamous "revert button" feature of admins, see also above screenshot) is more convenient.

So each flag only needs one button: The "apply" button. It is not desireable to uncheck again a tagged version (see my previous email for the detailed rationale).

As well different quality scales for each flag such as "unvandalised" and "superb" (and possibly more) tend to create a vote point system. Honest people waste to much time in giving a grade according to their judgement and dishonest people always take the highest grade. This social proplem alone has the potential to provoke new kinds of flames and trolling (flames about the right grade and such). Furthermore too much differenceiasation makes the system more complicated for the user.

So I advocate for a system that is not too generic in a technical way and which consists of single click through flagging (on diff view).

Keep up the good work, Daniel Arnold / Arnomane

On Wednesday 14 March 2007 20:40:42 Erik Moeller wrote:

I don't think this UI was really ready for criticism yet :).

I know that it is a very early stage which mainly is technical work behind the scenes such as how to store the items and how to connect it with the default MediaWiki framework. As the interface does reflect the storage part to a certain degree I think it can be helpful to discuss some logical aspects of the UI (I am not talking about default font size, alignment, CSS and friends ;). Drop down boxes vs. buttons is something which potentially affects the technical internals.

Ok you could say (in pseudocode):

if (flag = single_item and unset_flag = false) use buttons or plain links else use drop down boxes endif

But I suppose it is easier to do something like this if you have it in mind from the beginings on. That's what I want to make sure.

My main aim is to avoid double work and also to avoid that this extension evolves into something too complex.

Please be a little patient, at this time Joerg is just trying out a way to implement the required feature set, we can always make it prettier later. And the required feature set does include the capability for multiple quality types / different dimensions, even if the use in the de.wikipedia case might be very simple at first.

Well especially a simple flag unsetting can't work within a wiki (regardless which one). Flag unsetting feature is equal to quality vote wars.

Joerg has a specific set of specifications to work with; these will be implemented. Flexibility on the backend does not make it impossible to implement UIs for specific use scenarios.

Hm all my comments are based on the feature set and specifications that were discussed about in public and which are written down in the de.wikipedia wiki. Are these the same? I am a bit confused.

Anyhow I want to say thank you for the nice work done so far and I am really looking forward.

Cheers, Daniel Arnold / Arnomane

Erik Moeller wrote:

Saw the first code going in .. more coming?

Tiny bit more in, but beware - this is me finding out how to do things, not clean or save code. Also I am committing quite often, so that you have a backup all the time ;-)

Cheers,

Joerg