site review request

[B McDonald]

http://www.galtsvalley.com

Hi all. I've recently made some major stylistic changes to my site and now
it is essentially a new design with some new CSS plumbing. I am hoping that
a few hardy souls can go check it out and tell me how it renders on their
platform/browser combos. I have tested it under W2K, WXP, and System 9 on a
Power Mac 8600:

W2K: IE5.5 and Opera 7.1 (some small issues in Opera)
WXP: IE6 and NS7.1 (in IE6 a strange jerkiness when clicking on links that
are not inline... bottom margins seem to collapse a bit...)
OS9/Mac: IE5.1 and NS6 (very good)

Reports on Mozilla, Firebird, other NS and IE versions, and later Mac
platforms most appreciated!

Brian

[Darin McGrew]

Barry Pearson <ne**@childsupportanalysis.co.uk> wrote:

The decision HAS to be made - it can't be ignored. At some point, just about
every photographer publishing on the web has to decide " how many pixels wide
& high should my photographs be?"

The approach I like the best is one I saw at photo.net. Thumbnail images
are linked to pages that display larger versions as inline images. On those
pages, there are links to even larger versions. That leaves the user in
control, deciding how big an image is most useful, worth downloading, etc.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"If you aren't part of the solution, then you are part of the precipitate."

[Barry Pearson]

Darin McGrew wrote:

Barry Pearson <ne**@childsupportanalysis.co.uk> wrote:

The decision HAS to be made - it can't be ignored. At some point,
just about every photographer publishing on the web has to decide "
how many pixels wide & high should my photographs be?"

The approach I like the best is one I saw at photo.net. Thumbnail
images are linked to pages that display larger versions as inline
images. On those pages, there are links to even larger versions. That
leaves the user in control, deciding how big an image is most useful,
worth downloading, etc.

Interesting approach! But that takes extra effort (for the photographer).

On my photography site, I provide 2 sizes. The smaller size fits into a 500 x
500 box, and is typically less than 50 KB. The larger size fits into a 700 x
700 box, and is typically less than 100 KB. The thumbnail galleries provide
the choice. For example, have a look at:

http://www.barry.pearson.name/photog...olios/lrps.htm

But I now wonder whether the extra effort is worthwhile. (Each size has its
own unsharp-mask parameters, and sometimes its own compression parameters). As
we move towards larger screens and faster internet connections, the importance
of the smaller size will become less.

On my latest site, I simply decided that all photographs would fit into a 700
x 500 box. This followed analysis of typical screen sizes, other similar sites
(the size is a bit bigger than most sites), discussion with others, etc. Eg:

http://www.birdsandanimals.info/bcp/...mals_kenya.htm

This appears OK on an 800 x 600 screen, especially in full-screen mode. (I
place the photograph at the top of a page to avoid the need to scroll). But it
means that upright ("portrait") photographs may be rather small. For example,
this is 360 x 500:

http://www.birdsandanimals.info/bcp/...94_14_20_2.htm

Ideally, we would have scalability. But this would not be in the downloaded
image, because a scalable photograph would be very large (in KB). So perhaps
we need scalability at the server, with the user agent calling down an image
that fits what the HTML & CSS decide. I haven't found out yet whether JPEG2000
in the server will be adequate. (I suspect not).

Choosing photograph sizes is the hardest decision I have to make for a web
site with photograph on. I wish I even knew what the target answer was.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Darin McGrew]

I wrote:

The approach I like the best is one I saw at photo.net. Thumbnail
images are linked to pages that display larger versions as inline
images. On those pages, there are links to even larger versions. That
leaves the user in control, deciding how big an image is most useful,
worth downloading, etc.

Barry Pearson <ne**@childsupportanalysis.co.uk> wrote: Interesting approach! But that takes extra effort (for the photographer).

On my photography site, I provide 2 sizes. The smaller size fits into a 500 x
500 box, and is typically less than 50 KB. The larger size fits into a 700 x
700 box, and is typically less than 100 KB. The thumbnail galleries provide
the choice.
I just took a look at the photo.net site again. Thumbnails fit in a 200px
square box. They are linked to a page that displays medium images that fit
in a 600px square box. The large images fit in an 800px square box. ISTR
having seen even larger images (fitting in a 1024px box? in a 1200px box?),
but I didn't see any looking around just now.
For example, have a look at:

http://www.barry.pearson.name/photog...olios/lrps.htm
The main problem I see is that the photo pages are orphaned, except for the
link to the site's home page. And based on the context of that link, I
assumed that it was a mailto link. It would be nice to include links to
smaller/larger versions of the same image, to the index page for the set,
to the info page, etc., much the way photo.net does it. With a
database-backed site, it shouldn't be too difficult to do this kind of
thing automatically.
As we move towards larger screens and faster internet connections, the
importance of the smaller size will become less.

What do you mean "we"?

I was borrowing a relative's computer recently. The resolution was 800x600,
and the available display area was much less after all the taskbars,
hotlists, and other chrome. (Is it just me, or does anyone else find the
default chrome for recent versions of MS Windows too bloated?) The
connection speed was usually just a bit over 20kbps with a 56kbps modem.

I regularly use a device with a 160x160 display to view web content,
although admittedly, I don't access photography sites with it.

WebTV (aka MSN TV) has a resolution of 544x372 with no horizontal scrolling.

I see a trend towards more diversity in browsing platforms, not a uniform
trend towards huge displays and broadband connections.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"It said 'Insert disk #3', but only two will fit..."

[Jonathan Snook]

"Brian" <us*****@mangymutt.com.invalid-remove-this-part> wrote in message
news:fx********************@rwcrnsc52.ops.asp.att. net...

devices. Just as, with a text site, one may or may not be able to
provide additional translations of the documents. Now, what has this
to do with resolution?

There is no extra cost to creating a site that works on every
resolution. Why do you keep insisting that there is?

Ah, I seem to be misunderstanding you... when you say "creating a site that
works on every resolution" I thought you meant, don't create a site that
would have a scroll bar on an 800x600 screen size or should I say browser
size to be more specific. (the word resolution is often used instead of
"screen size")

