Separation of form and content

[Griff]

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. 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. 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.

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.

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.

By the way, if I would do better posting this to a different group,
please let me know.

Thanks,

Griff

[David Dorward]

Griff wrote:

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.
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++.
Some technologies which have been touted as handy for this include
ASP.NET code-behinds, Zope page templates, ActiveX controls and DHTML.

ActiveX?! DHTML?! The mind boggles.

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

[Claire Tucker]

On 19 Jul 2004 05:47:31 -0700, gr*****@aol.com (Griff) wrote:

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.
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".
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.

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 "meaningless" 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:
http://www.livejournal.com/doc/s2/
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:
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]

"Griff" <gr*****@aol.com> wrote in message news:d6**************************@posting.google.c om...
: 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]

On Mon, 19 Jul 2004 14:58:43 +0100, David Dorward <do*****@yahoo.com>
wrote:

Griff wrote:

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.

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++.

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('category.logic'); ?>

and

<?php print "$breadcrumb \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

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

[Andy Dingley]

gr*****@aol.com (Griff) wrote in message news:<d6**************************@posting.google. com>...

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.

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]

In <d6**************************@posting.google.com >, on 07/19/2004
at 05:47 AM, gr*****@aol.com (Griff) said:

I'm after some suggestions as to how one might best separate form and
content in a normal run-of-the-mill web application.

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 sp******@library.lspace.org

[Chris Morris]

di*****@codesmiths.com (Andy Dingley) writes:

At least you're not doing layouts in PhotoShop

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]

gr*****@aol.com (Griff) writes:

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. [...]
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.
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".
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.

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]

Chris Morris <c.********@durham.ac.uk> wrote in message news:<87************@dinopsis.dur.ac.uk>...

di*****@codesmiths.com (Andy Dingley) writes:

At least you're not doing layouts in PhotoShop
That's not, in itself, a mistake.

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)

it's a perfectly good prototyping
and graphics-generation tool.

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]

di*****@codesmiths.com (Andy Dingley) writes:

Chris Morris <c.********@durham.ac.uk> wrote:

di*****@codesmiths.com (Andy Dingley) writes:

At least you're not doing layouts in PhotoShop
That's not, in itself, a mistake.

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

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.

it's a perfectly good prototyping and graphics-generation tool.

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

I didn't say web-prototyping, I said prototyping - as in
visual design prototyping.
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
Font is a HTML implementation issue, FrontPage is a HTML
(mis)implementation tool. Visual design and the *HTML implementation*
of that design can be kept largely separate.
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,
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
encourage the wasting over time over pixel-counting trivia
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.
and worst of all it will clarify nothing as to the real
question at issue - how your HTML needs to be structured.
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.
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.
This is probably time to get a good web designer as opposed to a good
print designer, then.
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.

*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]

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]

Chris Morris <c.********@durham.ac.uk> wrote in message news:<87************@dinopsis.dur.ac.uk>...

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

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]

gr*****@aol.com (Griff) wrote in
news:d6**************************@posting.google.c om:

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. 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. 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.

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 "programmers" 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
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/

[Brian]

Andy Dingley wrote:

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.
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.
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.

:-D You have some interesting motivational tools.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Claire Tucker]

On 20 Jul 2004 15:45:25 +0100, Chris Morris <c.********@durham.ac.uk>
wrote:

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?

In that situation, I'd probably make the prototype as a static
HTML/CSS mockup. It's not like it takes an excessive amount of time to
write out some CSS rules, and the HTML structure should be (with some
allowances for the limitations of the HTML/CSS combo) obvious from the
nature of the content.

I'm not sure whether I'd then take a screenshot of said mockup and
submit that or submit the HTML I mocked up, since of course in the
latter case you're basically handing them an early version of the
finished product for free! :)

The thinking behind this, though, is that it's going to have to be
written in HTML and CSS eventually, so working in HTML and CSS from
the start seems sensible, and that is indeed how I usually work
although I'm not a web "designer" by trade. In fact, I think I'd
actually get the job done faster writing HTML and CSS than I would
faffing about with big rectangular hunks of pixels in a bitmap
editor... but maybe that's just because I'm more of a
programmer/techie type.

Best regards,
-Claire

[Claire Tucker]

On 20 Jul 2004 08:48:50 -0700, gr*****@aol.com (Griff) wrote:

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.)
In general, I think it's advisable to use Dreamweaver to make a mockup
and then to use that mockup to make the final template. Trying to edit
the templates live in Dreamweaver, which won't be able to interpret
them and thus represent them onscreen in a sensible fashion, will
likely cause confusing things to happen. I assume that once you've got
something designed it's going to basically stay the same unless you
later redesign from scratch...
(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.

From my limited reading on S2 it looked like a general templating
system which had been applied to two specific websites but could be
made to do basically anything. I didn't really read much about it,
though, and the manual did look a bit hazy in places. S2 specifically
would probably be trouble, but other similar products would allow your
designers to work in a more "simple" code/template system without the
loss of flexibility which inevitably arises with pure template-based
systems. (In my experience, I've always ended up with lots of
near-identical copies of the same template chunk to handle odd cases
which came up later.)

I didn't realise your designers were Dreamweaver-types, though. If
they're used to WYSIWYG you're probably better off letting them, as I
mentioned above, create examples of the pages in Dreamweaver and then
getting your devs to bend the example into a template with guidance
from the designers. (Programmers tend to write better HTML/CSS than
designers, anyway... especially when WYSIWYG tools get involved.)

Best of luck,
-Claire

[Andy Dingley]

On Tue, 20 Jul 2004 15:10:15 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

:-D You have some interesting motivational tools.

You should see the Clue Iron, and now the ClueBat 8-)
Incidentally, on the subject of pencil sketches, somewhere around I
have a set of fonts and widgets that make Java UI code look like a
pencil sketch. Just the job for prototyping when you want to make it
clear that it's a rough prototype and not finished and shiny product.
The users are also very impressed when you turn it off and make the
dialogs square again - "It must have taken so much effort to polish up
all of it "

--
Smert' spamionam

[Kris]

In article <28*************************@posting.google.com> ,
di*****@codesmiths.com (Andy Dingley) wrote:

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

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.

Site in my sig was during development discussed over many times using
Photoshop mockups. The value that those have on purely *aesthetic*
merits is not to be understated.

The site is credited by many in the industry as one of the prettiest
sites that are build The Right Way.

--
Kris
<kr*******@xs4all.netherlands> (nl)

[Kris]

In article <kr*****************************@news1.news.xs4all .nl>,
Kris <kr*******@xs4all.netherlands> wrote:

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

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.

Site in my sig was during development discussed over many times using
Photoshop mockups. The value that those have on purely *aesthetic*
merits is not to be understated.

The site is credited by many in the industry as one of the prettiest
sites that are build The Right Way.

--
Kris
<kr*******@xs4all.netherlands> (nl)

Duh.
http://www.cinnamon.nl/

--
Kris
<kr*******@xs4all.netherlands> (nl)

[Chris Morris]

Claire Tucker <fa**@invalid.invalid> writes:

In that situation, I'd probably make the prototype as a static
HTML/CSS mockup. It's not like it takes an excessive amount of time to
write out some CSS rules, and the HTML structure should be (with some
allowances for the limitations of the HTML/CSS combo) obvious from the
nature of the content.

Oh, agreed, as would I. But the intersection of people with both good
visual design talent and good HTML/CSS skills is very small and
doesn't include me.

--
Chris