http://www.calacanis.com/2007/02/20/technological-obscurification-three-ways...
(no, he didn't know the word "obscurantism.")
Discussion please.
- d.
On 13/10/2007, David Gerard dgerard@gmail.com wrote:
http://www.calacanis.com/2007/02/20/technological-obscurification-three-ways...
(no, he didn't know the word "obscurantism.")
Discussion please.
- d.
Old.
Anyone who has spent much time on a forum with WSYIWYG will see the problem there (otherwise consider how much pink comic sans you really need).
On 10/13/07, David Gerard dgerard@gmail.com wrote:
http://www.calacanis.com/2007/02/20/technological-obscurification-three-ways...
His name is Calacanis, and it's an old thread - but IMHO quite relevant to the discussion about slowing growth.
Good WYSIWYG in a wiki is hard; even Wikia hasn't solved that particular problem yet. Hopefully we'll make serious progress on it next year.
The LiquidThreads discussion extension which could replace talk pages is now in production use e.g. on WikiEducator.org ; all it needs is a champion within the Wikimedia community.
On 10/13/07, David Gerard dgerard@gmail.com wrote:
http://www.calacanis.com/2007/02/20/technological-obscurification-three-ways...
(no, he didn't know the word "obscurantism.")
Discussion please.
- d.
There are a couple of things that I'd like to bring up: First off all, Calacanis seems to digress into his old "rant" about advertising, which seems to me to be completely missing th point. MediaWiki has wonderful developers who have worked really hard to create the best wiki-software in the world, and most of them did it without pay.
Second, this seems to be one of those "Wikipedia could never work in theory" kind of issues that frequently crop up. It is true that some of our wikicode is fairly obtuse to the newcomer, but people seem to figure out how it works pretty well. I mean, it's not like we have a lack of users, including many who haven't seen a line of code in their life.
Third, I don't think he understands how most people edits wikipedia. I would bet good money that most people start to edit by pressing the edit link at the top of a section (they see a typo and looks for the nearest link, in other words). What will then show in 98% of cases is not complicated at all, basically just the text of that section (no infoboxes or scary templates, at most maybe an image tag). I think wikipedia is easier to edit than he makes it out to be,
Fourth, many features of wikipedia relies on fairly advanced editing techniques that couldn't easily be replicated with a wysiwyg-editor. I think wikipedia would be a fair bit uglier if that tool was used. As some-one said, pink Comic Sans everywhere!
It's one of those "I see what you're saying, but you're wrong" kinda-situations. By the way, I just checked out the LiquidThreads-thing on WikiEducator, and oh man, that looks fantastic! This is something we should think about rolling out on wikipedia proper.
--Oskar
[Uncloaking]
Yes, this is very old, and frankly with the "completion of wikipedia" on horizon my thoughts on the subject are probably irrelevant now.
One could argue that Wikipedia needs *less* general participation at this point, and more "expert" (or targeted, or focused, whatever) participation. What % of your work is policing/reverting vs. evolving I wonder? How has that changed over the past five years?
Perhaps making it hard to edit *is* a blessing today... Intended or not.
Of course, you folks would know better than me... At Mahalo we use wikimarkup and not wysiwyg, so I'm haven't solved the issue and I have seven f/t devs!
Rock on,
Jason --------------- Jason@Calacanis.com | Mobile: 310-456-4900 http://www.calacanis.com | http://www.mahalo.com Executive Assistant: admin@calacanis.com
-----Original Message----- From: "David Gerard" dgerard@gmail.com
Date: Sat, 13 Oct 2007 14:40:34 To:"Wikimedia developers" wikitech-l@lists.wikimedia.org,"English Wikipedia" wikien-l@lists.wikimedia.org Subject: [WikiEN-l] Jason Calancis on Wikipedia's technological obscurantism
http://www.calacanis.com/2007/02/20/technological-obscurification-three-ways...
(no, he didn't know the word "obscurantism.")
Discussion please.
- d.
_______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On Oct 13, 2007, at 9:40 AM, David Gerard wrote:
http://www.calacanis.com/2007/02/20/technological-obscurification- three-ways-wikipedia-keeps-99-of/
(no, he didn't know the word "obscurantism.")
Discussion please.
His point about talk pages is particularly good - I doubt a lot of the templatecruft we put on talk pages is worthwhile given the oppressively long amount of non-text that it brings up when one tries to edit.
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
-Phil
Re: message boards we built a new system for them on mahalo.com (search for discussion link on the sopranos page to see it). We've contributed it back, or are close to doing so (need to ask my devs). So, if wikipedia wants message boards like this I can loan out a developer for a week to help impliment it.
Best, j --------------- Jason@Calacanis.com | Mobile: 310-456-4900 http://www.calacanis.com | http://www.mahalo.com Executive Assistant: admin@calacanis.com
-----Original Message----- From: Phil Sandifer Snowspinner@gmail.com
Date: Sat, 13 Oct 2007 15:58:31 To:English Wikipedia wikien-l@lists.wikimedia.org Subject: Re: [WikiEN-l] Jason Calancis on Wikipedia's technological obscurantism
On Oct 13, 2007, at 9:40 AM, David Gerard wrote:
http://www.calacanis.com/2007/02/20/technological-obscurification- three-ways-wikipedia-keeps-99-of/
(no, he didn't know the word "obscurantism.")
Discussion please.
His point about talk pages is particularly good - I doubt a lot of the templatecruft we put on talk pages is worthwhile given the oppressively long amount of non-text that it brings up when one tries to edit.
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
-Phil _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 13/10/2007, Jason McCabe Calacanis jason@calacanis.com wrote:
Re: message boards we built a new system for them on mahalo.com (search for discussion link on the sopranos page to see it). We've contributed it back, or are close to doing so (need to ask my devs). So, if wikipedia wants message boards like this I can loan out a developer for a week to help impliment it.
Could be good - your devs should definitely be on mediawiki-l and mediawiki.org, of course. Contribute developer effort to MediaWiki and you can say what you like about Wikipedia ;-)
- d.
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
That'sa fantastically good idea! See if it flies on the Village Pump, etc. A bot run would be enough once you have something acceptable to the VP and the most template-heavy projects.
- d.
On 13/10/2007, David Gerard dgerard@gmail.com wrote:
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
That'sa fantastically good idea! See if it flies on the Village Pump, etc. A bot run would be enough once you have something acceptable to the VP and the most template-heavy projects.
- d.
Would make a complete mess of fromowner and significantly slow down editing stuff in templates I'm also not total sure how the ref tags would react.
Generally if someone hits the edit button they should be able to edit the info on that page.
On 13/10/2007, geni geniice@gmail.com wrote:
On 13/10/2007, David Gerard dgerard@gmail.com wrote:
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
That'sa fantastically good idea! See if it flies on the Village Pump, etc. A bot run would be enough once you have something acceptable to the VP and the most template-heavy projects.
Would make a complete mess of fromowner and significantly slow down editing stuff in templates I'm also not total sure how the ref tags would react.
We're talking about the mess of project ownership claims at the top of talk pages.
Generally if someone hits the edit button they should be able to edit the info on that page.
There is that.
- d.
On 13/10/2007, David Gerard dgerard@gmail.com wrote:
We're talking about the mess of project ownership claims at the top of talk pages.
Oh thought you were talking about info boxes. I would argue that rather than messing around with sub pages it would be better to create a genuine name space (ratings say) and move the project boxes there)
On 14/10/2007, geni geniice@gmail.com wrote:
On 13/10/2007, David Gerard dgerard@gmail.com wrote:
We're talking about the mess of project ownership claims at the top of talk pages.
Oh thought you were talking about info boxes. I would argue that rather than messing around with sub pages it would be better to create a genuine name space (ratings say) and move the project boxes there)
Hmm, maybe. I see Phil was talking about the templates. I think the templates are not too awful - a pile of programming can in fact be turned to the purpose of a reasonable user interface - and highly suited to WYSIWYG-ifying. "Here's an infobox, fill in these blanks." Which is what the present template interface says in wikitext.
- d.
Is there any way for the templates to be included at the bottom of the wikisyntax page, but display at the top of the HTML page? Maybe include some CSS positioning thingy inside the template?
I know how to do this sort of thing with raw html/css, but I'm not sure how it would work within mediawiki.
On 10/13/07, David Gerard dgerard@gmail.com wrote:
On 13/10/2007, geni geniice@gmail.com wrote:
On 13/10/2007, David Gerard dgerard@gmail.com wrote:
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
That'sa fantastically good idea! See if it flies on the Village Pump, etc. A bot run would be enough once you have something acceptable to the VP and the most template-heavy projects.
Would make a complete mess of fromowner and significantly slow down editing stuff in templates I'm also not total sure how the ref tags would react.
We're talking about the mess of project ownership claims at the top of talk pages.
Generally if someone hits the edit button they should be able to edit the info on that page.
There is that.
- d.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 14/10/2007, Ben Yates ben.louis.yates@gmail.com wrote:
Is there any way for the templates to be included at the bottom of the wikisyntax page, but display at the top of the HTML page? Maybe include some CSS positioning thingy inside the template?
I know how to do this sort of thing with raw html/css, but I'm not sure how it would work within mediawiki.
A big problem is that new sections are (conventionally or automatically) added at the bottom. I don't know how you'd get around this.
Well (unless I'm mistaken) the whole article is within a giant div tag. And I distinctly remember that there are css tricks to move elements away from their default place in the code flow. But now that I actually try to do some (extremely sleep-deprived) research, i'm not sure it's actually possible in this context.
On 10/14/07, Andrew Gray shimgray@gmail.com wrote:
On 14/10/2007, Ben Yates ben.louis.yates@gmail.com wrote:
Is there any way for the templates to be included at the bottom of the wikisyntax page, but display at the top of the HTML page? Maybe include some CSS positioning thingy inside the template?
I know how to do this sort of thing with raw html/css, but I'm not sure how it would work within mediawiki.
A big problem is that new sections are (conventionally or automatically) added at the bottom. I don't know how you'd get around this.
--
- Andrew Gray andrew.gray@dunelm.org.uk
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 10/15/07, Ben Yates ben.louis.yates@gmail.com wrote:
Well (unless I'm mistaken) the whole article is within a giant div tag. And I distinctly remember that there are css tricks to move elements away from their default place in the code flow. But now that I actually try to do some (extremely sleep-deprived) research, i'm not sure it's actually possible in this context.
Get Firefox and make sure you install the DOM Inspector when you install it. Then get the Web Developer addon. You can use the former to see where any element in the DOM is on the page (useful for seeing the hidden divs that Monobook uses) and the latter to edit the CSS in realtime.
On Oct 13, 2007, at 5:43 PM, geni wrote:
Would make a complete mess of fromowner and significantly slow down editing stuff in templates I'm also not total sure how the ref tags would react.
I'm not sure I understand the problem with fromowner - nor would I think we'd touch the image pages, which are completely non-human readable anyway, more or less by design.
Certain maintenance tags seem to me like they should be excluded - unreferenced, npov, accuracy dispute, and cleanup are obvious ones, to me - these are things that people should probably be able to see.
The slowdown is no doubt genuine, but I'm not sure the slowdown is significant unless you're doing a huge amount of batch template editing, in which case you're probably automating anyway. And if the templates are always in a consistent location, it shouldn't be a huge problem. The biggest problem I see is the lag in people adding the new header pages to their watchlists.
Generally if someone hits the edit button they should be able to edit the info on that page.
Sure - but if we're creating huge HCI problems with our templates, which I'm inclined to agree we are, we're already creating difficulty in editing the info on a given page. I think this is a trade-off - certain things about a page become harder to edit, but the overall page's editability increases.
-Phil
On Oct 13, 2007, at 4:54 PM, David Gerard wrote:
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
That'sa fantastically good idea! See if it flies on the Village Pump, etc. A bot run would be enough once you have something acceptable to the VP and the most template-heavy projects.
For the article namespace this apparently runs into the problem that we've disabled subpages for articles.
I suspect this is easy to undo, and possibly even wise to undo (did we just move all /Draft pages to the talk namespace?). Dev?
In any case, the idea would work fine for talk in the current situation.
-Phil
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
I suspect this is easy to undo, and possibly even wise to undo (did we just move all /Draft pages to the talk namespace?). Dev?
Pretty much. There are probably a few that got missed. Required a reworking of the copyvio templates and the like.
On 10/13/07, Phil Sandifer Snowspinner@gmail.com wrote:
For the article namespace this apparently runs into the problem that we've disabled subpages for articles.
I suspect this is easy to undo, and possibly even wise to undo (did we just move all /Draft pages to the talk namespace?). Dev?
Subpages were disabled because 1) they weren't viewed as remarkably useful and 2) it made it impossible to have an article whose name contained a slash without some rather confusing behavior occurring. The latter reason is a bit degenerate anyway, mind, because the corresponding talk pages behave weirdly even if you disable subpages for main namespace. Things that begin with a slash are especially weird: [[/dev/null]] works fine in articles, but anywhere else it links to [[currentpage/dev/null]], and you have to use [[:/dev/null]].
It would be easy to reenable subpages for article space, but you'd probably want to manually rename all the articles (non-redirects) containing slashes, to avoid strange behavior. I count 30,163 or so as of ten days ago when the toolserver was up-to-date. It's probably easier to use talk page subpages instead of whatever you want to use the main namespace subpages for.
Cross-posted to wikien-l and wikitech-l.
David Gerard wrote:
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
That'sa fantastically good idea! See if it flies on the Village Pump, etc. A bot run would be enough once you have something acceptable to the VP and the most template-heavy projects.
I don't think it's a good idea at all.
Instead, I would suggest having two edit boxes on the edit page -- one at the top for templates, and a second one for the main article text. The one at the top would be hidden by default, you would click a button to expand it.
The dividing line between the two would be determined heuristically on the server side.
A link would be provided to a non-JS version of the edit page, for compatibility. A user preference could also be added.
Contrary to popular belief, PHP programming is not impossible.
-- Tim Starling
On 10/14/07, Tim Starling tstarling@wikimedia.org wrote: [snip]
Instead, I would suggest having two edit boxes on the edit page -- one at the top for templates, and a second one for the main article text. The one at the top would be hidden by default, you would click a button to expand it.
The dividing line between the two would be determined heuristically on the server side.
A link would be provided to a non-JS version of the edit page, for compatibility. A user preference could also be added.
If we're going as far as two edit boxes and JS magic it would probably be better to adjust the edit window so that template parameters, (and probably ref tags) are hidden by JS and clicking on them or moving the cursor into them expands them.
It wouldn't be any more evil than the various syntax highlighting user-scripts that already exist.
The parsing required to identify templates is not at all hard. (I think it's the only aspect of our Wikitext parsing that is fairly easy to get right... :) )
We could go even further and have it go fetch a template configuration page for each template, and then automatically show all the fields, refuse to allow the user to completely remove a mandatory field, provide hover-over/pop up help about the various field types, and even basic input validation.
Is this line of thinking too kludgy?
Gregory Maxwell wrote:
We could go even further and have it go fetch a template configuration page for each template, and then automatically show all the fields, refuse to allow the user to completely remove a mandatory field, provide hover-over/pop up help about the various field types, and even basic input validation.
Is this line of thinking too kludgy?
Not necessarily, but if we're going to fix infoboxes, personally I think we should go whole-hog and adopt/implement the semantic mediawiki.
On 10/14/07, Tim Starling tstarling@wikimedia.org wrote:
I don't think it's a good idea at all.
Instead, I would suggest having two edit boxes on the edit page -- one at the top for templates, and a second one for the main article text. The one at the top would be hidden by default, you would click a button to expand it.
The dividing line between the two would be determined heuristically on the server side.
A link would be provided to a non-JS version of the edit page, for compatibility. A user preference could also be added.
Contrary to popular belief, PHP programming is not impossible.
-- Tim Starling
Maybe a type of section break that does not produce a visible header or appear in the TOC would be useful. This could be put at the end of infobox template code. Then follow it up having a slightly more intelligent section-edit url syntax that corresponds with the TOC (decimal points, etc, so the infobox would be section "0.0") and also allow editing of a specified range of sections. Probably in this case it would be everything from "0.1" to the end (or earlier if we wanted to disregard stuff at the bottom).
Might be a bit more hackish but it might be of more general usefulness than just ignoring infoboxes when editing.
—C.W.
On 15/10/2007, Charlotte Webb charlottethewebb@gmail.com wrote:
Might be a bit more hackish but it might be of more general usefulness than just ignoring infoboxes when editing.
—C.W.
Problem is that compared to heavily refed text well designed infoboxes are fairly easy to get around.
On 10/15/07, geni geniice@gmail.com wrote:
Problem is that compared to heavily refed text well designed infoboxes are fairly easy to get around.
That's why I like wikEd, it has an option to visually collapse <ref> tags in the edit box.
--Darkwind
On 10/15/07, Tim Starling tstarling@wikimedia.org wrote:
Cross-posted to wikien-l and wikitech-l.
David Gerard wrote:
On 13/10/2007, Phil Sandifer Snowspinner@gmail.com wrote:
At the very least, we should move things like WikiProjects, GA nomination statuses, and other such pieces of processcruft to a subpage and transclude it so that newbies trying to discuss on talk pages just get "{{single template link}}". We could probably afford to do the same with infoboxes and the like on main articles - move them to a subpage and transclude a single template. Yes, it makes editing the infobox a step less intuitive, but someone who can't figure that step out probably can't handle the template syntax anyway.
That'sa fantastically good idea! See if it flies on the Village Pump, etc. A bot run would be enough once you have something acceptable to the VP and the most template-heavy projects.
I don't think it's a good idea at all.
Instead, I would suggest having two edit boxes on the edit page -- one at the top for templates, and a second one for the main article text.
You mean, like the on-the-fly separation (and reintegration) of language links, categories, and "invisible/at-the-end-of-the-article" templates I hacked into the core code during the Berlin CCC in 2005? 2004? ;-)
Seriously, I think separation of such meta-data on the fly is possible and should be attempted again. Part of which would encompass header/footer templates. Maybe "surround" the main edit box with three (initially hidden) boxes, on the top (header templates, infoboxes), on the right (categories, interlanguage), and bottom (bottom templates, end-of-article navboxes).
If this too extreme, maybe we could create bogus section links that would /only/ show top or bottom templates in the edit box.
Cheers, Magnus
Magnus Manske wrote:
Seriously, I think separation of such meta-data on the fly is possible and should be attempted again. Part of which would encompass header/footer templates.
Me, I'd love to see infoboxes phased out in favor of something like [[meta:Field-value pairs]], with the field/value pairs edited in a separate textarea. But that's probably too extreme at this point, too.
On 10/16/07, Steve Summit scs@eskimo.com wrote:
Me, I'd love to see infoboxes phased out in favor of something like [[meta:Field-value pairs]], with the field/value pairs edited in a separate textarea. But that's probably too extreme at this point, too.
Infoboxes aren't really metadata, though; they are about the subject, not about the article itself or Wikipedia's internal workings.
Perhaps a more structured way of handling key:value pairs of data about a subject might be a good idea, though.
We've been historically very resistant to anything about an article not being part of the editable article text, though ...
-Matt
On 10/13/07, David Gerard dgerard@gmail.com wrote:
http://www.calacanis.com/2007/02/20/technological-obscurification-three-ways...
I guess I accidentally started reading from the second paragraph.
The Wikipedia is currently designed to lower participation so it is easier to manage.
I can see how one might get that idea, but his reasons aren't the ones I expected to see, having blindly clicked David's link as usual, and initially missing the "technological" focus of this blogger's rant. I guess I expected something of a more cultural nature.
—C.W.