This document identifies the system flow of all information in the RocReadaR System.
All information starts at the RocReadaR Portal. There are 4 user types:
- Administrator
- Editor
- Publisher
- Advertiser
Administrators can create and edit any users. They are the "system admins".
Editors are the managers of the system, and create and manage Publishers and Advertisers.
Publishers are the main users of the system, and can manage their publications and media.
Advertisers are secondary users of the system. Currently they have no privileges, but in the future will be able to edit media after being provided access to it by publishers.
These can all be edited in the RocReadaR Portal on the Users page. Publishers fall into "Publisher Groups", which is a company or group in control of a publication. For example, there could be several Publisher users in the Publisher Group "Rochester Women". This group may have only one publication, "Rochester Women", or many publications.
The main flow from this involves a hierarchy of elements.
Publisher Groups can have 0 or more Publications
A Publication can have 0 or more Issues (like a monthly issue, like the July 2011 issue of People Magazine)
Issues can have 0 or more Pages. Not all pages a required to be in the system, only the pages with digital media. These require an image of the physical page for image recognition.
Pages can have 0 or more Media Elements. Media Elements have various types, like images, videos, or questionnaires, and can be overlayed on their page.
The RocReadaR Portal is designed to mimic this hierarchy. Publishers can access the Publications page, which shows the publications. From there, clicking on a publication takes them to the Issues page, showing the issues for that publication. Clicking on the Issues takes them to the pages page, showing all the pages in that issue. Finally, clicking on the page itself brings up an editor where the publisher can manage the media elements.
When Pages are made with their image recognition image, they are uploaded as Base64 strings to the Loopback Server. This then saves them as a local file. Then, the .wtc processing script is called to process them, producing a .wtc file. The bytes of the .wtc file are then saved in the database. The original image is also saved in the database.
When Media Elements are edited, they are also uploaded in Base64 strings, and all the data is stored in the Loopback Server. The database follows this same hierarchical structure.
From here, a RocReadaR Mobile App user scans an application. We have mocked the original API it uses, and the Loopback Server simply provides the related .wtc file and the original image. Future iterations of image recognition will require the App to upload a Base64 string of the current image. The image recognition script from the App will have to be copied into a remote method, where it will take the image and compare it to the .wtc file. If it is a success, it can send back information about the related media. f
After the app has recognized the image, the related media is displayed on the phone.