Separation of form and content

**David Dorward** · Jul 20 '05, 07:22 PM

Re: Separation of form and content

Griff wrote:[color=blue]
> The situation I'd like to end up with is the ability to split web
> development work into two halves - programmers writing back-end logic,
> and web designers building the look and feel of web pages.
>
> At the moment, when we develop a web page, we have a web designer mock
> up the page using Dreamweaver or whatever, and hand the sample HTML
> over to the programmers, who then hardcode it as best they can into
> Python/Perl/C++ scripts etc.[/color]

Get a decent templating module for your languages of choice. HTML::Template
is nice for Perl. There are equivalents for Python, and probably for C++.
[color=blue]
> Some technologies which have been touted as handy for this include
> ASP.NET code-behinds, Zope page templates, ActiveX controls and DHTML.[/color]

ActiveX?! DHTML?! The mind boggles.

--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

**Claire Tucker** · Jul 20 '05, 07:23 PM

Re: Separation of form and content

On 19 Jul 2004 05:47:31 -0700, griffph@aol.com (Griff) wrote:[color=blue]
>
>In summary, we don't want our graphic designer to EVER see a line of
>server side code/scripting, and we don't want our programmers to EVER
>write a line of HTML or client-side JavaScript. I realise this is
>unlikely to be achievable, but as close as possible would be good.[/color]

I think for this goal to work out you'd need someone in between doing
the gluework, since at some point there has to be an interface between
an HTML template and "real code".
[color=blue]
>Some technologies which have been touted as handy for this include
>ASP.NET code-behinds, Zope page templates, ActiveX controls and DHTML.
>Your thoughts on these solutions or alternative suggestions would be
>most welcome.[/color]

The best approaches I've seen have involved making a 'Page' be some
kind of class (in the object-oriented programming sense) which defines
your basic page template with no real "content" (just the boilerplate
and some placeholder content) and then different kinds of page, such
as a "news page" or a "product page" are then subclasses of Page and
add new fields and override the method which produces the main "guts"
of the page.

Of course, for your requirements you need a way to specify these
"classes" without writing code, or at least with writing minimal code.