Example, doing this: <div style="width:800px;">this is my content</div>
would seem to be a poor way to do web development. Now, Tina says a scroll
bar is okay (and the code would theoretically still be quite accessible in
different browsers, backwards compatible, etc). Your statement of "not be
able to provide additional content for different sized display devices"
means to me that it obviously isn't practical to put a photograph to display
properly in a PDA and still have it look good on a person's monitor.

So, while my example may not "look" good on every screen, am I creating a
site that works on every resolution?
Jonathan
--
http://www.snook.ca/

[Alan J. Flavell]

On Sat, 4 Oct 2003, Jonathan Snook wrote:

(the word resolution is often used instead of "screen size")
Which is unfortunate, as in most other technical fields the term
"resolution" refers to the number of elements (e.g pixels) per unit of
size (e.g per inch, or per degree subtended at the observer, etc.).
I find it quite unfortunate that it gets used here for the total
screen or window size in pixels, irrespective of physical size.
So, while my example may not "look" good on every screen, am I creating a
site that works on every resolution?

The axiom around here is that stylesheets are for presentation. If
your content is inherently pixel-sized, then that's a feature of your
content, not of your presentation. If the content inherently needed
to be 2000 pixels wide (for example, some teaching material on the
interpretation of X-ray pictures, which needed to be that big in order
to show some important detail in its context) then "so be it", and the
readers have to make the best of whatever screen size they happen to
have, even though most of them will be unable to see the whole thing
at once.

On the other hand if your pictures were 200px wide and you stubbornly
fitted them five to a line in the belief that everyone[1] had a
browser window at least 1024px wide, without having any content-based
reason to do so, then that would be "presentation". There seems to be
a significant difference between the two - at least I think there is.

[1] "everyone", that is, in the supposed "target audience". Not a
term that I care for, since for me it's inherent that viewers will
sometimes be using one browsing situation, sometimes another: if they
first meet a web page in a less-suitable situation, their experience
is likely to determine whether they bother to revisit it later when
they're in a more-suitable browsing environment. So I'd prefer a page
that goes a reasonable way towards accommodating different viewing
situations, to whatever degree is feasible given the inherent nature
of the content.

[Alan J. Flavell]

On Sat, 4 Oct 2003, Barry Pearson wrote:

The approach I like the best is one I saw at photo.net. Thumbnail
images are linked to pages that display larger versions as inline
images. On those pages, there are links to even larger versions.
Interesting approach! But that takes extra effort (for the photographer).

If you weren't such a perfectionist, you could have a script which
automatically produced and indexed the reduced-size versions at the
push of a button ;-)
But I now wonder whether the extra effort is worthwhile. (Each size has its
own unsharp-mask parameters, and sometimes its own compression parameters).
Just my point...
As we move towards larger screens and faster internet connections,
the importance of the smaller size will become less.

As we move to more mobile computing, the diversity of display
situations will become more important, not less.

[Barry Pearson]

Darin McGrew wrote:

I wrote:

The approach I like the best is one I saw at photo.net. Thumbnail
images are linked to pages that display larger versions as inline
images. On those pages, there are links to even larger versions.
That leaves the user in control, deciding how big an image is most
useful, worth downloading, etc.
Barry Pearson <ne**@childsupportanalysis.co.uk> wrote:

Interesting approach! But that takes extra effort (for the
photographer).

On my photography site, I provide 2 sizes. The smaller size fits
into a 500 x 500 box, and is typically less than 50 KB. The larger
size fits into a 700 x 700 box, and is typically less than 100 KB.
The thumbnail galleries provide the choice.
I just took a look at the photo.net site again. Thumbnails fit in a
200px square box. They are linked to a page that displays medium
images that fit in a 600px square box. The large images fit in an
800px square box. ISTR having seen even larger images (fitting in a
1024px box? in a 1200px box?), but I didn't see any looking around
just now.

Here are the photo.net Guidelines:

"Photographs uploaded to photo.net, either to the Gallery or as an attachment
to a forum post, should be JPEG images less than 100k in size and less than
800 pixels in the long dimension. Panoramic images may be wider than 800
pixels, but be aware that this will force many of your viewers to scroll.
Panoramic images must still conform to the 100K size limit. Most likely,
photo.net will recompress your images to make them smaller and to produce
thumbnail, medium, and large views. For images where one dimension is less
than 267 pixels, the three thumbnails will be the same size. For larger
images, the Large size will be the same size as your original, the Medium will
be 3/4 the size, and the Small size will be scaled down to 200 pixels along
its largest dimension."

They have presumably designed this for 800 x 600 screens/windows. In that
case, I'm a bit dubious about making it the full 800 - the reason I use 700 is
to allow for overheads. However, I respect what they have done. In effect, I
have 3 versions, including the thumbnail. These fit into a 125 x 125 box, so
that I can comfortably get 5 in a row. Rows-of-5 is a specific design feature,
and I want it preserved.
For example, have a look at:

http://www.barry.pearson.name/photog...olios/lrps.htm

The main problem I see is that the photo pages are orphaned, except
for the link to the site's home page. And based on the context of
that link, I assumed that it was a mailto link. It would be nice to
include links to smaller/larger versions of the same image, to the
index page for the set, to the info page, etc., much the way
photo.net does it. With a database-backed site, it shouldn't be too
difficult to do this kind of thing automatically.

I don't use a database-backed site - just absolutely bog-standard HTML, CSS,
and JPEGs uploaded "raw".

I agree about the orphan problem. I've been wondering what I should do about
that. What I do know is that people sometimes find my photographs then manage
to navigate to the rest of the site, but I haven't checked how they do it. If
they simply strip off the RHS of the URL (I would just use the "up" button of
the Google toolbar!), they will get to a page designed to help them proceed.
Example:
http://www.barry.pearson.name/photog...pictures/eg95/

I wanted to avoid clutter near the photograph. (Until recently, the photograph
appeared in a pop-up window, but I've decided for various reasons, including
accessibility, to keep things very simple). Perhaps I'll add to the admin row
at the bottom - it is far enough from the photograph not to worry me.

Thanks - I'll give this some thought.

