1.5 BETA Suggestions

[BenV]

Okay, first off, I installed 1.22 last Monday. That was about an hour or two before I found the link to 1.3 out there. So I get 1.3 installed and tweaked like I want it and then you go and release 1.5 beta. So the upgrade train goes... :)

Second off, fantastic gallery. The idea of getting around safe-mode with FTP servers is pretty cool! These are a few suggestions:

1) FTP servers & path setup - specify on the form what fields require the trailing slash and which do not. I know that most/all of them are in the manual but having them on the form would be MUCH faster.

2) Common Settings - be able to turn auto-refresh off by default.

3) Photo Editor - seems to always show "EMPTY DIRECTORY LISTING (wrong microthumb path?)" in the Select Filename select list even when the microthumb and thumb display correctly and the filename does in fact exist. Bug?

4) Also, in the "Select photo:" select list, it would be helpful to add the filename to the display list. When I do a batch import and give all the photos the same generic title, the list becomes useless for selecting a photo. Of course, once I go in and make titles for each photo, the suggestion is moot. But then, by the time I have made titles I won't be using the photo editor any more anyway.

5) Commenting seems to always be on. Can it be turned off? A per-exhibition setting would probably be more flexible for everybody else though I need to turn them all off. A single config setting and one line of code at photo.php, line 2596 should do it.

6) This is the big suggestion from an implementation standpoint. In the UPLOAD TO DATABASE page, when processing a bunch of images, it seems really likely that the browser or the server is going to time out. If the browser times out it's not too much of a problem because the process will still finish, but if the server times out (on an ISP, this would be likely where they have strict script run-time and resource limits in place), this is a big problem. Since server and browser setting are so varied is seems like your asking for trouble in this area. In my case, both were timing out and I was limited to a few images at a time.

I have a couple suggestions for solving the browser problem. The first is to consistently dump status data to the browser making sure that PHP isn't buffering the output. You could do plain text output or you could do a fancy GIF progess bar using GIF frames delivered to the browser at the appropriate time. Since the browser will display a frame as soon as it is received, and since the browser will be getting periodic data, the page will look dynamic and won't time out over long operations.

The second (probably more realistic) idea is to break the batch process into individual images. So if you have 40 images, process the first image, and outout a status page to the browser. This page serves as a status to the user and automatically launches the processing of image #2 via a META-REFRESH, etc... This is a bit of a hack (to me) and maybe a bit slower but will be very reliable in not ever timing out at the browser. It also takes care of the server time-out problem.

7) Server Infomation - it would be nice to have a listing of the IPTC functions along with the EXIF list.

8 ) Exhibition Groups - I suppose it's too late to suggest that you forego the idea of exhibition groups and instead be able to arrange the exhibitions heirarchically. For each exhibition, you set its parent exhibition (or none) and that's it. One field. To emulate the current groups idea, you just make an exhibition with no photos. Visually, if an exhibition has child-exhibitions, you can display the children just below the title like the categories in the Google Directory. You'd just need to modify the list.php code to take into account that the gallery operator might want an exhibition with no photos, and forego the display of the "no images to display" section. Another advantage is that you can have infinite levels and from a PHP standpoint, there is only one page to code, list.php.

9) What's the "Optional password..." thing at the top of the news?

10) It'd be nice to be able to specify the location of the comments. I'd like it directly below the photo. Others might want it directly above the photo (same width as the photo) or under the title in a paragraph.

Okay, that's enough :)

Like I said, looks fantastic so far. Let me know if you want any local mods I make contributed back to you.
---
BenV

[BenV]

BenV wrote:
10) It'd be nice to be able to specify the location of the comments. I'd like it directly below the photo. Others might want it directly above the photo (same width as the photo) or under the title in a paragraph.

Above, I was talking about the photos' EXIF/IPTC comments, not site visitor comments.

---
BenV

[Pekka]

