I tried to correct a sentence on the article MySpace in the English Wikipedia today. Well, I never got around to doing it.
Here is what I'm hit with when I click the edit button. I really tried to change the stuff I wanted. I gave up.
====Beginning of madness======
{{pp-semi-protected|small=yes}} {{Infobox Dotcom company |company_name = MySpace |company_slogan = A Place for Friends |owner = [[Fox Interactive Media]] |company_logo = [[Image:MySpace logo.svg|225px]] |company_type = [[Subsidiary]] |foundation = 2003 |location_city = [[Beverly Hills, California|Beverly Hills]], [[California]] |location_country = U.S. |key_people = [[Tom Anderson (MySpace)|Tom Anderson]], President<br>[[Chris DeWolfe]], CEO |num_employees = 300 |url = [http://www.myspace.com/ MySpace.com] |registration = Required |launch_date = August, 2003 |current_status = Active |language = [[MySpace#International sites|15 languages]] |advertising = [[Google]], [[AdSense]] |website_type = [[Social network service|Social networking]] }} [[Image:Foxinteractivemediaheadquarters.jpg|thumb|260px|Fox Interactive Media headquarters, 407 North Maple Drive, [[Beverly Hills]], California, where MySpace is also housed]]
'''MySpace''' is a popular [[social network service|social networking]] [[website]] offering an interactive, user-submitted network of friends, personal profiles, blogs, groups, photos, music and videos for teenagers and adults internationally. Its headquarters are in [[Beverly Hills]], [[California]], [[USA]],<ref>[http://www.laobserved.com/biz/2006/08/my_space_is_not_thei.php My Space is not their space anymore] - Article on the move to [[Beverly Hills]]. Retrieved March 16, 2007.</ref> where it shares an office building with its immediate owner, [[Fox Interactive Media]]; which is owned by [[News Corporation]], which has its headquarters in [[New York City]]. In June 2006, MySpace was the most popular social networking site in the [[United States]].<ref>[http://mashable.com/2006/07/11/myspace-americas-number-one/ MySpace, America's Number One<!-- Bot generated title -->]</ref> According to [[comScore]], MySpace has been overtaken by main competitor [[Facebook]] in April 2008, based on monthly unique visitors.<ref>{{cite web |url=http://www.techtree.com/India/News/Facebook_Largest_Fastest_Growing_Social_N... |title=Facebook: Largest, Fastest Growing Social Network |accessdate=2008-08-14 |author=Techtree News Staff |date=2008-08-13 |work=Techtree.com |publisher=ITNation |doi= |archiveurl= |archivedate= |quote= }}</ref> The company employs 300 staff<ref name="CNNMoney-MyspaceCowboys">{{cite news | url=http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in... | publisher=CNN | title=MySpace Cowboys | last=Sellers | first=Patricia | date=2006-08-24 | accessdate=2006-08-28 }}</ref> and does not disclose [[revenue]]s or [[profit]]s separately from News Corporation. The 100 millionth account was created on August 6, 2006<ref name="MySpace100Millionth Profile">{{cite news |url=http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendI... |publisher=MySpace |title=100,000,000th Account |date=2007-02-25 |accessdate=2007-02-21 }}</ref> in the [[Netherlands]]<ref name="Murdochcomments">{{cite news | url=http://internet.seekingalpha.com/article/15237 | publisher=SeekingAlpha | title=Rupert Murdoch Comments on Fox Interactive's Growth | last=Murdoch | first=Rupert | date=2006-08-09 | accessdate=2006-09-12 }}</ref> and approximately 106 million accounts on September 8, 2006,<ref name="ElReg-MySpaceMusic">{{cite news | url = http://go.theregister.com/feed/http://www.theregister.co.uk/2006/09/08/myspa... | title = MySpace music deal poses multiple threats | date= 2006-09-08 | accessdate = 2006-09-08 | publisher = The Register }}</ref> and the site attracts 230,000 new users per day.<ref>{{cite news|last=Sellers|first=Patricia|title=MySpace cowboys|url=http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in... (magazine)|Money]]|publisher=CNN.com|date=2006-09-04|accessdate=2008-04-13}}</ref>
=======End of madness======
If we're really to bring knowledge to the world, it's becoming urgent that we work on accessibility, because even experienced users (I consider myself one) just can't do it.
In any case, if anyone wants to (can?) make the change, here is what I wanted to change:
Change the sentence "The 100 millionth account was created on August 6, 2006[5] in the Netherlands[6] and approximately 106 million accounts on September 8, 2006,[7] and the site attracts 230,000 new users per day.[8]"
Which does not make sense, to something like:
"The 100 millionth account was created on August 6, 2006 [5] in the Netherlands [6] and the site counted approximately 106 million accounts on September 8, 2006 [7]. MySpace.com attracts 230,000 new users per day. [8]"
Which actually makes sense.
Delphine
2008/9/25 Delphine Ménard notafishz@gmail.com:
If we're really to bring knowledge to the world, it's becoming urgent that we work on accessibility, because even experienced users (I consider myself one) just can't do it.
We can for example the code you posted is just an infobox, a picture and some refed text. Something you will find in most articles although the opening para tends not to be that heavily refed.
Still yes more normal users do have a problem. Most implementable solution at this point is probably syntax highlighting with as default everything other than straight article text being grayed out.
In any case, if anyone wants to (can?) make the change, here is what I wanted to change:
Done. So I guess you could edit it, but indirectly!
You're right, the way we currently do references results in a complete mess. It requires some development work to make any progress, I think - I'll take a look at the relevant code and see if it can be done easily.
Thomas Dalton thomas.dalton@gmail.com wrote:
You're right, the way we currently do references results in a complete mess. It requires some development work to make any progress, I think
- I'll take a look at the relevant code and see if it can be done
easily.
One solution would be to define references at the bottom of the article, and use them in the text. (This is possible with the current implementation, but only messily.) Then the code above would look something like below.
The infobox is a separate problem, but fixing the inline references will be a huge improvement.
###################################### The 100 millionth account was created on August 6, 2006<ref name="MySpace100Millionth" /> in the [[Netherlands]]<ref name="Murdochcomments" /> and approximately 106 million accounts on September 8, 2006,<ref name="ElReg-MySpaceMusic" /> and the site attracts 230,000 new users per day<ref name="PatriciaSellers" />.
==References== <ref name="MySpace100Millionth Profile">{{cite news |url=http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendI... |publisher=MySpace |title=100,000,000th Account |date=2007-02-25 |accessdate=2007-02-21 }}</ref>
<ref name="Murdochcomments">{{cite news | url=http://internet.seekingalpha.com/article/15237 | publisher=SeekingAlpha | title=Rupert Murdoch Comments on Fox Interactive's Growth | last=Murdoch | first=Rupert | date=2006-08-09 | accessdate=2006-09-12 }}</ref>
<ref name="ElReg-MySpaceMusic">{{cite news | url = http://go.theregister.com/feed/http://www.theregister.co.uk/2006/09/08/myspa... | title = MySpace music deal poses multiple threats | date= 2006-09-08 | accessdate = 2006-09-08 | publisher = The Register }}</ref>
<ref name="PatriciaSellers">{{cite news|last=Sellers|first=Patricia|title=MySpace cowboys|url=http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in... (magazine)|Money]]|publisher=CNN.com|date=2006-09-04|accessdate=2008-04-13}}</ref>
<references /> ######################################
On Thu, Sep 25, 2008 at 8:23 AM, Jesse Plamondon-Willard pathoschild@gmail.com wrote:
Thomas Dalton thomas.dalton@gmail.com wrote:
You're right, the way we currently do references results in a complete mess. It requires some development work to make any progress, I think
- I'll take a look at the relevant code and see if it can be done
easily.
One solution would be to define references at the bottom of the article, and use them in the text. (This is possible with the current implementation, but only messily.) Then the code above would look something like below.
The infobox is a separate problem, but fixing the inline references will be a huge improvement.
###################################### The 100 millionth account was created on August 6, 2006<ref name="MySpace100Millionth" /> in the [[Netherlands]]<ref name="Murdochcomments" /> and approximately 106 million accounts on September 8, 2006,<ref name="ElReg-MySpaceMusic" /> and the site attracts 230,000 new users per day<ref name="PatriciaSellers" />.
==References== <ref name="MySpace100Millionth Profile">{{cite news |url=http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendI... |publisher=MySpace |title=100,000,000th Account |date=2007-02-25 |accessdate=2007-02-21 }}</ref>
<ref name="Murdochcomments">{{cite news | url=http://internet.seekingalpha.com/article/15237 | publisher=SeekingAlpha | title=Rupert Murdoch Comments on Fox Interactive's Growth | last=Murdoch | first=Rupert | date=2006-08-09 | accessdate=2006-09-12 }}</ref>
<ref name="ElReg-MySpaceMusic">{{cite news | url = http://go.theregister.com/feed/http://www.theregister.co.uk/2006/09/08/myspa... | title = MySpace music deal poses multiple threats | date= 2006-09-08 | accessdate = 2006-09-08 | publisher = The Register }}</ref>
<ref name="PatriciaSellers">{{cite news|last=Sellers|first=Patricia|title=MySpace cowboys|url=http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in... (magazine)|Money]]|publisher=CNN.com|date=2006-09-04|accessdate=2008-04-13}}</ref>
<references /> ######################################
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
-- phoebe
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
The problem at the moment is that you would end up with links to each ref at the bottom of the article and each ref would have an extra letter linking back to those links. I'm looking at the code now to see how easy it would be to allow hidden refs - it should be doable.
Don't waste your time, it has already been donehttp://www.mediawiki.org/wiki/Extension_talk:Cite/Cite.php#Variation_for_refs_in_the_final_references_block, just not implemented.
2008/9/25 Thomas Dalton thomas.dalton@gmail.com
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
The problem at the moment is that you would end up with links to each ref at the bottom of the article and each ref would have an extra letter linking back to those links. I'm looking at the code now to see how easy it would be to allow hidden refs - it should be doable.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Thu, Sep 25, 2008 at 8:37 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
The problem at the moment is that you would end up with links to each ref at the bottom of the article and each ref would have an extra letter linking back to those links. I'm looking at the code now to see how easy it would be to allow hidden refs - it should be doable.
I wrote code to create a <refdefine> tag to do that literally years ago. There wasn't much interest in it at the time.
-Robert Rohde
2008/9/25 Robert Rohde rarohde@gmail.com:
On Thu, Sep 25, 2008 at 8:37 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
The problem at the moment is that you would end up with links to each ref at the bottom of the article and each ref would have an extra letter linking back to those links. I'm looking at the code now to see how easy it would be to allow hidden refs - it should be doable.
I wrote code to create a <refdefine> tag to do that literally years ago. There wasn't much interest in it at the time.
I've got a patch written now, didn't take long at all. I've just added an attribute to the existing ref tag. <ref name="foo" hidden="true">text</ref> won't appear inline and won't be linked back to. It seems a much simpler approach to the others I've seen. I've put it on the bugtracker (https://bugzilla.wikimedia.org/show_bug.cgi?id=15724), I suggest implementing it and just giving people to option of using it, see what happens.
reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
-- phoebe
I cannot see anything positive in that refname system. It is complicated to the user and invites people to indicate less thoroughly were the information comes from (dropping page numbers, because it's the same book). There is absolutely no problem to copy the full reference information into the ref, making it independent from other refs and from "Literature".
Ziko
I cannot see anything positive in that refname system. It is complicated to the user and invites people to indicate less thoroughly were the information comes from (dropping page numbers, because it's the same book). There is absolutely no problem to copy the full reference information into the ref, making it independent from other refs and from "Literature".
The problem is that it results in the source of the article being a complicated mess than new users don't stand a chance of understanding.
2008/9/25 phoebe ayers phoebe.wiki@gmail.com:
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
-- phoebe
Basically it results in a high maintenance cost with a fairly high chance of errors. It means you have to keep the article text and the end section in sync rather than just keeping all the stuff in one place.
2008/9/25 geni geniice@gmail.com:
2008/9/25 phoebe ayers phoebe.wiki@gmail.com:
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
-- phoebe
Basically it results in a high maintenance cost with a fairly high chance of errors. It means you have to keep the article text and the end section in sync rather than just keeping all the stuff in one place.
If a reference is used more than once, it's not all in one place anyway. It actually solves the issue of someone accidentally deleting the text for the ref not realising it is used elsewhere. For refs only used once, it makes maintenance of the ref a little harder, but maintenance of the rest of the article much easier.
2008/9/25 Thomas Dalton thomas.dalton@gmail.com:
If a reference is used more than once, it's not all in one place anyway. It actually solves the issue of someone accidentally deleting the text for the ref not realising it is used elsewhere. For refs only used once, it makes maintenance of the ref a little harder, but maintenance of the rest of the article much easier.
There are areas where articles are likely to rack up a lot of single use refs. But such a system already exists. Doesn't help a huge amount. See:
http://en.wikipedia.org/wiki/Manchester_Bolton_and_Bury_Canal#Work_begins
It is not only the references that could benefit from being moved away from the start of the article. The first thing a user sees in the edit field is usually an infobox. These too can get quite big and don't obviously enough correspond to the article itself. How obvious is it anyway that the content of the second column is defined ahead of the first?
A possibility to move the definition of the infobox out of the way would present a reasonably recognisable text to the user. I believe both new and old users would benefit.
Hans A. Rosbach (Haros)
On Thu, Sep 25, 2008 at 6:41 PM, geni geniice@gmail.com wrote:
2008/9/25 Thomas Dalton thomas.dalton@gmail.com:
If a reference is used more than once, it's not all in one place anyway. It actually solves the issue of someone accidentally deleting the text for the ref not realising it is used elsewhere. For refs only used once, it makes maintenance of the ref a little harder, but maintenance of the rest of the article much easier.
There are areas where articles are likely to rack up a lot of single use refs. But such a system already exists. Doesn't help a huge amount. See:
http://en.wikipedia.org/wiki/Manchester_Bolton_and_Bury_Canal#Work_begins
-- geni
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Thu, Sep 25, 2008 at 9:14 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
2008/9/25 geni geniice@gmail.com:
2008/9/25 phoebe ayers phoebe.wiki@gmail.com:
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
-- phoebe
Basically it results in a high maintenance cost with a fairly high chance of errors. It means you have to keep the article text and the end section in sync rather than just keeping all the stuff in one place.
If a reference is used more than once, it's not all in one place anyway. It actually solves the issue of someone accidentally deleting the text for the ref not realising it is used elsewhere. For refs only used once, it makes maintenance of the ref a little harder, but maintenance of the rest of the article much easier.
And arguably it would make it easier, not harder, if you had several similar refs, to correct any errors in all of your references at once, see irregularities, etc.
-- phoebe
The Mediawiki software, the wiki syntax and the Wiki interface is in desperate need of a few people with some knowledge on user interfaces and semantics who can make useful suggestions on enhancing it. That won't be easy, as the wiki syntax was built in a very organic way, without a lot of standardization or good thought on how it will work in the future. This had the benefit that the projects could grow very fast, but the problems are showing right now.
WYSIWYG editors are not the solution because, as Delphine pointed out, they don't magically add semantic meaning to text, they just make it look pretty. What is really needed is a standard on what wikitext is, what wikitext isn't and what wikitext will be in the future. HTML has gone through the same process, and i believe we are on the same stage right now as when people were beginning to think that the <blink> tag was a bad thing.
So, something like a specification for MediaWiki wikitext should be agreed upon (in a text document, not in the MediaWiki PHP code). After that, on a solid foundation, nice gadgets can be built to help people built tables and templates.
-- Hay / Husky
On Fri, Sep 26, 2008 at 1:03 AM, phoebe ayers phoebe.wiki@gmail.com wrote:
On Thu, Sep 25, 2008 at 9:14 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
2008/9/25 geni geniice@gmail.com:
2008/9/25 phoebe ayers phoebe.wiki@gmail.com:
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
-- phoebe
Basically it results in a high maintenance cost with a fairly high chance of errors. It means you have to keep the article text and the end section in sync rather than just keeping all the stuff in one place.
If a reference is used more than once, it's not all in one place anyway. It actually solves the issue of someone accidentally deleting the text for the ref not realising it is used elsewhere. For refs only used once, it makes maintenance of the ref a little harder, but maintenance of the rest of the article much easier.
And arguably it would make it easier, not harder, if you had several similar refs, to correct any errors in all of your references at once, see irregularities, etc.
-- phoebe
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Well, Brion probably knows what's coming, but what you are describing was attempted here:
A commonly agreed upon wiki syntax that is easy to use. Wiki Creole is actually mostly derived from Mediawiki Syntax.
It is a success---many wiki engines use it. Brion was at the first workshop and expressed his support and interest, and we discussed many migration options. As far as I can tell nothing happened wrt to Mediawiki using WikiCreole---the reality of day-to-day work and the complexity of a heavy-duty wiki engine took its toll (my guess).
If you are serious about reviving efforts for simplified or more formally defined wiki text (i.e. a specification not just an implementation) I suggest you talk to the Wiki Creole guys. You may also like my own work on an (EBNF) grammar for wiki text, see http://www.riehle.org/category/wiki-tech/
Cheers, Dirk
On Thu, Sep 25, 2008 at 4:48 PM, Husky huskyr@gmail.com wrote:
The Mediawiki software, the wiki syntax and the Wiki interface is in desperate need of a few people with some knowledge on user interfaces and semantics who can make useful suggestions on enhancing it. That won't be easy, as the wiki syntax was built in a very organic way, without a lot of standardization or good thought on how it will work in the future. This had the benefit that the projects could grow very fast, but the problems are showing right now.
WYSIWYG editors are not the solution because, as Delphine pointed out, they don't magically add semantic meaning to text, they just make it look pretty. What is really needed is a standard on what wikitext is, what wikitext isn't and what wikitext will be in the future. HTML has gone through the same process, and i believe we are on the same stage right now as when people were beginning to think that the <blink> tag was a bad thing.
So, something like a specification for MediaWiki wikitext should be agreed upon (in a text document, not in the MediaWiki PHP code). After that, on a solid foundation, nice gadgets can be built to help people built tables and templates.
-- Hay / Husky
On Fri, Sep 26, 2008 at 1:03 AM, phoebe ayers phoebe.wiki@gmail.com wrote:
On Thu, Sep 25, 2008 at 9:14 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
2008/9/25 geni geniice@gmail.com:
2008/9/25 phoebe ayers phoebe.wiki@gmail.com:
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
-- phoebe
Basically it results in a high maintenance cost with a fairly high chance of errors. It means you have to keep the article text and the end section in sync rather than just keeping all the stuff in one place.
If a reference is used more than once, it's not all in one place anyway. It actually solves the issue of someone accidentally deleting the text for the ref not realising it is used elsewhere. For refs only used once, it makes maintenance of the ref a little harder, but maintenance of the rest of the article much easier.
And arguably it would make it easier, not harder, if you had several similar refs, to correct any errors in all of your references at once, see irregularities, etc.
-- phoebe
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Thu, Sep 25, 2008 at 6:57 PM, Dirk Riehle dirk@riehle.org wrote:
Well, Brion probably knows what's coming, but what you are describing was attempted here:
A commonly agreed upon wiki syntax that is easy to use. Wiki Creole is actually mostly derived from Mediawiki Syntax.
It is a success---many wiki engines use it. Brion was at the first workshop and expressed his support and interest, and we discussed many migration options. As far as I can tell nothing happened wrt to Mediawiki using WikiCreole---the reality of day-to-day work and the complexity of a heavy-duty wiki engine took its toll (my guess).
If you are serious about reviving efforts for simplified or more formally defined wiki text (i.e. a specification not just an implementation) I suggest you talk to the Wiki Creole guys. You may also like my own work on an (EBNF) grammar for wiki text, see http://www.riehle.org/category/wiki-tech/
A uniform syntax across wikis is a good goal, but it really doesn't address the issue talked about here. The character sequence for marking bold or italic text doesn't present an additional learning curve; it's the meta-programming language we've introduced to allow people to be really clever and make pretty boxes with obscure syntax that poses a problem. Or rather, it's that they need to take advantage of it.
Metadata (the #1 use for templates) is something not addressed by the MediaWiki software at all (save for categories and alternate languages). It's instead left for people to implement themselves in an arbitrary, non-normalized way. This hacked-in functionality results in the unintuitive mess Delphine encountered.
A WYSIWYG interface isn't an answer by itself, but normalizing metadata and providing an interface for it can be. I don't outline a comprehensive solution, and I know it's been talked about many times before, but I do think that we shouldn't be afraid to implement Wikipedia-specific functionality in MediaWiki. (And similar for any other projects; all I'm saying is that it doesn't need to be a generic pseudo-solution. MediaWiki is our software, first and foremost.)
Austin
So, something like a specification for MediaWiki wikitext should be agreed upon (in a text document, not in the MediaWiki PHP code). After that, on a solid foundation, nice gadgets can be built to help people built tables and templates.
People have been working on that, but doing so in a way that preserves backwards compatibility proves challenging since the existing code is very idiosyncratic. Ideally, we need to make a new syntax from scratch, but that clearly isn't an option.
On Fri, Sep 26, 2008 at 9:48 AM, Husky huskyr@gmail.com wrote:
WYSIWYG editors are not the solution because, as Delphine pointed out, they don't magically add semantic meaning to text, they just make it look pretty.
I think these sort of assumptions about wysiwyg are wrong. Just because Word encourages people to increase the font and use bold instead of adding a properly structured header does not mean that a wiki solution would do the same thing. The FCK Editor for MediaWiki has options for "normal, heading 2, heading 3, preformatted". Increasing the font size isn't an option in wysiwyg any more than it is in wikitext (you can still switch to wikitext and do that with HTML if you need to). Wikia will hopefully have a public demo of this soon so I can show you what I mean.
Angela
Yeah, that seems far more friendly for all involved. I wonder how feasible it is to change format incrementally - add it as a simple fix in AWB for example?
Mike
2008/9/25 Nemo_bis nemowiki@gmail.com:
Cite templates are against wiki-text philosophy.
Would you care to elaborate? Wiki-text doesn't really have a philosophy, it's just what developers felt was a good idea at the time (and later regretted in many cases, I believe!). It's generally intended to be simple to use, but cite templates are certainly simpler to use than writing out the reference by hand, so I don't know what you mean...
Thomas Dalton:
Would you care to elaborate?
«A wiki enables documents to be written collaboratively, in a simple markup language using a Web browser» (http://en.wikipedia.org/wiki/Wiki).
I think this (http://en.wikipedia.org/w/index.php?title=Manchester_Bolton_%26_Bury_Canal&a...) is still absurd. We should write «<ref>Priestley 1831, p. 435.</ref>», not «<ref name="Priestleyp435">{{Harvnb|Priestley|1831|p=435.}}</ref>». All that code only to add this quite useless link http://en.wikipedia.org/wiki/Manchester_Bolton_%26_Bury_Canal#CITEREFPriestl... ? :-/
Nemo
The problem isn't cite templates as such. It's including cite templates in the main body of text that's the problem. The issue here is people thinking it's clever to jam their "notes" section and their "references" section together. If you have two separate sections, then all that has to go in the ref tags (and consequently in the main body of text) is the author's name and page number, as the full reference is already listed elsewhere. This makes editing the article possible.
CM
Odi profanum vulgus et arceo.
From: nemowiki@gmail.com To: foundation-l@lists.wikimedia.org Date: Thu, 25 Sep 2008 20:41:20 +0200 Subject: Re: [Foundation-l] Can anyone really edit Wikipedia?
Cite templates are against wiki-text philosophy.
Nemo _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
_________________________________________________________________ Discover Bird's Eye View now with Multimap from Live Search http://clk.atdmt.com/UKM/go/111354026/direct/01/
On Thu, Sep 25, 2008 at 3:12 PM, Christiano Moreschi moreschiwikiman@hotmail.co.uk wrote:
The problem isn't cite templates as such. It's including cite templates in the main body of text that's the problem. The issue here is people thinking it's clever to jam their "notes" section and their "references" section together. If you have two separate sections, then all that has to go in the ref tags (and consequently in the main body of text) is the author's name and page number, as the full reference is already listed elsewhere. This makes editing the article possible.
Create a flexible citation tool that can be used both ways (inline and out of line). Communities can decide which style of citation tool best meets their own needs. Smaller projects like Wikibooks or Wikiversity place a much higher premium on attracting new members and lowering the technical barrier to entry then Wikipedia apparently does. Wikipedia, conversely, would probably be wise to put the needs of their active long-term maintenance people above those of random new users.
Point being, this is clearly not one-size-fits-all, and trying to create a single solution that everybody must be forced to use is not really tenable. Adding an ability to put references at the end of the page (or even on a separate page entirely, as Wikibooks has been asking for) gives the flexibility for projects to produce the results they want from it.
--Andrew Whitworth
On Thu, Sep 25, 2008 at 8:29 AM, phoebe ayers phoebe.wiki@gmail.com wrote:
One solution would be to define references at the bottom of the article, and use them in the text. (This is possible with the current implementation, but only messily.) Then the code above would look something like below.
I was going to say as well, what happened to that proposal to define references at the bottom of the article instead of inline? And then Pathos posted a nice implementation above. It does make a whole lot more sense from both a reader and an editor's point of view to have reference metadata in a single place, away from the wikitext. Defining refs with a "refname" in the text doesn't seem too bad... other than the mess of trying to get a different stylistic system going, is there some reason we don't do this?
That would be a huge leap forward.
-Luna
Well, we can change the way refs are done, sure, but I think we want to watch how we downplay them. We don't want to make them less present, we want to make them more comprehensible to the layman. Refs are an intrinsic part of an article, and it doesn't necessarily help an article to make them easier for contributors to ignore.
--Ford MF
On 9/25/08, Thomas Dalton thomas.dalton@gmail.com wrote:
In any case, if anyone wants to (can?) make the change, here is what I wanted to change:
Done. So I guess you could edit it, but indirectly!
You're right, the way we currently do references results in a complete mess. It requires some development work to make any progress, I think
- I'll take a look at the relevant code and see if it can be done
easily.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Thu, Sep 25, 2008 at 11:12 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
You're right, the way we currently do references results in a complete mess. It requires some development work to make any progress, I think
- I'll take a look at the relevant code and see if it can be done
easily.
Some kind of syntax highlighting might be good (we obviously have syntax highlighting extensions already installed, the trick now is just making it work in the edit window). Syntax folding might be a nice addition too, but I've never seen that in a working web interface. WYSIWYG is obviously the ultimate goal, but progress on that has been understandably slow. There are some interesting helpful editing extensions available, maybe some of them need to be evaluated and good cross-platform features could be folded into MediaWiki's core eventually.
--Andrew Whitworth
On Thu, Sep 25, 2008 at 17:37, Andrew Whitworth wknight8111@gmail.com wrote:
On Thu, Sep 25, 2008 at 11:12 AM, Thomas Dalton thomas.dalton@gmail.com wrote:
You're right, the way we currently do references results in a complete mess. It requires some development work to make any progress, I think
- I'll take a look at the relevant code and see if it can be done
easily.
Some kind of syntax highlighting might be good (we obviously have syntax highlighting extensions already installed, the trick now is just making it work in the edit window). Syntax folding might be a nice addition too, but I've never seen that in a working web interface. WYSIWYG is obviously the ultimate goal, but progress on that has been understandably slow. There are some interesting helpful editing extensions available, maybe some of them need to be evaluated and good cross-platform features could be folded into MediaWiki's core eventually.
For what it's worth, I think WYSIWYG is evil. But there is probably a middle path between cluttered text and Word-like unstructuration.
To some extent, I am thinking that this difficult in editing might prompt vandalism (It's all gibberish anyway, so who cares") and prevent participation ("I seriously tried to edit this page to make this grammatical mistake go away, but I just couldn't".)
Delphine
On Thu, Sep 25, 2008 at 11:42 AM, Delphine Ménard notafishz@gmail.com wrote:
For what it's worth, I think WYSIWYG is evil. But there is probably a middle path between cluttered text and Word-like unstructuration.
What has WYSIWYG ever done to you? :)
What about some kind of separation? We put together a gadget that reads the text when you open an edit window and moves all the complicated stuff (refs, complicated infobox templates, etc) out of the main edit window and into a secondary edit window? When you click "Save" the javascript reinserts the data before sending it off to the server. This idea is off the top of my head and is obviously not perfect, but does this kind of concept address your concerns?
--Andrew Whitwoth
2008/9/25 Delphine Ménard notafishz@gmail.com:
For what it's worth, I think WYSIWYG is evil. But there is probably a middle path between cluttered text and Word-like unstructuration.
It shouldn't be worse than wikitext - wikitext isn't any more structured than Word. It's a display markup code that translates into HTML, not a document structure code.
- d.
On Thu, Sep 25, 2008 at 17:48, David Gerard dgerard@gmail.com wrote:
2008/9/25 Delphine Ménard notafishz@gmail.com:
For what it's worth, I think WYSIWYG is evil. But there is probably a middle path between cluttered text and Word-like unstructuration.
It shouldn't be worse than wikitext - wikitext isn't any more structured than Word. It's a display markup code that translates into HTML, not a document structure code.
Maybe not, but it mostly forces some kind of structure if you want it to look "pretty". Which WYSIWYG doesn't. You can just bold up stuff and make it size 40 and it looks like a header, but isn't one. That's what I mean with "structure", if that make sense.
Delphine
That makes perfect sense, and that is exactly the rationale behind LaTeX (and other such typesetting software). Good documents have good structure; WYSIWYG is not intended to foster good structure, it's designed to foster looking pretty. While looking pretty is nice, it should never come at the expense of form. If you have good structure the rest can come along behind.
Mike
-----Original Message----- From: Delphine Ménard [mailto:notafishz@gmail.com] Sent: September 25, 2008 1:55 PM To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Can anyone really edit Wikipedia?
On Thu, Sep 25, 2008 at 17:48, David Gerard dgerard@gmail.com wrote:
2008/9/25 Delphine Ménard notafishz@gmail.com:
For what it's worth, I think WYSIWYG is evil. But there is probably a middle path between cluttered text and Word-like unstructuration.
It shouldn't be worse than wikitext - wikitext isn't any more structured than Word. It's a display markup code that translates into HTML, not a document structure code.
Maybe not, but it mostly forces some kind of structure if you want it to look "pretty". Which WYSIWYG doesn't. You can just bold up stuff and make it size 40 and it looks like a header, but isn't one. That's what I mean with "structure", if that make sense.
Delphine
mikelifeguard@fastmail.fm wrote:
That makes perfect sense, and that is exactly the rationale behind LaTeX (and other such typesetting software). Good documents have good structure; WYSIWYG is not intended to foster good structure, it's designed to foster looking pretty. While looking pretty is nice, it should never come at the expense of form. If you have good structure the rest can come along behind.
As someone who mainly uses LaTeX but also uses Word for academic papers (depending on the field), this doesn't make any sense to me. Both LaTeX and Word let you do both semantic and pretty-looking stuff. In LaTeX I can mark a section title with e.g. \subsection{}, and in Word I can select the "subsection" style in the toolbar; in both cases, this is semantic meaning, which then gets formatted according to the stylesheet or template being used. And, in either one, I can do semantically meaningless formatting, e.g. in LaTeX use {\large Subsection title} instead of using \subsection{Subsection title}, and similarly in Word.
The degree towards which you promote one or the other is completely orthogonal to WYSIWYG versus markup-based formatting, and depends on which primitives you provide and make easiest to use in the interface (where "interface" means either the markup language or the GUI, as the case may be).
-Mark
2008/9/27 Delirium delirium@hackish.org:
mikelifeguard@fastmail.fm wrote:
That makes perfect sense, and that is exactly the rationale behind LaTeX (and other such typesetting software). Good documents have good structure; WYSIWYG is not intended to foster good structure, it's designed to foster looking pretty. While looking pretty is nice, it should never come at the expense of form. If you have good structure the rest can come along behind.
As someone who mainly uses LaTeX but also uses Word for academic papers (depending on the field), this doesn't make any sense to me. Both LaTeX and Word let you do both semantic and pretty-looking stuff. In LaTeX I can mark a section title with e.g. \subsection{}, and in Word I can select the "subsection" style in the toolbar; in both cases, this is semantic meaning, which then gets formatted according to the stylesheet or template being used. And, in either one, I can do semantically meaningless formatting, e.g. in LaTeX use {\large Subsection title} instead of using \subsection{Subsection title}, and similarly in Word.
The degree towards which you promote one or the other is completely orthogonal to WYSIWYG versus markup-based formatting, and depends on which primitives you provide and make easiest to use in the interface (where "interface" means either the markup language or the GUI, as the case may be).
That's true, but when people use LaTeX they always do it properly with all the semantic information included, when people use Word they rarely do. WYSIWYG doesn't stop you doing things properly, but it does make it easier not to.
Thomas Dalton wrote:
That's true, but when people use LaTeX they always do it properly with all the semantic information included, when people use Word they rarely do. WYSIWYG doesn't stop you doing things properly, but it does make it easier not to.
Hah, I wish that were true. Since the LaTeX stylesheet language is a terrible stack-based monstrosity that nobody wants to edit, real-world LaTeX use is riddled with manual formatting, especially nonsense like \vspace{}. In any case, WYSIWYG doesn't make it easier not to do things properly; *Word's* specific implementation of WYSIWYG makes it easier, by making lots of semantically-meaningless formatting commands easy to get to. Nobody is saying that a wikitext WYSIWYG editor ought to copy the interface of Word.
In any case, if we're taking LaTeX as an analog for wikitext, there are LaTeX WYSIWYG editors (like LyX), so the analogy isn't much of an argument against wikitext WYSIWYG editors.
-Mark
On Thu, Sep 25, 2008 at 5:42 PM, Delphine Ménard notafishz@gmail.com wrote:
On Thu, Sep 25, 2008 at 17:37, Andrew Whitworth wknight8111@gmail.com wrote:
Some kind of syntax highlighting might be good (we obviously have syntax highlighting extensions already installed, the trick now is just making it work in the edit window). Syntax folding might be a nice addition too, but I've never seen that in a working web interface. WYSIWYG is obviously the ultimate goal, but progress on that has been understandably slow. There are some interesting helpful editing extensions available, maybe some of them need to be evaluated and good cross-platform features could be folded into MediaWiki's core eventually.
For what it's worth, I think WYSIWYG is evil. But there is probably a middle path between cluttered text and Word-like unstructuration.
To some extent, I am thinking that this difficult in editing might prompt vandalism (It's all gibberish anyway, so who cares") and prevent participation ("I seriously tried to edit this page to make this grammatical mistake go away, but I just couldn't".)
http://mediawiki.fckeditor.net/ might be useful tho. It allows to enter structure as well as specify looks.
Might be better to take out the looks parts tho.
Finne/henna
On Sat, Sep 27, 2008 at 6:20 PM, Finne Boonen hennar@gmail.com wrote:
http://mediawiki.fckeditor.net/ might be useful tho. It allows to enter structure as well as specify looks.
FCKeditor has a good approach, but, it is still not for usage on Wikipedia (while it may be used on some sites which are not using extensively Parser and similar functions). But, it is the best WYSIWYG editor for MediaWiki and it would be a good idea if MediaWiki developers start to work more closely with FCKeditor developers on solving problems; as well as it would be a good idea if Wikimedians are able to test its functions extensively and to submit bug reports.
This long-standing complaint of wiki complexity, e.g., that users must write encyclopedia articles in a turing complete language, is reminiscent of the motivations for cascading style sheets. You need to separate style from content for maintainability and accessibility. Likewise, users should not be specifying infobox structure and content in the same place (I use infoboxes as an example). The interfaces really need to be separate - you edit the infobox using html form fields, and you specify the structure and style of the infobox and it's form fields using some kind of interface language. There are some weak extensions to help users fill out tables and the like with this method and it really should be expanded on IMO.
On Thu, Sep 25, 2008 at 9:02 AM, Delphine Ménard notafishz@gmail.comwrote:
I tried to correct a sentence on the article MySpace in the English Wikipedia today. Well, I never got around to doing it.
Here is what I'm hit with when I click the edit button. I really tried to change the stuff I wanted. I gave up.
====Beginning of madness======
{{pp-semi-protected|small=yes}} {{Infobox Dotcom company |company_name = MySpace |company_slogan = A Place for Friends |owner = [[Fox Interactive Media]] |company_logo = [[Image:MySpace logo.svg|225px]] |company_type = [[Subsidiary]] |foundation = 2003 |location_city = [[Beverly Hills, California|Beverly Hills]], [[California]] |location_country = U.S. |key_people = [[Tom Anderson (MySpace)|Tom Anderson]], President<br>[[Chris DeWolfe]], CEO |num_employees = 300 |url = [http://www.myspace.com/ MySpace.com] |registration = Required |launch_date = August, 2003 |current_status = Active |language = [[MySpace#International sites|15 languages]] |advertising = [[Google]], [[AdSense]] |website_type = [[Social network service|Social networking]] }} [[Image:Foxinteractivemediaheadquarters.jpg|thumb|260px|Fox Interactive Media headquarters, 407 North Maple Drive, [[Beverly Hills]], California, where MySpace is also housed]]
'''MySpace''' is a popular [[social network service|social networking]] [[website]] offering an interactive, user-submitted network of friends, personal profiles, blogs, groups, photos, music and videos for teenagers and adults internationally. Its headquarters are in [[Beverly Hills]], [[California]], [[USA]],<ref>[ http://www.laobserved.com/biz/2006/08/my_space_is_not_thei.php My Space is not their space anymore] - Article on the move to [[Beverly Hills]]. Retrieved March 16, 2007.</ref> where it shares an office building with its immediate owner, [[Fox Interactive Media]]; which is owned by [[News Corporation]], which has its headquarters in [[New York City]]. In June 2006, MySpace was the most popular social networking site in the [[United States]].<ref>[http://mashable.com/2006/07/11/myspace-americas-number-one/ MySpace, America's Number One<!-- Bot generated title -->]</ref> According to [[comScore]], MySpace has been overtaken by main competitor [[Facebook]] in April 2008, based on monthly unique visitors.<ref>{{cite web |url= http://www.techtree.com/India/News/Facebook_Largest_Fastest_Growing_Social_N... |title=Facebook: Largest, Fastest Growing Social Network |accessdate=2008-08-14 |author=Techtree News Staff |date=2008-08-13 |work=Techtree.com |publisher=ITNation |doi= |archiveurl= |archivedate= |quote= }}</ref> The company employs 300 staff<ref name="CNNMoney-MyspaceCowboys">{{cite news | url= http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in... | publisher=CNN | title=MySpace Cowboys | last=Sellers | first=Patricia | date=2006-08-24 | accessdate=2006-08-28 }}</ref> and does not disclose [[revenue]]s or [[profit]]s separately from News Corporation. The 100 millionth account was created on August 6, 2006<ref name="MySpace100Millionth Profile">{{cite news |url= http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendI... |publisher=MySpace |title=100,000,000thhttp://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendID=100000000%7Cpublisher=MySpace%7Ctitle=100,000,000thAccount |date=2007-02-25 |accessdate=2007-02-21 }}</ref> in the [[Netherlands]]<ref name="Murdochcomments">{{cite news | url=http://internet.seekingalpha.com/article/15237 | publisher=SeekingAlpha | title=Rupert Murdoch Comments on Fox Interactive's Growth | last=Murdoch | first=Rupert | date=2006-08-09 | accessdate=2006-09-12 }}</ref> and approximately 106 million accounts on September 8, 2006,<ref name="ElReg-MySpaceMusic">{{cite news | url = http://go.theregister.com/feed/http://www.theregister.co.uk/2006/09/08/myspa... | title = MySpace music deal poses multiple threats | date= 2006-09-08 | accessdate = 2006-09-08 | publisher = The Register }}</ref> and the site attracts 230,000 new users per day.<ref>{{cite news|last=Sellers|first=Patricia|title=MySpace cowboys|url= http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in...http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/index.htm%7Cwork=%5B%5BMoney
(magazine)|Money]]|publisher=CNN.com|date=2006-09-04|accessdate=2008-04-13}}</ref>
=======End of madness======
If we're really to bring knowledge to the world, it's becoming urgent that we work on accessibility, because even experienced users (I consider myself one) just can't do it.
In any case, if anyone wants to (can?) make the change, here is what I wanted to change:
Change the sentence "The 100 millionth account was created on August 6, 2006[5] in the Netherlands[6] and approximately 106 million accounts on September 8, 2006,[7] and the site attracts 230,000 new users per day.[8]"
Which does not make sense, to something like:
"The 100 millionth account was created on August 6, 2006 [5] in the Netherlands [6] and the site counted approximately 106 million accounts on September 8, 2006 [7]. MySpace.com attracts 230,000 new users per day. [8]"
Which actually makes sense.
Delphine
-- ~notafish
NB. This gmail address is used for mailing lists. Your emails will get lost. Ceci n'est pas une endive - http://blog.notanendive.org
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
btw, the FCKeditor extension to Mediawiki is a fantastic step in the right direction. If you haven't tried it you should!
On Thu, Sep 25, 2008 at 1:26 PM, Brian Brian.Mingus@colorado.edu wrote:
This long-standing complaint of wiki complexity, e.g., that users must write encyclopedia articles in a turing complete language, is reminiscent of the motivations for cascading style sheets. You need to separate style from content for maintainability and accessibility. Likewise, users should not be specifying infobox structure and content in the same place (I use infoboxes as an example). The interfaces really need to be separate - you edit the infobox using html form fields, and you specify the structure and style of the infobox and it's form fields using some kind of interface language. There are some weak extensions to help users fill out tables and the like with this method and it really should be expanded on IMO.
On Thu, Sep 25, 2008 at 9:02 AM, Delphine Ménard notafishz@gmail.comwrote:
I tried to correct a sentence on the article MySpace in the English Wikipedia today. Well, I never got around to doing it.
Here is what I'm hit with when I click the edit button. I really tried to change the stuff I wanted. I gave up.
====Beginning of madness======
{{pp-semi-protected|small=yes}} {{Infobox Dotcom company |company_name = MySpace |company_slogan = A Place for Friends |owner = [[Fox Interactive Media]] |company_logo = [[Image:MySpace logo.svg|225px]] |company_type = [[Subsidiary]] |foundation = 2003 |location_city = [[Beverly Hills, California|Beverly Hills]], [[California]] |location_country = U.S. |key_people = [[Tom Anderson (MySpace)|Tom Anderson]], President<br>[[Chris DeWolfe]], CEO |num_employees = 300 |url = [http://www.myspace.com/ MySpace.com] |registration = Required |launch_date = August, 2003 |current_status = Active |language = [[MySpace#International sites|15 languages]] |advertising = [[Google]], [[AdSense]] |website_type = [[Social network service|Social networking]] }} [[Image:Foxinteractivemediaheadquarters.jpg|thumb|260px|Fox Interactive Media headquarters, 407 North Maple Drive, [[Beverly Hills]], California, where MySpace is also housed]]
'''MySpace''' is a popular [[social network service|social networking]] [[website]] offering an interactive, user-submitted network of friends, personal profiles, blogs, groups, photos, music and videos for teenagers and adults internationally. Its headquarters are in [[Beverly Hills]], [[California]], [[USA]],<ref>[ http://www.laobserved.com/biz/2006/08/my_space_is_not_thei.php My Space is not their space anymore] - Article on the move to [[Beverly Hills]]. Retrieved March 16, 2007.</ref> where it shares an office building with its immediate owner, [[Fox Interactive Media]]; which is owned by [[News Corporation]], which has its headquarters in [[New York City]]. In June 2006, MySpace was the most popular social networking site in the [[United States]].<ref>[ http://mashable.com/2006/07/11/myspace-americas-number-one/ MySpace, America's Number One<!-- Bot generated title -->]</ref> According to [[comScore]], MySpace has been overtaken by main competitor [[Facebook]] in April 2008, based on monthly unique visitors.<ref>{{cite web |url= http://www.techtree.com/India/News/Facebook_Largest_Fastest_Growing_Social_N... |title=Facebook: Largest, Fastest Growing Social Network |accessdate=2008-08-14 |author=Techtree News Staff |date=2008-08-13 |work=Techtree.com |publisher=ITNation |doi= |archiveurl= |archivedate= |quote= }}</ref> The company employs 300 staff<ref name="CNNMoney-MyspaceCowboys">{{cite news | url= http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in... | publisher=CNN | title=MySpace Cowboys | last=Sellers | first=Patricia | date=2006-08-24 | accessdate=2006-08-28 }}</ref> and does not disclose [[revenue]]s or [[profit]]s separately from News Corporation. The 100 millionth account was created on August 6, 2006<ref name="MySpace100Millionth Profile">{{cite news |url= http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendI... |publisher=MySpace |title=100,000,000thhttp://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendID=100000000%7Cpublisher=MySpace%7Ctitle=100,000,000thAccount |date=2007-02-25 |accessdate=2007-02-21 }}</ref> in the [[Netherlands]]<ref name="Murdochcomments">{{cite news | url=http://internet.seekingalpha.com/article/15237 | publisher=SeekingAlpha | title=Rupert Murdoch Comments on Fox Interactive's Growth | last=Murdoch | first=Rupert | date=2006-08-09 | accessdate=2006-09-12 }}</ref> and approximately 106 million accounts on September 8, 2006,<ref name="ElReg-MySpaceMusic">{{cite news | url = http://go.theregister.com/feed/http://www.theregister.co.uk/2006/09/08/myspa... | title = MySpace music deal poses multiple threats | date= 2006-09-08 | accessdate = 2006-09-08 | publisher = The Register }}</ref> and the site attracts 230,000 new users per day.<ref>{{cite news|last=Sellers|first=Patricia|title=MySpace cowboys|url= http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in...http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/index.htm%7Cwork=%5B%5BMoney
(magazine)|Money]]|publisher=CNN.com|date=2006-09-04|accessdate=2008-04-13}}</ref>
=======End of madness======
If we're really to bring knowledge to the world, it's becoming urgent that we work on accessibility, because even experienced users (I consider myself one) just can't do it.
In any case, if anyone wants to (can?) make the change, here is what I wanted to change:
Change the sentence "The 100 millionth account was created on August 6, 2006[5] in the Netherlands[6] and approximately 106 million accounts on September 8, 2006,[7] and the site attracts 230,000 new users per day.[8]"
Which does not make sense, to something like:
"The 100 millionth account was created on August 6, 2006 [5] in the Netherlands [6] and the site counted approximately 106 million accounts on September 8, 2006 [7]. MySpace.com attracts 230,000 new users per day. [8]"
Which actually makes sense.
Delphine
-- ~notafish
NB. This gmail address is used for mailing lists. Your emails will get lost. Ceci n'est pas une endive - http://blog.notanendive.org
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
-- (Not sent from my iPhone)
NO. There is no reason to give users easy access to making test red at 3px font. Outside of infoboxes and tabels nothing should allow any kind of style editing.
WYSIWYG editors are not the answer here unless you strip everything off them except a "insert reference" button.
On Thu, Sep 25, 2008 at 12:30 PM, Brian Brian.Mingus@colorado.edu wrote:
btw, the FCKeditor extension to Mediawiki is a fantastic step in the right direction. If you haven't tried it you should!
On Thu, Sep 25, 2008 at 1:26 PM, Brian Brian.Mingus@colorado.edu wrote:
This long-standing complaint of wiki complexity, e.g., that users must write encyclopedia articles in a turing complete language, is reminiscent of the motivations for cascading style sheets. You need to separate style from content for maintainability and accessibility. Likewise, users should not be specifying infobox structure and content in the same place (I use infoboxes as an example). The interfaces really need to be separate - you edit the infobox using html form fields, and you specify the structure and style of the infobox and it's form fields using some kind of interface language. There are some weak extensions to help users fill out tables and the like with this method and it really should be expanded on IMO.
On Thu, Sep 25, 2008 at 9:02 AM, Delphine Ménard notafishz@gmail.comwrote:
I tried to correct a sentence on the article MySpace in the English Wikipedia today. Well, I never got around to doing it.
Here is what I'm hit with when I click the edit button. I really tried to change the stuff I wanted. I gave up.
====Beginning of madness======
{{pp-semi-protected|small=yes}} {{Infobox Dotcom company |company_name = MySpace |company_slogan = A Place for Friends |owner = [[Fox Interactive Media]] |company_logo = [[Image:MySpace logo.svg|225px]] |company_type = [[Subsidiary]] |foundation = 2003 |location_city = [[Beverly Hills, California|Beverly Hills]], [[California]] |location_country = U.S. |key_people = [[Tom Anderson (MySpace)|Tom Anderson]], President<br>[[Chris DeWolfe]], CEO |num_employees = 300 |url = [http://www.myspace.com/ MySpace.com] |registration = Required |launch_date = August, 2003 |current_status = Active |language = [[MySpace#International sites|15 languages]] |advertising = [[Google]], [[AdSense]] |website_type = [[Social network service|Social networking]] }} [[Image:Foxinteractivemediaheadquarters.jpg|thumb|260px|Fox Interactive Media headquarters, 407 North Maple Drive, [[Beverly Hills]], California, where MySpace is also housed]]
'''MySpace''' is a popular [[social network service|social networking]] [[website]] offering an interactive, user-submitted network of friends, personal profiles, blogs, groups, photos, music and videos for teenagers and adults internationally. Its headquarters are in [[Beverly Hills]], [[California]], [[USA]],<ref>[ http://www.laobserved.com/biz/2006/08/my_space_is_not_thei.php My Space is not their space anymore] - Article on the move to [[Beverly Hills]]. Retrieved March 16, 2007.</ref> where it shares an office building with its immediate owner, [[Fox Interactive Media]]; which is owned by [[News Corporation]], which has its headquarters in [[New York City]]. In June 2006, MySpace was the most popular social networking site in the [[United States]].<ref>[ http://mashable.com/2006/07/11/myspace-americas-number-one/ MySpace, America's Number One<!-- Bot generated title -->]</ref> According to [[comScore]], MySpace has been overtaken by main competitor [[Facebook]] in April 2008, based on monthly unique visitors.<ref>{{cite web |url= http://www.techtree.com/India/News/Facebook_Largest_Fastest_Growing_Social_N... |title=Facebook: Largest, Fastest Growing Social Network |accessdate=2008-08-14 |author=Techtree News Staff |date=2008-08-13 |work=Techtree.com |publisher=ITNation |doi= |archiveurl= |archivedate= |quote= }}</ref> The company employs 300 staff<ref name="CNNMoney-MyspaceCowboys">{{cite news | url= http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in... | publisher=CNN | title=MySpace Cowboys | last=Sellers | first=Patricia | date=2006-08-24 | accessdate=2006-08-28 }}</ref> and does not disclose [[revenue]]s or [[profit]]s separately from News Corporation. The 100 millionth account was created on August 6, 2006<ref name="MySpace100Millionth Profile">{{cite news |url= http://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendI... |publisher=MySpace |title=100,000,000thhttp://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendID=100000000%7Cpublisher=MySpace%7Ctitle=100,000,000thAccount |date=2007-02-25 |accessdate=2007-02-21 }}</ref> in the [[Netherlands]]<ref name="Murdochcomments">{{cite news | url=http://internet.seekingalpha.com/article/15237 | publisher=SeekingAlpha | title=Rupert Murdoch Comments on Fox Interactive's Growth | last=Murdoch | first=Rupert | date=2006-08-09 | accessdate=2006-09-12 }}</ref> and approximately 106 million accounts on September 8, 2006,<ref name="ElReg-MySpaceMusic">{{cite news | url = http://go.theregister.com/feed/http://www.theregister.co.uk/2006/09/08/myspa... | title = MySpace music deal poses multiple threats | date= 2006-09-08 | accessdate = 2006-09-08 | publisher = The Register }}</ref> and the site attracts 230,000 new users per day.<ref>{{cite news|last=Sellers|first=Patricia|title=MySpace cowboys|url= http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/in...http://money.cnn.com/magazines/fortune/fortune_archive/2006/09/04/8384727/index.htm%7Cwork=%5B%5BMoney
(magazine)|Money]]|publisher=CNN.com|date=2006-09-04|accessdate=2008-04-13}}</ref>
=======End of madness======
If we're really to bring knowledge to the world, it's becoming urgent that we work on accessibility, because even experienced users (I consider myself one) just can't do it.
In any case, if anyone wants to (can?) make the change, here is what I wanted to change:
Change the sentence "The 100 millionth account was created on August 6, 2006[5] in the Netherlands[6] and approximately 106 million accounts on September 8, 2006,[7] and the site attracts 230,000 new users per day.[8]"
Which does not make sense, to something like:
"The 100 millionth account was created on August 6, 2006 [5] in the Netherlands [6] and the site counted approximately 106 million accounts on September 8, 2006 [7]. MySpace.com attracts 230,000 new users per day. [8]"
Which actually makes sense.
Delphine
-- ~notafish
NB. This gmail address is used for mailing lists. Your emails will get lost. Ceci n'est pas une endive - http://blog.notanendive.org
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
-- (Not sent from my iPhone)
-- (Not sent from my iPhone) _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
The latest WikipediaWeekly podcast spent some time on the need for syntax highlighting (relating to Ben Yates' blog post). http://en.wikipedia.org/wiki/Wikipedia:WikipediaWeekly/Episode62 http://www.enotes.com/blogs/wikipedia/2008-09/wikipedia-needs-syntax-highlig...
As mentioned, the Gadget "wikEd" works quite well for this. (but it is currently for Mozilla-browsers only, and can slow down the response on older machines. Unfortunately, the syntax highlighting is the "most time consuming procedure".) http://en.wikipedia.org/wiki/User:Cacycle/wikEd http://en.wikipedia.org/wiki/Image:WikEd_screenshot.png
There was also Magnus Manske's "less edit clutter" script that separates the different content types, and a slew of other things. http://lists.wikimedia.org/pipermail/wikien-l/2008-March/091978.html http://www.magnusmanske.de/wikipedia/less_page_clutter.png
I've used both on-and-off, and hope they continue to refine and grow.
-- Quiddity
Hi!
I tried to correct a sentence on the article MySpace in the English Wikipedia today. Well, I never got around to doing it.
Thats the penalty you get for thinking about MySpace :)
On the serious side, that will be one very useful hacking project - ability to hide template code in edit boxes, or even better - providing visual template editors once someone clicks template object (as expected metadata is already known). The only problem with it is that someone will have to implement it. :)
Domas Mituzas wrote:
Hi!
I tried to correct a sentence on the article MySpace in the English Wikipedia today. Well, I never got around to doing it.
Thats the penalty you get for thinking about MySpace :)
On the serious side, that will be one very useful hacking project - ability to hide template code in edit boxes, or even better - providing visual template editors once someone clicks template object (as expected metadata is already known). The only problem with it is that someone will have to implement it. :)
I think we should carefully redesign our templates. Templates was invented at the beginning with little design, and if I recall correctly, they are at the beginning also very simple. There were no conditions for example in the templates and often there were start and closing templates seperated. With the time new functionalities was implemented to overcome these problems. But they had made the templates very complicated.
In the best case, the normal editor doesn't want to bother with the code of the template. Very often, when he is making changes in a text, he would not bother with templates at all. So, to hide the bulg of the template would be nice. Just like in Eclipse to hide a function. For example if the Text reads so:
+{{Two other uses|...}} +{{US state |...}} '''Washington''' (+{{IPAEng|...}}) is a [[U.S. state|state]] in the [[Pacific Northwest]] region of the [[United States]]. Washington was carved out of the western part of [[Washington Territory]] and admitted to the Union as the 42nd state in 1889. In 2006, the [[United States Census Bureau|Census Bureau]] estimated the state's population at 6,395,798. ...
It would be easier to edit for the editors who just want to make changes in the text. The plus-signes can be clicked and if he clicks at the plus-sign he would see the template content, with mandatory fields highlighted. If someone want to, for instance, start a new article and want to put a template somewhere. He types in for instance {{Infobox_scientist| and an assistant would open up, with all parameters listed and the mandatory parameters highlighted.
Any way that is my dream. But Eclipse is rich client and I am not sure if this is ever available on a browser oriented editor.
And it needs that we do some reingeneering on our template concepts. For example I would like to see that only templates that are "benign" can be used in the text. As benign templates I mean templates that are in themselves closed. Breaking down on HTML, if a template starts with <table>, it should end with </table>, if it starts with <td> it should end with </td> and so on. Such templates I call benign. I am not sure if we still have those "ugly" templates somewhere. The taxo-templates before the Taxobox are introduced are such ugly templates. The other benefit for this approach is that you can really very easy extract keyword informations out of such templates. You can have a bot go through all benign templates and make a DTD-file for them all and you can be sure that these templates are closed and you can extract the content in it into an XML-file without problem. The negative side of this is we must go through all our articles and eliminate the "ugly" templates and replace them in "benign" templates.
Ting
Syntax highlighting and inline expansion of references and other complex code sounds like the solution to me. I know every developer wants to kill anyone who says this but "that doesn't sound so hard". WikiED already has the syntax highlighting, you would just need to tone it down for the general public.
The only things that I see that could benefit from inline expansion are: -Infoboxes -References -Tables
Outside of templates I can't see any complex code. There's wikilinks, bold, italics, headers, images, and tables. Once you master those you can edit pretty much any article. That's all regular users need. Period.
The benefits of the above layed out ideas would make even this mess of wikicode manageable. http://en.wikipedia.org/w/index.php?title=George_Washington&action=edit
On Thu, Sep 25, 2008 at 5:00 PM, Ting Chen wing.philopp@gmx.de wrote:
Domas Mituzas wrote:
Hi!
I tried to correct a sentence on the article MySpace in the English Wikipedia today. Well, I never got around to doing it.
Thats the penalty you get for thinking about MySpace :)
On the serious side, that will be one very useful hacking project - ability to hide template code in edit boxes, or even better - providing visual template editors once someone clicks template object (as expected metadata is already known). The only problem with it is that someone will have to implement it. :)
I think we should carefully redesign our templates. Templates was invented at the beginning with little design, and if I recall correctly, they are at the beginning also very simple. There were no conditions for example in the templates and often there were start and closing templates seperated. With the time new functionalities was implemented to overcome these problems. But they had made the templates very complicated.
In the best case, the normal editor doesn't want to bother with the code of the template. Very often, when he is making changes in a text, he would not bother with templates at all. So, to hide the bulg of the template would be nice. Just like in Eclipse to hide a function. For example if the Text reads so:
+{{Two other uses|...}} +{{US state |...}} '''Washington''' (+{{IPAEng|...}}) is a [[U.S. state|state]] in the [[Pacific Northwest]] region of the [[United States]]. Washington was carved out of the western part of [[Washington Territory]] and admitted to the Union as the 42nd state in 1889. In 2006, the [[United States Census Bureau|Census Bureau]] estimated the state's population at 6,395,798. ...
It would be easier to edit for the editors who just want to make changes in the text. The plus-signes can be clicked and if he clicks at the plus-sign he would see the template content, with mandatory fields highlighted. If someone want to, for instance, start a new article and want to put a template somewhere. He types in for instance {{Infobox_scientist| and an assistant would open up, with all parameters listed and the mandatory parameters highlighted.
Any way that is my dream. But Eclipse is rich client and I am not sure if this is ever available on a browser oriented editor.
And it needs that we do some reingeneering on our template concepts. For example I would like to see that only templates that are "benign" can be used in the text. As benign templates I mean templates that are in themselves closed. Breaking down on HTML, if a template starts with
<table>, it should end with </table>, if it starts with <td> it should end with </td> and so on. Such templates I call benign. I am not sure if we still have those "ugly" templates somewhere. The taxo-templates before the Taxobox are introduced are such ugly templates. The other benefit for this approach is that you can really very easy extract keyword informations out of such templates. You can have a bot go through all benign templates and make a DTD-file for them all and you can be sure that these templates are closed and you can extract the content in it into an XML-file without problem. The negative side of this is we must go through all our articles and eliminate the "ugly" templates and replace them in "benign" templates.
Ting
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
wikimedia-l@lists.wikimedia.org