Web Design: Would you design a PDF by writing Postscript in Notepad?

[Eric Lindsay]

[commenting on the Freeway website]

Give them credit that unlike MS they actually use their software to built
their site! That said, neither impressed with the output of their site nor
their gallery of sites. Agree with Andy here....

Incidentally, the W3C Markup Validation Service found 0 errors with the
Freeway site but 19 with the Adobe site. Oops, I forgot, validation is
apparently useless. But isn't it adherence to standards that should bring
about uniformity in presentation of a website amongst all browsers?

Why should I see the site the same on my 20 inch iMac as on my small
display, colour restricted PDA or cell phone? That is what all the web
site tools I've seen so far fail to handle. Maybe because it turns out
to be a really hard problem.

 

[Eric Lindsay]

There is indeed software, available now for the Macintosh, that allows one to
construct a website using WYSIWYG methods and with no requirement that the
user should have any knowledge of such as HTML. That software is Freeway
Express and Freeway Pro. Freeway works much like InDesign in that the website
author concentrates on appearance and action and not upon the underlying code
that makes things happen. As an aside, the resulting HTML of a Freeway
generated website is quite good, usually passing the strictest of code
verification.

Actually, if you want an interesting challenge, try to write a
traditional restaurant menu using Freeway (or any other wysiwyg tool on
a Mac).

The challenging bit is to have a dotted leader from the meal to the
price, and for that dotted leader to cope with any browser window size
or font size the reader uses, so the meal is on the left, and the price
is on the right regardless of browser changes.

Steak and eggs ....................................... 10.95
over easy, sunny side up, scrambled
Bacon and eggs .......................................10.95
over easy, sunny side up, scrambled

I have two or three ways of doing that manually (all of them with
unacceptable problems). It seemed so simple when I first tried it.

 

[Eric Lindsay]

Why do we put up with web design software? Nobody makes a PDFs by
writing Postscript in Notepad, but that is what designer's working for
the web are expected to do.

Actually until I got a Macintosh 3 years ago, that was pretty much how I
did all my PDFs. I got better results (then I got lazy).

Good point about web design software however. So far I haven't found one
acceptable product (and I would really like to).

 

[Tom Stiller]

<p><strong>Beware! To touch these wires is
<strong>instant death</strong>. Anyone found
doing so will be prosecuted.</strong></p>

Either the second sentence is unnecessary, or the first is false.

I wonder how Mr. Inkster would mark *that* in HTML?

 

[Tom Stiller]

Not really -- as I stated earlier, HTML is not a document presentation
format; it's a language for marking up the *meaning* of the document.

HTML defines the structure of the document, not its meaning; that's the
job of the human who reads the document.

Well designed web pages separate the _presentation_ of the of the
document from its structure by moving the former to formal CSS
directives.

Once the browser has interpreted the meaning of the document, it should
convey that meaning to the user. Different browsers will use different
methods of conveying meaning to the user: that's kind of the whole point
of even having different browsers. If different browsers displayed things
the same, why would we need more than one browser per operating system?

In a word: performance. Modern browsers do more than just display HTML
markup. They add value with things like ad-blockers, tabbed pages, RSS
feeds, bookmark styles, etc.

How are Firefox, the Nokia browser, Lynx and Jaws *ever* going to achieve
"uniformity in presentation"? It's ridiculous to even suggest that they
should try.

I'm glad the good folks who write browsers don't share that view.

 

[Benjamin Niemann]

I'm glad the good folks who write browsers don't share that view.

If "good" browser developers think that they could achieve "uniformity in
presentation" in FF, ... Jaws - what do average browser developers think?
That certainly explains a lot...

 

[Spartanicus]

Steak and eggs ....................................... 10.95
over easy, sunny side up, scrambled
Bacon and eggs .......................................10.95
over easy, sunny side up, scrambled

I have two or three ways of doing that manually (all of them with
unacceptable problems). It seemed so simple when I first tried it.

http://homepage.ntlworld.ie/spartanicus/eric2.htm

 

[TaliesinSoft]

Unacceptable product. Web site uses transitional HTML instead of Strict.
Uses tables for layout of a non-table text. Getting the code to validate
is one thing. Getting it to be acceptable is another. Can you point me to
any page done with Freeway that doesn't have these problems?

Here is the result of validation of a Freeway Pro produced website.....

