Template for Articles

[COBOLdinosaur]

What do I mean by that?

As we develop tools to use stadard pieces it will make it easier to do "standard" builds.  We don't ever want t cross over to where the tools make it difficult to do custom builds. If using templates and standard methods encourages us to tell an author they have to change something because it won't work with our templates or is to difficult to do because we can't use our tools, then there is something wrong with it.

Nothing about the creation of content should ever be automatic, the way it is on a big nes and information portal.  Each peice represent substanial personal effort by the author, and is deserving of respect.  if it is less then perfect in all aspects, then that makes is special and unique.  It is like the difference between a homemade soup and stuff from a can.  The homemade may be less consistent, and sometimes less than perfect, but the stuff in the can can never be more or less than just okay.

The two most difficult pages to work with on the site, and the ones that have the most frequent problems, also happen to be the ones that are the most viewed, and most bookmark pages on the site.  The number one page on the site, has also had the most criticism about "crappy layout" to go along with the 30,000+ views, hundreds of thank you responses and front page on Digg.

It is on top because it is a unique presentation that supports and enhances the authors content.  Could it be better; sure, and so could the last batch of soup I made. Perhaps more tarragon next time...

There are thousands of sites on the Internet who grew like we have and then died at the point where they could of had real impact.  The most difficult part of teh transition is maintaining whatever makes you special, while you try to grow into a mainstream slot and expand your niche following.  You don't just see it on the Internet, you see it in all kinds of businesses where they choke to death on growth because they forgot what got them started.

[GrandSchtroumpf]

Cd&, you made it clear enough that you wanted a 100% flexible solution, so that's what you'll get from me.
My suggestion is about organising the wrappers and giving authors the option to reuse their code.

This solution allows the authors to:
- modify the wrapper's html code of a set of their articles just by modifying a .wrap file.
- modify the presentation of a set of their articles just by modifying a .css file.
- modify the behaviour of a set of their articles just by modifying a .js file.

This solution also allows the authors to:
- modify the content of an article just by modifying a clean .inc file.
- modify the wrapper's html code of an article just by specifying a different .wrap file in the article's attributes.
- modify the presentation of an article just by specifying different .css files in the article's attributes.
- modify the behaviour of an article just by specifying different .js files in the article's attributes.

There is no set relationship between any of the files:
- Two articles that use the same .wrap file are not required to use the same .css files or .js files.
- Two articles that use the same .css file are not required to use the same .wrap file or .js files.
- Two articles that use the same .js file are not required to use the same .wrap file or .css files.


Here is an implementation example for suggestion #2:

Example of wrapper file:
http://www.serger.biz/ert/template02/my-wrapper.wrap

Example of article content:
http://www.serger.biz/ert/template02/some-article.inc

Example of article attributes:
http://www.serger.biz/ert/template02/some-article.php
source code:  http://www.serger.biz/ert/template02/some-article.txt

File that merges it all together:
http://www.serger.biz/ert/template02/ertmerge.php
source code:  http://www.serger.biz/ert/template02/ertmerge.txt

You get the final article by using the url of the article attributes:
http://www.serger.biz/ert/template02/some-article.php
On ERT, this file will use a "html" extension, but my server needs a php extension to process php.

Note that, the external css and js files used in this example do not exist on the server.

[COBOLdinosaur]

Serge,

The way we are going with this is fine.  I am just trying to make sure that anyone following this understands that it is not just a philosophical issue.  There are solid business reason to maintain the slow custom development of content, and to accept that some things may be flawed.

What ever we have become in the first year, has by most measures resulted in a successful penetration of the niche we want to occupy.  We just need to be careful that in our efforts to improve and get more efficient, we don't accidently change the product we are delivering in such a way that we lose some of the support we have built up by being what we are.

New and improve must not replace. It must enhance and extend.  I think that is what we are doing, but if at any point I see something that impedes or discourages our authors and potential authors; I am going to fight to preserve an authors right to be wrong.

[coral1]

Here's a live example you can play with.   : )

Yell if you need help getting hold of the html file.

http://www.expertsrt.net/journal/node/656

[VGR]

CD&, I agree but what the big Schtroumpf proposes can be seen two ways : either as a way to transparently "automate" the "ERT layout integration" that you do when an Author has produced "an article" (from the HTML point of view, the "useful part" of the BODY, plus eventually an extra HEAD javascript section), OR as guidelines for an Author to produce a set of files himself, so that their contets could be referenced in a DB and thus enable ERT to dynamically produce the Articles based on an ID or reference.

