Hi *,
following the discussions and layouts that we have had over the last weeks Frank Linnenschmidt has come up with the following approach for the integration of the text and icons for the FlaggedRevs. He has designed icons for the german approach, but those should be pretty much reusalbe for other settings as well:
http://www.baach.de/wpdesign/Main_Page_1.html - a page header with the 'approved' icon
if you would click on the icon, a box would unfold: http://www.baach.de/wpdesign/Main_Page_2.html
This gives more info on the detailed flaggs, with different colored backgrounds instead of little bars, and the colors ranging from green to red.
The non-vandalized/sighted icon: http://www.baach.de/wpdesign/Main_Page_files/2.png
The not-checked / no criteria met icon: http://www.baach.de/wpdesign/Main_Page_files/1.png
There are smaller versions of these icons as well, for integration with recent changes. Note the change on the 'not-checked' icon:
http://www.baach.de/wpdesign/Main_Page_files/1-small.png http://www.baach.de/wpdesign/Main_Page_files/2-small.png http://www.baach.de/wpdesign/Main_Page_files/3-small.png
The box for actual flagging of the pages would not need any changes in his opinion, and could stay the way that Aaron designed them.
(All the files can be found in a zip archive at: http://www.baach.de/wpdesign/wpdesign.zip)
Now, any comments/objections before we start integrating that?
Cheers,
Joerg
2007/5/21, Joerg Baach lists@baach.de:
Now, any comments/objections before we start integrating that?
Well, as I already said, I really like this design. As a comment, I would extend the text to provide information about more current versions and so on.
Furthermore, there is one question left: If we do not provide a prominent textbox telling people all the stuff (which I like very much), the potential for confusion if the default version is not the current one is increased. In particular, as the edit button is hidden, large parts of the wiki might look uneditable to IP users. How do we solve this?
We could take up Arnomanes idea again which means to show the editbutton, with a different behaviour in those cases. Or, we could provide a more prominent link to the current version. Or, we could place the icon very close to the current version button.
Bye,
Philipp
On 5/21/07, P. Birken pbirken@gmail.com wrote:
Furthermore, there is one question left: If we do not provide a prominent textbox telling people all the stuff (which I like very much), the potential for confusion if the default version is not the current one is increased. In particular, as the edit button is hidden, large parts of the wiki might look uneditable to IP users. How do we solve this?
One could implement a relatively simple UI control to set the "default view" to be either the latest version, latest sighted version, latest reviewed version, etc. IMHO this control should be always visible, and the default should _not_ be different for registered & unregistered users.
I would suggest something roughly like:
My preferred view: [ ^ Most recent revision ] Last sighted revision Last accurate revision ...
That way, both readers and editors could choose the setting they prefer. This would require storing the preference in a cookie for readers, but that shouldn't be a big deal (we already do this for table of contents collapse/expand preferences).
The "default view" is a very important concept and I do not really think we can or should simplify it behind an icon.
2007/5/22, Erik Moeller erik@wikimedia.org:
One could implement a relatively simple UI control to set the "default view" to be either the latest version, latest sighted version, latest reviewed version, etc. IMHO this control should be always visible, and the default should _not_ be different for registered & unregistered users.
I see that this would solve some problems. Where would this control be? How simple is simple? Shouldn't we move this to phase II?
The "default view" is a very important concept and I do not really think we can or should simplify it behind an icon.
So essentially you suggest a different design?
Bye,
Philipp
Hmm, one think I'm certain on is that the default revision for anons should be stable and for users, the current version. I don't want the user base to become complacent and not check the current version much. It's very important to keep the current revisions the main focus as well as RC patrol, watchlist.
As for making it a preference, maybe later, but that seems to introduce more features and complexity than I'd like. Preferences are already a tad bloated.
<div><FONT color=#3333cc>-Aaron 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: Re: [Wikiquality-l] design / icons Date: Tue, 22 May 2007 19:15:02 +0200
2007/5/22, Erik Moeller erik@wikimedia.org:
One could implement a relatively simple UI control to set the "default view" to be either the latest version, latest sighted version, latest reviewed version, etc. IMHO this control should be always visible, and the default should _not_ be different for registered & unregistered users.
I see that this would solve some problems. Where would this control be? How simple is simple? Shouldn't we move this to phase II?
The "default view" is a very important concept and I do not really think we can or should simplify it behind an icon.
So essentially you suggest a different design?
Bye,
Philipp
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
2007/5/22, Aaron Schulz jschulz_4587@msn.com:
Hmm, one think I'm certain on is that the default revision for anons should be stable and for users, the current version. I don't want the user base to become complacent and not check the current version much. It's very important to keep the current revisions the main focus as well as RC patrol, watchlist.
That's also what I think. Furthermore, I don't believe that the userbase would accept not seeing the current version anymore by default. I consider IPs and users seeing different versions by default a minor point in comparison.
As for making it a preference, maybe later, but that seems to introduce more features and complexity than I'd like. Preferences are already a tad bloated.
I fully agree. We should finish the current proposal and get the thing on the road.
Thinking about this, maybe our problem could be solved simply by a site notice? After we actually start this on a wiki, a site notice would be a reasonable thing anyhow, linking to pages that explain the new icons and concepts. Then, we could work with the design as proposed?
Bye,
Philipp
After talking to Tim Starling a bit, I've decided to take a more explicit method of dealing with transcluded pages and images. This means that less code changes elsewhere will be needed (currently there are a lot).
What I will be doing is: *Modifying Parser.php to list the revision/image timestamp used for each revision/image *Recording the above for stable versions in two new tables *Adding a hook to Parser to let the extension select the desired image/template version *Attaching the functions that query the above tables to the above hook for stable versions
Most of these changes won't have much noticable difference from the end-user standpoint, and the UI will be left alone. It just makes things more...well...stable ;)
I've been considering doing this for a while, this should be the last major schema additions.
<div><FONT color=#3333cc>-Aaron Schulz</FONT></div></html>
_________________________________________________________________ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
2007/5/23, Aaron Schulz jschulz_4587@msn.com:
After talking to Tim Starling a bit,
This reminds me of a point I had on my mind some time ago: as I understood, Tim Starling is our optimization wizard. Would it be useful to ask him to look into the flagged revisions extension with regard to this? Or maybe yes, but not now?
I've been considering doing this for a while, this should be the last major schema additions.
Great! The inclusion of this into the recent changes is rather straightforward?
Bye,
Philipp
P. Birken schrieb:
2007/5/22, Aaron Schulz jschulz_4587@msn.com:
As for making it a preference, maybe later, but that seems to introduce more features and complexity than I'd like. Preferences are already a tad bloated.
I fully agree. We should finish the current proposal and get the thing on the road.
! :-)
Thinking about this, maybe our problem could be solved simply by a site notice? After we actually start this on a wiki, a site notice would be a reasonable thing anyhow, linking to pages that explain the new icons and concepts. Then, we could work with the design as proposed?
We should definitely use a sitenotice to inform Wikipedians and the outside world about the new features. We need to make the biggest buzz possible about it. It's our non-recurring chance to regain many people's trust.
Kurt
P. Birken schrieb:
In particular, as the edit button is hidden, large parts of the wiki might look uneditable to IP users. How do we solve this?
We could take up Arnomanes idea again which means to show the editbutton, with a different behaviour in those cases.
I still think this is the best solution. It will also avoid criticism from community members who fear IP users would be obstructed. And there's also the press, but some of them won't get it anyway ;-)
Kurt
On Wednesday 23 May 2007 19:41:00 Kurt Jansson wrote:
P. Birken schrieb:
In particular, as the edit button is hidden, large parts of the wiki might look uneditable to IP users. How do we solve this?
We could take up Arnomanes idea again which means to show the editbutton, with a different behaviour in those cases.
I still think this is the best solution. It will also avoid criticism
from community members who fear IP users would be obstructed. And
there's also the press, but some of them won't get it anyway ;-)
I think the same. When I recruit new people for Wikipedia I often encourage them to read a bit and to correct typos they find on reading in order to get quickly a feeling how Wikipedia "works" and in order to show quick results to them.
During reading you don't want to read anew on a small error, you want to fix the problem right now (impulse action) and proceed. Clicking on "current revision" would require this much more than just clicking on edit and inmediatly focusing on the "just do it" part.
However as I wrote in one of the emails the "section edit" would still be lost with the idea of the modified edit button for IPs as you cannot take the section structure of an older and the current version as identical and even if it would be identical it could be easily the case that two sections just changed their places (very common task on reorganizing article content).
A possible solution for keeping even section edit would be a similarity comparison: * When clicking on section edit on an old (approved, whatever flagged) revision it takes the text of that old section you want to edit and compares it to the full text of the current revision. * The smallest nearby matching (sub-) section of the current revision will be opened for editing (alongside the full diff view to current revision above the edit box). * In case there is no nearby match (depending on resonable threshold) or if the section is splitted into two or more top level sections the full article would be opened for editing (as the full article would be the smallest matching section in that case).
I know that this is maybe to advanced for the first version (and we need to test it at one point in the wild if we want to suceed) but IMHO worthwile for later improvements.
Grüße, Arnomane
First of all, It would be important to discuss the design. Is the design such, that we can tell Jörg to implement it?
2007/5/24, Daniel Arnold arnomane@gmx.de:
During reading you don't want to read anew on a small error, you want to fix the problem right now (impulse action) and proceed. Clicking on "current revision" would require this much more than just clicking on edit and inmediatly focusing on the "just do it" part.
My personal fear is that we will then get a lot of people doing things twice. I mean, people get confused the more, the more confusing things are :-) They click on edit and up pops this huge preview, probably with a message box, which they won't read anyway. Then they have to scroll down towards the edit box and see different text thatn what they expected. I'm not really convinced that this will work.
I know that this is maybe to advanced for the first version (and we need to test it at one point in the wild if we want to suceed) but IMHO worthwile for later improvements.
Yes, definitely :-)
Cheers,
Philipp
Indeed an "edit" link would cause even more confusion as likely the typos/changes would have been made already, the "current revision" tab is less confusing.
As for reducing the number of flags (and levels), there is no need to re-hard code anything, all of those are easily configured localsettings variables. I'd rather leave the current schema as the default and let the devs installing it on de custimize the global variables as they see fit.
<div><FONT color=#3333cc>-Aaron 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: Re: [Wikiquality-l] design / icons Date: Thu, 24 May 2007 18:54:37 +0200
First of all, It would be important to discuss the design. Is the design such, that we can tell Jörg to implement it?
2007/5/24, Daniel Arnold arnomane@gmx.de:
During reading you don't want to read anew on a small error, you want to
fix
the problem right now (impulse action) and proceed. Clicking on "current revision" would require this much more than just clicking on edit and inmediatly focusing on the "just do it" part.
My personal fear is that we will then get a lot of people doing things twice. I mean, people get confused the more, the more confusing things are :-) They click on edit and up pops this huge preview, probably with a message box, which they won't read anyway. Then they have to scroll down towards the edit box and see different text thatn what they expected. I'm not really convinced that this will work.
I know that this is maybe to advanced for the first version (and we need
to
test it at one point in the wild if we want to suceed) but IMHO
worthwile for
later improvements.
Yes, definitely :-)
Cheers,
Philipp
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
On Thursday 24 May 2007 18:54:37 P. Birken wrote:
My personal fear is that we will then get a lot of people doing things twice. I mean, people get confused the more, the more confusing things are :-) They click on edit and up pops this huge preview, probably with a message box, which they won't read anyway. Then they have to scroll down towards the edit box and see different text thatn what they expected. I'm not really convinced that this will work.
There is no preview. It is a diff-view. This is quite different and also very often way shorter than the article.
There is no big message needed except a headline "Difference to current revision<link>". If the diff is more than one screen page people will have to read anew anyways.
Cheers, Arnomane
2007/5/25, Daniel Arnold arnomane@gmx.de:
There is no preview. It is a diff-view. This is quite different and also very often way shorter than the article.
OK, that's shorter but I consider this even more confusing, in particular since our diff functionality sucks.
There is no big message needed except a headline "Difference to current revision<link>". If the diff is more than one screen page people will have to read anew anyways.
Ah, OK!
Bye,
Philipp
On Monday 21 May 2007 14:42:17 Joerg Baach wrote:
following the discussions and layouts that we have had over the last weeks Frank Linnenschmidt has come up with the following approach for the integration of the text and icons for the FlaggedRevs. He has designed icons for the german approach, but those should be pretty much reusalbe for other settings as well:
http://www.baach.de/wpdesign/Main_Page_1.html
- a page header with the 'approved' icon
I like it and the place where it is located at too.
However we need to keep in mind that the same corner is being used by some Wikipedias for displaying data: a) The geographical coordinates of places. So we probably will have to convince people that placing such data outside the content frame is evil (and some Wikipedians already are saying so without knowing the details of this feature here). A better place for geograhical coordinates would probably be the right corner below the title bar. b) Icons in order to indicate featured and good articles are located there too. So we need to take that in account too that both elements can coexist there in a non-confusing way. This means IMHO that both icons maybe should have the same size and maybe use a similar color and style scheme (the featured article icon for example is as quasi standard throughout all Wikipedias).
if you would click on the icon, a box would unfold: http://www.baach.de/wpdesign/Main_Page_2.html
Well it is nice and concise but I have some questions:
How could it avoid hiding parts of the article content such as images and boxes which are placed below the title in the right corner by default in virtually every article? I don't want to encourage people moving things in articles around just for avoiding some potential visual problems (we already have problems with people that are abusing Wikipedia as a browser encyclopedia with lots of workarounds and whatnot in order to optimize articles for certain browsers in a certain resolution only).
The box for actual flagging of the pages would not need any changes in his opinion, and could stay the way that Aaron designed them.
As I already wrote: I dislike the box. It is too complicated and everytime I have to block an article in Wikipedia I feel uncomfortable with the interface. Please make radio buttons (and check boxes) in case there are more than one binary flagging option (defined in settings) and a single "apply" button in case there is one option only (also depending on user's flagging rights).
Cheers, Arnomane
2007/5/25, Daniel Arnold arnomane@gmx.de:
On Monday 21 May 2007 14:42:17 Joerg Baach wrote:
following the discussions and layouts that we have had over the last weeks Frank Linnenschmidt has come up with the following approach for the integration of the text and icons for the FlaggedRevs. He has designed icons for the german approach, but those should be pretty much reusalbe for other settings as well:
http://www.baach.de/wpdesign/Main_Page_1.html
- a page header with the 'approved' icon
I like it and the place where it is located at too.
However we need to keep in mind that the same corner is being used by some Wikipedias for displaying data:
Urgs. I always edit in classic skin, there you are save from a lot of this ;-) Well, there are two solutions, either display the new icons directly right of the lemma, display the new icons directly right of the buttons or discus the current situation with the people involved and change it, for example move the coordinates. Actually, I have no real idea what they are doing there so prominently.
if you would click on the icon, a box would unfold: http://www.baach.de/wpdesign/Main_Page_2.html
Well it is nice and concise but I have some questions:
How could it avoid hiding parts of the article content such as images and boxes which are placed below the title in the right corner by default in virtually every article? I don't want to encourage people moving things in articles around just for avoiding some potential visual problems (we already have problems with people that are abusing Wikipedia as a browser encyclopedia with lots of workarounds and whatnot in order to optimize articles for certain browsers in a certain resolution only).
May we could add a cross in the right upper corner wich gets you back to the originally state upon clicking?
Bye,
Philipp
On Friday 25 May 2007 16:17:31 P. Birken wrote:
However we need to keep in mind that the same corner is being used by some Wikipedias for displaying data:
Urgs. I always edit in classic skin, there you are save from a lot of this ;-) Well, there are two solutions, either display the new icons directly right of the lemma, display the new icons directly right of the buttons or discus the current situation with the people involved and change it, for example move the coordinates. Actually, I have no real idea what they are doing there so prominently.
Ok let's have a look at one example: http://de.wikipedia.org/wiki/Alexanderplatz
There you can see (in standard Monobook skin) both the coordinates and the featured article icon in the upper right corner (by the way a bit misaligned in Konqueror, I like those errorprone CSS skin hacks positioning content outside the content frame). It is not exactly aligned to the title line but is placed in the "site notice field."
IMHO the Coordinate is way better placed below the title line in the upper right corner.
The featured article icon and the approved version icon could be placed next to each other (the approved icon in the right and the featured article icon would be placed a bit left from it) directly above the title line (and not in the site notice).
Of course this would involve some small changes to some templates in Wikipedia but eveyone should be aware that such hacks are not supported by MediaWiki and that they can break anytime and of course everytime you have a longer site notice such hacks cause a problem with text overlays (or small screen resolution with a medium site notice).
So we could take this as an opportunity to get rid of these problems with a very good point. ;-)
if you would click on the icon, a box would unfold: http://www.baach.de/wpdesign/Main_Page_2.html
[...]
May we could add a cross in the right upper corner wich gets you back to the originally state upon clicking?
Hm ok this would probably do it. Either a small cross or a small ^ for retracting the small info box. The close icon should be placed in the right corner of the box, cause the mouse is pointing there after clicking on the approved icon. So that you can close it fast and comfortable again.
Cheers, Arnomane
2007/5/25, Daniel Arnold arnomane@gmx.de:
IMHO the Coordinate is way better placed below the title line in the upper right corner.
The featured article icon and the approved version icon could be placed next to each other (the approved icon in the right and the featured article icon would be placed a bit left from it) directly above the title line (and not in the site notice).
That sounds reasonable. In some articles, for example http://de.wikipedia.org/wiki/Berlin, you also have the spoken articles link, but this seems to be a particular feature of the german wikipedia. I know the guy who initiated that project (Benutzer:Longbow4u) and will talk to him on the weekend. This leaves us with two icons there. Not really what I dreamed of, but it will serve. By the way, the icon for featured articles is quite different from that for exzellente Artikel.
Of course this would involve some small changes to some templates in Wikipedia but eveyone should be aware that such hacks are not supported by MediaWiki and that they can break anytime and of course everytime you have a longer site notice such hacks cause a problem with text overlays (or small screen resolution with a medium site notice).
So we could take this as an opportunity to get rid of these problems with a very good point. ;-)
Yes, but we have to be careful not to step on everyones feet.
May we could add a cross in the right upper corner wich gets you back to the originally state upon clicking?
Hm ok this would probably do it. Either a small cross or a small ^ for retracting the small info box. The close icon should be placed in the right corner of the box, cause the mouse is pointing there after clicking on the approved icon. So that you can close it fast and comfortable again.
OK! Everybody comfortable with this?
Cheers,
Philipp
Meh, I'd changed the tab schema slightly. I'll look at this later.
<div><FONT color=#3333cc>-Aaron 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: Re: [Wikiquality-l] design / icons Date: Fri, 25 May 2007 22:33:15 +0200
2007/5/25, Daniel Arnold arnomane@gmx.de:
IMHO the Coordinate is way better placed below the title line in the
upper
right corner.
The featured article icon and the approved version icon could be placed
next
to each other (the approved icon in the right and the featured article
icon
would be placed a bit left from it) directly above the title line (and
not in
the site notice).
That sounds reasonable. In some articles, for example http://de.wikipedia.org/wiki/Berlin, you also have the spoken articles link, but this seems to be a particular feature of the german wikipedia. I know the guy who initiated that project (Benutzer:Longbow4u) and will talk to him on the weekend. This leaves us with two icons there. Not really what I dreamed of, but it will serve. By the way, the icon for featured articles is quite different from that for exzellente Artikel.
Of course this would involve some small changes to some templates in
Wikipedia
but eveyone should be aware that such hacks are not supported by
MediaWiki
and that they can break anytime and of course everytime you have a
longer
site notice such hacks cause a problem with text overlays (or small
screen
resolution with a medium site notice).
So we could take this as an opportunity to get rid of these problems
with a
very good point. ;-)
Yes, but we have to be careful not to step on everyones feet.
May we could add a cross in the right upper corner wich gets you back to the originally state upon clicking?
Hm ok this would probably do it. Either a small cross or a small ^ for retracting the small info box. The close icon should be placed in the
right
corner of the box, cause the mouse is pointing there after clicking on
the
approved icon. So that you can close it fast and comfortable again.
OK! Everybody comfortable with this?
Cheers,
Philipp
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
On Friday 25 May 2007 22:33:15 P. Birken wrote:
2007/5/25, Daniel Arnold arnomane@gmx.de:
IMHO the Coordinate is way better placed below the title line in the upper right corner.
The featured article icon and the approved version icon could be placed next to each other (the approved icon in the right and the featured article icon would be placed a bit left from it) directly above the title line (and not in the site notice).
That sounds reasonable.
By the way en.wikipedia is already doing so and places the coordinates below the title line, see for example: http://en.wikipedia.org/wiki/Berlin
However de.wikipedia does not have a the "From Wikipedia, the free encyclopedia" tag line (luckily IMHO as I don't like redundant branding everyhwere) and placing the coordinates below the title line would interfere with the first line of text but I am sure that people in de.wikipedia will be able to solve this nicely.
In some articles, for example http://de.wikipedia.org/wiki/Berlin, you also have the spoken articles link, but this seems to be a particular feature of the german wikipedia.
Yes and in en.wikipedia you have the locked icon for write protected articles (see http://en.wikipedia.org/wiki/Berlin which is protected at the moment). So probably every Wikipedia has some individual not quality related icons there.
This leaves us with two icons there. Not really what I dreamed of, but it will serve.
Hm another solution would be a merge of quality related icons. If the approved icon has a label in the HTML source code (and is located within a labeled container) people could influence it easily via template + CSS and could replace it in these cases indvidually with a combined "featured + approved" icon. As well the info box with pops up on clicking at the approved icon could also be extented by them individually with a line indicating "featured article" status.
So we could take this as an opportunity to get rid of these problems with a very good point. ;-)
Yes, but we have to be careful not to step on everyones feet.
Of course the solutions for these icon hacks in Wikipedia should be decided by the Wikipedias themselves but we now have some suggestions and of course we can take care in advance that we have proper labeled elements which can be modified more easily within the wiki via templates + CSS.
So I think we can provide the Wikipedias enough flexibility that they can solve it smoothly.
Cheers, Arnomane
I am quite satisfied with the current UI and tagging. If any new ideas are implemented, that will be done as alternatives (we could have global variables to set UI styles). That way if any ugly CSS hacks that probably break non-monobook skins or other stuff is to be made, it would be an alternative UI option.
I'd like to have a nice, stable, working UI most imporanly, anything else is additional.
<div><FONT color=#3333cc>-Aaron Schulz</FONT></div></html>
_________________________________________________________________ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
2007/5/26, Aaron Schulz jschulz_4587@msn.com:
I am quite satisfied with the current UI and tagging. If any new ideas are implemented, that will be done as alternatives (we could have global variables to set UI styles). That way if any ugly CSS hacks that probably break non-monobook skins or other stuff is to be made, it would be an alternative UI option.
I think that this could be improved significantly by not showing the state of the current version. For example, when I see a version that is not flagged at all, the option "unapproved" shouldn't show. I believe that makes life easier.
I'd like to have a nice, stable, working UI most imporanly, anything else is additional.
I agree that this is very important. However, we must not forget usability. And there, integration into the recent changes is an important topic.
Bye,
Philipp
On Sunday 27 May 2007 19:02:07 P. Birken wrote:
I think that this could be improved significantly by not showing the state of the current version. For example, when I see a version that is not flagged at all, the option "unapproved" shouldn't show. I believe that makes life easier.
Indeed. This is uneeded redundancy and of course we have to fight the boxes and editoral hint creep in Wikipedia.
While we are at it: In the interface anon people see the "current revision" tab. Therefore the hint to the curent revsion in the quality info box is redundant and can be left out.
A one-liner like in this mockup http://de.wikipedia.org/wiki/Bild:Sighted-version-mockup.png is way better than the current text. It contains all the necessary info an anon reader needs to know. The example interface text in the mockup is in English: "This article version is reviewed. There is a newer not yet reviewed version (diff)."
The quality level icon should be the first element (in my example it is a simple yellow spot), not the last and should not be separated with a newline by default (people can do this in the wiki themselves if they want).
Cheers, Arnomane
2007/5/27, Daniel Arnold arnomane@gmx.de:
While we are at it: In the interface anon people see the "current revision" tab. Therefore the hint to the curent revsion in the quality info box is redundant and can be left out.
The "quality info box" will no longer be there. That's the whole point of the design done by Jörg and Frank.
Bye,
Philipp
OK, so summing up this discussion, I'd say that the points that were brought up in this discussion can be solved and thus, I'd say we stick with the design. Jörg, could you implement this?
Bye,
Philipp
Hi *,
OK, so summing up this discussion, I'd say that the points that were brought up in this discussion can be solved and thus, I'd say we stick with the design. Jörg, could you implement this?
I try to catch up tonight or tomorrow during the day, if that's ok.
Cheers,
Joerg
Hi *,
live from the ferry, slow but working internet connection.
OK, so summing up this discussion, I'd say that the points that were brought up in this discussion can be solved and thus, I'd say we stick with the design. Jörg, could you implement this?
Ok, I understand it that we want to have the icons as designed by Frank (and overrideable by the site admins in prefs or css) on the top right corner, clicking on it opens the box, with a small cross on the top right corner (preferably directly under the mouse) to close the box again.
Right?
Cheers,
Joerg
2007/5/31, Joerg Baach lists@baach.de:
OK, so summing up this discussion, I'd say that the points that were brought up in this discussion can be solved and thus, I'd say we stick with the design. Jörg, could you implement this?
Ok, I understand it that we want to have the icons as designed by Frank (and overrideable by the site admins in prefs or css) on the top right corner, clicking on it opens the box, with a small cross on the top right corner (preferably directly under the mouse) to close the box again.
Yes, that's it! Have a nice trip :-)
Bye,
Philipp
Tim Starling has merged FileRepo work into trunk. I've added a function and fixed a few bugs there. Additionally, I've added the hooks to /trunk that FlaggedRevs uses (excepting a revisiondelete, which I'll add later, and is not important now).
Therefore the extension is no testable on trunk. Because I took a more explicit method, there are no dependencies on the rev_deleted branch anymore.
With this out of the way, I may have more time to look into styling. It really helps to give mockups for any ideas (we already have some); perhaps post them at http://www.mediawiki.org/wiki/Extension_talk:FlaggedRevs.
-<SPAN style="font color: #3333cc;">Aaron Schulz</SPAN>
_________________________________________________________________ Like the way Microsoft Office Outlook works? Youll love Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
On Thursday 31 May 2007 19:27:03 Aaron Schulz wrote:
(excepting a revisiondelete, which I'll add later, and is not important now).
Although not exactly FlaggedRevisions related I am curious to know: Is this a new feature for deleting single revisions (instead of deleting the entire article and restoring all "good" versions)? Would be a very nice time saving feature for admins. :-)
Therefore the extension is no testable on trunk.
I am sure you meant now. ;-)
With this out of the way, I may have more time to look into styling. It really helps to give mockups for any ideas (we already have some); perhaps post them at http://www.mediawiki.org/wiki/Extension_talk:FlaggedRevs.
Wow cool sounds really promising now that everything gets into shape and the tweaking begins. Thank you very much for the work so far. :-)
Cheers, Daniel
All test sites (like baach.de) should simply be running /trunk from SVN with FlaggedRevs enabled. This would give people a better idea of what it looks like atm.
-<SPAN style="font color: #3333cc;">Aaron Schulz</SPAN>
_________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm
This brings me to the point: what's the status of the wikis on the toolserver?
Bye,
Philipp
2007/6/1, Aaron Schulz jschulz_4587@msn.com:
All test sites (like baach.de) should simply be running /trunk from SVN with FlaggedRevs enabled. This would give people a better idea of what it looks like atm.
-<SPAN style="font color: #3333cc;">Aaron Schulz</SPAN>
Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
I noticed that http://baach.de/phase3 seems to have some errors and notices, likely due to using outdated PHP (a separate branch).
I'd advise completely checking out a new instance of /trunk from SVN and installing FlaggedRevs there.
-Aaron Schulz
_________________________________________________________________ Like puzzles? Play free games & earn great prizes. Play Clink now. http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2
Hi *,
I noticed that http://baach.de/phase3 seems to have some errors and notices, likely due to using outdated PHP (a separate branch).
I'd advise completely checking out a new instance of /trunk from SVN and installing FlaggedRevs there.
They are using
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/FlaggedRevs
and
http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
I try to get the testing servers set up asap, most likely tomorrow evening. Really great that the whole changes are in trunk now!
Thanks a lot,
Joerg
Sorry, there is a hook change I forgot to commit involving ArticleViewHeader. Done. SVN up /trunk again.
-Aaron Schulz
From: Joerg Baach lists@baach.de Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] http://baach.de/phase3 Date: Sun, 03 Jun 2007 21:37:24 +0100
Hi *,
I noticed that http://baach.de/phase3 seems to have some errors and
notices,
likely due to using outdated PHP (a separate branch).
I'd advise completely checking out a new instance of /trunk from SVN and installing FlaggedRevs there.
They are using
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/FlaggedRevs
and
http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
I try to get the testing servers set up asap, most likely tomorrow evening. Really great that the whole changes are in trunk now!
Thanks a lot,
Joerg
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&...
Hi *,
I installed two wikis on the toolserver:
http://tools.wikimedia.de/~stable/phase3 http://tools.wikimedia.de/~stable/phase3de
baach.de is redirecting there now.
In phase3de there are the following settings different from the default config:
$wgFlaggedRevTags = array( 'accuracy'=>1 ); $wgFlagRestrictions = array( 'accuracy' => array('review' => 1), );
I did them in FlaggedRevs.php for now, as they did not seem to have any effect when done in the LocalSettings.php. Aaron?
Who wants to have the WikiSysop password? Save to post it here, or does Phillip want to distribute it (given that he knows more members on this list than I do?)
Cheers,
Joerg
also, I looked for the nlwiki dump on
http://download.wikimedia.org/
but the dump seems to be aborted, so I leave that for now....
Cheers,
Joerg
Great, please enable file uploads :)
-Aaron Schulz
From: Joerg Baach lists@baach.de Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] http://baach.de/phase3 Date: Tue, 05 Jun 2007 18:48:01 +0100
also, I looked for the nlwiki dump on
http://download.wikimedia.org/
but the dump seems to be aborted, so I leave that for now....
Cheers,
Joerg
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
The password might be useful :)
-Aaron Schulz
From: Joerg Baach lists@baach.de Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] http://baach.de/phase3 Date: Tue, 05 Jun 2007 18:48:01 +0100
also, I looked for the nlwiki dump on
http://download.wikimedia.org/
but the dump seems to be aborted, so I leave that for now....
Cheers,
Joerg
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
Joerg Baach schrieb:
Who wants to have the WikiSysop password? Save to post it here, or does Phillip want to distribute it (given that he knows more members on this list than I do?)
+1 please :)
Btw, the German localization it up to date into SVN.
Raymond.
2007/6/5, Joerg Baach lists@baach.de:
Hi *,
I installed two wikis on the toolserver:
http://tools.wikimedia.de/~stable/phase3 http://tools.wikimedia.de/~stable/phase3de
baach.de is redirecting there now.
Great! I will ask Daniel Baur to set up a passwordprotection via the apache.
Who wants to have the WikiSysop password? Save to post it here, or does Phillip want to distribute it (given that he knows more members on this list than I do?)
I trust everybody on this list, so I would say just post it here. (OK, and the potential damage is rather small ;-) That way, anybody who might need the PW has it and can make necessary changes.
Regarding the nl dump, I'm sure it will be there again soon.
Cheers,
Philipp
Oh yes, the password for the Wikisysop is: pioneering
Please do not give this password to anybody.
Bye,
Philipp
2007/6/5, P. Birken pbirken@gmail.com:
2007/6/5, Joerg Baach lists@baach.de:
Hi *,
I installed two wikis on the toolserver:
http://tools.wikimedia.de/~stable/phase3 http://tools.wikimedia.de/~stable/phase3de
baach.de is redirecting there now.
Great! I will ask Daniel Baur to set up a passwordprotection via the apache.
Who wants to have the WikiSysop password? Save to post it here, or does Phillip want to distribute it (given that he knows more members on this list than I do?)
I trust everybody on this list, so I would say just post it here. (OK, and the potential damage is rather small ;-) That way, anybody who might need the PW has it and can make necessary changes.
Regarding the nl dump, I'm sure it will be there again soon.
Cheers,
Philipp
wikiquality-l@lists.wikimedia.org