BenV wrote:
Okay, first off, I installed 1.22 last Monday. That was about an hour or two before I found the link to 1.3 out there. So I get 1.3 installed and tweaked like I want it and then you go and release 1.5 beta. So the upgrade train goes... :)

Second off, fantastic gallery. The idea of getting around safe-mode with FTP servers is pretty cool! These are a few suggestions:

Thanks! I'll reply to each suggestion in detail:

1) FTP servers & path setup - specify on the form what fields require the trailing slash and which do not. I know that most/all of them are in the manual but having them on the form would be MUCH faster.

Very good. Will be added.

2) Common Settings - be able to turn auto-refresh off by default.

Good one - those autorefreshes can be annoying if you don't need them at the moment.

3) Photo Editor - seems to always show "EMPTY DIRECTORY LISTING (wrong microthumb path?)" in the Select Filename select list even when the microthumb and thumb display correctly and the filename does in fact exist. Bug?

Will look into that.

4) Also, in the "Select photo:" select list, it would be helpful to add the filename to the display list. When I do a batch import and give all the photos the same generic title, the list becomes useless for selecting a photo. Of course, once I go in and make titles for each photo, the suggestion is moot. But then, by the time I have made titles I won't be using the photo editor any more anyway.

That is a good suggestion and I'll add it to 1.5 final todo list.

5) Commenting seems to always be on. Can it be turned off? A per-exhibition setting would probably be more flexible for everybody else though I need to turn them all off. A single config setting and one line of code at photo.php, line 2596 should do it.

Has been on my todo list.

6) This is the big suggestion from an implementation standpoint. In the UPLOAD TO DATABASE page, when processing a bunch of images, it seems really likely that the browser or the server is going to time out. If the browser times out it's not too much of a problem because the process will still finish, but if the server times out (on an ISP, this would be likely where they have strict script run-time and resource limits in place), this is a big problem. Since server and browser setting are so varied is seems like your asking for trouble in this area. In my case, both were timing out and I was limited to a few images at a time.

I have a couple suggestions for solving the browser problem. The first is to consistently dump status data to the browser making sure that PHP isn't buffering the output. You could do plain text output or you could do a fancy GIF progess bar using GIF frames delivered to the browser at the appropriate time. Since the browser will display a frame as soon as it is received, and since the browser will be getting periodic data, the page will look dynamic and won't time out over long operations.

The second (probably more realistic) idea is to break the batch process into individual images. So if you have 40 images, process the first image, and outout a status page to the browser. This page serves as a status to the user and automatically launches the processing of image #2 via a META-REFRESH, etc... This is a bit of a hack (to me) and maybe a bit slower but will be very reliable in not ever timing out at the browser. It also takes care of the server time-out problem.

To make long reply short: I have fought with browser timeouts when making EE Backup 1.0 and I tried all sorts of things, and all of what you wrote above. What now is in EE backup 1.05 is that it prints linefeeds while processing, the browser receives them but does not print them out (as in html standard) and result is that browser receives info during process and browser does not time out. I will add that same system to ftp.php soon.

7) Server Infomation - it would be nice to have a listing of the IPTC functions along with the EXIF list.

There are no actual IPTC functions, only one for reading it one for writing (which EE does not do). IPTC is read from getimagesize's extra info array using http://fi.php.net/manual/en/function.iptcparse.php

8 ) Exhibition Groups - I suppose it's too late to suggest that you forego the idea of exhibition groups and instead be able to arrange the exhibitions heirarchically. For each exhibition, you set its parent exhibition (or none) and that's it. One field. To emulate the current groups idea, you just make an exhibition with no photos. Visually, if an exhibition has child-exhibitions, you can display the children just below the title like the categories in the Google Directory. You'd just need to modify the list.php code to take into account that the gallery operator might want an exhibition with no photos, and forego the display of the "no images to display" section. Another advantage is that you can have infinite levels and from a PHP standpoint, there is only one page to code, list.php.

