CSC-342 Client Side Design Team Preliminary Design Document: People's Consultants

Team manager: Darius Luchian Other team members: Ryan Mass, Tyler Atwell

Brief description of overall design concept:

- Flat Design - Clean and functional, with little bloating - Accessibility and UX take priority - Designed as desktop-first, non-responsive - Fully modular front-end - Front-facing single-project homepage - Overall goal -> funnel visitors to donation form - Relevant Search Engine Optimization - Social Network integration for greater visibility (Fb, Twitter, G+) - Maintain compatibility with at least IE8 - Target browsers: Firefox, GChrome, Safari, Opera, IE8+ - Content management capabilities - Stripe and/or Recurly for payment processing.

We will be using a custom front-end framework based off Bootstrap 2.x, with elements from Bootstrap 3.0 and Foundation 4.

Description of site structure:

Root will be the homepage of the currently active project (only one project may be the active one at any given time). Each individual project will have a root subfolder (eg. www.peoples-consultants.com/project2/), and will maintain the same basic layout as the main/active project. Administrators should be able to mark any of the projects as completed, active, cancelled, etc. All projects will be centralized on a Projects page. The multi-project system is to be implemented iff time permits, so initially we would want the infrastructure for a SINGLE project to be done, and then, if we have extra time, expand that to be able to run multiple projects.

Navigation: Main navbar will be fixed (will scroll with the page) on top of the page. Left-side navigation will be available for administration interfaces. Some pages will also feature a right- side "Get involved" widget containing a picture and/or short amount of text with a link to the appropriate action. In addition, should the user decide to rescale the browser and toy with its size, the navbar will gradually collapse into an icon that can be pressed and will thus drop down the navbar links. A footer will be employed that will contain a navigation structure similar to the navbar, Social Network connections, any extra information (eg. recent news, motto, terms of use, privacy policy).

Search: The navbar will contain an expandable search bar ( will redirect to a google search with the parameters "site:www.domain.com", "keyword").

Main Navbar -> Home, About Us, Our Projects, Get Involved, Search, User Login/ Registration Logged in users should be able to access specific menus from a drop-down on the navbar.

Other pages: Registration, Login, Admin Interface, User interface, Our Goals, Terms of Use, Privacy Policy, Donation page, Admin logs, Bios, Billing+Payments+Tax forms.

High-level description of features of the site requiring server-side processing

- User Login/Registration - User Authorization - Editing and retrieval capabilities on all items, text, image, video (which implies everything must be stored in the database, and must be accessible to mass-assignment) - Most pages will require pagination capabilities - E-mail newsletter and announcement capabilities - Billing and payments, tax forms

The features requiring custom functions: - The capability to dynamically edit the page SCSS files - The capability to dynamically alter the routes.rb file

Form validation will also be employed server-side.

High-level description of exclusively client-side, interactive features of the site: (e.g., Creative visual effects, drop-down menus, rollovers, etc.)

Some interactive features that will be employed are: Buttons, Drop-down menus, Carousels, Modals, Checkboxes, Drop-down selectors, Pagination, Alerts, Progress bars

Description of ways in which Ajax can be employed to get information from the server without refreshing the page. (This JavaScript-based technology will be the responsibility of your team.)

AJAX will not be employed at is opens up some security vulnerabilities and is deemed unnecessary for the purpose of our project.

If applicable, give a detailed description of required administrative features, as well as other levels of access with different capabilities.

All users should be able to register a new account using: Username, Password, Password Confirmation and E-mail. E-mail confirmation and/or reCAPTCHA should be used to prevent bot registrations. Temporary lockout after 5 attempts to prevent bruteforce attacks. Password recovery should also be employed for all users. STRONGLY recommend the gem Devise for user registration

Levels of access: - User - Donator -> can access extra information regarding donation/payment history - Collaborator -> should Dr. Clemens decide to give users restricted editing capabilities (eg. a student blogger or content editor). - Administrator -> full access to content / user editing capabilities / administrative options (eg. setting the current active project). - Developer -> full access, user spoofing capabilities for debugging purposes, CRON jobs (if needed) Recommend the gem CanCan for user authorization

Description of home page layout/design (including sketch/mock-up BELOW

@dluchian, 9/11/2013:1200ET