450481 in/out web-based program for photos

Project Overview The public (customer) will visit our website and upload one or more photos. We will be alerted. We (our artists) will improve and retouch these photos, then repost them to the website. The customer will then be alerted their photo(s) is done. Extended Project Scope, Needs and Desires 1. No graphical creative needed. We will be skinning the entire website/interface ourselves. But you will be expected to use rough images so we can replace them where needed. We can provide these. 2. Initially, this will be a service provided for the customers of one large company (our client – we'll call them Big Company). Thus, their customers can freely visit the website and use us. If someone from the general public stumbles in, they can use us too. This is because our work, the site, and the emails surrounding it will be branded with the Big Company's name and they stand a chance to earn this person's future business. However, in the future, we may need to restrict this free use. We plan to accomplish this with entry codes. We would maintain a master list of entry codes. We could set them for single use, or unlimited use. Unlimited use codes would likely be given to many people. Codes should also be able to be dated so they expire. Tracking of used codes will be noted later. This element of the project might be considered a future add-on. It may be able to be completed stand-alone later. For example, when a person goes to submit a photo, they must enter this code or their upload will not work. 3. When customer first visits the site to upload a photo, they will also be required to provide basic personal details (name, address, phone, description). At this point, they should also be required to create their account username and password. Their first project will go under this account, as would any future project. The system will also attach a unique account number to their account for use later. Under the upload area will be a note saying “already have an account? Log in before you upload”. 4. Once they are logged in, they will see a basic dashboard. This dashboard will allow them to update their personal data, update the description of any pending project, view pending product status, and to view any completely project. 5. Flow – they arrive at the site and are instantly able to browse and select up to three images to upload. Upon clicking “next” – they are taken to the data-capture page where they provide their details, then press an “upload now” button. However, if they are an existing customer, they'd log in prior to upload as noted above. 6. In addition to providing their personal information, they'll be asked to choose a category for their image. For example: pets, boats, cars, houses. Their submission will further be tagged with this data for later use. 7. Our notification - upon their successful submission, we are alerted by email we have a new project. In this email will be a link(s) directly to the images they've uploaded. There will also be the description of the project they entered in the email. However, no other personally identifiable information will be in the email. Thus, to the person who receives this request and is to do the work, they will not ever have any connection or way to see who it is for. If the project is tagged “pets”, it will go to one email address. If it is tagged “houses”, it will go to another email address. We need the ability to add/remove the categories and also define what email addresses they go to. 8. Customer uploaded image renaming – when they created their account, the system defined and created a unique customer number for them. They will be uploading photos direct from their machines with all different styles of naming. Our system needs to rename any photos they upload, as they are being uploaded – and add their unique customer number to the beginning of the photo. For instance, they might upload two photos named [login to view URL] and EXP0009.jpg. Our system would rename them [login to view URL] and 100001-0002.jpg. 100001 would be their customer number, and -0001 would be numbered automatically as they upload, automatically choosing the next unused number available. 9. Our re-upload of completed photos – when our artist completes their photos, we need a way for them to re-upload them into the system for the retrieval by the customer. Our artists will likely manually rename the finals [login to view URL] and [login to view URL], with the prefix “rev1-“ signifying it is a completed photo. We want a single portal/place for artists to upload these completed photos. When they do, the system automatically files them so only customer number 100001 can see these particular photos. 10. Notification to customers of completed photos – once a completed photo has been re-uploaded by an artist, the customer should receive an email that their photo is complete. This email will simply instruct then that it's done, and to click a link in the email to view it. When they click the link, they should be able to visit a special page with the completed photo WITHOUT having to log in. If at that point, they want to request revisions, or update their account details, only then would they be required to login. 11. (this is not a mandatory requirement) Quality control sandbox – injected into the steps just above, rather than the act of an artist uploading a completed project being the trigger to alert the customer it is done – we'd like the ability to review the artist's work first. Thus, when an artist uploads a completed photo – WE are notified by email and can click a link to view it. When we do this, we see buttons for “approve” or “deny”. If we approve – that's the trigger for the customer to be notified. If we deny, we can enter a note to the artist and an email is dispatched to them to improve their work. The email would contain links to the original and final image they worked on. Here, we need to address the naming of these files flagged by us in reference to file overwriting (noted below). This functionality might be tied to the “request revisions” tool, also noted below. Removal of sandbox – at some future point, we may choose to remove the sandbox altogether. Or, since we know which artists get which categories of work, perhaps we remove the sandbox for some who have shown consistently good work, but leave the sandbox in play for others. 12. File overwriting – the customer may upload a photo, then decide to swap it for another prior to use working on it – and it may be named the same as the original. Or it may be a mistake on their part. Likewise, our artists may make an error and name an image the same as one which already exists. To prevent this, no overwriting should be possible. The system should alert the user/artist to try again or automatically rename images by appending the image name. 13. The page the customer sees when they visit the site to see completed photos – on this page, the main focus will be on the completed photo. But also present on the page will be the corresponding original. They will be labeled “after” and “before” respectively. There will be two buttons present: print and request revisions. If we have done more than one completed photo, then there will be matched pairs down the page. For instance, going down would be after 1, before 1, after 2, before 2, etc. The “print” and “request revisions” buttons would apply to the “1” set, then a second set of buttons would apply to the “2” set, etc. They can thus print each set individually. But if there is more than one set for them, also present on the page would be a “print all”. 14. When they press the “print” button next to any set (or a “print all”), it would print the after/before pictures on a clean page with minimal other elements from the webpage it appears on. So perhaps a template would be designed for the printing. 15. Revisions – if the customer presses the “request revisions” button next to any photo, it opens a dialog box where they can enter a description of the revisions. Our guess is that this will utilize the same functionality already existing in the system. Our designer will get an email notification exactly like the original. Except, the description/subject will include the notes on revisions, and the link(s) to the photo will be a link to BOTH the original and also the “rev1” versions – which was the first final presented to the customer. As noted above in a possible quality control sandbox and with file renaming, perhaps whether we (quality control) or the customer requests a revision, the policy is that photos are automatically renamed rev1, rev2, rev3, etc. 16. Limiting revisions – customer is allowed to request just one revision on a first final. If they have done this and are viewing the revision, it's assumed the “print” and “request revisions” button would still be present. Clicking “request revisions” on a first revision would throw up a dialog or pop-up box that says “sorry, you have exceeded the max number of revisions. Contact us for details (link). Here, they can visit a page and email us to complain they want yet another revision. Some admin would get this email. Within their customer account (as viewed from our admin side), a value of 1 would be present somewhere. We would have access to change this to 2 (or 3, 4, etc.) per our discretion. That would allow them to press the “revision” button as usual a few more times. 17. Notification to customer of completed revision – the artist will manually rename the image “rev2-etc” and upload it back to the system as before. Then here, the system will notify the customer as before. However, this time a subject line or note in the email should say “revised” or include something else to denote it's a revision and not the first final. 18. Our master control panel – we alone will have access. This area will allow us to view: • Total number of requests pending (meaning photos uploaded which have not been completed and re-uploaded by an artist, which would automatically mark it as complete). • Total number of requests completed. • Entry codes used, and details on them and ways to update then. For instance, we can create new codes, change/set expiration dates on codes, and change the number of uses for codes. • Customer records – we will need a way to view and sort all customer details. We will be marketing to these people. Thus, we need a way to keep track, sort, and/or flag/mark customers. For instance, if we've already exported their data once, we will need a way to denote this so we don't export it again in the future. • Advanced dissemination of customer data – name, address, phone, email, project description, category – based on these collected fields, it will classify each person differently. As such, their personal details will be sent to different people for follow up. Ideally, this will happen in real time. Similar to how we funnel projects from different categories to different email addresses/artists – depending on the customer information (perhaps using address, category or description) their personal details will be emailed to the party best able to further service them. The trigger for the dissemination of their details will be the upload of the final art (the first time regardless of whether future revisions are done) which marks their first project as complete. So when the system marks it as complete, their data is bundled by email and sent to a third-party. Initially, it may all go to one party. But in the future, all requests from certain ZIP codes and within certain categories will go to email recipient A, and requests from other ZIP codes and within certain categories will go to recipient B.