Now that we have a rough sketch of some requirements for the on-line photo album, we can begin answering some of the questions that were poised. It's easy to see that one of the more complex issues will be organization/categorization/presentation of the pictures, and that the choices made concerning how the pictures are stored/organized will directly affect (and limit) how they can be presented. For example, if we do not associate pictures with specific categories such as "Summer Vacation Pics"; we cannot present them to a viewing user as that group. That is, a user cannot choose to view all of the "Summer Vacation Pics."
But, this can be easily simplified with a couple of general assumptions. The first is that we can assume (for the first iteration of the web app, at least) that categorical pictures usually fall within a similar time frame. That is, a category such as "Summer Vacation Pics" will most likely all occur within a one month time frame. Reworded another way, pictures happen in timeframe groupings. Thus, pictures will be organized according to date. Now, we need to choose what time frame for the date -- store pictures according to the day they were uploaded, the week, the month, the year? I believe month will be more than adequate.
Furthermore, we can continue to reduce complexity by saying a thumbnail is a thumbnail is a thumbnail. There is no reason to have differently sized thumbnails. All pictures get compressed to a thumbnail resolution all the same even though the pictures themselves may be different. I think 160x120 is a good size for thumbnails. (View what that size looks like at http://www.pbase.com/gallery/ddyer/yellowstone.) It's not too small that one cannot make out the picture, but not too big that you cannot easily fit many photos on a screen. But, how many can you put on a screen leaving page size still reasonable?
A quick estimation puts 160x120x24b around 4k. So, a 32 exposure roll of film all uploaded will hover around 128k. 40 pics will be sitting pretty around 160k. (Slashdot's homepage sits around 180k.) That's not too bad. So, at maximum, one can view 40 thumbnails on one page. I think that we have enough info to go ahead and write up a user scenario:
User Scenario #1
- User surfs to default main page and sees at least 40 thumbnails of the most current pictures. Also on the page, is a menu where the user can choose to view other months of pictures. If any page has more than 40 pictures, there will be a navigation bar that lets the user scroll forward or backward through the month's groupings of thumbnails.
- If the user clicks on a thumbnail, a new window opens displaying the picture in its entirety along with the associated caption.
If you noticed, I slipped in an answer to another question. When clicking on a thumbnail, a new window will open displaying the pic. I think that that is reasonable, and that is how I would expect something like a on-line photo album to work. I want the main page to sit where it is for navigation and thumbnail viewing purposes; if I want to see a full picture, I want to click it and have it open in a new window.
So, I think that pretty much covers things from the user end. Now, we need to talk about the interface and options for the photographer; and then we can get into design. We, also, need to come up with a name for this bad sucka. How about "Photog" pronounced foe-TOG? A search on SourceForge for a project called "Photog" turned up nothing. So, we are going with that unless anyone has a better suggestion up front.
| J$ |
|
Comments