As we move towards larger screens and faster internet connections,
the importance of the smaller size will become less.

What do you mean "we"?

I was borrowing a relative's computer recently. The resolution was
800x600, and the available display area was much less after all the
taskbars, hotlists, and other chrome. (Is it just me, or does anyone
else find the default chrome for recent versions of MS Windows too
bloated?) The connection speed was usually just a bit over 20kbps
with a 56kbps modem.

I didn't say we were there! That is why I still have the 2 (or 3) sizes of
photograph. It is a serious design constraint. I had a number of discussions
with people with various combinations of speed and size before arriving at
this compromise.
I regularly use a device with a 160x160 display to view web content,
although admittedly, I don't access photography sites with it.
Indeed! My sites each have different designs, depending on the conditions in
which my target audience is likely to be viewing them. One provides advice,
and the text parts of it can be satisfactorily accessed on smaller screens
(and work at full screen). But the analysis parts of it can't, because they
have graphs and charts in GIF form. Even at 640 x 480, those parts are a bit
of a joke.
WebTV (aka MSN TV) has a resolution of 544x372 with no horizontal
scrolling.

I see a trend towards more diversity in browsing platforms, not a
uniform trend towards huge displays and broadband connections.

Yes to the trend, but not necessarily for each purpose. Although I don't
currently make use of "media type", I am conscious that I am really designing
my photography material for "screen", and could envisage in future doing
something with one of my sites for "handheld" (or even "tv").

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[kchayka]

Jonathan Snook wrote:

(the word resolution is often used instead of "screen size")

The word resolution is often used instead of "window size".
Screen size is one factor of resolution, window size is totally unrelated.

This whole argument about artists' sites is a little silly. The art is
the content. Attempts are made to present it in the most complimentary
way. A PDA is not the most suitable means of viewing that content, but
there is no reason why it can't still be accessed. The viewer could, at
best, get a feel for the art, and would likely revisit the site once
they had access to more appropriate equipment.

Based on comments I've already received in another ng, I apparently
already accomplished this with an artist's gallery.
<URL:http://www.tedbeardsley.com/>

AFAIK, it's accessible in pretty much any viewing environment, but, of
course, looks *best* on a desktop in a particular minimum window size
with the latest graphical browsers. BTW, making it accessible took no
special effort on my part. Most of the effort was tweaking the CSS to
prevent IE from making a mess of it.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Barry Pearson]

Alan J. Flavell wrote:
[snip]

The axiom around here is that stylesheets are for presentation. If
your content is inherently pixel-sized, then that's a feature of your
content, not of your presentation. If the content inherently needed
to be 2000 pixels wide (for example, some teaching material on the
interpretation of X-ray pictures, which needed to be that big in order
to show some important detail in its context) then "so be it", and the
readers have to make the best of whatever screen size they happen to
have, even though most of them will be unable to see the whole thing
at once.
I agree with your 1st sentence. But not with my reading of your 2nd. With
inherently visual material, presentation in a broad sense gets incorporated
from conception. In other words, what the HTML on the web considers to be
content (a JPEG, GIF, PNG, etc) may have a number of presentation decisions
built into it. And in some cases, it can be a bit arbitrary when those
presentation features should be built in. I'l give some example, then point
you at an article that gives some OTT examples of this.

If I produce a chart with Excel, I can use Excel's positioning of the legend
in the chart. Or I can treat the legend and the chart as 2 separate pieces of
content, and position the legend onto the chart using Photoshop. Or I can
treat them as 2 separate pieces of content as far as HTML is concerned, and
let the CSS position them. (Typically I do the 2nd). Ditto for a caption (but
I would probably do the 3rd).

I can add a border at just about any stage, including the last (CSS). I can't
(yet!) manipulate the colours with the CSS, but I certainly have choices at
earlier stages. Ditto transparency. I can control the image size at various
stages. (But if the "img" specifies the size, doesn't that stop me changing
the size via the CSS? I must investigate). So there is a process or workflow
from conception to browse, and presentation can be added at various stages, as
appropriate. I add borders to my photographs at the last stage using CSS. Many
photographers do it earlier.

To illustrate this (although it is pretty obvious), I wrote the following
article:
http://www.barry.pearson.name/articl...esentation.htm

If you can't be bothered with the whole article, this page illustrates most of
the points:
http://www.barry.pearson.name/articl..._09_09_2_2.htm
(The image is an unrevealing picture of a woman with no clothes on, so think
before you look at this).

It "simply" shows 3 different combinations of a double-border being added to a
photograph. Before uploading to the web, after uploading (and hence at browse
time), or both of these. Someone may claim that adding borders within the JPEG
isn't really presentation, and/or isn't on-topic for this NG. So the borders
IN the JPEGs were added to the original image using exactly the same CSS used
for the final browse! I simply used the CSS at an earlier stage. (Which is why
all the borders should typically look the same).

I did it to make a point, and perhaps laboured the point. I don't normally use
CSSs as a photo-editing method to produce JPEGs!

There is a danger (but probably not for you) of thinking of web authoring as
simply making the best of available content. Sometimes it is. And, of course,
I won't argue against getting structure, content, and presentation, all
properly sorted out. But it can also be about developing earlier content with
the final presentation in mind, then choosing the best places to add various
presentation features.
On the other hand if your pictures were 200px wide and you stubbornly
fitted them five to a line in the belief that everyone[1] had a
browser window at least 1024px wide, without having any content-based
reason to do so, then that would be "presentation". There seems to be
a significant difference between the two - at least I think there is.
You talked about "content inherently needed to be 2000 pixels wide", and also
"your pictures were 200px wide". But much content is not inherently 2000
pixels wide. The developer can choose that within limits. Should s/he make it
2000 wide, 700 wide, 200 wide, wait for SVG to become ubiquitous?
[1] "everyone", that is, in the supposed "target audience". Not a
term that I care for, since for me it's inherent that viewers will
sometimes be using one browsing situation, sometimes another: if they
first meet a web page in a less-suitable situation, their experience
is likely to determine whether they bother to revisit it later when
they're in a more-suitable browsing environment. So I'd prefer a page
that goes a reasonable way towards accommodating different viewing
situations, to whatever degree is feasible given the inherent nature
of the content.