Either way, it's the same proposal and it's an improvement IMHO.

[GrandSchtroumpf]

This is what happened when I submitted my article:

This is the article i submitted:
http://www.serger.biz/webdev/background/exact-alignment-background-image-and-text-2.html
Easy color scheme that only uses human-readable RBG values.

Sandi uploaded the page and Roy added a wrapper because Sandi does not know how to do that.
I was not happy with the end result because it did not validate and did not like the colors.
Then I wrote a new simplified wrapper that Roy sliced and placed inside some obscure alternate "site-wide" includes.
I also changed the colors to match those that are used on the forum.
There were a few typos left that got corrected and the article got published.
I am satisfied with the final result which proves that the method works with stubborn authors.

During that process, i did not feel like i was controlling much.  The only thing i could do was waiting for Roy to finish the secret incantations that would turn the code into what i had requested.  Until he finally decided to share some of his magic formula that revealed to be just some php code (http://www.expertsrt.net/main/forum/topic,924.msg8717#msg8717).  With that, things got a little clearer, but still not transparent.

This is the final result:  http://www.expertsrt.com/tutorials/GS/CSS-background.html
The wrapper set aside, the only difference between the original and the final is the use of cold colors versus warm colors.  Taken outside of any context, do I prefer one or the other?  Not really.  They are just different.  I'm not attached to a specific look/layout, I just want my pages to look good.  Do I prefer one or the other in the context of the ERT site?  Most definitely!  I perfer the one that blends into the site.  Colors carry emotions and i don't like to create abrupt emotional changes when it's not required.


Then i followed the submission of the next articles.

Here is Matt's submission:
http://www.nicholassolutions.com/ERT/firefox-tab-tut/firefox-tab-new-window-with-history.html
Which leads to this after adding the wrapper:
http://www.expertsrt.com/articles/Matt/IE-FF-tabs.html
I was surprised to see the custom wrapper i had written for my article.

There were also 2 submissions from Vincent:
http://www.fecj.org/extra/AJAX-Demythified-for-PHP-programmers.html
http://www.fecj.org/extra/SWF-info-and-Frame-Rate-extraction.html
That format is very familiar.

That flatters my ego.  My code is being reused on ERT for both submissions and wrapper.
But wait a second... aren't we starting to use arbitrary implicit layout standards?
Does that happen because that's what the authors really want or just because it's less work for the authors who don't really care about the layout?
If the code is being implicitely reused, then why not formalizing a method that helps authors reuse their own code and the code written by others?


A small illustration:

Here is one of Matt's first layout (with some variations between articles):
http://www.expertsrt.com/articles/Matt/mysql-backup.html

Now look at Matt's last submission:
http://www.nicholassolutions.com/ERT/firefox-tab-tut/firefox-tab-new-window-with-history.html
That looks very similar to what i came up with for my article:  navigation similar to ERT's home page, colors similar to ERT forum.  Is that a pure coincidence?

Some authors just want their article to blend into the site.
And that should be a valid request if authors really have full control over their layout.
As the site evolves, the early pieces reflect the look of the site in its early stage and not the current look.
I know that you like it that way, and i find it historically interesting...  It brings back memories.
But my point is that it might not be the author's initial intent.  The author's intent is what really matters and what we should try to respect.


Conclusion:

If we want to give real control to the authors, we need to clearly explain what reusable elements are needed to build an ERT article page and allow the authors to write and modify their own reusable elements.
That's what i'm trying to do here.

The method i suggest does not replace but extends what we currently have.
The method i suggest does not modify the current publication processes.  The articles will still be discussed and optimized as they currently are.
The method i suggest simplifies the maintenance and prepares us for the database-driven version of the article index page with the search functionality.
The method i suggest allows the authors to easily maintain their layouts and make them evolve with time if they want to.
The method i suggest does not impose anything to the authors, it's just an additional option for them.
The method i suggest will encourage existing authors and potential authors to use ERT by giving them more control.

We can combine this method with other methods, like the one used for Rod's articles if I'm correct, where he wants the content to be hosted on his own server.  The important part is to document each available method so the authors know what the existing options are.  If the currently available methods are not enough, we can add some other methods and document them.

We still need to discuss the wrapper's custom tags that will be supported.
Currently, i only have these: @CONTENT@, @CSS@, @JAVASCRIPT@, @TITLE@.
Do we also want to have a set of tags that correspond to some site-wide standard includes?  Like one or more standard navigation, one or more standard logos, one or more standard footers, one or more standard set of bookmark icons.