Hum... why should these "button validations" count less, so that four or five of them are needed to change the page status? Certainly not because "the code is not being checked", since the code stays unchecked no matter how many "button validations" are done. Possibly it would be better if the button(s) opened a flyout telling users what to do: create an account if they do not have one yet, then click edit, [correct what's wrong,] change the page status and save. I think it is better that new users begin to take part in the main editing workflow rather than operating on a separate one that is designed for them.
Whether to make the _next_ page appear after saving is entirely another question, and one to which I would answer "yes". This cannot be done for the very last page of an index, of course.
Erasmo
Date: Fri, 14 Aug 2015 15:46:31 +0200 From: Andrea Zanni zanni.andrea84@gmail.com To: "discussion list for Wikisource, the free library" wikisource-l@lists.wikimedia.org Subject: Re: [Wikisource-l] Better way to validate pages Message-ID: CAC=VxyZZG0vNpOhkqN52bqYS-48U0PVopax9PuPoWpqRd_8-0g@mail.gmail.com Content-Type: text/plain; charset="utf-8"
On Fri, Aug 14, 2015 at 2:06 PM, zdzislaw zdzislaw.wiki@gmail.com wrote:
In the view mode of the yellow Pages (sic! :-)), we can add the "Thin (but long) Green Button" (TGB) described: "I read and carefully compared the contents with the scan - there's no mistakes." :) Users who "DO read our books" (and they do not want / do not have time / skills... to edit) click on this button and simply go to the view mode of the next page. Such a click would be counted (extra field in the mw database), but did not cause an immediate change of the Page status. If for a given page will be counted three??, four?? such clicks (this amount would have to have the ability to configure for each WS - community could determine their "quality threshold"
- for "one click" it will became into BGB), then the Page status would
change automatically from "yellow" to "green". Of course, it would be also configurable, to whom show TGB (ip, registered, autopotrolled ...). Such a solution would have be implemented directly in the proofread extension. "TGB" would allow adjustment of the level of "quality" and would be acceptable by most the community. If it is true that " a lot of users DO read our books," even for 5-4 "clicks" the status would change quickly.
I do like this approach, and I'd love to see some tests. I really believe that is good to do tests and experiments, as we are sometimes convinced by things that are not really proven.
A 3 step validation passage as you suggest could maybe be easy enough for new users and casual readers, and we could gain some validations we could not have had otherwise.
I also would like to repeat my question about the Visual Editor: are we close tho that or nobody is working on it?
Aubrey
IMHO, even if I'm testing the BGB as a personal script, I'm not satisfied by it, since - ironically - I don't agree fully with Andrea: I think that a good look to wiki code is mandatory, I want to see if transclusion codes are OK, I want see templates and their use and so on. Unexperienced but interested users need to look at code to learn by example. Often experienced users need too (but they are aware of such a need).
It would be great IMHO that the raw code of the page would be uploaded by default into some system variable in view mode too, so that it can be reviewed immediately by a click. It is a really simple job to do by javascript, but I think that wiki code should be uploaded by default/by an extension. I think that server and browser load would be very low.
Alex
2015-08-17 15:07 GMT+02:00 Erasmo Barresi erasmo_barresi@live.it:
Hum... why should these "button validations" count less, so that four or five of them are needed to change the page status? Certainly not because "the code is not being checked", since the code stays unchecked no matter how many "button validations" are done. Possibly it would be better if the button(s) opened a flyout telling users what to do: create an account if they do not have one yet, then click edit, [correct what's wrong,] change the page status and save. I think it is better that new users begin to take part in the main editing workflow rather than operating on a separate one that is designed for them.
Whether to make the _next_ page appear after saving is entirely another question, and one to which I would answer "yes". This cannot be done for the very last page of an index, of course.
Erasmo
Date: Fri, 14 Aug 2015 15:46:31 +0200 From: Andrea Zanni zanni.andrea84@gmail.com To: "discussion list for Wikisource, the free library" wikisource-l@lists.wikimedia.org Subject: Re: [Wikisource-l] Better way to validate pages Message-ID: CAC=VxyZZG0vNpOhkqN52bqYS-48U0PVopax9PuPoWpqRd_8-0g@mail.gmail.com Content-Type: text/plain; charset="utf-8"
On Fri, Aug 14, 2015 at 2:06 PM, zdzislaw zdzislaw.wiki@gmail.com
wrote:
In the view mode of the yellow Pages (sic! :-)), we can add the "Thin
(but
long) Green Button" (TGB) described: "I read and carefully compared the contents with the scan - there's no mistakes." :) Users who "DO read
our
books" (and they do not want / do not have time / skills... to edit)
click
on this button and simply go to the view mode of the next page. Such a click would be counted (extra field in the mw database), but did not
cause
an immediate change of the Page status. If for a given page will be
counted
three??, four?? such clicks (this amount would have to have the
ability to
configure for each WS - community could determine their "quality
threshold"
- for "one click" it will became into BGB), then the Page status would
change automatically from "yellow" to "green". Of course, it would be
also
configurable, to whom show TGB (ip, registered, autopotrolled ...). Such a solution would have be implemented directly in the proofread extension. "TGB" would allow adjustment of the level of "quality" and would be acceptable by most the community. If it is true that " a lot of users
DO
read our books," even for 5-4 "clicks" the status would change quickly.
I do like this approach, and I'd love to see some tests. I really believe that is good to do tests and experiments, as we are sometimes convinced by things that are not really proven.
A 3 step validation passage as you suggest could maybe be easy enough for new users and casual readers, and we could gain some validations we could not have had otherwise.
I also would like to repeat my question about the Visual Editor: are we close tho that or nobody is working on it?
Aubrey
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
On Mon, Aug 17, 2015 at 6:52 PM, Alex Brollo alex.brollo@gmail.com wrote:
IMHO, even if I'm testing the BGB as a personal script, I'm not satisfied by it, since - ironically - I don't agree fully with Andrea: I think that a good look to wiki code is mandatory, I want to see if transclusion codes are OK, I want see templates and their use and so on. Unexperienced but interested users need to look at code to learn by example. Often experienced users need too (but they are aware of such a need).
I see this discussion is going on, so let me draw an example I think it fits.
Take Linux, and take Windows/Apple.
If you wanted people to learn how a computer works, you give them Linux. They will have to face issues, and solve them. The will use the command line, understand a bit of architecture, and some of them will become professional and use these skills for work.
If, on the other hand, you want people just to use a computer, and do stuff with it, you give them Windows/Apple. It's simpler, it hides complexity, is made for being used and not understood.
There are drawbacks in using Windows or Apple, of course. Beside privacy and freedom factors (they are not important, in this metaphor) you just learn less, using them. But there are drawbacks in giving people Linux too: sometimes, people just don't want to learn how to use a computer. they just want to use it.
---
I think that showing the wikicode is a crucial factor in assessing the quality of the page. It's prabably a very good idea to make it mandatory for the page validation. AT THE SAME TIME, I am pretty convinced that we must not think that all Wikisource readers want to understand how Wikisource works, and are all potential Wikisource editors. I think that we can aim for them to read Wikisource, and sometimes correct a typo, if it's really easy and straightforward and quick. But they come to Wikisource to read books, not to learn hot correct books on Wikisource. It's a crucial difference.
Can we harness the simple fact that they are reading a text and give them a quick tool to fix typos when they see it? I hope so. I believe many people would use such a tool (if we make it good enough).
I don't believe that maintaining the barrier high because we want editors to learn by themselves is a very good idea, if we want Wikisource to be a place with a lot of good books to read. For me, it goes like this: Lot of correct books > lots of readers > lots of potential users It's a feedback loop and we want it to go in the right direction.
Community building is very important too, but at the same time I don't see a conflict in letting users do the good of Wikisource (correcting a typo) even if they do not become expert users. Wikisource is still too complicated, and this is one of the reasons we don't have big communities.
Aubrey
2015-08-17 19:12 GMT+02:00 Andrea Zanni zanni.andrea84@gmail.com:
*Wikisource is still too complicated*, and this is one of the reasons we don't have big communities.
IMHO what is really complicated is, the last step of digitalization (OCR review + formatting), it's almost impossible to simplify what is intrinsically complex. Do you know the Distributed Proofreaders approach to split such an intrinsic complexity into many steps?
Nevertheless, there's a wide range of complexity - some text being very simple (i.e. novels), other being extremely difficult (ancient books, theatre, scientific textbooks); perhaps the degree of complexity could be evaluated and explicitely stated, both by automatic scripts (page length + no. of templates + no. of unicode, non-ASCII characters....) and by expert users.
BGB should be used in very simple texts only.
Alex
wikisource-l@lists.wikimedia.org