site review request

Darin McGrew wrote:

Barry Pearson <news (AT) childsupportanalysis (DOT) 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/

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 <news (AT) childsupportanalysis (DOT) 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, mcgrew (AT) stanfordalumni (DOT) org, http://www.rahul.net/mcgrew/
Web Design Group, darin (AT) htmlhelp (DOT) com, http://www.HTMLHelp.com/

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

"Brian" <usenet1 (AT) mangymutt (DOT) com.invalid-remove-this-part> wrote

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/

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.

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.

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 <news (AT) childsupportanalysis (DOT) 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/

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.

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/

"Barry Pearson" <news (AT) childsupportanalysis (DOT) co.uk> wrote

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/

"Jonathan Snook" <goto_www.snook.ca (AT) snook (DOT) ca> exclaimed in <NSpfb.207923$Lnr1.65574 (AT) news01 (DOT) 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
tina (AT) greytower (DOT) net http://www.greytower.net/
[+46] 0708 557 905