Indeed. But how should we go about answering my question, just about about how
big the images should be developed as?

I am comfortable about making most choices, such as when to add borders,
captions, etc. But the image/photograph size issue is probably the single
hardest design decision I have had to make.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Jonathan Snook]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:te**************@newsfep1-gui.server.ntli.net...

If I produce a chart with Excel, I can use Excel's positioning of the legend in the chart. Or I can treat the legend and the chart as 2 separate pieces of content, and position the legend onto the chart using Photoshop. Or I can
treat them as 2 separate pieces of content as far as HTML is concerned, and let the CSS position them. (Typically I do the 2nd). Ditto for a caption (but I would probably do the 3rd).
Well, one could argue that the data that the chart is based on is the true
content and that the chart [image] that represents it is merely
presentation.

Photographs and artwork on the other hand, as I think everybody has agreed
upon, is the content and thus brings us to your last issue. Deciding the
size of the image in pixels.
I am comfortable about making most choices, such as when to add borders,
captions, etc. But the image/photograph size issue is probably the single
hardest design decision I have had to make.

Despite the inaccuracies in any statistics and the inherently difficult way
to determine what screen size, window size, or if you use the word
resolution to mean either of these two things, of all users, I still feel
that the statistics I have seen which indicate that people are mostly using
a screen size of 800x600 or greater are closer to the truth than false. So,
700px wide for your photographs would seem to be a valid option.

Jonathan
--
http://www.snook.ca/

[Tina Holmboe]

"Jonathan Snook" <go***************@snook.ca> exclaimed in <NS*********************@news01.bloor.is.net.cable .rogers.com>:

Ah, I seem to be misunderstanding you... when you say "creating a site that
works on every resolution" I thought you meant, don't create a site that
would have a scroll bar on an 800x600 screen size or should I say browser
"Do not create a document which imply scrollbars in any window size
unless the content has an inherent size larger than said window"

In other words:
Example, doing this: <div style="width:800px;">this is my content</div>
Really bad, as what goes inside that div might not have an inherent size
of 800 pixels, and so COULD reflow unless the author forced it.

<img src="photograph.png" width="800" ... >

on the other hand simply means to include content which happens to be 800
pixels in width. Can't reflow. Might mean a scrollbar.
would seem to be a poor way to do web development. Now, Tina says a scroll
bar is okay (and the code would theoretically still be quite accessible in
Well. Let me moderate myself: a scrollbar is usefu should the content have
an inherent size larger than the window. We should strive to avoid the
scroll, however, since it does present problems for some user groups.
So, while my example may not "look" good on every screen, am I creating a
site that works on every resolution?

'tis better to ask: "Can everyone, regardless of resolution, get to the
content ?" - and then, perhaps, "Have I made it difficult for them by
forcing widths ?"

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905

[Barry Pearson]

Jonathan Snook wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:te**************@newsfep1-gui.server.ntli.net...

If I produce a chart with Excel, I can use Excel's positioning of
the legend in the chart. Or I can treat the legend and the chart as
2 separate pieces of content, and position the legend onto the chart
using Photoshop. Or I can treat them as 2 separate pieces of content
as far as HTML is concerned, and let the CSS position them.
(Typically I do the 2nd). Ditto for a caption (but I would probably
do the 3rd).
Well, one could argue that the data that the chart is based on is the
true content and that the chart [image] that represents it is merely
presentation.

True - very good point!
Photographs and artwork on the other hand, as I think everybody has
agreed upon, is the content and thus brings us to your last issue.
Deciding the size of the image in pixels.

[snip]

"... is the content ..." to the final HTML. But it includes presentation when
the whole process is considered. (Borders are a common example where different
people make different choices).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Alan J. Flavell]

On Sat, 4 Oct 2003, Barry Pearson wrote:

With inherently visual material, presentation in a broad sense gets
incorporated from conception.
Yes; I evidently over-simplified the argument.
In other words, what the HTML on the web considers to be content (a
JPEG, GIF, PNG, etc) may have a number of presentation decisions
built into it. And in some cases, it can be a bit arbitrary when
those presentation features should be built in.
That's right: there's a whole field of borderline cases where you as
author are called upon to decide whether a feature more properly
belongs (using the terms in a broad sense) to the content or to the
presentation.

On the other hand the WWW, by its very nature, is going to separate
content from presentation, in the more-specialised technical sense.

Thus, the task involves optimising the extent to which your general
sense of content v. presentation aligns with what the web is going to
do - in and of itself. Or as I've expressed it on other occasions,
something like "designing to take advantage of the inherent strengths
of the web as a medium, while avoiding as far as possible its
weaknesses".

[instructive details omitted for brevity.]
To illustrate this (although it is pretty obvious), I wrote the following
article:
http://www.barry.pearson.name/articl...esentation.htm
It's well-argued, indeed.
There is a danger (but probably not for you) of thinking of web
authoring as simply making the best of available content. Sometimes
it is. And, of course, I won't argue against getting structure,
content, and presentation, all properly sorted out. But it can also
be about developing earlier content with the final presentation in
mind, then choosing the best places to add various presentation
features.
Indeed. But, as I say, every kind of web page designer (whether
predominantly textual, predominantly image-oriented, or predominantly
something else for that matter) would do well to make their choices in
the light of the diversity of web viewing situations that their pages
can and will meet.
You talked about "content inherently needed to be 2000 pixels wide",
and also "your pictures were 200px wide". But much content is not
inherently 2000 pixels wide. The developer can choose that within
limits.
Yes: indeed in terms of current image formats they _have_ to choose...
Should s/he make it 2000 wide, 700 wide, 200 wide, wait for
SVG to become ubiquitous?
Or maybe, given the acknowledged limitations of pixel-oriented
formats, to make three choices available?
I am comfortable about making most choices, such as when to add borders,
captions, etc. But the image/photograph size issue is probably the single
hardest design decision I have had to make.