I understand that in ASP.NET pages are instances of a class, although
I'm not sure how flexible it is with deciding what to override and so
forth, plus that's really the opposite of what you want: it applies
the data to a template rather than applying a template to the data.
(designers would have to write VB.NET or C# code)

I recall some solutions surrounding Apache's Tomcat but there are so
many "meaningles s" product names surrounding that which make it hard
to remember which software solves which problems. JSP is similar to
ASP.NET, but one of the other products might do it in a way which
works better for you.

Also, in my quick Googling I encountered a small project called S2
which sounds interesting:

S2 Manual

http://www.livejournal.com/doc/s2/

An all-inclusive manual on S2 and using S2 with LiveJournal.

From my quick reading it seems to be designed for sites where *users*
can upload templates to customise, for example, a weblog or a photo
gallery, or at least that's what the guys at LiveJournal seem to be
using it for. The introduction stuff seems to think it's general
enough to apply in your case too, though. The talk of "language
reference" and stuff leads me to believe that maybe your designers
would still have to write some code in some language or other, but I
assume it's a language designed for this specific goal.

Some have enjoyed success with having the designers learn XSLT and
them writing XSLT templates to format raw data expressed in XML into
XHTML or HTML. This might be a big training overhead for your
designers, but XSLT is a declarative language rather than a
programming language so they will probably find it more easy to deal
with than the scripting languages you mentioned. Again, I think
there's a part of the Apache Jakarta stuff which can handle the XSLT
transforms for you once your designers have written the templates:

The Jakarta Site - The Apache Jakarta™ Project -- Java Related Products

http://jakarta.apache.org/

Finally, there are lots of different general content management system
solutions out there, although I've not had much experience with them
since every site I've had some relationship with has developed such a
thing in-house.

Sorry that this is all very vaugue, but I'm trying to give you an idea
of what to search for to find more stuff rather than give you concrete
answers, since you really need to explore the options yourself as you
know better than I do what will work for you and your staff.

Good luck,
-Claire

**Long - CM web hosting** · Jul 20 '05, 07:23 PM

Re: Separation of form and content

"Griff" <griffph@aol.co m> wrote in message news:d698d3e7.0 407190447.2173e 7cc@posting.goo gle.com...
: Hi there
:
: I'm after some suggestions as to how one might best separate form and
: content in a normal run-of-the-mill web application. I'm sure whole
: bookshelves have been written on this, but I could use some pointers
: as to the most helpful roads to investigate.
:
: The situation I'd like to end up with is the ability to split web
: development work into two halves - programmers writing back-end logic,
: and web designers building the look and feel of web pages.
:
: At the moment, when we develop a web page, we have a web designer mock
: up the page using Dreamweaver or whatever, and hand the sample HTML
: over to the programmers, who then hardcode it as best they can into
: Python/Perl/C++ scripts etc.
:
Perhaps you should consider having programmers write a high-level templating
framework where custom tags can be added/inserted in the HTML by the designers.
An example tag might be similar to SSI #include. This way, the custom tags are
also processed when the HTML template is processed by the main script. The
custom tags can be as complex as you like, from simple include to reading a
database and outputing HTML. Handcoding of HTML within scripts can then be
reduced significantly.

: What would be nice is a situation where
: the programmers can write all the back-end logic, and just tell the
: graphic designer what URLs he has to call.
:
This is another aspect of the framework that is specialized for form processing.
Form handler scripts should be written in place of custom tags.

: So, if we do a database
: lookup and it returns X rows, we don't have to explicitly write a loop
: at the back end generating the right number of HTML TABLE/TD/TR tags
: etc. The front end would "understand " that this particular query is
: going to return table data, and then format the results according to a
: particular layout (CSS ?) as specified by the web designer. Plus
: ideally, if the database lookup completely fails, we might not want to
: show a table format at all but write out a text message explaining why
: it failed.
:
A custom tag or 2 would be able to handle this example requirement, depending
on the number of different output formats.

: In summary, we don't want our graphic designer to EVER see a line of
: server side code/scripting, and we don't want our programmers to EVER
: write a line of HTML or client-side JavaScript. I realise this is
: unlikely to be achievable, but as close as possible would be good.
:
Well, it is actually achievable since we have been practicing this approach using
our product, WebCharm CMS. Access to WebCharm CMS functionality is
included in our web hosting services offering so our clients can benefit as well.

: Some technologies which have been touted as handy for this include
: ASP.NET code-behinds, Zope page templates, ActiveX controls and DHTML.
: Your thoughts on these solutions or alternative suggestions would be
: most welcome.
:
If you have the resources and plan to develop the custom tag framework yourself
then Zope, ASP.NET, PHP and the likes will do. You can add WebCharm CMS
to your list, however one major difference is our product is pre-packaged with
specific functionality, to be used by designers (i.e. no server-side programming).

HTH,

--
Long
www.webcharm.ca - Integrated content management web hosting

**Stephen Poley** · Jul 20 '05, 07:23 PM

Re: Separation of form and content

On Mon, 19 Jul 2004 14:58:43 +0100, David Dorward <dorward@yahoo. com>
wrote:
[color=blue]
>Griff wrote:[color=green]
>> The situation I'd like to end up with is the ability to split web
>> development work into two halves - programmers writing back-end logic,
>> and web designers building the look and feel of web pages.
>>
>> At the moment, when we develop a web page, we have a web designer mock
>> up the page using Dreamweaver or whatever, and hand the sample HTML
>> over to the programmers, who then hardcode it as best they can into
>> Python/Perl/C++ scripts etc.[/color][/color]
[color=blue]
>Get a decent templating module for your languages of choice. HTML::Template
>is nice for Perl. There are equivalents for Python, and probably for C++.[/color]

The trouble with templating modules is of course that you save the web
designers from having to learn PHP/Perl/Python but make them learn the
templating module instead; if the templating module is powerful enough
to do everything you might need, learning it probably costs as much work
as learning the minimum PHP etc they'd ever need. (Ditto for the
programmers and HTML/CSS).

I don't rule out the possibility of templating modules being useful in
places. But when I did a CMS last year, I just placed a few simple bits
of PHP in the HTML, along the line of:

<?php require('catego ry.logic'); ?>

and

<?php print "$breadcrum b \n" ?>

