Experts Round Table Network

This is my template suggestion for the articles.


Each article has 3 files.

Example for a dummy article:

http://www.serger.biz/ert/template01/dummy-article.php
This is where the php variables are defined and where the template used is defined.
source code:  http://www.serger.biz/ert/template01/dummy-article.txt

http://www.serger.biz/ert/template01/dummy-article.inc
This is the content of the article.  That's what the authors will write.

http://www.serger.biz/ert/template01/dummy-article.css
This is the custom css file for the article.


The default template has 2 files:

http://www.serger.biz/ert/template01/template.php
This is the definition of the default template.  This template should be used by most articles.
source-code: http://www.serger.biz/ert/template01/template.txt

http://www.serger.biz/ert/template01/default.css
This is the css file where the template layout is defined.
It also contains the default styles for the most commonly used html elements, such as lists and tables.
The authors can override those defaults in the custom css file for their article.


Each author will have his/her own css file:

This is what i understood from a previous discussion with Cd&.  I hope it's correct.
Each author will be able to control his/her own layout customisations centrally using an author css file that will be applied to all his/her articles.
This means 3 css files will be applied to each article in the following order:  template's css, author's css, article's css.
That's not part of the current code, but it's very easy to add it.
Each author could also have his/her own template.


In the future, the content and the values for the php variables will be fetched from a database.


Here is what it looks like for my article:
http://www.serger.biz/ert/template01/css-background.php

Have a look at the css file to see how easy it is to alter the default layout:
http://www.serger.biz/ert/template01/css-background.css

pitet mettre un tbody dans les tables

(surtout en 4.01 strict)

May be I made a mistake, but it seems to em the code implementing the various footer functions (like loadButtonDZ(); ) is missing from the template.txt

also : this is case inconsustent : type="text/CSS"

> pitet mettre un tbody dans les tables
There are no tables in the template.
The table is only in the dummy-article.inc which is the author's work.
I have included some typical html structure in dummy-article.inc to illustrate the default css.

> the code implementing the various footer functions (like loadButtonDZ(); ) is missing from the template.txt
Yes, that's done on purpose.  I did not include the .js file to keep it simple.

> also : this is case inconsustent : type="text/CSS"
That's right... that's a copy/paste from the W3C specs.


The important part of this thread is wheter or not we should have a default template an what should be part of that default template.  What should we impose and what should we offer as an option to the authors?  Should we hand-craft each layout or should we try to focus on producing content that uses valid accessible code?


Answers to Cd& posts from this topic:
http://www.expertsrt.net/main/forum/topic,836.msg8807

> Default (ERT standard) styles are fine as defaults.
If you mean http://www.expertsrt.com/CSS/primary.css I don't think that's fine.  It has too much unnecessary stuff.
I think that articles should have their own clean and understandable default css.

> We should encourage to support user preferences for styles.
That's a very theoretical...  In practice, people don't even know they can modify their user stylesheet.
Take a look at an unstyled table for instance, nobody wants that.
We should provide a minimalistic default stylesheet that gives a decent page when the article's css file is empty.

I certainly don't want to impose any specific layout to the article's content.
But YES, i DO want to impose a somewhat common navigation.
Having the navigation once on the top, once on the left and another time on the right is a pure nightmare.
However, I encourage the authors to change the colors... especially to hotpink ;).

http://www.w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation
13.4 Use navigation mechanisms in a consistent manner. [Priority 2]

I beleive we needed a decent default template because some authors (like myself) don't want to have to completely control their layout.  I remember someone saying to me once that content is the only thing that really matters.
If you want complete layout freedom, you also need to be able to rely on a decent default layout.
That is specially important to authors who are not be fluent in html/css.
I called this a "template", Cd& calls it a "wrapper"... for me it's pretty much the same thing.  The important thing to know is that my "template" suggestion is completely flexible and completely customisable by the author.
Actually, it's almost identical to what Cd& is currently doing, the only difference is that the files are organized a little differently.

I also beleive we needed default template because, to create the real layout that fits their needs/mood, authors need to know in advance what final html/css code they will get after their article has been wrapped.  Then, they can choose what default css they want to override.

About standards.  ERT standards for PHP <?php always <? never  ... ;^)