Sometimes, as I say, the nature of the visual content itself mandates
a certain minimum size, below which the image is incapable of doing
its job. Sometimes (in your case it may be "often") it's your choice
as author/designer to produce something which will appeal to the
audience.[1] But a key point in that is that it should appeal to the
_audience_ (who might be browsing in different situations at different
times). Which is why I urge flexibility wherever it's not excluded by
the inherent nature of the content.

Of course, if you're a perfectionist and insist on pixel-optimising
all three versions of an image, then you're inevitably going to triple
the work. But I've got no say in your authoring decisions - I can
only comment from my standpoint as a potential reader/viewer.

cheers

[1] but hopefully avoiding the kind of circular arguement which, in
claiming to choose the offering so as to appeal to the audience,
succeeds only in choosing the audience which is to be appealed to by
the offering.

[Nikolaos Giannopoulos]

Alan J. Flavell wrote:

On Sat, 4 Oct 2003, Barry Pearson wrote:

The approach I like the best is one I saw at photo.net. Thumbnail
images are linked to pages that display larger versions as inline
images. On those pages, there are links to even larger versions.
Interesting approach! But that takes extra effort (for the photographer).

Not necessarily. Not for one who uses proper tools that is.

If you weren't such a perfectionist, you could have a script which
automatically produced and indexed the reduced-size versions at the
push of a button ;-)

Actually if ImageReady (a component of Photoshop in the last few
releases) is used then one could simply drag a folder onto a ImageReady
batch file and voila - tens, hundreds, thousands of images get processed
(of course you probably will want to find something else to do while
this is going on).

Of course he may need to buy it - but being into photography he may
already have it - and btw there is effort involved -

(1) Installing Photoshop... once
(2) Creating a simple script in ImageReady... once
(3) Saving the script... once
(4) dragging folders onto ImageReady batch file... as often he likes ;-)

Anyone who does thumbnail stuff by hand is wasting their time especially
since this task is typically done over, and over, and over again.

By the way you could have 2, 3, or 4 scripts (actually the same script
but simply change the the scaling) and it takes no more effort than
copying a folder and dragging it onto one of the batch files X number of
times.

HTH,

--Nikolaos

[Herbert]

On Wed, 1 Oct 2003 11:21:12 +0100, "Barry Pearson"
<ne**@childsupportanalysis.co.uk> wrote:

B McDonald wrote:

Brian wrote ...

B McDonald wrote:[snip] > It is way too constricting. I mean, unless I'm selling pantyhose
> to the masses - or some other mass-market item - there's no point.

If you're not writing for "the masses," then why write at all? Shut
off your site and reduce the noise.

Huh? Pablo Neruda wrote for himself. Where would that put the rest of
us if he didn't write his daily poetry?

[snip]

The real answer to the question that you are responding to is "cater for your
client's target audience, and they may not be the masses".

You may be your own client, of course. (As I am for all of my sites).

That doesn't mean specifically code to inhibit the rest. And there are many
equal-cost alternatives where one version is more widely accessible than
another, and it worth getting into the habit of doing things the more
accessible way.

But there comes a point at which it is valid to say "that is all I am prepared
to spend on this, everyone else can take pot-luck or walk away".

Amen

[Barry Pearson]

Nikolaos Giannopoulos wrote:

Alan J. Flavell wrote:

On Sat, 4 Oct 2003, Barry Pearson wrote:

The approach I like the best is one I saw at photo.net. Thumbnail
images are linked to pages that display larger versions as inline
images. On those pages, there are links to even larger versions.

Interesting approach! But that takes extra effort (for the
photographer).
Not necessarily. Not for one who uses proper tools that is.
Then I'm not sure what these tools are. I have Photoshop 6 and ImageReady 3,
and use them all the time, and those are not the tools.
If you weren't such a perfectionist, you could have a script which
automatically produced and indexed the reduced-size versions at the
push of a button ;-)

Actually if ImageReady (a component of Photoshop in the last few
releases) is used then one could simply drag a folder onto a
ImageReady batch file and voila - tens, hundreds, thousands of images
get processed (of course you probably will want to find something
else to do while this is going on).

For various reasons I do the unsharp mask in Photoshop & the compression in
ImageReady. I normally use different USM parameters for different photographs
sizes, and anyway often use different parameters for different photographs, so
can't do all of those satisfactorily in bulk.

I often use different compression for different photographs. I sometimes, but
only rarely, use different compression parameters for different sizes of the
same photograph. (A problem is that I am trying to keep the size of the
largest photographs to no more than 100 KB, and that needs careful
compression).
Of course he may need to buy it - but being into photography he may
already have it - and btw there is effort involved -

(1) Installing Photoshop... once
(2) Creating a simple script in ImageReady... once
(3) Saving the script... once
(4) dragging folders onto ImageReady batch file... as often he likes
;-)

Anyone who does thumbnail stuff by hand is wasting their time
especially since this task is typically done over, and over, and over
again.
I don't understand what you mean by "thumbnail stuff".
By the way you could have 2, 3, or 4 scripts (actually the same script
but simply change the the scaling) and it takes no more effort than
copying a folder and dragging it onto one of the batch files X number
of times.

HTH,

Thanks, but it didn't really. I have ruled those options out on quality
grounds.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Nikolaos Giannopoulos]

Barry Pearson wrote:

Nikolaos Giannopoulos wrote:

Alan J. Flavell wrote:

Interesting approach! But that takes extra effort (for the
photographer).
Not necessarily. Not for one who uses proper tools that is.

Then I'm not sure what these tools are. I have Photoshop 6 and ImageReady 3,
and use them all the time, and those are not the tools.

Really? Could it be that you don't know about a feature of a tool that
you use all the time? Honestly, it is possible unless you are of course
the author of the tool (of which mind you for PhotoShop/ImageReady there
is no single person in any event).

In ImageReady, do you see the "Layers, History, Actions" tab of the
panel (typically in the lower right of your screen). Click on the
Actions tab.

Those actions can do *amazing* things as each action can contain an
arbitrary number of steps that interact with ImageReady, including
*having a dialog (you can toggle dialogs on and off to the left of the
the step when its a panel) for user input on any given panel*. Take a
look at what is already there and either create a new action or
duplicate one that is similar to what you want to start with and
customize it as you see fit.

