design / icons

[Joerg Baach]

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:
Loading Image...

The not-checked / no criteria met icon:
Loading Image...

There are smaller versions of these icons as well, for integration with
recent changes. Note the change on the 'not-checked' icon:

Loading Image...
Loading Image...
Loading Image...

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

[P. Birken]

Post by Joerg Baach
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]

Post by P. Birken
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.

[P. Birken]

Post by Erik Moeller
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?

Post by Erik Moeller
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]

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>

Subject: Re: [Wikiquality-l] design / icons
Date: Tue, 22 May 2007 19:15:02 +0200

Post by Erik Moeller
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?

Post by Erik Moeller
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
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________
More photos, more messages, more storage—get 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

[P. Birken]

Post by Aaron Schulz
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.

Post by Aaron Schulz
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]

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 storage—get 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

[P. Birken]

Post by Aaron Schulz
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?

Post by Aaron Schulz
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]

Post by P. Birken

Post by Aaron Schulz
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.

! :-)

Post by P. Birken
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]

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]

Post by Kurt Jansson

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

[P. Birken]

First of all, It would be important to discuss the design. Is the
design such, that we can tell Jörg to implement it?

Post by Daniel Arnold
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.

Post by Daniel Arnold
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]

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>

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?

Post by Daniel Arnold
During reading you don't want to read anew on a small error, you want to

fix

Post by Daniel Arnold
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.

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

to

Post by Daniel Arnold
test it at one point in the wild if we want to suceed) but IMHO

worthwile for

Post by Daniel Arnold
later improvements.

Yes, definitely :-)
Cheers,
Philipp
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________
More photos, more messages, more storage—get 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

[Daniel Arnold]

Post by P. Birken
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

[P. Birken]

Post by Daniel Arnold
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.

Post by Daniel Arnold
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]

Post by Joerg Baach
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
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).

Post by Joerg Baach
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).

Post by Joerg Baach
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]

Post by Daniel Arnold

Post by Joerg Baach
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
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

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.

Post by Daniel Arnold

Post by Joerg Baach
http://www.baach.de/wpdesign/Main_Page_2.html

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

[Daniel Arnold]

Post by P. Birken

Post by Daniel Arnold
However we need to keep in mind that the same corner is being used by

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

Post by P. Birken

Post by Daniel Arnold

Post by Joerg Baach
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]

Post by Daniel Arnold
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.

Post by Daniel Arnold
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.

Post by Daniel Arnold

Post by P. Birken
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

[Aaron Schulz]

Meh, I'd changed the tab schema slightly. I'll look at this later.

<div><FONT color=#3333cc>-Aaron Schulz</FONT></div></html>

Subject: Re: [Wikiquality-l] design / icons
Date: Fri, 25 May 2007 22:33:15 +0200

Post by Daniel Arnold
IMHO the Coordinate is way better placed below the title line in the

upper

Post by Daniel Arnold
right corner.
The featured article icon and the approved version icon could be placed

next

Post by Daniel Arnold
to each other (the approved icon in the right and the featured article

icon

Post by Daniel Arnold
would be placed a bit left from it) directly above the title line (and

not in

Post by Daniel Arnold
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.

Post by Daniel Arnold
Of course this would involve some small changes to some templates in

Wikipedia

Post by Daniel Arnold
but eveyone should be aware that such hacks are not supported by

MediaWiki

Post by Daniel Arnold
and that they can break anytime and of course everytime you have a

longer

Post by Daniel Arnold
site notice such hacks cause a problem with text overlays (or small

screen

Post by Daniel Arnold
resolution with a medium site notice).
So we could take this as an opportunity to get rid of these problems

with a

Post by Daniel Arnold
very good point. ;-)

Yes, but we have to be careful not to step on everyones feet.

Post by Daniel Arnold

Post by P. Birken
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

Post by Daniel Arnold
corner of the box, cause the mouse is pointing there after clicking on

the

Post by Daniel Arnold
approved icon. So that you can close it fast and comfortable again.

OK! Everybody comfortable with this?
Cheers,
Philipp
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

[Daniel Arnold]

Post by P. Birken

Post by Daniel Arnold
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.

Post by P. Birken
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.

Post by P. Birken
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.

Post by P. Birken

Post by Daniel Arnold
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]

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 storage—get 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

[P. Birken]

Post by Aaron Schulz
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.

Post by Aaron Schulz
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]

Post by P. Birken
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
Loading Image... 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]

Post by Daniel Arnold
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]

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]

Hi *,

Post by P. Birken
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]

Hi *,

live from the ferry, slow but working internet connection.

Post by P. Birken
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]

Post by Joerg Baach

Post by P. Birken
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

[Aaron Schulz]

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? You’ll love Windows Live
Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_outlook_0507

[Daniel Arnold]

Post by Aaron Schulz
(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. :-)

Post by Aaron Schulz
Therefore the extension is no testable on trunk.

I am sure you meant now. ;-)

Post by Aaron Schulz
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]

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]

This brings me to the point: what's the status of the wikis on the toolserver?

Bye,

Philipp

Post by Aaron Schulz
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
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

[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.

-Aaron Schulz

_________________________________________________________________
Like puzzles? Play free games & earn great prizes. Play Clink now.
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2

[Joerg Baach]

Hi *,

Post by 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

[Aaron Schulz]

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

-Aaron Schulz

Subject: Re: [Wikiquality-l] http://baach.de/phase3
Date: Sun, 03 Jun 2007 21:37:24 +0100
Hi *,

Post by Aaron Schulz
I noticed that http://baach.de/phase3 seems to have some errors and

notices,

Post by Aaron Schulz
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
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&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01

[Joerg Baach]

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]

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]

Great, please enable file uploads :)



-Aaron Schulz

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

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

[Joerg Baach]

Post by Aaron Schulz
Great, please enable file uploads :)

See your point, done ;-)

Cheers,

Joerg

[Aaron Schulz]

The password might be useful :)


-Aaron Schulz

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

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

[Raimond Spekking]

Post by Joerg Baach
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]

Post by Joerg Baach
Hi *,
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.

Post by Joerg Baach
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]

Oh yes, the password for the Wikisysop is: pioneering

Please do not give this password to anybody.

Bye,

Philipp

Post by P. Birken

Post by Joerg Baach
Hi *,
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.

Post by Joerg Baach
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