design / icons

List overview All Threads
Download

newer

older

Bugs

Protection for new Wikis

Joerg Baach

21 May 2007 21 May '07

12:42 p.m.

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

Show replies by date

P. Birken

21 May 21 May

8:04 p.m.

2007/5/21, Joerg Baach <lists(a)baach.de>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

Erik Moeller

22 May 22 May

10:49 a.m.

On 5/21/07, P. Birken <pbirken(a)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. -- Peace & Love, Erik DISCLAIMER: This message does not represent an official position of the Wikimedia Foundation or its Board of Trustees. "An old, rigid civilization is reluctantly dying. Something new, open, free and exciting is waking up." -- Ming the Mechanic

P. Birken

5:15 p.m.

2007/5/22, Erik Moeller <erik(a)wikimedia.org>rg>:

...

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

Aaron Schulz

5:44 p.m.

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(a)gmail.com> Reply-To: Wikimedia Quality Discussions <wikiquality-l(a)lists.wikimedia.org> To: "Wikimedia Quality Discussions" <wikiquality-l(a)lists.wikimedia.org> Subject: Re: [Wikiquality-l] design / icons Date: Tue, 22 May 2007 19:15:02 +0200 2007/5/22, Erik Moeller <erik(a)wikimedia.org>rg>:

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(a)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_mig…

P. Birken

9:08 p.m.

2007/5/22, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

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

Aaron Schulz

10:23 p.m.

New subject: Major rewrites planned

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_mig…

P. Birken

23 May 23 May

5:05 p.m.

New subject: Major rewrites planned

2007/5/23, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

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

Kurt Jansson

5:40 p.m.

P. Birken schrieb:

...

2007/5/22, Aaron Schulz <jschulz_4587(a)msn.com>om>:

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

Kurt Jansson

5:41 p.m.

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

Daniel Arnold

24 May 24 May

4:05 p.m.

On Wednesday 23 May 2007 19:41:00 Kurt Jansson wrote:

...

P. Birken schrieb:

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

P. Birken

4:54 p.m.

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(a)gmx.de>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

Aaron Schulz

5:53 p.m.

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(a)gmail.com> Reply-To: Wikimedia Quality Discussions <wikiquality-l(a)lists.wikimedia.org> To: "Wikimedia Quality Discussions" <wikiquality-l(a)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(a)gmx.de>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.

I know that this is maybe to advanced for the first version (and we need

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(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

Daniel Arnold

25 May 25 May

11:15 a.m.

On Thursday 24 May 2007 18:54:37 P. Birken wrote:

...

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

P. Birken

2:19 p.m.

2007/5/25, Daniel Arnold <arnomane(a)gmx.de>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

Daniel Arnold

11:09 a.m.

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

P. Birken

2:17 p.m.

2007/5/25, Daniel Arnold <arnomane(a)gmx.de>de>:

...

On Monday 21 May 2007 14:42:17 Joerg Baach wrote:

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

May we could add a cross in the right upper corner wich gets you back to the originally state upon clicking? Bye, Philipp

Daniel Arnold

4:40 p.m.

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:

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

P. Birken

8:33 p.m.

2007/5/25, Daniel Arnold <arnomane(a)gmx.de>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?

OK! Everybody comfortable with this? Cheers, Philipp

Aaron Schulz

10:32 p.m.

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(a)gmail.com> Reply-To: Wikimedia Quality Discussions <wikiquality-l(a)lists.wikimedia.org> To: "Wikimedia Quality Discussions" <wikiquality-l(a)lists.wikimedia.org> Subject: Re: [Wikiquality-l] design / icons Date: Fri, 25 May 2007 22:33:15 +0200 2007/5/25, Daniel Arnold <arnomane(a)gmx.de>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

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. ;-)

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(a)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_mig…

Daniel Arnold

26 May 26 May

10:38 a.m.

On Friday 25 May 2007 22:33:15 P. Birken wrote:

...

2007/5/25, Daniel Arnold <arnomane(a)gmx.de>de>:

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

Aaron Schulz

8:51 p.m.

New subject: UI alternatives

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_mig…

P. Birken

27 May 27 May

5:02 p.m.

New subject: UI alternatives

2007/5/26, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

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

Daniel Arnold

6:56 p.m.

New subject: UI alternatives

On Sunday 27 May 2007 19:02:07 P. Birken wrote:

...

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

P. Birken

9:22 p.m.

New subject: UI alternatives

2007/5/27, Daniel Arnold <arnomane(a)gmx.de>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

P. Birken

29 May 29 May

6:39 p.m.

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

Joerg Baach

30 May 30 May

4:37 p.m.

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

Joerg Baach

31 May 31 May

10:44 a.m.

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

P. Birken

11:05 a.m.

2007/5/31, Joerg Baach <lists(a)baach.de>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?

Yes, that's it! Have a nice trip :-) Bye, Philipp

Aaron Schulz

5:27 p.m.

New subject: compatible with trunk

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_mig…

Daniel Arnold

5:45 p.m.

New subject: compatible with trunk

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

Aaron Schulz

1 Jun 1 Jun

9:10 p.m.

New subject: Test sites

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

P. Birken

2 Jun 2 Jun

10:45 a.m.

New subject: Test sites

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(a)msn.com>om>:

...

Aaron Schulz

3 Jun 3 Jun

4:46 p.m.

New subject: http://baach.de/phase3

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

Joerg Baach

8:37 p.m.

New subject: http://baach.de/phase3

Hi *,

...

Aaron Schulz

10:37 p.m.

New subject: http://baach.de/phase3

Sorry, there is a hook change I forgot to commit involving ArticleViewHeader. Done. SVN up /trunk again. -Aaron Schulz

...

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(a)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&am…

Joerg Baach

5 Jun 5 Jun

5:44 p.m.

New subject: http://baach.de/phase3

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

Joerg Baach

5:48 p.m.

New subject: http://baach.de/phase3

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

Aaron Schulz

7:04 p.m.

New subject: http://baach.de/phase3

Great, please enable file uploads :) -Aaron Schulz

...

From: Joerg Baach <lists(a)baach.de> Reply-To: Wikimedia Quality Discussions <wikiquality-l(a)lists.wikimedia.org> To: Wikimedia Quality Discussions <wikiquality-l(a)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(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

Joerg Baach

6 Jun 6 Jun

7:05 p.m.

New subject: http://baach.de/phase3

Aaron Schulz wrote:

...

Great, please enable file uploads :)

See your point, done ;-) Cheers, Joerg

Aaron Schulz

5 Jun 5 Jun

7:11 p.m.

New subject: http://baach.de/phase3

The password might be useful :) -Aaron Schulz

...

Raimond Spekking

5:59 p.m.

New subject: http://baach.de/phase3

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.

P. Birken

7:27 p.m.

New subject: http://baach.de/phase3

2007/6/5, Joerg Baach <lists(a)baach.de>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

P. Birken

6 Jun 6 Jun

8:07 a.m.

New subject: http://baach.de/phase3

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(a)gmail.com>om>:

...

2007/6/5, Joerg Baach <lists(a)baach.de>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?)

6186

days inactive

6202

days old

wikiquality-l@lists.wikimedia.org

Manage subscription

43 comments

7 participants

tags (0)

participants (7)

Aaron Schulz
Daniel Arnold
Erik Moeller
Joerg Baach
Kurt Jansson
P. Birken
Raimond Spekking