MicrostockGroup
Agency Based Discussion => Sites that no longer exist => Zymmetrical.com => Topic started by: zymmetricaldotcom on May 20, 2009, 16:23
-
We have been hard at work for the last while preparing the end to 'FTP synch' and the related chores associated with the FTP uploads. We have always known that it is expected that when you FTP, it should show up on the website, period. This is ready to go, but I thought I would run it by the gang here and see if we are missing anything..
It is kind of ironic because we just added a graphical 'FTP Folders' option last week to be able to view and delete erroneous uploads - but this was really just a band-aid solution. In the new way, you simply FTP files, and the moment the system detects each file upload is finished, it goes into action.
The tricky part: we accept raster .JPG graphics, .EPS vector graphics, and .JPG raster + .EPS vector graphics. It is no problem to generate .JPG's from the .EPS's automatically, but the last option is there to enable people to take advantage of the IPTC keywords embedded in the .JPG's- most designers are already set up with their portfolio keyworded in the .JPG's.
Problem 1: Zipping the .JPG and .EPS together is an annoyance
Problem 2: If the 2 matching files aren't coming in at the same time, then you need some kind of lag to enable the system to match up the uploads. Someone could upload 500 .EPS and 500 matching .JPG, but they wouldn't be uploaded instantly together of course.
So, the current gameplan for what happens when you upload into the following two FTP folders:
(http://www.zymmetrical.com/images/stock-photo-forum-pictures/ftp-workflow.jpg)
Yes it looks complex but the short and skinny of it is - you will be able to upload raster-only, or vector-only, or both together. Uploading into the /Graphics folder will introduce a 12 hour delay, to allow for the alternate format to be uploaded. If, after 12 hours, there is no matching file (goes by base filename, MyGraphic.jpg <> MyGraphic.eps), then it simply pushes the file onto the Describe area.
Any feedback is appreciated- but make it quick because annoying our valued designers with more delays is not fun!
-
Why is zipping so annoying? A step more, I agree, but it seems a simpler solution.
-
I am sure there is some utility out there that can do batch file zipping by rules, I just have not encountered it yet. We could program something ourselves but creating systems for the web and creating systems for Mac and PC desktops is a whole different ballgame.
There is also the likelihood that as a manual chore, many designers already as part of their workflow .ZIP the two formats together due to the existing requirements of agencies.
In any case, it is just as easy for our system programatically open up a .ZIP or .SIT file and see if there is a .JPG and/or an .EPS within, as it is to just process the raw files separately. Easier in fact since there is no time delay between the sub-files. It would just be another branch on that flowchart. Short of any identified method for people to batch-zip files however, it seems really inconvenient to force this as a rule. Requiring any operation that needs manual clicking for hundreds of files when there is an automated alternative is just a waste of everyone's time.
Yes .EPS compresses nicely but I don't think many of us are really that desperate on the bandwidth resources - people should just be designing, and auto-FTP
'ing the content in each night.
Anyhoo - thanks for the feedback I guess there should be an option for people who already have the content zipped together.
-
Windows allows to create zipped folders directly. Why not let users store more than one .eps/.jpg pair in a single zip file? Then the user just creates a zip archive in Windows explorer and simply drags all his .eps/.jpg files into it.
(I guess there is something similar for Macs, but I haven't checked).
-
That is probably a practical solution.. from the tech geek side of things though, there's a few concerns with making just one big .ZIP of a graphics batch:
- even though our FTP server supports resuming interrupted downloads, sending a 3 GB .ZIP file is probably going to be more prone to errors due to internet hiccups and such. Sending many smaller files individually adds overhead and a bit of upload time, but i've always found with any kind of file transfers it's better to make it short and sweet rather than trying to upload your whole portfolio in one transfer.
- unzipping huge files is not really a problem on desktops, but on web servers it's a pretty big performance hit when the file sizes are big
There's only one way to find out whether my initial paranoia about this is valid, and that's to test it out and run some numbers.. :)
-
I think it's great that you are trying to avoid zipping of the files. The algorithm makes sense and 12 hours is certainly reasonable and in the same time not too long a delay. Have you thought of accepting SVGs as well?
-
SVG is cool because it's XML-based and completely flexible.. i'm sure it's the successor to .EPS. For now we don't have a business case to add the format as an extra buyer option. Converting uploads from SVG to EPS in the submissions process could be implemented easily though, if there's a demand for it.