Success at last!

Question

As you are probably all aware, for probably two years I have
been trying to get
my head around php and MySQL, primarily with the intention of
making a better
program for a web site photo album.
I have looked at many sites prepared using commercial
programs, but none took my
fancy. My main objections to them all were:
1. They all used a single layout for all pages. This was
generally far
too cluttered with distracting and largely irrelevant
information, so that there
was very little space to display the photograph.
2. They invariably had only a single level of indexing,
generally with
a row of thumbprints at the top of the page, and a single
slightly larger main
photograph, and almost invariably you had to move the mouse
all over the place,
and often scroll the page up and down, to move from one image
to the next.
3. Most were as slow as a wet week.
I wanted:
1. Multiple level indexing.
2. A simple uncluttered page, with the largest possible
image, without
having to scroll the page.
3. The ability to scroll from picture to picture, or menu to
menu,
without having to move the mouse.
4. A simple way to insert or delete images, and to change
the order in
which they appear.
I already have quite a large photo album which meets these
requirements, but
every photo is displayed in its own page. Setting up a new
album was a lot of
work, and once it was set up it was effectively impossible to
modify the format
of the existing pages.
The more I thought about it, the more I came to the
conclusion that a database
was not the answer to this application. Two weeks ago I
wrote:
".... but if I wait till I get a database set up it looks as
if I'll be lucky
to have it done by Christmas."
Murray kindly offered to help, and I spent a week trying to
clarify my ideas.
I decided that the best answer was to use a series of text
files to specify
which photos should be shown, and in what order. I worked out
a rough format,
and a week ago I tried to write a php program which would
automatically convert
a sample Word file into the desired format, and add a heading
containing
pointers, etc.
I got this working much sooner than I expected, so I decided
to try the real
thing. I got a preliminary version working to day, and you
may care to have a
look at it:
http://www.corybas.com/Albums/07_Europe/Intro.php
The home directory for my albums is called 'Albums'. This
contains the program
files, and a short text file listing all the subdirectories.
Below this is another directory for each individual album --
for example
07_Europe. Each individual directory contains an introductory
page 'Intro.php',
a file 'Main_ndx.txt', listing the photos to be shown on the
top-level index,
and 'Slide_ndx.txt', which lists all the photos to be shown,
together with their
titles, in the appropriate order.
The main index has a sample photo for each block of 16
photos, together with
short descriptions of the groups. There are 6 photos on each
page.
Below this is the subindex, which shows thumb prints for all
the photos in the
album, with 16 photos on each page.
Finally there are the photos themselves. These are the
maximum size which can
be shown on a 768 by 1024 pixel screen, with the given screen
layout, and are
displayed without any distracting extraneous information.
Apart from the introductory page, all the pages are the same
size, and have the
navigation arrows in exactly the same place.
You can scan through the albums, backwards and forwards, at
any level, and you
can drop to the level below by clicking on any of the thumb
prints. At present
you can only move from one album to another at the top level,
but eventually you
will be able to do so at any level.
At present the albums contain only enough photos to enable me
to test the
program, and the titles are very scrappy. The top-level data
file lists several
albums which have not yet been converted, so you will get an
error message if
you try to scan left from the first album. I did this
primarily to enable me to
test the error handling procedures.
At present the procedures for locating a given image are
fairly primitive, but
the performance I get is excellent. Although the photos are
relatively large,
my program takes an average of three seconds to load each
picture.
By contrast
http://www.wildimages.biz/wi_gallery-wildlife.php
takes an average
of 10 seconds to load each page, and
http://www.2010vancouverphotos.com/Index.php?spgmGal=BC%20Moments,
takes about
25 seconds. I realise that some or all of the difference
could be explained by
propagation delays across the Pacific, and I would appreciate
any comparisons
from your side.
The whole program occupies about 25KB, with another 5-10KB
for each set of data
files. Because the individual albums are relatively small,
they are fairly
easily easy to manage, but the system can be extended
indefinitely without
degrading performance.
I would be would be very grateful for your views on this
album, and any bug
reports. You can contact me privately using the yellow button
in the bottom
right hand corner of the introductory page.
Clancy

Answer 1

