It's not what I'd recommend. Albums are a done deal nowadays. You'll
get a better album, more quickly, by downloading an existing one. You
probably ought to try a few anyway, just to study features that you
like.
If you want a pure learning exercise, then it's certainly a reasonable
learning exercise - but is an album the best end result to aim at?
It takes a fair few technologies to make a decent album, so it's not a
trivial exercise. There are also several meanings of "photo album
site"
* Do you want a simple album / gallery with lots of text annotation?
Think about using a wiki
* A continuously editable and updatable album, that allows you to re-
oder or re-describe images? Sounds like a database back-end.
* Do you simply want to upload a one-off description file(s) with the
image(s) and then make a web site appear? Consider using XML, XSLT and
no database at all. Even with this you can repeat the process to
update an image.
Your main technologies will be a server-side scripting language and
HTML/CSS for the client side. You'll probably use a SQL database too.
You should (strongly) avoid dependencies on client-side JavaScript to
make it work, but _enhancing_ it with a better client-side UI through
JavaScript is good, so long as it still "works" without. A good
understanding of metadata (read the Dublin Core site) is also
valuable.
Begin by wireframing the site (rough pencil sketches) and thinking
about your navigation structure (pages in a site), page design
(objects on a page, less important than the site layout) and also the
information architecture.
Make sure that each "image" is addressable by a simple, stable URL,
ideally a sensible and comprehensible one (which might involve mapping
from the camera's DSC0001234 form to a more friendly identifier) Also
support cool URLs for your "collections". Certainly allow multiple
"collections" and "albums" to be defined rather than restricting
images to only being in a single one, in a simple hierarchy. It's
really useful to have automatic default collections such as "Stuff I
uploaded on Tuesday" and also "Photographs taken on Sunday" (probably
only visible to you) where you can then assign individual images into
categories or collections such as "Party at Torture Garden" and
"Vicar's Tea Party" manually.
You should also think about image sizes. What happens about making
thumbnails? (this needs to be automated, as it's horribly tiresome
otherwise) What sizes do you support? Can different URLs request bare
images at particular sizes?
Think about video too.
As to the server-side scripting, then Ruby would be a good choice as a
decent contemporary language with enough power to do this easily and
an active community of competent coders, books, example code etc.
You'll probably use PHP instead though, mostly because you can get it
hosted so easily.
All that your users see is the HTML / CSS, so make sure that this is
good. Work on prototypes of single hand-coded static pages until this
client-side design is perfect, and only then automate their
generation. Meta-coding HTML by writing it _through_ a scripting
language is hard work.
The HTML / CSS should be fluid and should reflow nicely according to
browser window size. Don't put your thumbnail gallery in a <table>,
float each thumbnail in a container <div> instead. Think about the
"zoom to one big image" function - do you want a popup, an overlay, an
expanding div within a page? How can you show two big images at once?
How does it work for a tabbed browser? How does it print?
Think about metadata: how much do you store, what are you forced to
enter, what's displayed (who to?) and how extensible is the data
model. It's really useful to be able to annotate images with things
like the list of people in a photo, or even to add annotation notes to
an image as drawn boxes.