My feeling is that as long as you take the trouble to document how one
is going to use the PHP (or whatever) in the HTML, and only allow a
handful of basic constructs, then it's a good way to go.

But it's certainly an area with room for differing opinions.

--
Stephen Poley

Web Matters - Main Page

http://www.xs4all.nl/~sbpoley/webmatters/

**Andy Dingley** · Jul 20 '05, 07:23 PM

Re: Separation of form and content

griffph@aol.com (Griff) wrote in message news:<d698d3e7. 0407190447.2173 e7cc@posting.go ogle.com>...
[color=blue]
> At the moment, when we develop a web page, we have a web designer mock
> up the page using Dreamweaver or whatever, and hand the sample HTML
> over to the programmers, who then hardcode it as best they can into
> Python/Perl/C++ scripts etc.[/color]

Employ some HTML coders who know how to structure and write the stuff.
Not Dezyners who can only drive Dreamweaver.

At least you're not doing layouts in PhotoShop

**Shmuel (Seymour J.) Metz** · Jul 20 '05, 07:23 PM

Re: Separation of form and content

In <d698d3e7.04071 90447.2173e7cc@ posting.google. com>, on 07/19/2004
at 05:47 AM, griffph@aol.com (Griff) said:
[color=blue]
>I'm after some suggestions as to how one might best separate form and
>content in a normal run-of-the-mill web application.[/color]

In some cases, good old fashioned style sheets are adequate.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@librar y.lspace.org

**Chris Morris** · Jul 20 '05, 07:23 PM

Re: Separation of form and content

dingbat@codesmi ths.com (Andy Dingley) writes:[color=blue]
> At least you're not doing layouts in PhotoShop[/color]

That's not, in itself, a mistake. Provided the designer is someone you
can work with (and understands or is willing to have explained to them
the properties of the web medium), it's a perfectly good prototyping
and graphics-generation tool.

--
Chris

**Bruce Lewis** · Jul 20 '05, 07:23 PM

Re: Separation of form and content

griffph@aol.com (Griff) writes:
[color=blue]
> Hi there
>
> The situation I'd like to end up with is the ability to split web
> development work into two halves - programmers writing back-end logic,
> and web designers building the look and feel of web pages.[/color]
[...]
[color=blue]
> particular layout (CSS ?) as specified by the web designer. Plus
> ideally, if the database lookup completely fails, we might not want to
> show a table format at all but write out a text message explaining why
> it failed.[/color]

In other words, the web designers should control some front-end logic.
The "If there are results, show this; if there's an error, show this; if
zero results are returned, show this" concept is logic, but you're right
that it's the front-end person's decision. After all, that's the "feel"
part of "look and feel".
[color=blue]
> In summary, we don't want our graphic designer to EVER see a line of
> server side code/scripting, and we don't want our programmers to EVER
> write a line of HTML or client-side JavaScript. I realise this is
> unlikely to be achievable, but as close as possible would be good.[/color]

You're ahead of the crowd in knowing that this is unlikely to be
achievable. There are many products out there falsely promising
"complete separation" of presentation and content. If you're doing an
application that's at all interesting, separation is impossible.

I'd like to hear more detail on the problem you're trying to solve.
What problem do you encounter when a graphic designer sees a line of
server-side code? It would be especially helpful if you could supply an
example piece of code that causes confusion. It may be that "complete
separation" is not the bullseye you're shooting for.

**Andy Dingley** · Jul 20 '05, 07:24 PM

Re: Separation of form and content

Chris Morris <c.i.morris@dur ham.ac.uk> wrote in message news:<87zn5vnjx 7.fsf@dinopsis. dur.ac.uk>...[color=blue]
> dingbat@codesmi ths.com (Andy Dingley) writes:[color=green]
> > At least you're not doing layouts in PhotoShop[/color]
>
> That's not, in itself, a mistake.[/color]

Yes it is. It's just about the worst conscious mistake you can make in
the running of a HTML design bureau.

I speak with some well-earned authority here, for I've seen more money
pissed away on wrong-headed web projects than most people get to see
8-) Photoshop is probably the fourth worst culprit here, in terms of
causing over-spending on projects, and particularly for producing
awful sites.

