Re: [WikiEN-l] MediaWiki is getting a new programming language

2009-07-16 Thread Sheldon Rampton
Steve Bennett wrote:

> Oh, this is so easy in MOO code[1], it's not funny:
>
> {{`tostr(args[1], " + ", args[2], " = ", args[1] + args[2]) ! ANY =>
> "that's an error"'}}
>
> (yes that's a backquote at the start and a normal one at the end.
> Semantics of "+" may differ from what you intended.)


I think it needs more squiggly brackets. And a couple of @ symbols.  
Can you sprinkle in some hash marks too, pretty please?

---

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




___
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l


Re: [WikiEN-l] MediaWiki is getting a new programming language

2009-07-09 Thread Sheldon Rampton
Charles Matthews wrote:

> I'm not yet convinced that the absence of WYSIWYG is a barrier to WP
> doing anything specific, and I don't believe that the usability  
> studies
> I have seen prove that it is. But then I tend to believe that the  
> issue
> with expository problems lies in the underestimation of expository  
> writing.


The question is whether WYSIWYG would make editing Wikipedia articles  
easier for most users. I think the answer to that question is fairly  
self-evident.

Twenty years ago there were similar debates about WYSIWYG with regard  
to word processors, just as there were debates about whether command- 
line DOS was better or worse than the GUI that Apple introduced with  
Macintosh computers. Some people back then argued that word processors  
like WordPerfect were better than WYSIWYG because you could go into  
edit mode and "see" the markup codes -- [b] for bold, [i] for italic,  
etc. Similarly, people argued that command-line DOS was better than  
dragging-and-clicking windows in a GUI because you could "see" the  
commands and their parameters. In the end, WYSIWYG and the GUI won.  
Most people don't WANT to see [b] for bold. They just want to be able  
to make the text bold. As a result, some once-dominant word processors  
died off, and Microsoft was forced to adapt by replacing DOS with  
Windows.

Wikipedia has enough earned reputation that path dependency will keep  
it on top of the heap for the foreseeable future, even without WYSIWYG  
editing, but sooner or later someone will develop a better alternative  
-- either within Wikipedia, or outside it.

---

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




___
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l


Re: [WikiEN-l] MediaWiki is getting a new programming language

2009-07-09 Thread Sheldon Rampton
Stevertigo wrote:

>> (1) No WYSIWYG editing system.
>
> Browsers by limitation are not real "WYSIWIG editing systems," and
> because WP is a website, its nearly entirely dependent on the browser.
> New functionality, regardless of its development, is mostly either
> proprietary or useless unless the W3C deals with it.  One improvement
> that comes to mind is text edit fields that are readable and
> formattable, so the distinction between presentation and editing text
> is blurred - maybe quick shifting between edit and view modes.


Nevertheless, there are a number of WYSIWYG editing technologies that  
people have developed which work with web browsers, such as FCKEditor.  
A number of non-Mediawiki wikis already have WYSIWYG functionality, as  
does Google's Knols project.

I know people who have tried developing WYSIWYG for Mediawiki, and the  
main obstacle they encounter is the wiki markup language, which is too  
idiosyncratic to parse properly and consistently. If Mediawiki used  
some other markup syntax, such as XML or HTML, they'd be able to do  
it. The current syntax was designed with the original intention of  
making it very easy and quick for people to edit articles and add  
formatting such as bold, italic, hyperlinks, etc. However, even a  
lightweight markup language is still a markup language, and WYSIWYG is  
easier for most people, so in this regard Wikipedia has fallen behind  
with regard to state-of-the-art standards for user-friendliness.  
Moreover, the original simplicity of Wikipedia's markup syntax has  
been lost somewhat as new functionality has been added. The whole  
templates mess is an example of this.

If someone were trying to design Wikipedia from scratch today, I think  
they'd be able to come up with a markup syntax that supports WYSIWYG  
very nicely, but of course designing it from scratch is not an option.  
There's too much legacy material that has already been created using  
the existing syntax, so changing it becomes very difficult. Again,  
this is en example of path dependency.

---

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




___
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l


Re: [WikiEN-l] MediaWiki is getting a new programming language

2009-07-07 Thread Sheldon Rampton
Stevertigo wrote:

> The word "monopoly" implies unfair business practices such that make
> an inferior product the exceedingly market-dominant one. Putting aside
> its basic inapplicability in an open-source context, and the fact that
> in that context people will make free choices to use a tool, and not
> to mention participate in that tools' further development..  what is
> the argument?

If you don't like the connotations of the word "monopoly," maybe  
you'll be happier with "path dependence," which conveys the same basic  
point:

http://en.wikipedia.org/wiki/Path_dependence

Obviously, "unfair business practices" are not responsible for  
maintaining Wikipedia's existing templating system. However, path  
dependence clearly occurs even in open source contexts. I think path  
dependence plays a big role in enabling Wikipedia to maintain its  
standing as the most popular online encyclopedia, and it probably is  
responsible for preventing a number of improvements from happening  
with Wikipedia. For example:

(1) No WYSIWYG editing system.

(2) The current templating system, which works but is far from easy  
for most people to use.

(3) Governance practices which are sometimes less than optimal.

If you look at Wikipedia pages and really compare them to what has now  
become state-of-the-art website design, it's hard to avoid the  
conclusion that Wikipedia looks a lot like Web 1.0 rather than Web  
2.0. Web design has come a long way since Wikipedia was launched. Many  
websites now integrate video very nicely and use Javascript/AJAX to  
improve user-friendliness and make pages more interactive and dynamic.  
The semantic web is also becoming more than a buzzword, and it's not  
hard to imagine a "Wikipedia 2.0" that would incorporate those sorts  
of features to become even more useful, attractive and popular than it  
already is. So why aren't those features already in place? Because the  
huge weight of Wikipedia's millions of articles and users makes it  
inevitable that introducing those sorts of features will be more  
technically challenging than if someone were to design those same  
features for a website that only has a small number of articles and  
users. In short, path dependence means that Wikipedia's very success  
makes it harder in some ways for the project to innovate and improve.

---

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




___
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l


Re: [WikiEN-l] MediaWiki is getting a new programming language

2009-07-03 Thread Sheldon Rampton
Stevertigo wrote:

> Hm. That "crap" seems to have worked quite well for a few years now.

Hardly. The templating system has been a source of complaints and  
frustrations for a very long time. I remember hearing Aaron Swartz get  
a lot of laughter when he gave a talk at Wikimania 2006 and showed a  
Powerpoint slide with a screenful of templating gibberish that  
consisted of an huge, nested series of squiggly brackets, numerals and  
odd symbols. The line that drew the big laugh was when he asked if  
people thought that syntax was user-friendly.

The current system of parser functions is actually an improvement over  
what existed previously, because at least it provides for an if-then  
statement and some rudimentary calculations and logical branching.  
Before parser functions existed, people used an even uglier workaround  
in which they achieved the RESULT of an if-then statement through a  
process so complicated and counter-intuitive that it would take  
several labored paragraphs for me to even describe it . It was because  
that system DIDN'T "work quite well" that parser functions were  
developed. They're not very easy to use either, which is why the  
developers are now trying to come up with a better alternative.

I should mention too that a number of Mediawiki extensions have been  
written over the years -- Semantic Mediawiki, for example -- which are  
also basically attempts to overcome the limitations of Mediawiki  
syntax and the templating system in particular. There are also oodles  
of extensions that people have written in attempts to add some widget  
or transclusion feature to Mediawiki such as Google maps or RSS feeds.  
If the current system "worked quite well," a lot of those add-on  
extensions would be unnecessary.

The fact that the current template system works poorly is no one's  
fault. It's a consequence of the ad hoc way that Mediawiki and  
Wikipedia have evolved, and of course that ad hoc evolution is no  
one's fault either. If everyone had waited until they had a perfect  
wiki platform before launching Wikipedia, the project would never have  
gotten off the ground. The tech people have generally performed  
admirably at building and maintaining the software that runs  
Wikipedia, and I think it's great that they're talking about ways to  
further improve the templating system, which could certainly use it. I  
think they understand all too well that it's not a good system, and  
they also understand how difficult it will be to come up with a better  
alternative.

---

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




___
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l


Re: [WikiEN-l] An open letter to Jimmy Wales

2009-04-12 Thread Sheldon Rampton
Brian  wrote:

> Let's be clear that, especially after the failure of Nupedia to take  
> off,
> Wikipedia's success was a surprise both to Sanger and Wales. Neither  
> of them
> expected that this would happen and can therefore not take full or  
> too much
> credit for it.

The fact that they were surprised by its success does not mean that  
they don't deserve credit for it. History is full of ideas whose  
success surprised their creators. I'm sure the Beatles were surprised  
when they soared to the top of the music charts (especially after they  
had spent years grinding away with only modest success in Hamburg and  
Liverpool). When Linus Torvalds released the first version of Linux,  
he had no way of knowing that it would take off the way it did. That  
doesn't mean the Beatles don't deserve credit for their music or  
Torvalds doesn't deserve credit for Linux.

If anything, the failure of Nupedia shows that Sanger and Wales  
deserve *more* credit, not less. Rather than giving up on the idea of  
an online encyclopedia after their first attempt, they persevered,  
retooled and came up with an alternative approach that did work. Of  
course they had no way of knowing what a success it would become. They  
got lucky, and a huge community of other people has contributed in  
various ways. But they still deserve credit for the original innovation.

---

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




___
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l


Re: [WikiEN-l] An open letter to Jimmy Wales

2009-04-10 Thread Sheldon Rampton
I haven't written anything on wikien-l in a long time, but I've been  
following a bit of this thread about Larry Sanger's open letter and  
thought I'd propose something.

Wikis are good for purposes other than creating encyclopedias, and it  
might be interesting to see if Jimmy and Larry could use a wiki to  
resolve their differences.

Currently the way in which the conflict is being expressed is leading  
toward more polarization and hostility rather than less. One of the  
things we see frequently often on wikis, however, is that people who  
have strong disagreements about some topic can nevertheless agree to a  
considerable degree on what an article about that topic should say.  
The process of reiteratively editing a single article often leads to a  
synthesis that multiple parties accept. (In some cases, a mediator or  
arbitration committee may need to render a judgment, but this is only  
necessary in a minority of cases.)

So here's my proposal, if Jimmy and Larry would agree to it: Why don't  
they both start a wiki page in which they both edit and revise a  
statement describing the history of Wikipedia and their roles within  
it? Rather than do this on Wikipedia, I would suggest doing this on a  
private wiki that only they and other parties of their choosing are  
allowed to see. If they would both agree to go through this process, I  
think they might find it possible to work out something that they can  
both accept. And if they can't reach and agreement, they can look for  
some independent third parties to mediate.

Right now there is some obvious hostility between them, but I think  
they both should have good reason to want to overcome that. They both  
played crucial roles in creating what has now become a remarkable  
project of great benefit to the world, and they both should feel pride  
and satisfaction in what they've accomplished. Watching this conflict  
simmer and bubble (as it has now for years) is a bit like watching the  
Beatles feuding after the band broke up. I think it would be better  
for both parties' reputations, and for their personal happiness as  
well, if they could find some way to reconcile, and the current  
process doesn't seem to be leading that way.

Just a suggestion.

-------

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: 608-260-9713

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




___
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l