You removed the scripting to simplify, but EVERY ERT PAGE uses scripting, and some Authurs uses additional scripting, and some Authors are abslutely depedent on the correct function and interaction of the script style and DOM, and they don't always stay to strict standards.

There is also content doing includes cross domain and using frames.  I prefer the word wrapper because that is what I use.  Template implies, and infact with this approach we see encroachment onto the area that belongs to the author.

My approcha has been that I will do whatever is necessary to present the authors content the way they want it displayed.  I may give advice and guidance to improve the presentation, but the author owns the content.  If that means extra work, it gives me motivation to move more quickly to automate some of the work.

I I can't give the author the presentation they want then maybe I will have to insist on changes, but I am not going to impose or require specific presentation formats, unless the GC decides it would be best for the site. 

That is all speaking as the editor who has been putting the stuff together; and yes someof them are a lot of work, but Sandi get preliminary layout done, and the authors keep improving and helping out.

What follows is COBOLdinosaur contributing author. 
<no compromise>
I am going to say this absolutely as clearly as I possibly can: The day ERT "requires" me to change my content to fit an, image, template or philosophy; is the day i ceases contributing as an author.

A year before this site was started I had discussio with EE about doing exactly what we are doing here, in their white papers area. That did not happen because they were not willing to give authors creative control and an unencumbered Copyright.

ERT has given unencumbered copyright  and creative control to authors.  I'm not going to attempt to speak for other authors, just for me.  My content will be presented the way I want it presented, or it will not be presented; and I support any author who trys to protect their rights and creative control.  If I get reduced to bloggin g that is preferable to have my presentation change in a way I don't like.
</no compromise>

Okay now back to the more practical aspects of this I think we need quidelines and recommendations, but not requirements.  If an authur makes demands we cna meet then we will just ahve to pass on their content, but we should do everything we can to allow authors the full range of control and expression.

BTW, I like the pieces that are there, and the simple approach they allow is not a lot of work.  It is just the idea of a template sends chills up my back.  I would be the first step in reducing author control.

> It is just the idea of a template sends chills up my back.

It's not a template for the content, it's a template for the wrapper.  So, i'll call it "wrapper template".
We just have to declare the article attributes in some php variables and php creates the wrapper for us.  The article's content is located inside a separate file that has no php code.  No more need to edit a complex files.  Everything is clean and separated.  That should greatly reduce the number of typos and the amount of time needed to fix things.

http://www.expertsrt.net/main/forum/topic,924.15/  Reply #29
That's what i want to avoid... IMHO, it's a little messy.

Now we can  decide what's an article attribute and what's not.
The title is clearly an article attribute, it's not part of the content because it will be used in lots of differnent places.
Copyright and subtitle can be part of the content, that's no problem.
In the future, article attributes might also include date, author, categories.
Those could be used by the "wrapper template" to display links to all articles in the same categories or all articles by the same author... that's a very standard functionality (look at dzone for instance).

Cd&, please tell me clearly if what i suggest helps or not.  If it does not help, then there is no need to continue this discussion.

It helps.  The job is much easier.  The problem I have has nothing to do with the technical quality of the approch or fo the techniques being used here.

It is the political and creative side of thing that raise concerns.  The thrust seems to be that the author simply writes a bunch of code and then turns it over.  The who point of the learning center approach is the t the author remains connected to the content, and it not just tossing it out there. 

The author need to be part of develping the piece not just writing it, but through the process of developing for the site.  Going slow and not being able to just feed it into a 'bot that generates a final page is not a disadvantage ; it is part of the QA process.

If a piece take three weeks of discussion and playing before it goes onto the site; so what?  There is no timetable for delivery.  The point of automation by using a database is to make delivery more efficient.  If there are some side effects that reduce work for setup, that is okay, but not less work at the expense of flexibility.

If we start stadardizing a lot of things, then there is more that has to be overridden for non-standard presentations.  If it becomes extra work to override, then the easy way is to use teh "standard" defaults.

IT is not so much about what is in the template, but rather the idea that anything is "standard" or that there will be requirements that limit an author.  Up to now the only absolute requirements have been that the page has to carry the ERT logo, and some form of ERT compatible navigation has to be used.  Everything else has been and is open to discussion with the author.