Hi Kim,
Thanks for the comments.
I looked at that web site (yours?) and thought "yes, it is
very fast, but they
are very small images". Then I downloaded a few samples and
noticed that two of
them were 400K bit maps. I get the impression that the site
is in Scandinavia,
and if so I am amazed that I can download these files in a
second or so.
Even if they were cached locally (which I doubt) this would
still be a very good
performance, so I don't know what is going on. I don't think
that there is any
substantial degradation in performance in unpacking JPEGs,
but as these 400K
file shrink to 20 to 30KB as JPEGs I would have thought it
would be well worth
doing, if only to save space on the server.
I had another look, and it takes just over one second to
download each image.
Some sets load faster than others, but I don't know whether
it is the bit maps
or the others. I had another look at my site, and my images,
which are
typically 450 by 600 or 720 by 540, with lengths of 50 to
150KB seem to take
about 2.7 seconds to download, with no noticeable difference
between the ones
with individual pages and the ones referenced via the
datafile. It appears that
my dirty procedures are fast enough, at least for this size
of album.
Clancy
>Hi Clancy,
>
>Looks nice and seem to work fine. But if it's faster than
other
>scripts/solutions that am not sure about. If you look at
this page
>
http://lazur.dk/inspiration.php
do you then think the images loads
>faster/slower than your solution?
>
>The beauty of dynamic stuff is that you can get the
solution *you* want
>and don't have to relay on others ideas etc :)
>
>Have fun
>
>Kim
>
>Clancy skrev:
>> As you are probably all aware, for probably two
years I have been trying to get
>> my head around php and MySQL, primarily with the
intention of making a better
>> program for a web site photo album.
>>
>> I have looked at many sites prepared using
commercial programs, but none took my
>> fancy. My main objections to them all were:
>>
>> 1. They all used a single layout for all pages. This
was generally far
>> too cluttered with distracting and largely
irrelevant information, so that there
>> was very little space to display the photograph.
>>
>> 2. They invariably had only a single level of
indexing, generally with
>> a row of thumbprints at the top of the page, and a
single slightly larger main
>> photograph, and almost invariably you had to move
the mouse all over the place,
>> and often scroll the page up and down, to move from
one image to the next.
>>
>> 3. Most were as slow as a wet week.
>>
>> I wanted:
>>
>> 1. Multiple level indexing.
>>
>> 2. A simple uncluttered page, with the largest
possible image, without
>> having to scroll the page.
>>
>> 3. The ability to scroll from picture to picture, or
menu to menu,
>> without having to move the mouse.
>>
>> 4. A simple way to insert or delete images, and to
change the order in
>> which they appear.
>>
>> I already have quite a large photo album which meets
these requirements, but
>> every photo is displayed in its own page. Setting up
a new album was a lot of
>> work, and once it was set up it was effectively
impossible to modify the format
>> of the existing pages.
>>
>> The more I thought about it, the more I came to the
conclusion that a database
>> was not the answer to this application. Two weeks
ago I wrote:
>>
>> ".... but if I wait till I get a database set up it
looks as if I'll be lucky
>> to have it done by Christmas."
>>
>> Murray kindly offered to help, and I spent a week
trying to clarify my ideas.
>>
>> I decided that the best answer was to use a series
of text files to specify
>> which photos should be shown, and in what order. I
worked out a rough format,
>> and a week ago I tried to write a php program which
would automatically convert
>> a sample Word file into the desired format, and add
a heading containing
>> pointers, etc.
>>
>> I got this working much sooner than I expected, so I
decided to try the real
>> thing. I got a preliminary version working to day,
and you may care to have a
>> look at it:
>>
>>
http://www.corybas.com/Albums/07_Europe/Intro.php
>>
>> The home directory for my albums is called 'Albums'.
This contains the program
>> files, and a short text file listing all the
subdirectories.
>>
>> Below this is another directory for each individual
album -- for example
>> 07_Europe. Each individual directory contains an
introductory page 'Intro.php',
>> a file 'Main_ndx.txt', listing the photos to be
shown on the top-level index,
>> and 'Slide_ndx.txt', which lists all the photos to
be shown, together with their
>> titles, in the appropriate order.
>>
>> The main index has a sample photo for each block of
16 photos, together with
>> short descriptions of the groups. There are 6 photos
on each page.
>>
>> Below this is the subindex, which shows thumb prints
for all the photos in the
>> album, with 16 photos on each page.
>>
>> Finally there are the photos themselves. These are
the maximum size which can
>> be shown on a 768 by 1024 pixel screen, with the
given screen layout, and are
>> displayed without any distracting extraneous
information.
>>
>> Apart from the introductory page, all the pages are
the same size, and have the
>> navigation arrows in exactly the same place.
>>
>> You can scan through the albums, backwards and
forwards, at any level, and you
>> can drop to the level below by clicking on any of
the thumb prints. At present
>> you can only move from one album to another at the
top level, but eventually you
>> will be able to do so at any level.
>>
>> At present the albums contain only enough photos to
enable me to test the
>> program, and the titles are very scrappy. The
top-level data file lists several
>> albums which have not yet been converted, so you
will get an error message if
>> you try to scan left from the first album. I did
this primarily to enable me to
>> test the error handling procedures.
>>
>> At present the procedures for locating a given image
are fairly primitive, but
>> the performance I get is excellent. Although the
photos are relatively large,
>> my program takes an average of three seconds to load
each picture.
>>
>> By contrast
http://www.wildimages.biz/wi_gallery-wildlife.php
takes an average
>> of 10 seconds to load each page, and
>>
http://www.2010vancouverphotos.com/Index.php?spgmGal=BC%20Moments,
takes about
>> 25 seconds. I realise that some or all of the
difference could be explained by
>> propagation delays across the Pacific, and I would
appreciate any comparisons
>> from your side.
>>
>> The whole program occupies about 25KB, with another
5-10KB for each set of data
>> files. Because the individual albums are relatively
small, they are fairly
>> easily easy to manage, but the system can be
extended indefinitely without
>> degrading performance.
>>
>> I would be would be very grateful for your views on
this album, and any bug
>> reports. You can contact me privately using the
yellow button in the bottom
>> right hand corner of the introductory page.
>>
>> Clancy
Clancy