If you right mouse click on the action you will see an option that says,
"create droplet" which allows you to save your action as an droplet exe
file.

Now outside ImageReady simply drag a file or folder onto the droplet
(ImageReady doesn't need to be running at this point) and automatically
ImageReady will launch (if it isn't already running) and each of the
files will have the action applied to them. BTW you can play actions
inside ImageReady - which is ideal for development.

Personally, I find it easier to have one action for each size that I
want to scale an image down to but YMMV.

Actually if ImageReady (a component of Photoshop in the last few
releases) is used then one could simply drag a folder onto a
ImageReady batch file and voila - tens, hundreds, thousands of images
get processed (of course you probably will want to find something
else to do while this is going on).

For various reasons I do the unsharp mask in Photoshop & the compression in
ImageReady.

Why? ImageReady has an unsharp mask and from the panel it looks like it
has the same options. I imagine its possible that the filter is not as
good but I would be somewhat surprised.

In any event, if it is and you want to ignore the advice contained
herein then that is your choice - I doubt the difference would be worth
it but its your show.
I normally use different USM parameters for different photographs sizes, and anyway often use different parameters for different photographs, so
can't do all of those satisfactorily in bulk.
Once again it seems like you think you know better. You know nothing of
the feature that I am suggesting - to help you - and yet you already
drop it because you think it works in a manner that you are used to
elsewhere. News flash - it may surprise you that you have not sampled
all software in existence and as such you could help yourself by having
a more open mind - the choice is yours of course.

I assume that you have a procedure that you work with - i.e. a basic set
of steps when processing an image - from this you can create actions.

From actions you can produce droplets and away you go. If you find
them inflexible enough that you can't work with them then I would be
very surprised.

I often use different compression for different photographs. I sometimes, but
only rarely, use different compression parameters for different sizes of the
same photograph. (A problem is that I am trying to keep the size of the
largest photographs to no more than 100 KB, and that needs careful
compression).

If I wanted to complicate my life with multiple actions then no problem.
Once I look at a picture, I generally speaking know which approach I
am going to take to adjust it and therefore this is a non-issue IMO -
and in a worst case you could drop the same file on a gamut of actions
and simply preview which one did the best job.

ImageReady allows you the option of having a dialog for user input on
any panel - even if it is to just accept the panel settings - so the
needing manual attention has been - guess what - already thought of ;-)

Anyone who does thumbnail stuff by hand is wasting their time
especially since this task is typically done over, and over, and over
again.

I don't understand what you mean by "thumbnail stuff".

You are producing smaller versions of an original - correct? You are
producing a thumbnail, a 500x500 and 700x700 all from an original are
you not. Every time you need to create a 100x100 (or whatever the size
is of your) thumbnail you are doing this manually from your own admission.

I am telling you that you are flat out wasting your time producing
smaller images manually when there are mechanisms that can automate this
- even if you need to fine tune things along the way.

By the way you could have 2, 3, or 4 scripts (actually the same script
but simply change the the scaling) and it takes no more effort than
copying a folder and dragging it onto one of the batch files X number
of times.

Thanks, but it didn't really. I have ruled those options out on quality
grounds.

No. You ruled this stuff out on grounds of not knowing any better and
conveying an attitude of all knowing and all seeing.

In the end, it's your choice - you can either continue to waste your
time or not, but do others a favor and don't make misleading suggestions
that everything w.r.t. software is so black and white.

--Nikolaos

[Barry Pearson]

Alan J. Flavell wrote:

On Sat, 4 Oct 2003, Barry Pearson wrote:

With inherently visual material, presentation in a broad sense gets
incorporated from conception.

Yes; I evidently over-simplified the argument.

In other words, what the HTML on the web considers to be content (a
JPEG, GIF, PNG, etc) may have a number of presentation decisions
built into it. And in some cases, it can be a bit arbitrary when
those presentation features should be built in.

That's right: there's a whole field of borderline cases where you as
author are called upon to decide whether a feature more properly
belongs (using the terms in a broad sense) to the content or to the
presentation.

On the other hand the WWW, by its very nature, is going to separate
content from presentation, in the more-specialised technical sense.

[snip]

I've been trying to understand this "content versus presentation" issue in
terms of the objectives.

It is easy to read the discussion as "put your presentation into the CSS". But
that isn't the real aim. I now believe that the real advice is "if you haven't
sorted out the presentation by the time the content reaches the mark-up, don't
sort it out with the mark-up - sort it out with the CSS".

In other words, the aim is not to enrich CSS to encroach upon the grounds of
pre-mark-up tools (whether these deliver image or sound or video content). The
aim is to de-enrich the mark-up, to reduce it to an identification mechanism
for content, that in turn invokes CSS (or whatever) to enhance the content. It
is all about making the mark-up as tight as possible.

In this model, presentation can go anywhere, including the content, except the
mark-up. So authors don't have N places in the process to add presentation,
they only have N-1.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Nikolaos Giannopoulos wrote:

Barry Pearson wrote:

Nikolaos Giannopoulos wrote:

Darin McGrew wrote: [snip]Barry Pearson wrote ... [snip]>Interesting approach! But that takes extra effort (for the
>photographer).

Not necessarily. Not for one who uses proper tools that is.
Then I'm not sure what these tools are. I have Photoshop 6 and
ImageReady 3, and use them all the time, and those are not the tools.

Really? Could it be that you don't know about a feature of a tool
that you use all the time? Honestly, it is possible unless you are
of course the author of the tool (of which mind you for
PhotoShop/ImageReady there is no single person in any event).

I am aware of what you talk about below. What I said applies. The reason is
that you are talking about a process for automating batch (non-interactive)
actions for lots of files. My problem is highly interactive processing of
relatively few files.

See your comment below - that suggested to me that you were tackling a
different problem from the one that I was tackling. I process perhaps on
average 10 or 20 photographs a month, and spent a lot of time on each.

[snip]

For various reasons I do the unsharp mask in Photoshop & the
compression in ImageReady.

Why? ImageReady has an unsharp mask and from the panel it looks like
it has the same options. I imagine its possible that the filter is
not as good but I would be somewhat surprised.

It is probably largely irrelevant where it is done for the web - I guess the
code is a copy (like some of the other things). But I do it in Photoshop for
printing, and tend to stick to one way of doing things where possible. Since I
am doing the work anyway, what does it matter?

[snip] I normally use different USM parameters for different photographs

sizes, and anyway often use different parameters for different
photographs, so can't do all of those satisfactorily in bulk.
Once again it seems like you think you know better. You know nothing
of the feature that I am suggesting - to help you - and yet you
already
drop it because you think it works in a manner that you are used to
elsewhere. News flash - it may surprise you that you have not sampled
all software in existence and as such you could help yourself by
having
a more open mind - the choice is yours of course.

You didn't respond to my point. As I said, I use different parameters - so
there is a manual stage. This certainly means it doesn't work in the way
implied by your "of course you probably will want to find something else to do
while this is going on".

[snip]

I often use different compression for different photographs. I
sometimes, but only rarely, use different compression parameters for
different sizes of the same photograph. (A problem is that I am
trying to keep the size of the largest photographs to no more than
100 KB, and that needs careful compression).

If I wanted to complicate my life with multiple actions then no
problem. Once I look at a picture, I generally speaking know which
approach I
am going to take to adjust it and therefore this is a non-issue IMO -
and in a worst case you could drop the same file on a gamut of actions
and simply preview which one did the best job.

It sounds simpler to just pass the file from Photoshop (where I've been
processing it, for example changing the colour mode) to ImageReady, then
change the parameters in the normal way! It appears that you somehow get a lot
of photographs close to the end of the process, then do the final stages
en-mass. I don't - I work on a few at a time, then run them through to
completion just one or two at a time.
ImageReady allows you the option of having a dialog for user input on
any panel - even if it is to just accept the panel settings - so the
needing manual attention has been - guess what - already thought of
;-)
Indeed - but so what? What have I then saved? Remember the starting point
here - I said, in response to a post about the photo.net approach of having
multiple sizes "But that takes extra effort (for the photographer)". Where
have you changed that fact? Unless I stop setting the USM & compression
parameters per photograph and per size, that effort is still in any process.