This Page Is Valid HTML 4.01 Strict!

In Freeway Pro one can choose whether the generated code will conform to
transitional or strict.

The website can be found at

<http://homepage.mac.com/taliesinsoft/Adams/>

The validator can be found at

<http://validator.w3.org/>

 

[David Segall]

http://homepage.ntlworld.ie/spartanicus/eric2.htm

No! It leaves most of the width of my 1680 by 1050 screen blank. On
the other hand, if you had succeeded in putting the prices on the
right of my screen, the ... would have been ridiculously long.

I think Eric has managed to pose the quintessential web design
problem. I don't think there is a solution, let alone a WYSIWYG editor
that can do it, but I am really curious to see some. A menu that looks
right from 800x600px to 1680x1050px is a winner. Considerable extra
credit goes to no Java script and server-side processing is cheating.

Eric, please post your "three ways".

 

[TaliesinSoft]

I find it irrelevant.

Whether Dreamweevil is good or bad has _no_ influence on whether Freeway
is good or bad. Nor does whether Adobe have a good or a bad site.

But I made no comparison of "good / bad" between Freeway and Dreamweaver. But
I do find it interesting that Adobe opted to not use their own product to
develop their own website while Softpress did. As far as the two websites go,
nothing has stood out to me that makes one inherently superior to the other.
As to why Adobe chose to not use Dreamweaver, that would be interesting to
know.

 

[TaliesinSoft]

With Freeway I can design a trivial site with "a short word in a small
coloured box." On my desktop this sits as a tiny box up near the top
of the page, just as I intended. On my phone (200px screen) it fills
the whole display and is far bigger than the contained word. This is
_not_ what I intended to happen. Freeway takes this bogus concept of
"pixel identical rendering in all contexts" and forces it across the
web, even to devices where it's inappropriate to do so (the font size
in pixels varies widely between my desktop and my phone). Just try re-
sizing the font or changing browser window size in a Freeway-designed
site!

Actually, I think the long term answer lies in the presentation device,
computer, cellphone, television, etc., having the capability of arbitrarily
magnifying, reducing, and navigating the image. This has already happened
somewhat with Mac OS X (at least as it currently runs on my MacBook Pro) in
that I can arbitrarily magnify an image and yet navigate to those parts of
the image that might, as a result of the magnification, be off screen. My
expectation is that this separation of display from hardware specifics will
be better in Leopard. We'll see.

 

[Andy Dingley]

The website can be found at
<http://homepage.mac.com/taliesinsoft/Adams/>

Nurse! New keyboards and the monitor wipes please!

This is beautiful in the Adams-like clarity of its demonstration of
cluelessness.

The last comment could be paraphrased as "Freeway looks like it over-
uses <table> markup when inappropriate, please show an example of
better coding style". So what do you do, you take an example that's a
perfect situation for legitimately using a <table>, then you do it
with absolutely positioned <div>s. Total perversity in appropriate
markup.

If Jukka or Jonathan had done this, it would be funny. It might even
be convincing that Freeway could use non-table markup in _any_
situation. As it is though, I have to suspect that it just shows a
complete failure to even understand what the issue is, let alone how
to solve it.

 

[TaliesinSoft]

[responding to my request for definitions for "markup" and "page description"
languages]

HTML as a markup language describes parameters for a multitude of possible
interpreters rendering a page, based on what can be fairly vague
instructions, so that an instruction like 'font size="-2"' will display
different absolute results depending on the client doing the
interpretation (IE/Safari/Firefox/Omniweb/etc).

Postscript, OTOH, is a specific description language based on a known and
consistent interpreter, where an instruction such as '90 rotate 0 -612
translate' will do *exactly* the same thing no matter where it is
interpreted (HP/Agfa/Harlequin/etc), and display *exactly* the same result.

Thanks! Maybe you ought to start writing for Wikipedia!

 

[TaliesinSoft]

[responding to my giving a reference to a site produced with Freeway Pro that
passed "strict" validation]

Nurse! New keyboards and the monitor wipes please!

This is beautiful in the Adams-like clarity of its demonstration of
cluelessness.

The last comment could be paraphrased as "Freeway looks like it over- uses
<table> markup when inappropriate, please show an example of better coding
style". So what do you do, you take an example that's a perfect situation
for legitimately using a <table>, then you do it with absolutely
positioned <div>s. Total perversity in appropriate markup.