I thought long and hard about how to proceed with grouping and hierarchy. The system you see in EE now is only stage one. As EE is a true level 5 normalized relational database the existence of a group must not _require_ an exhibition. Creating and deleting exhibitions must be "free" of all ties to groups and creating and deleting groups must not affect any exhibitions. In other words, because all in EE is tied to direct "on-the-fly" formed SQL queries the relations must be free of artifical structures, otherwise there will be situations which may be impossible to cope (i.e exhibition 7 is child of child of exhibition 2 and when exhibition 2 is deleted there would be no reference to exhibition 7 in SQL viewpoint) and very confusing to edit and understand by a user.

What will come in later EE's is that I introduce "levels" which can hold exhibitions, texts, groups or even single photo thumbs if needed.

9) What's the "Optional password..." thing at the top of the news?

Some people have requested password input form for password protected exhibitions. That is that. I'll make showing it optional.

10) It'd be nice to be able to specify the location of the comments. I'd like it directly below the photo. Others might want it directly above the photo (same width as the photo) or under the title in a paragraph.

That would be pretty easy to do. But as always I think also of look and feel of the product, and how the interface will be "established" by viewers ("this is EE"). If everything is made to a choice then browsing very differently laid out EE galleries could become a major headache to visitors.

But I am thinking of a popup with camera data, that would refresh when you browser photos.


Like I said, looks fantastic so far. Let me know if you want any local mods I make contributed back to you.
---
BenV

Thanks - everything is apprecieated!

[iceman]

A few comments and qustions!

1. Likewise as above--great work

2. I also would like to be able to list the file name as the title on upload. It also would be nice to have an option to list the filename as an image attribute in order to make it easier for visitors to reference a particular image, sometimes I don't remember the title a gave to a image. It also would be nice to be able to search by file name.

3. The addition of groups is a very nice enhancement and one I have been looking forward to. It would be nice to have some microthumbs come up under the group description, this would balance to page with individual galleries.

4. When generating html output, what directory are the files created in? It would be nice to have a file browse button on the html export box so that you can direct the html output to any file folder you like.

5. In the export to html page, when asked if you want to include the image files, does that mean all sizes of the image are exported, or only the default images?
It would be nice to have the option.

Thanks,
Dennis

[Pekka]

iceman wrote:

3. The addition of groups is a very nice enhancement and one I have been looking forward to. It would be nice to have some microthumbs come up under the group description, this would balance to page with individual galleries.

This is being done.

4. When generating html output, what directory are the files created in? It would be nice to have a file browse button on the html export box so that you can direct the html output to any file folder you like.

There is "Export folder:" input field and if you don't type anything to it the export goes to /gallery/export/html/

If you type there e.g. mynewstuff then it goes to

/gallery/export/mynewstuff/

5. In the export to html page, when asked if you want to include the image files, does that mean all sizes of the image are exported, or only the default images?
It would be nice to have the option.


Those photo/style on/off switches are for situation when you need only the html pages and will copy rest by hand (to save e.g. download time when doing different variations of a same exhibition).

[iceman]

Thanks for the reply Pekka.

Also, when I assign several exhibits into a group, the other exhibits that haven't been assigned to a group disappear from the index page. Once you start using groups, do all exhibits than have to be in a group list in order to be displayed on the index page?

Thanks

[Pekka]

iceman wrote:
Thanks for the reply Pekka.

Also, when I assign several exhibits into a group, the other exhibits that haven't been assigned to a group disappear from the index page. Once you start using groups, do all exhibits than have to be in a group list in order to be displayed on the index page?

Thanks

Now it is so that:

- when you assign any exhibition to a group, the group system activates (you see a group index page).

- when group system is active, those groups which do not belong to any group will be accessible only from exhibition menu in exhibition browser page. This is why it is good to have one group which holds all the exhibitions, to avoid confusion and also the situation when only exhibition in only group is password protected you can not get into exhibition browser to view public exhibitions.

