Skip to content

Architecture

Logan Heckle edited this page Oct 23, 2017 · 24 revisions

Model

Login/Admin

Description: The page the user/admin sees when clicking the login button

  • user name: String
  • user password: String
    • Admin login will use built-in Django admin page
  • user ID : int
  • user e-mail : String
  • HTML/CSS
  • Login will be persistent utilizing certificates / cookies
    • These will expire after certain times, and will load dynamically on the page with a corresponding view. This is something most sites use for convenience and to not have to reload or create a page each time a different user logs in (i.e. amazon.com isn't amazon.com/######## for each different user logged in). User info will automatically be stored in separate database, to not mix the search data and the user's own credentials; fields will be as shown above, very simplistic

Since Django comes with a built-in resource for Web applications, and we will use Django to build the login page.

  1. Login page
  2. Logout page
  3. Sign up Page
  4. Password reset page : the template will set a password reset email to the user, provided with the text of HTML of the resetting link.

After we installed and configured all the built in default resources in Django, and configured the URL routes. Then create a sample login template; I am gonna use Python for the topic. Furthermore, We can discuss to customizing the login page with our client. Therefore, Login page is gonna be done with Django in Python, with some HTML template associate.

Search Bar

Description: The main focus and central functionality of the web app

  • input data: String
    • input data uses Google Standard
  • Advanced search features: radio boxes from expandable menu
    • Radio boxes to include:
      • Geolocation
      • Date/time filtering
      • Source filtering
  • Pulls from social media APIs (will utilize each API model, and output to API Controller)
  • Links to the user currently logged in, and Graph and Sentiment Analysis model (You can't search unless you're logged in; API controller data will filter to sentiment analysis and subsequent graph models)
  • Javascript

Line Graph

Description: A line graph depicting the sentiment analysis of the search results

  • Body
    • Utilization of jCanvas on the page to graph datasets retrieved from the API Controller
    • Links to user logged in, Search bar results
  • Json Django widget

Word Cloud

Description: A cloud of words displaying usage of specific words based on their relative size

  • results: String (formatted as image as well)
  • Links to Sentiment Analysis
  • Json/Django widget available?

Sentiment Analysis

Description: Analysis of the results pulled from the various social media APIs and run through Google Analytics

  • Display
  • Pulls from Google analytics
  • Links to Search Bar and User

Google Cloud Nature Language API has sentiment analysis, entity recognition, entity sentiment analysis and text annotations. We are gonna use the google technology for sentiment analysis.

A sentiment analysis is used to analyze a text string and classify it with the provide input string. Such as, you could analyze a input string post to determine whether it is positive or negative or sad, mad. Google has a Natural Language API application using Python code. In order to create a sentiment analysis, we need to complete blow requests:

  1. Collect Data : which is tweet entries
  2. Classify Data : labeling the data, assign labels to example tweet,such as, "sad","mad","excited","Boring",etc...
  3. Re-organize Data : we can able to use the Google Prediction API takes Classified data and format them as comma separated CVS files.
  4. Upload Data to google cloud Storage : update our organized CVS file to google cloud Storage
  5. Use google prediction API to make analysis of that data.

API Controller

Description: Organizes all of the retrieved data-sets from different social media queries into a unified data-set for more efficient usage and processing.

  • input : API datasets (this can be a part of this model rather than separate them into 5 different ones)
  • output : Unified dataset
  • links to sentiment analysis, Line Graph, Word Cloud, and Search Bar (filters search criteria to APIs search functions)

The unified dataset will merge irrelevant data like "likes", "happy reacts", "retweets", etc. into different counters of ints, since many of these reactions demonstrate relevance at a primal level and do not need to be separate entities for this project. Simply counting the number of interactions / views of posts gives enough information to suffice to demonstrate relevance; the rest of the common word associations will come from sentiment analysis to show how the parts of the important posts matter.

All models will be kept in Django's "Models" folder, and will store data in an off-set separate storage location that is TBD, but will most likely be a Google Cloud-based server

Views

Traditional Website / Application Navigations:

  • HTML Design View (Header/Template View)
    • Navigation Bar
    • Header w/ Logo
    • Login / Account
    • Body < div > Text (changes per page, but can be re-used as a template; home will just display a welcome)
  • Search Bar View (container for all search criteria)
    • Advanced Search Menu View
  • Sentiment Analysis / Results View (will display things differently, cannot use generic Body Text)
  • Line Graph View
  • Word Cloud View
  • FAQ View (can use Body Text)
  • Login Page View (specific fields for input data and POST submissions)
  • Reset Password View (field inputs)
  • Create Account View (field inputs)
  • Contact Us View (can use Body Text)
  • About Us View (can use Body Text)

URL Space