If Jukka or Jonathan had done this, it would be funny. It might even be
convincing that Freeway could use non-table markup in _any_ situation. As
it is though, I have to suspect that it just shows a complete failure to
even understand what the issue is, let alone how to solve it.

But the fact remains that the website, whether one likes it or not, displays
in every browser tested, six of them, *exactly* as intended. If the results
are as wanted, why should I be concerned about the underlying code structure

 

[Andy Dingley]

Actually, I think the long term answer lies in the presentation device,
computer, cellphone, television, etc., having the capability of arbitrarily
magnifying, reducing, and navigating the image.

Not at all. For one thing, a simple form of this is just scrolling,
moving an small viewport around a larger virtual canvas. This needs
manual intervention and it's annoying.

My trivial web design problem is "Show an icon of a coloured rectangle
slightly bigger than a word of text". By sizing the rectangle in ems I
can do this. Even better I might not size the rectangle at all, simply
set some internal padding on it (in ems). This works on my destop and
my phone and it looks proportionately similar on both.

My phone differs from my desktop in having characters with fewer
pixels to them. This goes with the territory and isn't changing any
time soon. By using a relative size unit, I easily produce a page that
looks proportionately similar on both devices.

By pixel-sizing and absolutely controlling the box, the wrong-headed
attempt to control _everything_ to the last pixel has produced a
visual result that's grossly different and inappropriate.

 

[Andy Dingley]

But I made no comparison of "good / bad" between Freeway and Dreamweaver.

Of course you did, as a straw man and a diversion.

Freeway has valid HTML but poor use of CSS positioning. Rather than
discussing the pixel-based absolute positioning of Freeway, you then
diverted into Adobe's non-valid products. No-one else mentioned
Adobe.

 

[TaliesinSoft]

Of course you did, as a straw man and a diversion.

Freeway has valid HTML but poor use of CSS positioning. Rather than
discussing the pixel-based absolute positioning of Freeway, you then
diverted into Adobe's non-valid products. No-one else mentioned Adobe.

Earlier in this thread Jonathan A. Little stated in regards to Freeway....

Give them credit that unlike MS they actually use their software to built
their site!

That piqued my curiosity enough for me to see what Adobe did with their site.
There was no attempt at diversion.

As for Freeway using a pixel-based scheme for positioning, the intent, a good
one in my opinion, is to provide some assurance as to how the resulting site
will appear. I'm afraid I'm not much of a fan of so-called "liquid" layouts.
All one has to do is to go to such as the Softpress (the implementors of
Freeway) or Adobe sites and start enlarging the text and soon the layout
degenerates into a hodgepodge of misplaced parts. To me, and apparently there
is much disagreement here, the better solution is uniform magnification
and/or reduction of the entire page.

 

[Toby A Inkster]

I think Eric has managed to pose the quintessential web design
problem. I don't think there is a solution

Jeez Louise! It's hardly rocket science.

http://examples.tobyinkster.co.uk/food-menu

Tested:
Firefox 1.0.6 (Linux)
Opera 9.10 (Linux)
Konqueror 3.4.2 (Linux)
IE 6 (Win XP)
IE 7 (Win XP)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

 

[TaliesinSoft]

[commenting in regards to the Ansel Adams website, the site to which I posted
a link]

The last comment could be paraphrased as "Freeway looks like it over- uses
<table> markup when inappropriate, please show an example of better coding
style". So what do you do, you take an example that's a perfect situation for

legitimately using a <table>, then you do it with absolutely positioned
<div>s. Total perversity in appropriate markup.

In the Ansel Adams site the 63 images included take a total of 596 KB, and
the code in the index.html page takes 40 KB. So why should I be concerned as
to just what construct the code uses given that the download time for the
code is a minimal component of the total download time for the page,
especially given that the generated code works as intended on every browser
on which it was checked?

As an aside, an advantage of Freeway is that if a new release makes an
improvement in the generated code it is a trivial matter to re-upload the
site to benefit from that improvement.

 

[Toby A Inkster]

But the fact remains that the website, whether one likes it or not, displays
in every browser tested, six of them, *exactly* as intended.

Here's how it looks in my web browser:

http://examples.tobyinkster.co.uk/jamesleoryan

It that "exactly as intended"?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!