(forgetting the core business plan, sloppy project management, and
believing silver-bullet marketing claims from platform vendors are the
others)

[color=blue]
>it's a perfectly good prototyping
> and graphics-generation tool.[/color]

It's a good tool, and it's a good graphics-generation tool. However it
is _disastrous_ as a web-prototyping tool.

A "prototype" exists to clarify certain design decisions that are up
for discussion. A good prototype should also closely emulate those
parts of the eventual solution that are not changeable, for
discrepancies here can't be fixed afterwards.

A bad prototype is one that fails to clarify what needs clarification,
or that misleads you as to what really can be changed. Photoshop fails
on both counts.

Using a bitmap editor to prototype websites is a fundamental mismatch
of technologies, akin to <FONT> or FrontPage. The HTML web is a
text-based and structure-based medium, with the ability to embed
image-like assets. It is _not_ a grpahical medium (in the sense of
Alan Kay). Treating the web as if it is graphical to this extent will
mislead you, encourage you to build features that aren't reliably
web-deployable, encourage the wasting over time over pixel-counting
trivia and worst of all it will clarify nothing as to the real
question at issue - how your HTML needs to be structured.

I've worked with designers who thought in Photoshop, and if you work
long enough in print media you get so that you can _only_ think in
Photoshop. The one time I've successfully avoided future design
conflicts was by locking them all in a tiny rooms with no Macs and
giving them crayons and a flipchart. We designed the page layouts in a
graphical manner, exactly as for Photoshop, but with far less
unimportant (and indeed, misleading) excess detail. In extreme
deadline cases, choose the sunny side of the building and remove the
tables, so there's nowhere to set a drink down.

**Chris Morris** · Jul 20 '05, 07:24 PM

Re: Separation of form and content

dingbat@codesmi ths.com (Andy Dingley) writes:[color=blue]
> Chris Morris <c.i.morris@dur ham.ac.uk> wrote:[color=green]
> > dingbat@codesmi ths.com (Andy Dingley) writes:[color=darkred]
> > > At least you're not doing layouts in PhotoShop[/color]
> >
> > That's not, in itself, a mistake.[/color]
>
> Yes it is. It's just about the worst conscious mistake you can make in
> the running of a HTML design bureau.[/color]

Hmm. It's often a *symptom* of a whole series of problems. But it
doesn't have to be. The last design I implemented had originally been
made in Photoshop by a print designer. It took a bit of discussion to
get a version of it that would work on the web. But the version that's
now on the web is recognisably the same design [1] as the Photoshop
original.

[1] As in visual theme, where elements are on the page, what colour it
is; not where each pixel is and what the precise font size is.

The *implementation * of the design means it stretches with window
width, and doesn't break with font resizing, and to an extent that did
need a decent design to start with. But it hasn't really suffered from
the original design document arriving on my desk as a printout of a
PDF.
[color=blue][color=green]
> > it's a perfectly good prototyping and graphics-generation tool.[/color]
>
> It's a good tool, and it's a good graphics-generation tool. However it
> is _disastrous_ as a web-prototyping tool.[/color]

I didn't say web-prototyping, I said prototyping - as in
visual design prototyping.
[color=blue]
> A "prototype" exists to clarify certain design decisions that are up
> for discussion. A good prototype should also closely emulate those
> parts of the eventual solution that are not changeable, for
> discrepancies here can't be fixed afterwards.
>
> A bad prototype is one that fails to clarify what needs clarification,
> or that misleads you as to what really can be changed. Photoshop fails
> on both counts.
>
> Using a bitmap editor to prototype websites is a fundamental mismatch
> of technologies, akin to <FONT> or FrontPage. The HTML web is a[/color]

Font is a HTML implementation issue, FrontPage is a HTML
(mis)implementa tion tool. Visual design and the *HTML implementation*
of that design can be kept largely separate.
[color=blue]
> text-based and structure-based medium, with the ability to embed
> image-like assets. It is _not_ a grpahical medium (in the sense of
> Alan Kay). Treating the web as if it is graphical to this extent will
> mislead you, encourage you to build features that aren't reliably
> web-deployable,[/color]

It's a text and structure based medium, yes. However, from the point
of view of the majority of end users it's also a graphical medium, or
graphical design wouldn't be needed at all.