These things are not cast in stone - for example I can add automatic "all exhibitions" group when first exhibition is assigned to first group. Also, there could be a "browse all" link to exhibition browser on front page. I could also make all "rogue" exhibitions (not in groups) hidden if needed.

[BenV]

Pekka wrote:
3) Photo Editor - seems to always show "EMPTY DIRECTORY LISTING (wrong microthumb path?)" in the Select Filename select list even when the microthumb and thumb display correctly and the filename does in fact exist. Bug?

Will look into that.


I looked into it and narrowed it down to the ee_checkthumb() function but didn't have time to find it.


6) This is the big suggestion from an implementation standpoint. In the UPLOAD TO DATABASE page, when processing a bunch of images, it seems really likely that the browser or the server is going to time out. ... (self-censured)

To make long reply short: I have fought with browser timeouts when making EE Backup 1.0 and I tried all sorts of things, and all of what you wrote above. What now is in EE backup 1.05 is that it prints linefeeds while processing, the browser receives them but does not print them out (as in html standard) and result is that browser receives info during process and browser does not time out. I will add that same system to ftp.php soon.
My concern still would apply to ISPs that don't allow PHP overrides in .htaccess files. I mention this because I noticed that you were playing with .htaccess directives (namely, php_value max_execution_time 1800) in the main/ and input/ dirs but a lot of users won't be able to use this feature. I run the server that I am on but most people aren't so lucky.


8 ) Exhibition Groups - I suppose it's too late to suggest that you forego the idea of exhibition groups and instead be able to arrange the exhibitions heirarchically. ... (self-censured).

I thought long and hard about how to proceed with grouping and hierarchy. The system you see in EE now is only stage one. As EE is a true level 5 normalized relational database the existence of a group must not _require_ an exhibition. Creating and deleting exhibitions must be "free" of all ties to groups and creating and deleting groups must not affect any exhibitions. In other words, because all in EE is tied to direct "on-the-fly" formed SQL queries the relations must be free of artifical structures, otherwise there will be situations which may be impossible to cope (i.e exhibition 7 is child of child of exhibition 2 and when exhibition 2 is deleted there would be no reference to exhibition 7 in SQL viewpoint) and very confusing to edit and understand by a user.

What will come in later EE's is that I introduce "levels" which can hold exhibitions, texts, groups or even single photo thumbs if needed.

Obviously there's no right way to do it but I'd vote that in this case the benefits of strict level 5 normalization are largely only realized by the developer, not the user. It's our job to sheild the user from these issues and there are pretty good ways of presenting an heirarchy management interface and resolving any orphan issues. One decent but simple interface I've seen is in Coppermine. Granted, I don't expect to change your mind - it's your design not mine - I just wanted to toss the suggestion out there.

10) It'd be nice to be able to specify the location of the comments. I'd like it directly below the photo. Others might want it directly above the photo (same width as the photo) or under the title in a paragraph.

That would be pretty easy to do. But as always I think also of look and feel of the product, and how the interface will be "established" by viewers ("this is EE"). If everything is made to a choice then browsing very differently laid out EE galleries could become a major headache to visitors.
I take more of the abstract approach like pMachine handles it. They have a ton of documented variables and function wigets (so to speak) that the user uses to construct a page. For example, you'd have variables for $ee_url_to_home, $ee_url_to_exhibition, $ee_photo_title, $ee_photo_caption, $ee_photo_owner, $ee_photo_width, etc ... and functions like ee_thumblist(count, offset), ee_commentform(), ee_searchform(), etc ...

The site owner uses all these to construct the page but obviously, you'd distribute a default set of templates with the product and most users wouldn't stray too far from the established look.

This would just make it easier to integrate the exhibitions into another site. For example, washingtonpost.com Camera Works.

---
BenV

[Peter Pan]

Pekka, I don't know if you see thta post, I'll copy/paste it here because it seems like the right thread :