I don't want to see authors start losing control of their content and have their content twisted the way the site documentation I wrote for EE was turned into promotion of things I opposed.

When the Google crush hit EE, it was chaos.  There was no site documentation of any use.  What little help text existed was out of date and not very helpful.  I wrote a series of pages that I posted on my own web space with links posted by me and other experts that pointed to help for new experts, new questioners and general information about the site.

Eric asked if he could copy them to CityofAngels.com and put them in an EE "template".  I made the mistake of saying yes without getting any commitment or recognition of copyright.  The content got "slightly" edited, and the the presentation was changed; including the sequencing of information.  After several months they got migrated directly onto the EE site, and the links to the original information were changed to point to the EE version.

Through several iterations of editing, revision, and manipulation, what started out as a clear and frank description of the right way to conduct yourself had been turned into promotional material that supported and encouraged the kind crap from Premium users that drove a lot of experts from the site. 

I suppose the crap would have eventually been there anyway, but my mistake left me with garbage I disagreed with being associated with my name, and there is not a thing I can do to change that.  What I can do is try and prevent authors at ERT from having to fight to protect their work, by making sure they always retain control.

(just xanting to help)

I solved the same problem in a similar way. The author won't lose control if you allow :
- inclusion of the article's body in the BODY of the HTML page (it's already the case)
- definition of some HEAD values like TITLE, meta-author , meta date-created and the like (it's partly the case)
- conditional inclusion of an $extra_js file in the HEAD section if the author defined $extra_js (will be a unique filename) : if (isset($extra_js)) if (is_file($extra_js)) require_once($extra_js);

The problem, I have is the level of automation, defaults and plugging variables into pre-defined structures as part of creation. 

Easier to use procedures and tools are fine, but nothing should be automatic when it comes to the creation or modification of the page. We want to build automation into the generation, but not into the building of the page. The creation of content is a collaboration involving the author, any who choose to review it during submission, Sandi during proofing and editing, and me doing the layout.  I don't want to speed up the process, and I don't want any of it to be automatic.  Cleaning up with wrappers reduces effort, and that is good, but we need to keep content creation "hands on by many".

It is not Lego.  We are not creating a hundred new pages every day like BBC, EE, or Yahoo.  We add a few new high quality pages every week.  I go back to pages and play with the tracking code to find out what is happening to them. If they need changes to do better I can make suggests based on an understanding of each page.

Where does it need links from? Where have similar pages done well?  How are visitors navigating into it and away from it? What does it need to get from page 2 of the SERPs to page 1?  Some pages have been easy (or perhaps I got lucky). Other pages took me a long time to find the right way to launch them, so they would get the critical mass needed to do well with Google.

It is fine to improve code quality and support the standards, but as far as the content creation process goes: there is nothing to fix because it is not broken.

Thanks VGR, that's exactly the type of comment i was expecting.


Let's give 100% control to the authors...  That's a great philosophy.

Each article will require:

• One file with the article's content - clean html only, no php.
• One file that defines the article's attributes - php variables.

(in the future, that data will come from the db)

Each author will have an unlimited number of the following files:

• Wrapper files: html code with some tags that will be replaced based on the value of the article's attributes.
• CSS files: to control the presentation.
• Javascript files: to control the behaviour.

The article attributes will define:

• The path to the content.
• The path to the wrapper that needs to be used to create the final html.
• The title, subtitle, date, authors, categories, date of revision, ... you name it.
• An array of css files that need to be linked to the page.
• An array of javascript files that need to be linked to the page.

Each author can create his/her wrappers, css and javascript files.
Each author can use his/her wrappers, css and javascript files on multiple articles.
A lazy author can borrow the files from another author.

That's all.  Everybody should be happy with that...  No?

We only need to publish an explanation of the structure and the syntax for the replacement tags used in the wrapper.  Then the authors will be able to create their own articles exactly how they want them to be.

Okay... just don't automate creation.  If we don't have something we need to handle a piece of content then we will make what we need and add it to the tool chest.  Content is not ice cream melting in the sun.  A little time to do it right does not cost anything.

> Okay...
Really???  I cannot beleive we finally agree on a practical solution :).

> ... just don't automate creation.
What do you mean by that?

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.

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.

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.

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

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.

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.