(In fact, I now know that what photo.net do it start with the largest size and
resample it downwards mechanistically. I don't use that approach, for quality
reasons).

[snip] You are producing smaller versions of an original - correct? You are
producing a thumbnail, a 500x500 and 700x700 all from an original are
you not. Every time you need to create a 100x100 (or whatever the
size is of your) thumbnail you are doing this manually from your own
admission.

I am telling you that you are flat out wasting your time producing
smaller images manually when there are mechanisms that can automate
this - even if you need to fine tune things along the way.
As I said, most of my effort is in the per photograph and per-size variations.

[snip]

Thanks, but it didn't really. I have ruled those options out on
quality grounds.

No. You ruled this stuff out on grounds of not knowing any better and
conveying an attitude of all knowing and all seeing.

I have ruled it out on quality grounds. Obviously it is impossible for you to
know my "grounds"! And you happen to have guessed wrong.
In the end, it's your choice - you can either continue to waste your
time or not, but do others a favor and don't make misleading
suggestions that everything w.r.t. software is so black and white.

It is clear that I have made no such suggestion. I wonder if you are actually
responding to me or to someone else?

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Nikolaos Giannopoulos]

Barry Pearson wrote:

Nikolaos Giannopoulos wrote:

I am aware of what you talk about below. What I said applies. The reason is
that you are talking about a process for automating batch (non-interactive)
actions for lots of files. My problem is highly interactive processing of
relatively few files.
Really. I strongly doubt not. Who said the process is
"non-interactive". It is if you want it to and it isn't if you don't.

If a step that utilizes a panel requires "manual intervention" then all
you need to do is toggle the "dialog input" icon to "on" for that step.

Once again you demonstrate this I know best attitude when you clearly
have no idea about this feature - yet are trying to now profess that you
do (and most likely will say you did all along) and are getting it
totally wrong because your true experience with this feature is showing
through.

See your comment below - that suggested to me that you were tackling a
different problem from the one that I was tackling. I process perhaps on
average 10 or 20 photographs a month, and spent a lot of time on each.
Whether you tackle more than 1 or a hundred the process is the same - if
you want to waste your time then go ahead just don't mislead other
people in your profession into believing that they need to waste their
time by not using tools that may be available to them.

Why? ImageReady has an unsharp mask and from the panel it looks like
it has the same options. I imagine its possible that the filter is
not as good but I would be somewhat surprised.

...But I do it in Photoshop for printing,

I imagine you have your reasons - what printing and compression of web
graphics have to do with each other is anyone's guess....

and tend to stick to one way of doing things where possible.
Really. Do you think this surprises anyone who has read your posts?

Since I am doing the work anyway, what does it matter?
It doesn't for you. It does for others reading this thread that believe
that ImageReady is as "inflexible" as you would like everyone to believe.

I normally use different USM parameters for different photographs

sizes, and anyway often use different parameters for different
photographs, so can't do all of those satisfactorily in bulk.
You didn't respond to my point.

Actually I did in the bulk of my e-mail how about an except you totally
clipped it - here goes again:
Those actions can do *amazing* things as each action can contain an
arbitrary number of steps that interact with ImageReady, including
*having a dialog (you can toggle dialogs on and off to the left of the
the step when its a panel) for user input on any given panel*.
Do you see the words "interact" and "having a dialog for user input on
any given panel". Is this what you label as "non-interactive".

As I said, I use different parameters - so there is a manual stage.
Right. And the problem with this feature is?

This certainly means it doesn't work in the way
implied by your "of course you probably will want to find something else to do
while this is going on".
If you setup an action that has "interactive" points then you provide
the manual input for the given dialog otherwise in "non-interactive"
cases you could simply walk away.

My droplets don't typically require interaction but I have on occassion
made them to be interactive - the choice is yours - the designer.

If I wanted to complicate my life with multiple actions then no
problem. Once I look at a picture, I generally speaking know which
approach I
am going to take to adjust it and therefore this is a non-issue IMO -
and in a worst case you could drop the same file on a gamut of actions
and simply preview which one did the best job.

