Tina Holmboe wrote:
"Barry Pearson" <ne**@childsupp ortanalysis.co. uk> exclaimed in
<0g************ *******@newsfep 2-win.server.ntli .net>:
[snip] Some say "design so that resolution doesn't matter". But that is
hard when images are being provided, whether GIF (or whatever)
diagrams, or JPEG photographs. Hard decisions have to be made - they
are not flexible like text
We've been down this road before. I can only conclude, to my
surprise, that you don't read what we write.
I did read what you wrote. I've been puzzled how a clearly intelligent person
could say something so obviously wrong! But I now think I know why we are
disagreeing over this.
The clue is in the following. Perhaps I should have worked out what you meant
in earlier posts.
If the CONTENT itself is 800 pixels wide, then there is nothing you
can do to make that fit 640. That has nothing what so ever to do
with the RESOLUTION on the client's monitor.
[snip] Same thing. If the CONTENT is x number of pixels, then it IS x
number of pixels. There is nothing contradictory about this.
[snip]
Where do you think those 800 pixels came from? Who decided they were 800
pixels, not 500 or 10,000? That material didn't float down from outer space
fixed at that size!
The simple answer is: I decided to make that material 800 pixels wide based on
a prediction of the resolutions of the monitors of my target audience!
(Actually, I tend to use 700 - because much of my target audience still uses
800 x 600 monitors, but hardly any still use 640 x 480, as far as I know).
I believe from statements of yours such as the above that you are discussing
the specific topic of the nature of the HTML and the CSS put onto the web. You
advocate not building into that HTML (and possibly CSS) anything to do with
the expected resolution of the audience's monitors.
But I am discussing the full authoring process from conception up to that
material on the web. There must be a dozen different decisions I have had to
make according to my analysis of the nature of the target audience, and the
technology they use. Many of those decisions later appear within what the
(dumb) HTML thinks is content. Although, of course, the HTML will have tags
within it such as <img src="..." width="..." height="..." alt="...">. Here are
examples of my attempts to understand the nature of my target audiences and
their technologies:
- The first example is actually a case where I know my material is not
suitable for all of the audience I actually want to reach. I write in English.
Some of the my ideal audience doesn't understand it. On-line translators often
don't do a good job on my material. I have largely given up on that issue. I
just use <html lang="en"> so at least it is explicit.
- When deciding what size of charts and graphs to use for one of my web sites,
I found that the best size giving adequate image quality would not fit on a
640 x 480 screen. I decided not to (for example) go for a poorer version, or
for 2 or more sizes, because I judged that few people would be using that size
of screen. I check that pages with charts & graphs on look OK on an 800 x 600
screen, but don't spend a second worrying about smaller screens anymore. Nor
do I worry about people who don't maximise their windows. They can adapt or
whatever they choose.
- I wondered whether I needed to use "web safe" colours in charts and graphs.
How many colours can people distinguish adequately on their screens? At first
I did try to use web safe colours. Now I don't. I believe, from what I've
read, and from the PCs in public libraries, that the need to do so has largely
passed. If not - well that's tough!
- My photographs were designed for monitors with at least 24-bit colour. After
a lot of discussion and checking, it appeared best to use sRGB colour space,
even though many viewers wouldn't be set up for that. At least it passed the
problem of colour balance over to them!
- Photograph sizes were chosen on 2 grounds. Monitor resolution and internet
connection rates. My photography site has 2 sizes for each photograph, one
that fits into a 500 x 500 pixel box and is typically less than 50 KB, the
other that fits into a 700 x 700 box and is typically less than 100 KB. This
appeared to be the best compromise after lots of discussion. with people with
different combinations of technologies.
- But another web site had a bit more text, and a bit less emphasis on the
photographs, so I standardised on a 700 x 500 box. This saves me effort.
- Even the text content is designed with the target audience in mind (of
course). When it accompanies complex graphs, etc, I have tended not to worry
much about fog factors and Flesch scores. But for a wider audience, I check
and try to control those. (What I actually do is put it into Word and use its
checker - but I think it is based on those theories).
- When my content is a document in word-processor format, I used to use RTF
because is was pretty general. Now it appears that the people who will use
such material can handle Word format, so that is what I use.
- When my content is a calculator, I use Excel. But although many of my target
audience do indeed have Excel, it turns out that some of them don't have the
latest version, so I save it as a mixed version to reach the maximum number of
Excel users in my audience. I don't intend to cater for people without Excel,
except to supply my spreadsheets to advice organisations.
- My Word documents sometimes contain colour, for example in charts and
graphs. My investigation showed that, (even if the users could see colours),
they would occasionally print them on a black-and-white printer, but more
often than that would use a black-and-white photo-copier. So I include
assistive text to guide the reader through a B&W version.
- How should I specify email addresses in the material? Some users in public
libraries can't use the "mailto:" link. But others can. So I provide it for
those that can, and leave the others to fend for themselevs.
That is 11 different decisions, and there are plenty more. The full authoring
task, of which developing the final HTML and CSS is just one part, needs a
pretty good understanding of the users and the technologies they will be using
to handle the material. And sometimes the same understanding carries through
to 2 or more different areas. For example, if a page has a 700 pixel
photograph on it, the descriptive text has a width (currently) of 600 set in
the CSS. It doesn't adapt to the screen/window. For stylistic reasons, I want
it to be a little narrower than the photograph.
--
Barry Pearson
http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/ 
