Most of the templates in our project, imho are just more clutter.
The number of people who know how to use any particular template, can probably be counted with a box of marbles. However when others see the templates, they just shy away, they don't bother to try to learn them.
If we want to make things easier for editors, we should scrape templates entirely. What they add to the project is not worth, what they detract.
W
What project are you speaking of? At en.WS the entire navigation structure of how to move between Chapters within a book is encoded in templates. I can't imagine how they could be scapped.
Birgitte SB
----- Original Message ----
From: "WJhonson@aol.com" WJhonson@aol.com To: foundation-l@lists.wikimedia.org Sent: Tue, December 28, 2010 9:46:56 PM Subject: [Foundation-l] Template Overkill
Most of the templates in our project, imho are just more clutter.
The number of people who know how to use any particular template, can probably be counted with a box of marbles. However when others see the templates, they just shy away, they don't bother to try to learn them.
If we want to make things easier for editors, we should scrape templates entirely. What they add to the project is not worth, what they detract.
W _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Both are true. Yes, templates are very useful, and yes, imho they do scare away newbies. Templates are useful not for navigation (that could be done without templates) but for sparing human and bot effort. Unfortunately many templates are at the top of our articles, so its the first thing that new volunteers see.
I see some overlap with the discussion started by David on WYSIWYG editing. WYSIWYG editors can not deal with our templates. A WYSIWYG editor with 2 modes (WYSIWYG and old fashioned wiki markup) would do a good job. The WYSIWYG modus should support standard wiki markup like * lists (#, *) * bold, underline, italic (') * headers (=) * tables (preferably, but not necessarily)) I think this covers the bulk of what we have in our articles as far as normal editing goes. The templates can be hidden/ignored for editing purposes in WYSIWYG editing mode.
With a two mode editor, such as blogger supports, we can have a best of both worlds: Newbies have an easy start, while old hands can still have all the templates the want.
Teun Spaans On Thu, Dec 30, 2010 at 5:59 AM, Birgitte SB birgitte_sb@yahoo.com wrote:
What project are you speaking of? At en.WS the entire navigation structure of how to move between Chapters within a book is encoded in templates. I can't imagine how they could be scapped.
Birgitte SB
----- Original Message ----
From: "WJhonson@aol.com" WJhonson@aol.com To: foundation-l@lists.wikimedia.org Sent: Tue, December 28, 2010 9:46:56 PM Subject: [Foundation-l] Template Overkill
Most of the templates in our project, imho are just more clutter.
The number of people who know how to use any particular template, can probably be counted with a box of marbles. However when others see the templates, they just shy away, they don't bother to try to learn them.
If we want to make things easier for editors, we should scrape templates entirely. What they add to the project is not worth, what they detract.
W _______________________________________________ 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
As a universal law, if something is both good and bad then it should be used wisely, suitably and selectively.
IMHO, the same applies to templates. They are most efficient when the patterns are clear, efficiently recursive, polymorphic and inheriting.
A possible direction will be to go back and start looking at each /set of templates and examine whether they could be completely revised with better structures/styles.
Though not very well-versed with the db internals of mediawiki, I feel that there is a case for re-engineering the whole wiki towards a Web 2.0 interactive framework (if not already to the sufficient). If properly implemented / interlinked, this can make templates much simpler in addition to bringing up possibilities for a better WYSIWIG editing experience. It can also facilitate several new usability layers for editing depending upon a user's proficiency and choice making the tough parts transparent to the lesser user.
Just my 2 cents. Thanks
On Thu, Dec 30, 2010 at 10:24, teun spaans teun.spaans@gmail.com wrote:
Both are true. Yes, templates are very useful, and yes, imho they do scare away newbies. Templates are useful not for navigation (that could be done without templates) but for sparing human and bot effort. Unfortunately many templates are at the top of our articles, so its the first thing that new volunteers see.
I see some overlap with the discussion started by David on WYSIWYG editing. WYSIWYG editors can not deal with our templates. A WYSIWYG editor with 2 modes (WYSIWYG and old fashioned wiki markup) would do a good job. The WYSIWYG modus should support standard wiki markup like
- lists (#, *)
- bold, underline, italic (')
- headers (=)
- tables (preferably, but not necessarily))
I think this covers the bulk of what we have in our articles as far as normal editing goes. The templates can be hidden/ignored for editing purposes in WYSIWYG editing mode.
With a two mode editor, such as blogger supports, we can have a best of both worlds: Newbies have an easy start, while old hands can still have all the templates the want.
Teun Spaans On Thu, Dec 30, 2010 at 5:59 AM, Birgitte SB birgitte_sb@yahoo.com wrote:
What project are you speaking of? At en.WS the entire navigation structure of how to move between Chapters within a book is encoded in templates. I can't imagine how they could be scapped.
Birgitte SB
----- Original Message ----
From: "WJhonson@aol.com" WJhonson@aol.com To: foundation-l@lists.wikimedia.org Sent: Tue, December 28, 2010 9:46:56 PM Subject: [Foundation-l] Template Overkill
Most of the templates in our project, imho are just more clutter.
The number of people who know how to use any particular template, can probably be counted with a box of marbles. However when others see the templates, they just shy away, they don't bother to try to learn them.
If we want to make things easier for editors, we should scrape
templates
entirely. What they add to the project is not worth, what they
detract.
W _______________________________________________ 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
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Where there exists a clean elegent technical solution to a social problem then it wasnt really a social problem to begin with.
Where it comes to something like ws maybe a tool to do an outline grouping a large multiarticle document into a single coherent one is whats really needed.
Any solution that calls for endless templates is a bad one socially as well as technically, and at the point where you even consider something on that scale you should probably be consulting developers for a better way, like a way to do parent!child relationships.
This goes for other cases too. While we dont need to be bothering the devs for every little thing, overloading the template system to get around shortcomings in mediawiki is a pretty good sign that a better way can or should exist.
Process templates as seen on en,wp are another huge example of this. All the xfd stuff, requests for x, and similar processes could be handled better with a chunk of backend code than with piles upon piles of ever growing templates, and all it would take is a reasonable request, decent specification, and enough momentum to go through with the project. In fact, i think its been discussed on strategy already.
These things always get derailed though, because people are apparently more willing to put up with a horrible solution than a good one that falls short of perfect.
If we are doomed as some naysayers claim we are, then its that very attitude of resisting improvements and reform that will be our demise - we will be so busy arguing about what color to paint the bikeshed that we wont even see that someone is building something better across the street.
The further we fall behind by allowing our goals and mission and our technology and policies to take a backseat to arguments about bikesheds the easier it will become for someone else to come in and do the job better.
On 12/30/10, Fred Bauder fredbaud@fairpoint.net wrote:
What project are you speaking of? At en.WS the entire navigation structure of how to move between Chapters within a book is encoded in templates. I can't imagine how they could be scapped.
Birgitte SB
[[Moby Dick, chapter 2]] might work.
Fred Bauder
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On 30 December 2010 08:55, Stephanie Daugherty sdaugherty@gmail.com wrote:
Any solution that calls for endless templates is a bad one socially as well as technically, and at the point where you even consider something on that scale you should probably be consulting developers for a better way This goes for other cases too. While we dont need to be bothering the devs for every little thing, overloading the template system to get around shortcomings in mediawiki is a pretty good sign that a better way can or should exist.
And there you've hit the nail on the head. People do everything in templates because of a shortage of developers, a terrible shortage of code reviewers, and the near-impossibility of getting someone to write new features that aren't for Wikipedia.
Before frustrating people by trying to block off template creation, think where the effort would then come out. Assuming the voilunteers don't just get up and leave, of course.
- d.
----- Original Message ----
From: Stephanie Daugherty sdaugherty@gmail.com To: fredbaud@fairpoint.net; Wikimedia Foundation Mailing List foundation-l@lists.wikimedia.org Sent: Thu, December 30, 2010 2:55:28 AM Subject: Re: [Foundation-l] Template Overkill
Where there exists a clean elegent technical solution to a social problem then it wasnt really a social problem to begin with.
Where it comes to something like ws maybe a tool to do an outline grouping a large multiarticle document into a single coherent one is whats really needed.
Any solution that calls for endless templates is a bad one socially as well as technically, and at the point where you even consider something on that scale you should probably be consulting developers for a better way, like a way to do parent!child relationships.
<snip>
That suggestion just makes my jaw drop. Do you realize how may months we wait for a very simple bug fixes to go live? How many years do think that the entire work of the community should be stalled while developers revamp the entire idea of how MediaWiki works? We have great developers, that are an integral part of our community, who put time and thought into writing coded solutions for Wikisource, but they can't even get the developers with authority to review and implement their code into MediaWiki. So we are left with JS hacks for ages. And you really think we should have sat around waiting for entirely new code that is not even started instead of making the project actually work with templates?
Birgitte SB
On 30 December 2010 08:55, Stephanie Daugherty sdaugherty@gmail.com wrote:
Any solution that calls for endless templates is a bad one socially as well as technically, and at the point where you even consider something on that scale you should probably be consulting developers for a better way, like a way to do parent!child relationships.
This goes for other cases too. While we dont need to be bothering the devs for every little thing, overloading the template system to get around shortcomings in mediawiki is a pretty good sign that a better way can or should exist.
Longstanding experence indicates that any solution that requires developer work is not in fact a solution.
Process templates as seen on en,wp are another huge example of this. All the xfd stuff, requests for x, and similar processes could be handled better with a chunk of backend code than with piles upon piles of ever growing templates, and all it would take is a reasonable request, decent specification, and enough momentum to go through with the project. In fact, i think its been discussed on strategy already.
Thing is
1)The average en wikipedian doesn't follow the strategywiki and any further attempts to use it to implement changes on en are unlikely to end well
2)En has control over those templates. Result is that the en community doesn't need dev work before making changes to it's XFD procedures. It's also able to directly address the difficult cases that even the best spec is unlikely to meet. You call it a weird corner case that will never happen. We call it Tuesday.
These things always get derailed though, because people are apparently more willing to put up with a horrible solution than a good one that falls short of perfect.
People would rather put up with a solution that can be shown to work rather than one that: a)doesn't exist and any existence is on a far from certain timetable b)Can't have it's bugs fixed on the fly.
If we are doomed as some naysayers claim we are, then its that very attitude of resisting improvements and reform that will be our demise
- we will be so busy arguing about what color to paint the bikeshed
that we wont even see that someone is building something better across the street.
The further we fall behind by allowing our goals and mission and our technology and policies to take a backseat to arguments about bikesheds the easier it will become for someone else to come in and do the job better.
Actually colour of templates is one thing that pretty much has been settled.
There are improvements that can be made but removing one of the community's most powerful tools to make new things happen is not one of them.
Instead you would be better off looking to collapsible templates and perhaps moving common ones like infoboxes into their own namespaces (note this already started happening with things like http://en.wikipedia.org/wiki/Template:Rolle_Canal_map ).
----- Original Message ----
From: Fred Bauder fredbaud@fairpoint.net To: Wikimedia Foundation Mailing List foundation-l@lists.wikimedia.org Sent: Thu, December 30, 2010 2:16:55 AM Subject: Re: [Foundation-l] Template Overkill
What project are you speaking of? At en.WS the entire navigation structure of how to move between Chapters within a book is encoded in templates. I can't imagine how they could be scapped.
Birgitte SB
[[Moby Dick, chapter 2]] might work.
Fred Bauder
No it wouldn't. You might actually wish to examine any random main namespace page on any language version of Wikisoure and gain a clue of what I am talking about. For one thing such links would break every time a work had to be moved for dismbiguation purposes.
Birgitte SB
Most of the templates in our project, imho are just more clutter.
The number of people who know how to use any particular template, can probably be counted with a box of marbles. However when others see the templates, they just shy away, they don't bother to try to learn them.
If we want to make things easier for editors, we should scrape templates entirely. What they add to the project is not worth, what they detract.
W
Yes, as it stands right now it would be easier to code eBay or Amazon pages. What we are dealing with is a display of prowess. Because of my work on Wikinfo I have messed around with nearly every single template. Template:California-south-geo-stub, indeed!
Fred Bauder
While i generally agree that its too much templates do have their place. The interface for using a template needs to be easier (see all the recent wysiwy* traffic), but used right they can even make the text easier to edit.
The problem therefore is to make sure they are used right, and that problem isn.t just template overload, its also a symptom of a bigger and closely relatef problem of too much need and no better alternatives.
In the end, on a per-project basis maybe we could look at restricting template creation somehow to try to stall template creep where we can. A template creation process that takes a few days would help the problem on a lot of the larger projects and if making a new template takes a request for template there is a good chance that someone will be pointed to an existing one.
Further. It mightactually be a good thing in some projects if template space were limited with respect to number of templates per project. This could force some cleanup as well as competition to eliminate overlap if done intelligently. Numbered slots like the editfilter maybe?
Grouping templates into pseudonamespaces by context might be more practical than limiting their number globally. The rationale here is that most of the templates serve very specific purposes rather than being for general use. Putting them into namespaces or even into packlages so that the namespace is kept clean of special purpose templates could cut the clutter. As an editing aid and subtle reminder to keep the top namespace clean, after breaking the non-essential ones into packages, start listing the ones thatare in the "global" context on the edit screen. We wont have the problem of too many templates for long if that is done as people will get sick of looking at a long list
On 12/28/10, WJhonson@aol.com WJhonson@aol.com wrote:
Most of the templates in our project, imho are just more clutter.
The number of people who know how to use any particular template, can probably be counted with a box of marbles. However when others see the templates, they just shy away, they don't bother to try to learn them.
If we want to make things easier for editors, we should scrape templates entirely. What they add to the project is not worth, what they detract.
W _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
wikimedia-l@lists.wikimedia.org