It sounds simpler to just pass the file from Photoshop (where I've been
processing it, for example changing the colour mode) to ImageReady, then
change the parameters in the normal way!

If you say so, but then again you also say that this feature is
"non-interactive" so I guess you know what you are talking about ;-)

It appears that you somehow get a lot of photographs close to the end
of the process, then do the final stages en-mass.
Sometimes I do sometimes I don't it depends on the case. Any time I
need to repeat a procedure more than 2-3 times it makes more sense IMO
to just create an action.

I don't - I work on a few at a time, then run them through to
completion just one or two at a time.
Yet, every time you manually trudge through a set of processes - even if
they require "user input" it would be best for someone in your
profession (obviously not you mind you) to create actions and avoid the
unnecessary repetition.

Note that I say best - not the only way - and anyone is free to take
this advice or not. The feature exists and it is capable of doing
things that you say it can't so if anyone is interested I'd suggest that
they simply look at their own manual.

ImageReady allows you the option of having a dialog for user input on
any panel - even if it is to just accept the panel settings - so the
needing manual attention has been - guess what - already thought of

Indeed - but so what?

Well, okay now which is it - is the feature "non-interactive" or
"interactive" or have you not made up your mind yet.

What have I then saved? Remember the starting point
here - I said, in response to a post about the photo.net approach of having
multiple sizes "But that takes extra effort (for the photographer)".
For somone who is open to writing an action the effort is minimized down
the road - for some who wants to do everything manually and wants to
"stick to one way of doing things" then you can keep exerting this extra
effort every time.

Where have you changed that fact? Unless I stop setting the USM & compression
parameters per photograph and per size, that effort is still in any process.
It's all the steps between adjusting an "interactive" panel.

(In fact, I now know that what photo.net do it start with the largest size and
resample it downwards mechanistically. I don't use that approach, for quality
reasons).
Read the words droplets can be "interactive". Imagine photo.net manual
approach - make an action out of it and then simply toggle the steps
that you want to provide "manual input" on. If you think this doesn't
save you anything well then that's unfortunate.

As I said, most of my effort is in the per photograph and per-size variations.

Right. I understand you are not open to anything that deviates from
what you are used to; even if you don't know the full capabilities of
the feature.

No. You ruled this stuff out on grounds of not knowing any better and
conveying an attitude of all knowing and all seeing.

I have ruled it out on quality grounds. Obviously it is impossible for you to
know my "grounds"! And you happen to have guessed wrong.

There you with that bull on quality grounds. If you don't use
ImageReady at all then yes your right what I am suggesting is not a good
idea.

In the end, it's your choice - you can either continue to waste your
time or not, but do others a favor and don't make misleading
suggestions that everything w.r.t. software is so black and white.

It is clear that I have made no such suggestion. I wonder if you are actually
responding to me or to someone else?

Funny. That was my thinking of your reply but then again you went from
(1) not knowing of a feature, to (2) knowing of it after it was
described to you to (3) clearly demonstrating that you have no
experience with it - which leads me to believe that you are clearly not
open to any suggestions however you should refrain from misleading
others in the process.

--Nikolaos

[Barry Pearson]

Nikolaos Giannopoulos wrote:

Barry Pearson wrote:

Nikolaos Giannopoulos wrote:

I am aware of what you talk about below. What I said applies. The
reason is that you are talking about a process for automating batch
(non-interactive) actions for lots of files. My problem is highly
interactive processing of relatively few files.

Really. I strongly doubt not.

[snip]

I simply stated a fact. I see no point in continuing this discussion. I am in
the solution business, not the debating business. While I recognise that you
know a lot about your subject matter, I can't see that this discussion will
contribute towards a solution for me.

For some reason, you are pushing your proposal at me without attempting to
identify whether it actually matches my requirements. Then when I say it
doesn't, you dispute my response, rather than take the trouble to see why
there is a difference between your view and mine.

I wonder if you have an agenda that I am unaware of? Do you have a reason for
convincing me (and perhaps others) that your proposal is "the way to go"? I
certainly appear to have inadvertently triggered an emotional response in you!

Perhaps we will be able to discuss other topics on a better footing. But I see
no future in this discussion. Until the next topic, then!

Thanks for your effort.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Nikolaos Giannopoulos]

Barry Pearson wrote:

Nikolaos Giannopoulos wrote:

I simply stated a fact. I see no point in continuing this discussion.
Likewise.

I am in
the solution business, not the debating business. While I recognise that you
know a lot about your subject matter, I can't see that this discussion will
contribute towards a solution for me.
No problem.

For some reason, you are pushing your proposal at me without attempting to
identify whether it actually matches my requirements. Then when I say it
doesn't, you dispute my response, rather than take the trouble to see why
there is a difference between your view and mine.
No. You were presented with an alternative solution - being in the
"solutions business" I imagine you can appreciate this - that IMO
mitigates "extra effort in downsizing images" BUT keep making erroneous
claims about the suitability of the solution whilest clearly
demonstrating you know very little about it, have zero experience with
it, yet claim to know about it (after the fact).

I wonder if you have an agenda that I am unaware of? Do you have a reason for
convincing me (and perhaps others) that your proposal is "the way to go"?
None that "I" know about ;-)

I certainly appear to have inadvertently triggered an emotional response in you!
Well, when you keep making false claims it does get aggravating - even
if the solution is not palatable for you it may be for others. Letting
false claims slide just doesn't seem fair to others reading this thread
down the road IMO.

Perhaps we will be able to discuss other topics on a better footing. But I see
no future in this discussion. Until the next topic, then!
Sure. Why not.

Thanks for your effort.

Your welcome and likewise.

--Nikolaos

[Jonathan Snook]

Nothing like beating a dead horse but...

My understanding of what Barry did was going between the unsharp mask and
the compression screens repeatedly to achieve the final result. Now
certainly my experience with ImageReady is limited but I always understood
the droplets to be a batch process in that it did step 1, then 2, then 3
without the ability to go back a step.

Jonathan
--
http://www.snook.ca/