Yes, there's a challenge in making a graphical design that can be
implemented accessibly, but it basically boils down to a few pieces of
advice:
1) Have good colour contrast
2) Make the design stretchable and compressable
3) Stay away from complicated rollover menus
[color=blue]
> encourage the wasting over time over pixel-counting trivia[/color]

That will either happen or not regardless of the tool. It's necessary
to convince the designer (and the people responsible for choosing what
design to use) that this is pointless. The tool is irrelevant. If they
prototype it in felt-tip they'll still complain about pixel positions
later if they're that way inclined.
[color=blue]
> and worst of all it will clarify nothing as to the real
> question at issue - how your HTML needs to be structured.[/color]

The vast majority of visual designs can be implemented in multiple
ways in HTML structure. The two (especially with CSS) are getting less
and less related. Ideally, the visual designer should hardly have to
think about HTML structure, provided they know enough not to get
over-ambitious and specify something impossible.
[color=blue]
> I've worked with designers who thought in Photoshop, and if you work
> long enough in print media you get so that you can _only_ think in
> Photoshop.[/color]

This is probably time to get a good web designer as opposed to a good
print designer, then.
[color=blue]
> The one time I've successfully avoided future design
> conflicts was by locking them all in a tiny rooms with no Macs and
> giving them crayons and a flipchart. We designed the page layouts in a
> graphical manner, exactly as for Photoshop, but with far less
> unimportant (and indeed, misleading) excess detail. In extreme
> deadline cases, choose the sunny side of the building and remove the
> tables, so there's nowhere to set a drink down.[/color]

*grin* This is a good solution if you need to make a designer
understand the issues of the web medium, and talking to them hasn't
worked, I'll admit.

Okay, situation: Organisation X is wanting a new web design. They
issue a tender document, ask for portfolios, etc.

Will the design companies approached give their design ideas as
a) Good quality graphical images, probably done in Photoshop
b) Crayon sketches
and what effect will this choice have on whether the company is hired?

*Provided* that the designer shows reasonable understanding of what's
possible on the web, and assuming that they don't have any significant
web skills themselves, I don't see a problem with letting them knock
together a few design ideas in Photoshop. If they do sketch it out on
paper with a crayon first, fine, but don't expect management to choose
between the designs based on the crayon sketches.

--
Chris

**Griff** · Jul 20 '05, 07:24 PM

Re: Separation of form and content

Thanks everybody for the amount of time and effort you put into those
responses. I've spent most of the day digesting it all and reading up
on the various suggested technologies.

My conclusions so far ( offered out of politeness rather than having
any particular wisdom to share... )

(1) Templating looks like a very plausible option. I spent some time
reading up on the Python "htmltmpl" module which looks like it is well
worth trying out. I accept the point that the designers will still
have to learn whatever custom template tags the developers come up
with, but that might still be easier than writing fully-fledged PHP
scripts or (god help us) XSLT transforms.

QUESTION: How will Dreamweaver react to custom HTML tags such as
<TMPL_LOOP Products>, will it silently ignore them or will it throw a
complete hissy fit ? (one nice thing about the PHP route is that
Dreamweaver will happily ignore the <?php ... ?> tags.)

(2) Thanks for the pointers on S2, WebCharm etc but these look like
optional services provided with web hosting packages rather than
software tools available for use by our in-house developers. However,
if we were going to go down the route of a fully-fledged content
management system, something like XOOPS looks like it would be good.

(3) I appreciate there's quite a lot that can be done with CSS, but I
don't think it'll quite achieve what we want. Even though CSS allows
us to code <TR CLASS="SNAZZY"> , we are still left with Developers
writing scripts to generate the right number of hardcoded <TR> items
for each row returned from the database.

Further corrections and clarifications are welcome,

Thanks,

Griff

**Andy Dingley** · Jul 20 '05, 07:24 PM

Re: Separation of form and content

Chris Morris <c.i.morris@dur ham.ac.uk> wrote in message news:<87658iohy y.fsf@dinopsis. dur.ac.uk>...
[color=blue]
> Okay, situation: Organisation X is wanting a new web design. They
> issue a tender document, ask for portfolios, etc.[/color]