What would be great would be if we could create an exhibition that would dynamically show the latest additions in all others exhibitions (like the last 10 photos added, regardless of where they actually are).

[daddy0]

I find it quite hard to manage localized texts for Exhibitions and Photos. Unfortunately I can't tell you a better solution than current but I'd like to see some improvement.

Current solution is propably driving me towards to use only one language.

Mikko

[Pekka]

daddy0 wrote:
I find it quite hard to manage localized texts for Exhibitions and Photos. Unfortunately I can't tell you a better solution than current but I'd like to see some improvement.

Current solution is propably driving me towards to use only one language.

Mikko

Having multiple languages means you "have" to input data for all languages equally.

There is going to be an utility to copy fields from one language to another as a "filled" data for those who need only public user interface translation and not actual photo etc. data.

If you find it difficult to change between languages in editor then why not open two browser windows, one for each language?

Of course I'd love to hear what specific problems you have.

[Pekka]

Peter Pan wrote:
Pekka, I don't know if you see thta post, I'll copy/paste it here because it seems like the right thread :

What would be great would be if we could create an exhibition that would dynamically show the latest additions in all others exhibitions (like the last 10 photos added, regardless of where they actually are).

This is on todo list.

[daddy0]

Pekka wrote:
daddy0 wrote:
I find it quite hard to manage localized texts for Exhibitions and Photos. Unfortunately I can't tell you a better solution than current but I'd like to see some improvement.

Current solution is propably driving me towards to use only one language.

Mikko

Having multiple languages means you "have" to input data for all languages equally.

There is going to be an utility to copy fields from one language to another as a "filled" data for those who need only public user interface translation and not actual photo etc. data.

If you find it difficult to change between languages in editor then why not open two browser windows, one for each language?

Of course I'd love to hear what specific problems you have.



My main problem is that adding photos is really slow when I want to use multiple languages. Also there is no easy (fast) way to check that I have remembered to fill all the fields in all languages in use.

TomKa suggested me to make a two column (actually three because we need to have some key to actual photo) text file having same fields for two languages side-by-side. List could be edited on normal texteditor. After editing it the list could be imported back to EE. I think this might be even easier to implement like the localized country name list on EE. Pekka, what do you think?

Mikko

[TomKa]

This weekend we will start with the italian translation of the public user interface, and then the german version.
I can put all the strings in an Excel table, one column for every language with a reference to the filename and maybe also the line number.

Editing a multlingual exhibit needs a bit of work, that's right. What do you think about a combination of the EE-backup utility and a tool to edit the SQL-table. At first i feed the pictures to EE, after that i extract the relevant data from the sql database, fill in my multilingual strings and put them back into the database with EE-backup. This is only an idea, I don't know if this is practical programming solution.

But I can also live with the actual solution, for me it's ok.

[daddy0]

TomKa wrote:
Editing a multlingual exhibit needs a bit of work, that's right. What do you think about a combination of the EE-backup utility and a tool to edit the SQL-table. At first i feed the pictures to EE, after that i extract the relevant data from the sql database, fill in my multilingual strings and put them back into the database with EE-backup. This is only an idea, I don't know if this is practical programming solution.

But I can also live with the actual solution, for me it's ok.

I think your idea is less practical than implementing same feature internally on EE (like country name editor). If Pekka is not interested to implement it your solution is the second one to consider.

Also I can live with current solution but some improvement wouldn't be bad.

Mikko

[iceman]

Pekka,

I may have seen this suggestion for EE1.5 before, but, thought I would mention it again.

Some visitors want to see the detail camera data and others don't, it would be nice to have an option on each individual image display to either hold a mouse over the image or select a button to see a popup of this info.

Thanks

[gillyworld]

Pekka,

Apologies if this has been suggested elsewhere (or is a feature I havn't discovered yet!) but it would be nice when uploading to be able to specify ALL pictures in a directory rather than each picture individually. I know an alternative would be to use an ftp program to upload to the temp directory.

Keep up the good work

Alan