Hi folks,
although both Aaron and Jörg keep eluding my requests for some definite time tables like Jelly, they cannot keep it a secret that the implementation of the specs is nearly finished. Therefore, we should start the planning of the next phase, namely testing this on a broader basis.
First of all, we need a wiki and a datadump. Any suggestions?
Furthermore, we need people to test this. Of course, the people on this list should be there, but that is the point where we would want to open up the test more. Personally, I'd say that we spread the word carefully.
Finally, there is the question of what to test. The implementation was done in a more flexible way than in the original german proposal, to allow for more tweaking to the needs of one community or the other. However, a test is not so good of we do not test in the way it will be turned on in the wiki. Therefore, I suggest either testing at first only the simpler original functionality.
Cheers,
Philipp
As long as it stays up to date, we can continue to use Joerg's site, as long as he is willing to import a database dump. Though the site needs another update to svn.
As for completion, yes the extension is not too far off, but most of the issues now resolve around core code, i.e. the he proposed timeframe functions. The extension itself stores an expanded copy of the text at the time, so if those parser functions have to be scaled back, I suppose it is not too much of a problem.
<html><div><FONT color=#3333cc>-Jason Schulz</FONT></div></html>
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org Subject: [Wikiquality-l] Start of the test phase: Preparations Date: Mon, 16 Apr 2007 21:01:56 +0200
Hi folks,
although both Aaron and Jörg keep eluding my requests for some definite time tables like Jelly, they cannot keep it a secret that the implementation of the specs is nearly finished. Therefore, we should start the planning of the next phase, namely testing this on a broader basis.
First of all, we need a wiki and a datadump. Any suggestions?
Furthermore, we need people to test this. Of course, the people on this list should be there, but that is the point where we would want to open up the test more. Personally, I'd say that we spread the word carefully.
Finally, there is the question of what to test. The implementation was done in a more flexible way than in the original german proposal, to allow for more tweaking to the needs of one community or the other. However, a test is not so good of we do not test in the way it will be turned on in the wiki. Therefore, I suggest either testing at first only the simpler original functionality.
Cheers,
Philipp
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ MSN is giving away a trip to Vegas to see Elton John. Enter to win today. http://msnconcertcontest.com?icid-nceltontagline
Hi *,
As long as it stays up to date, we can continue to use Joerg's site, as long as he is willing to import a database dump. Though the site needs
if we are going to test with a bit broader userbase and a larger database dump I would rather move the wiki to another machine, with a bit more resources. Thinking a bit ahead it might be good though to have a setup where more than user can administer the database and to the updating of the server (patching etc.). Would make sense if especially Aaron had some access as well. Would that be possible on the wikipedia machines? My feeling is that it would make more sense to move it there, but if its a hassle I am very willing to host the tests as well.
What do you think?
Joerg
On Tuesday 17 April 2007 17:44:39 Joerg Baach wrote:
if we are going to test with a bit broader userbase and a larger database dump I would rather move the wiki to another machine, with a bit more resources. Thinking a bit ahead it might be good though to have a setup where more than user can administer the database and to the updating of the server (patching etc.). Would make sense if especially Aaron had some access as well. Would that be possible on the wikipedia machines? My feeling is that it would make more sense to move it there, but if its a hassle I am very willing to host the tests as well.
Hm concerning the "let us keep this under the media radar". How about a invitation only wiki (for reading and writing) or maybe a normal wiki with a htaccess auth (and writing login and pass on this list)?
I think a closed wiki can have virtually any subdomain without creating any attention. So how about "cooker.mediawiki.org" and housing it on Wikimedia servers? Maybe Wikimedia Deutschland and Wikimedia CH have some servers ready for usage?
I think wo levels of administration would serve best:
One level would be people that just have buraucrat/admin rights in that wiki. Especially people that are more talented on visual stuff probably just want to tweak the individual css classes and message strings just by touching them directly "the wiki way" (and later the results get applied to svn as defaults).
And of course the technical skilled people. People that want to try a new bugfix, enhancement, speed improvement (which requires sql queries) and such.
So I think just ask what the people actually need. In order to avoid too much overhead just create a page in that wiki and people shall sign if they need just wiki admin rights or a shell account as well.
Arnomane
Hello *,
I think a closed wiki can have virtually any subdomain without creating any attention. So how about "cooker.mediawiki.org" and housing it on Wikimedia servers? Maybe Wikimedia Deutschland and Wikimedia CH have some servers ready for usage?
Sounds good to me, would be good if somebody would set that up. In the meantime I have an import of wikiversity running, on the old baach.de/phase3 address. This is an old server with limited traffic, so it better stays under the radar :-).
Cheers,
Joerg
On Wednesday 18 April 2007 16:38:56 Joerg Baach wrote:
Hello *,
I think a closed wiki can have virtually any subdomain without creating any attention. So how about "cooker.mediawiki.org" and housing it on Wikimedia servers? Maybe Wikimedia Deutschland and Wikimedia CH have some servers ready for usage?
Sounds good to me, would be good if somebody would set that up. In the meantime I have an import of wikiversity running, on the old baach.de/phase3 address. This is an old server with limited traffic, so it better stays under the radar :-).
I have briefly talked to DaB. (toolserver admin and member of Wikimedia Deutschland).
He said that the toolserver (tools.wikimedia.de) could be used for a wiki with a restricted group of people. The big advantage would be that the full database (every Wikimedia wiki) already is imported there in real time (only about 30s delay average to the real site).
@ P. Birken. Can you contact DaB. for details?
Cheers, Arnomane
2007/4/18, Daniel Arnold arnomane@gmx.de:
@ P. Birken. Can you contact DaB. for details?
OK!
Philipp
--- "P. Birken" pbirken@gmail.com wrote:
although both Aaron and Jörg keep eluding my requests for some definite time tables like Jelly, they cannot keep it a secret that the implementation of the specs is nearly finished. Therefore, we should start the planning of the next phase, namely testing this on a broader basis.
Excellent!
First of all, we need a wiki and a datadump. Any suggestions?
I'm sure Brion can set one up at either test.mediawiki.org or test.wikimedia.org up fairly quickly.
Furthermore, we need people to test this. Of course, the people on this list should be there, but that is the point where we would want to open up the test more. Personally, I'd say that we spread the word carefully.
Internal-l would be a great place to look for beta testers.
Finally, there is the question of what to test. The implementation was done in a more flexible way than in the original german proposal, to allow for more tweaking to the needs of one community or the other. However, a test is not so good of we do not test in the way it will be turned on in the wiki. Therefore, I suggest either testing at first only the simpler original functionality.
I agree - keep it simple at first and turn more stuff on if testing leads in that direction.
-- mav
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
--- Daniel Mayer maveric149@yahoo.com wrote:
First of all, we need a wiki and a datadump. Any suggestions?
I'm sure Brion can set one up at either test.mediawiki.org or test.wikimedia.org up fairly quickly.
Strike that. Those urls are far too public at this stage and would almost certainly cause some pre-mature press. http://baach.de/phase3/index.php/Main_Page is fine until we have an official beta/load test (which would only happen after we agree on exactly what to officially test).
I saw some things at the current test site that I think could be done better from an end-user standpoint (the reason I'm here :), but will wait until I see the new snapshot.
-- mav
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 4/16/07, P. Birken pbirken@gmail.com wrote:
Furthermore, we need people to test this. Of course, the people on this list should be there, but that is the point where we would want to open up the test more. Personally, I'd say that we spread the word carefully.
We should be clear what the purpose of the testing is. IMHO it is to identify major issues that prevent it from being used in any real world environment. For that purpose, the current baach.de/phase3 install is probably good enough. We could put it behind HTTP authentication and spread the word carefully on wmfcc-l and internal-l (the two main confidential Wikimedia lists). If the server breaks down, I've got a couple of others we can use.
After that, I think it would be wise to set up a public site at http://quality.wikimedia.org/ (with redirect from wikipedia.org)
which would include: - a brief summary for the public what this is all about - information about this particular extension - info for developers who want to work on it - links to 2-3 example setups (possibly in subdirectories) with different configurations - information about some other quality initiatives&brainstorming pages
We need to be very careful here. When we make a public announcement, we potentially have millions of people hearing about this -- if we play our cards right, this could lead to lots of new developers & ideas. But we should only do this when the extension is stable enough to use "as is". So I agree with a slightly more systematic closed testing phase over the next couple of weeks or so, preferably in an environment that is not officially connected to the Wikimedia Foundation.
On 4/18/07, Erik Moeller erik@wikimedia.org wrote:
We need to be very careful here. When we make a public announcement, we potentially have millions of people hearing about this -- if we play our cards right, this could lead to lots of new developers & ideas. But we should only do this when the extension is stable enough to use "as is". So I agree with a slightly more systematic closed testing phase over the next couple of weeks or so, preferably in an environment that is not officially connected to the Wikimedia Foundation.
:)
Lets hope citizendium doesn't pull a copy of the code out of SVN, roll it on their site, and beat us to the press.
2007/4/18, Erik Moeller erik@wikimedia.org:
On 4/16/07, P. Birken pbirken@gmail.com wrote:
Furthermore, we need people to test this. Of course, the people on this list should be there, but that is the point where we would want to open up the test more. Personally, I'd say that we spread the word carefully.
We should be clear what the purpose of the testing is. IMHO it is to identify major issues that prevent it from being used in any real world environment. For that purpose, the current baach.de/phase3 install is probably good enough. We could put it behind HTTP authentication and spread the word carefully on wmfcc-l and internal-l (the two main confidential Wikimedia lists). If the server breaks down, I've got a couple of others we can use.
OK. That automatically leads to the next question: what's the plan for afterwards? There is still the topic of the frontend and of including version remarks into the recent changes. What are our requisites before we turn the feature on?
Bye,
Philipp
On 4/18/07, P. Birken pbirken@gmail.com wrote:
OK. That automatically leads to the next question: what's the plan for afterwards? There is still the topic of the frontend and of including version remarks into the recent changes. What are our requisites before we turn the feature on?
Let's collect these on the wiki in the next few days. I've started a page here: http://baach.de/phase3/index.php/Launch_requirements
As I noted in an earlier post hear, the current UI is fine and simple, and works. New UIs should be extra options, rather than replacing the current one.
Anyway, I reverted that because: a) I was getting an error about some variable b) The Icon should be above the line (<hr> tag), to the right of the page title (or such), not off in the content, this makes it more obvious and less likely to go unnoticed. Given this, it should not open a large box then; perhaps it could just say "sighted revision" or "quality revision" depending. The box should go by the toolbox(it would fit nicely there) or some other decent place. c) Given the above, this needs to really be changed around to act differently in different skins, as the above don't work in non-monobook and the current was is still too sloppy.
-Aaron Schulz
_________________________________________________________________ Hotmail to go? Get your Hotmail, news, sports and much more! http://mobile.msn.com
Hiho,
2007/6/23, Aaron Schulz jschulz_4587@msn.com:
As I noted in an earlier post hear, the current UI is fine and simple, and works. New UIs should be extra options, rather than replacing the current one.
Anyway, I reverted that because: a) I was getting an error about some variable
Jörg told me that this version had some bugs and that it was more a quick hack, so we can have a look at that. So the current try at the design can be seen at http://tools.wikimedia.de/~stable/phase3/.
b) The Icon should be above the line (<hr> tag), to the right of the page title (or such), not off in the content, this makes it more obvious and less likely to go unnoticed.
I agree.
Given this, it should not open a large box then; perhaps it could just say "sighted revision" or "quality revision" depending. The box should go by the toolbox(it would fit nicely there) or some other decent place.
One thing about the box: it can be alternatively done such that the text does not flow around it, but that it opens above the text. It's simply a matter of taste. Personally, I would prefer the text not flowing around it, as it can be closed quite simple.
As for the other comment, I'm not sure what you mean. The reason for the box is, that the reader should get a simple way of navigating between different types of versions, so that if you are at http://tools.wikimedia.de/~stable/phase3/index.php?title=Waterfalls_of_the_H..., which is the last sighted version, you can go either to the current version or the last reviewed. OK, the box currently does not do this, but this is the purpose. I don't see any useful other way of doing this?
The toolbox is the left column of the interface?
c) Given the above, this needs to really be changed around to act differently in different skins, as the above don't work in non-monobook and the current was is still too sloppy.
That's right, different skins will be something to work on, but let's first concentrate on getting a final UI for the monobook.
Bye,
Philipp
I just talked to Arne Klempert and he had the idea, that the icon would be combined with one explanatory word of text in the sense of:
Reliability: [Icon].
The reson would be, that the icons are not selfexplanatory and would point everybody with a stick to what this is about. What do you think?
Bye,
Philipp
I pretty much suggested this last post. Seems like a good idea.
-Aaron Schulz
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Partial UI revert Date: Sat, 23 Jun 2007 14:24:24 +0200
I just talked to Arne Klempert and he had the idea, that the icon would be combined with one explanatory word of text in the sense of:
Reliability: [Icon].
The reson would be, that the icons are not selfexplanatory and would point everybody with a stick to what this is about. What do you think?
Bye,
Philipp
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ Like puzzles? Play free games & earn great prizes. Play Clink now. http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2
OK, I spend all day hacking at this again. I've re-added some of the UI stuff effectively based on my suggestions. However, the little box is still below the title (It's hard to get it with the title without using nasty hacks). It is fairly unobtrusive there.
It is only enable for monobook skins for now, and the regular tagging shows on edit and at special:stableversion (somewhat intentional, editors may want the info).
-Aaron Schulz
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Partial UI revert Date: Sat, 23 Jun 2007 14:24:24 +0200
I just talked to Arne Klempert and he had the idea, that the icon would be combined with one explanatory word of text in the sense of:
Reliability: [Icon].
The reson would be, that the icons are not selfexplanatory and would point everybody with a stick to what this is about. What do you think?
Bye,
Philipp
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_June07
Hi Aaron and the rest,
Jörg synchronized http://tools.wikimedia.de/~stable/phase3/index.php?title=Main_Page with your changes to trunk. Well, at last before you hacked some more ;-) The other "new UI" can still be seen at http://tools.wikimedia.de/~stable/phase3de/.
At this point there are in my view only a few questions left.
The first issue is: what is missing? In my eyes it is just getting the new UI to work in monobook as an alternative to Aarons original UI, which is working in every skin), making sure that the old UI is not lost and integrating this user interface into recent changes and watchlist, then some more testing, last bug fixes and we can turn this on at wikipedia.
So the first question: Does everybody share this view? In particular Aaron, do you want to do some more features? Or some other features?
The other issue is how the new UI will look like. In my view, unless there are serious problems with the design proposed by Jörg (now seen on http://tools.wikimedia.de/~stable/phase3de/), we should go with this design, which we talked about at length. So, are there problems with this design?
If yes, it might be worthwhile discussing the pro and cons also in regard to Aarons new UI (which is also thought out well, but has other problems in my eyes). If not, why don't we just stick with this and do it? We are so close! We could flag revisions live on the wikipedia within weeks! This is what we and in particular Aaron have been working for, right?
2007/6/24, Aaron Schulz jschulz_4587@msn.com:
OK, I spend all day hacking at this again. I've re-added some of the UI stuff effectively based on my suggestions. However, the little box is still below the title (It's hard to get it with the title without using nasty hacks). It is fairly unobtrusive there.
Mhmh.
It is only enable for monobook skins for now, and the regular tagging shows on edit and at special:stableversion (somewhat intentional, editors may want the info).
Yes, that looks like a feature to me, not a but.
Bye,
Philipp
Hi,
Jörg synchronized http://tools.wikimedia.de/~stable/phase3/index.php?title=Main_Page with your changes to trunk. Well, at last before you hacked some more ;-) The other "new UI" can still be seen at http://tools.wikimedia.de/~stable/phase3de/.
I have entered a further test article into both wikis in order to test if the new GUI elements conflict with existing Wikipedia content:
http://tools.wikimedia.de/~stable/phase3de/index.php?title=Irrlicht&stab... and http://tools.wikimedia.de/~stable/phase3/index.php?title=Will-o%27-the-wisp&...
These articles are pretty much Wikipedia average with a header template on top, an image/other box in the upper right, some paragraphs and categories. However I could not add interwikis as they aren't enabled in the wikis (beside that something is broken with images but that's not a real problem for this test).
At first comons UI problems of both variants: * The review rating form is above and not below the categories as it should be IMHO. * The review indicator box/indicator icon in the upper right conflicts with elements (the image in the example here) in the upper right of the article. Such elements are existing in nearly every good article in this place. :-( As Aaron told that it is currently not that easy to put something into the title without using nasty hacks I ask if it would be feasible changing MediaWiki that way that it is more easier to inject an item into the title? * the "stable version" tab on top is redundant to the review indicator box/indicator icon. It should be dropped entirely and the "article" tab should change itself in case you are on a stable version to something like "stable article version". Another option would be dropping the box/indicator icon in the upper right entirely and keeping the "stable version" tab with an expandable review text which would be directly below the tabs of the article.
Problems of the single UI variants: * In the english version the review toolbox will conflict with the Interwikis which are often very long and which would move on usual resolutions out of the screen. * In the German version the expanded box should move over (and partially hide) the article content. This is smother IMHO.
That's all for the moment. ;-)
Cheers, Arnomane
Daniel Arnold schrieb:
- the "stable version" tab on top is redundant to the review indicator
box/indicator icon. It should be dropped entirely and the "article" tab should change itself in case you are on a stable version to something like "stable article version". Another option would be dropping the box/indicator icon in the upper right entirely and keeping the "stable version" tab with an expandable review text which would be directly below the tabs of the article.
We should drop the term "stabile version" ("stable version") in all tabs and use "gesichtete Version" and "geprüfte Version" instead. The term "stable version" was more or less a working title and it will make future discussions difficult if we continue to use it in the UI or elsewhere (especially with regard to the press). Furthermore the user should clearly know which version ("gesichtet" or "geprüft") is available.
Greetings Frank
OK, here are my thought so far:
First, note that the original UI is still in the software, and is the default. Anyway, I don't like either of the alternates. Just having a checkbox (which either overlaps or moves the content around oddly when clicked isn't pretty and will go unnoticed. Thats why I add the "See the X revision" thing next to it. Also, my variant only works on monobook.
Phillip suggested putting ratings below the categories. Expanding on that, this seems like a good solution for the alternative UI. Doesn't get messed up by interwikis and works with all skins. I'll probably replace $wgSimpleFlaggedRevsUI with $wgFlaggedRevsTagsOnTop. That way, the tag would be on bottom and the little icon would appear on top only.
As for the tabs, they can stay, as they make things more clear, at worst, I can make a setting to disable them.
-Aaron Schulz
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Partial UI revert Date: Sun, 24 Jun 2007 23:47:37 +0200
Hi Aaron and the rest,
Jörg synchronized http://tools.wikimedia.de/~stable/phase3/index.php?title=Main_Page with your changes to trunk. Well, at last before you hacked some more ;-) The other "new UI" can still be seen at http://tools.wikimedia.de/~stable/phase3de/.
At this point there are in my view only a few questions left.
The first issue is: what is missing? In my eyes it is just getting the new UI to work in monobook as an alternative to Aarons original UI, which is working in every skin), making sure that the old UI is not lost and integrating this user interface into recent changes and watchlist, then some more testing, last bug fixes and we can turn this on at wikipedia.
So the first question: Does everybody share this view? In particular Aaron, do you want to do some more features? Or some other features?
The other issue is how the new UI will look like. In my view, unless there are serious problems with the design proposed by Jörg (now seen on http://tools.wikimedia.de/~stable/phase3de/), we should go with this design, which we talked about at length. So, are there problems with this design?
If yes, it might be worthwhile discussing the pro and cons also in regard to Aarons new UI (which is also thought out well, but has other problems in my eyes). If not, why don't we just stick with this and do it? We are so close! We could flag revisions live on the wikipedia within weeks! This is what we and in particular Aaron have been working for, right?
2007/6/24, Aaron Schulz jschulz_4587@msn.com:
OK, I spend all day hacking at this again. I've re-added some of the UI stuff effectively based on my suggestions. However, the little box is
still
below the title (It's hard to get it with the title without using nasty hacks). It is fairly unobtrusive there.
Mhmh.
It is only enable for monobook skins for now, and the regular tagging
shows
on edit and at special:stableversion (somewhat intentional, editors may
want
the info).
Yes, that looks like a feature to me, not a but.
Bye,
Philipp
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm
Hiho,
we had yesterday a chat with several people from this list (Aaron, Daniel and me, for the most time). Some things were agreed by all present: the icon does not belong into the content box and the box that opens in "Jörgs Design" should not move, but overlap the text. Furthermore, having a window in the toolbox is also suboptimal, since it disturbs the content there.
One suggestion of Aaron was to move the textbox to the footer, so that it does not disturb the text. Me, I'm still a fan of "Jörgs Design";-)
Aaron has now started to work on recent changes, by reusing functionality from patrolled edits. So, everybody which the toolserver guys luck, since it is down at the moment.
Cheers,
Philipp
Hi,
we had yesterday a chat with several people from this list (Aaron, Daniel and me, for the most time).
At first sorry for suddenly leaving in the middle of the discussion, I lost internet connection...
Some things were agreed by all present: the icon does not belong into the content box and the box that opens in "Jörgs Design" should not move, but overlap the text.
By the way: Duesentrieb has programmed and extension that (when using LANGUAGE_SELECTOR_INTO_TITLE) optionally injects an element into the title: http://www.mediawiki.org/wiki/Extension:LanguageSelector
So maybe we can have a look at his code? However I wasn't able to get this particular inject option to work (it just displayed the raw HTML in the title).
Another thing I like at Duesentriebs extension: He provides several GUI alternatives for injecting the extension into the page. I think his configuration scheme is quite nice.
Cheers, Arnomane
wikiquality-l@lists.wikimedia.org