Then they'll get a crap and unusable web design. And the more they
spend, and the more prestigious the beardy tossers (sorry, designers)
they choose, then the worse it will be. Counter examples welcome.

Pitching for websites and expecting to choose on the basis of a paper
tender is _no_ way to build a decent site. Pick your bodies, then
start haggling about the design. Don't choose the architects of an
interactive site by picking postcards of something that might look
like it. That's like choosing a pet at a taxidermists.

**Dave Patton** · Jul 20 '05, 07:24 PM

Re: Separation of form and content

griffph@aol.com (Griff) wrote in
news:d698d3e7.0 407190447.2173e 7cc@posting.goo gle.com:
[color=blue]
> Hi there
>
> I'm after some suggestions as to how one might best separate form and
> content in a normal run-of-the-mill web application.[/color]
[color=blue]
> The situation I'd like to end up with is the ability to split web
> development work into two halves - programmers writing back-end logic,
> and web designers building the look and feel of web pages.[/color]
[color=blue]
> In summary, we don't want our graphic designer to EVER see a line of
> server side code/scripting, and we don't want our programmers to EVER
> write a line of HTML or client-side JavaScript. I realise this is
> unlikely to be achievable, but as close as possible would be good.[/color]

It may not be practical in your situation(for a whole variety
of resons), but I'd suggest considering thinking about a
"non-software" component to the problem - hiring a 'third
person', who is, depending on your point of view, both a
"programmer " and a "designer", or neither of the above.

A "web developer" who can 'sit in the middle', and understands
at least some aspects of both sides, and has the ability to
communicate with both "sides", may be a valuable asset.

In my mind it's always a mistake to "isolate" people into
groups such as "programmer s" or "designers" . In a practical
sense, many companies feel they have to do this. As a
'jack of all trades', I don't fit into one 'category',
and in some situations, that's just what is needed. Too
often there are problems caused by the infexibility of
having different 'compartments', and/or there are no
"problems" per se, but the end product is not as good
as it could have been.

Sometimes, even if the addition of someone "in the middle"
isn't possible, either by adding staff or contract personel,
some in-house changes can help accomplish similar goals.
For example, set aside some time each week(e.g. lunchtime,
with mandatory attendance, and where the company provides
the lunch) where both "groups" get together, and one or more
people provide a "talk" - one week it may be a programmer
explaining basics of databases to the designers, the next
week it might be a designer explaining the basics of
good visual design to the programmers.

--
Dave Patton
Canadian Coordinator, Degree Confluence Project

the Degree Confluence Project

http://www.confluence.org/

The Degree Confluence Project contains photographs of the intersections of integer latitude and longitude degree lines.

My website: http://members.shaw.ca/davepatton/

**Brian** · Jul 20 '05, 07:24 PM

Re: Separation of form and content

Andy Dingley wrote:
[color=blue]
> I've seen more money pissed away on wrong-headed web projects than
> most people get to see 8-) Photoshop is probably the fourth worst
> culprit here, in terms of causing over-spending on projects, and
> particularly for producing awful sites.
>
> it is _disastrous_ as a web-prototyping tool.[/color]

I'd only disagree on a narrow point: If one creates a site in
HTML/strict, and has a fully functional site, I don't see the problem
with letting a graphics designer look at the default rendering, and
recreate it in Photoshop (or a layout program like Pagemaker). This
lets them play with colors and layout, pulling things around with
their normal tools.

When they're done, it's up to the css guru to make as much of it
happen as is possible and advisable. Pixel perfect is neither of those.
[color=blue]
> The one time I've successfully avoided future design conflicts was
> by locking them all in a tiny rooms with no Macs and giving them
> crayons and a flipchart. We designed the page layouts in a
> graphical manner, exactly as for Photoshop, but with far less
> unimportant (and indeed, misleading) excess detail. In extreme
> deadline cases, choose the sunny side of the building and remove
> the tables, so there's nowhere to set a drink down.[/color]

:-D You have some interesting motivational tools.

--
Brian (remove ".invalid" to email me)

Home - TS McHughs Irish Pub & Restaurant

http://www.tsmchughs.com/

Separation of form and content

Separation of form and content

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment