Challenge Overview

Welcome to the Rails Web App Development - Multi-part Watermarking App challenge!  HP’s Link Technology API allows for the hyperlinking of printed content through watermarks.  They have developed a scanning technology which can detect these watermarks on printed materials like catalogs, postcards, or business cards, and provide the functionality to navigate to associated digital content on a mobile device. For more information about HP Link Technology you should familiarize yourself with the features, API and the mobile LinkReader scanning app at https://www.linkcreationstudio.com and you can watch a video here.

We’ve completed developing the user interfaces for this Multipart Watermarking App -- the prototype code is attached to this challenge.  And we’ve also developed a basic Ruby on Rails web app that saves Projects, Images, and Regions to a local MySQL database.  The Rails app also makes a series a REST API calls to the Link API platform to initialize Triggers, Payoffs, and Watermarks.  It is these API calls that allow the LinkReader scanning app to read the “hyperlinks” in printed material or in images on the screen.  In this challenge,  we’re going to be tying the pieces all together and connecting the front-end development we’ve completed to the Rails web application.

Here are the detailed requirements:

  1. landing.html - We should make this the default landing page of the Rails Web Application.  Currently that is the /login action.

  2. sign-in.html -  Clicking the “Sign in” button should call the /login action in the Rails web application.  

  3. create-account.html - Users clicking the submit button on the create account page should call the /signup action in the Rails web application.

  4. dashboard.html - After logging in we should redirect users to this page. This page requires a new controller action. add a route and ‘dashboard’ action in the projects_controller.rb, and a view app/views/projects/dashboard.html.erb.  The last 4 projects opened by the user, and the last 4 images modified by the user should be displayed in each area. Clicking on a recently viewed image should open the /projects/:proj_id/images/:id/edit route

  5. my-projects.html - should display the results of the  /projects#index action, and be implemented in the app/views/projects/index.html.erb.   Do Not Implement filtering on the projects#index view, omit the ‘Filter Projects’ button. Add a button to ‘Create New Project’ to the right of the Delete Project button.

  6. Delete Project Button should show a confirmation pop-up and call projects#destroy

  7. create-new-project.html - implement this form in /app/views/projects/_form.html.erb. the fields on this page correspond to the Projects model.  When the user clicks submit the system should execute the /project#create action (as is already implemented in projects controller and view).

  8. edit-project.html - If you do the preceding step, this view will be implemented properly, as it uses the _form.html.erb. When the user clicks submit the app will be executing the /project#update action.

  9. project-details.html - This screen is generated by the view /app/views/projects/show.html.erb - use partials for some of the content (image row, payoff row, etc.), as it can be useful in other views. You may need to update the projects_controller#show action to load images and payoffs into instance variables.  Note that you will need to show the images tab initially. The Images tab shows a list of the images in the project, and the payoff tab shows a list of the payoffs and in the project.   Each payoff link in the destination column of the payoff library should actually hyperlink to the target page.  Clicking the edit button (the pencil) should allow users to update the hyperlink and/or change the payoff name.  In the images tab, each image row should list the Regions defined for that image. Each Region name should have a tooltip that displays the payoff url.   Do Not Implement filtering on the project details page.

  10. images-editor.html - Implemented in app/views/images/_form.html.erb. This screen is the real heart of the application.  There is a lot going on here.   Here are the functions that you should implement: Note: image model attributes are name, description, original, final, etc… and regions, as shown in the diagram  below.

    1. By default the Image Editor should show the existing images associated with the project in the left panel:  /projects/:proj_id/images/#index

    2. If opened for a specific image (:id) that image should be loaded in the editor view.   For example, if a user clicks an image on the my-project.html page from the image list, the app should load the image and the associated data for that image into the editor.

    3. The edit button (the pencil icon) associated to a particular image in the left column of the image editor should allow users to update the Name and Description of the image.

    4. Add Image Button - Allow users to add images to a project -- corresponds to the /projects/:proj_id/images/new route.   Interface should allow users to enter a name and description of an image.  The current prototype hasn’t implemented this feature currently.

    5. Delete Image - Allow users to remove images from a project -- corresponds to the /projects/:proj_id/images/:id DELETE action -- should include a pop-up confirmation.

    6. Show/Hide Regions button - on the selected image, highlight regions.

    7. Add Region Button - Give functionality to add a Region to the image: Required - never allow overlapping regions.

    8. Region List / Edit - Show region form  (app/views/regions/_form.html.erb)  as well as allowing in-image resizing. Always confirm updates result in no overlapping regions in the image. To edit Regions for an image: /images/:image_id/regions/:id/edit and/images/:image_id/regions/:id/ update to save the actual changes

    9. Region List / Delete - Provide functionality to delete a region from an image: /images/:image_id/regions/:id/delete

    10. Preview Watermarked Image Button - calls the download route (projects/:project_id/images/:id/download) and displays the result in the browser.

    11. Download button - downloads the image using the download route.

    12. Print - Directly prints the ‘downloaded’ image. This means requesting the same route as the previous step above but providing it in a print window.

    13. One business rule that hasn’t been implemented yet in the current image editor is that the minimum region size is 300x300 pixels.  Enforce this restriction by simply creating that size box to start with on the region editing screen and not allow users to minimize the dimensions beneath that threshold.

A description of the Rails application paths created can be found in the Rails Setup challenge.

Build and deployment instructions for the Rails Application can be found in the attached deployment.txt file.  You should use Ruby 2.1.x and Rails 4.x in order to build and deploy the application locally.  The Readme.md file contains the exact system requirements for the challenge.

There are four attachments to this challenge:

  1. Diagram of the Data Model of the app
  2. The prototype code for the web application - prototype.zip
  3. The code from the Rails Setup Challenge which configured a basic Rails Web Application - multimark-master.zip.
  4. Readme.md file which describes the deployment steps for the Rails Web App.
     


 



Final Submission Guidelines

  • - Your solution should use the previously develop ruby, javascript, css, html code as a starting point.  That code can be found attached as the code.zip file attached to Code Documents forum for this challenge.
  • - You are strongly encouraged to ask question is the forums about any technical decisions or issues with the app.  We're fortunate to have a very engaged (and technically savvy) customer for this application.
  • - You should use Ruby 2.1.x and Rails 4.x.  The current version of the ImageMagick gem depends upon this version of Ruby.
  • - Your complete Ruby on Rails project including your source code and gems upon which your code depends.
  • - Provide instructions on how to build and deploy your code.
  • - Documentation of your solution 
  • - The URL of your web application if it is public (optional)

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30051066