Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

HueDecide: A lecture voting system augmented by IoT


Published on

Jahangir Alom

Published in: Education
  • Login to see the comments

  • Be the first to like this

HueDecide: A lecture voting system augmented by IoT

  1. 1. FINAL YEAR PROJECT: HUE DECIDE By Jahangir Alom Supervisor: Dr Martin Chapman
  2. 2. BACKGROUND • In a lecture, students will not always understand the topic being discussed or will feel the lecturer is going too fast • Many students will feel intimidated in a large lecture hall with many other students • Therefore they will not feel inclined to stop the lecturer and ask them to clarify
  3. 3. MOTIVATION • Gather student feedback on a topic • Make use of an app & website so students can do this quickly • Useful visualisation of this feedback so lecturer can quickly get an idea of the general consensus
  4. 4. PROBLEMS • Don’t want to interrupt the lecture for too long • Text based feedback would be disruptive to lecture flow and opens possibility of trolling • Motivate students to participate by providing them with convenience
  5. 5. PROPOSED SOLUTION • Binary voting system provided via app & website • Using Philips Hue Bridge + Bulb • Bulb will visualise results of vote as a colour in a range • Red being negative,Yellow neutral and Green positive • Workings of solution (vote processing, connecting to bridge) should be as transparent as possible • Two distinct users – Student and Lecturer • Session created for each lecture
  6. 6. PHILIPS HUE • Lecturer connects to bridge using app • Bulbs are connected to the bridge • App can be used to provide values to the bridge will be translated to colours as displayed on the bulb
  7. 7. DESIGN – WIREFRAMES • Wireframes were developed for each proposed page • Intention was to create a simple UI and navigation system whereby both sets of users will do what they need to do with little effort • From right to left we have the start page, current session page and voting page
  8. 8. DESIGN – VOTE PROCESSING • Color range in focus for this project is red, yellow and green • From the table this will lie between 0 and 25500
  10. 10. FUNCTIONAL REQUIREMENTS • Database & API – Tables for users and sessions, queries to retrieve data etc. • LecturerWork Flow – Related to what the lecturer can do in the app and website • StudentWork Flow – Related to what the student can do in the app and website
  11. 11. NON-FUNCTIONAL REQUIREMENTS • Usability • Performance • Maintainability – e.g. Structured code • Testing • Security
  12. 12. IMPLEMENTATION Cloud/Server side code Application Website
  13. 13. STUDENT FLOW – SESSION SEARCH • Student will automatically search for active sessions • Found sessions will be listed along with details • Student selects session to initiate connection • Must enter correct session code in order to connect
  14. 14. STUDENT FLOW – VOTE • Two buttons • Positive vote (Understood) • Negative vote (Not understood • Concurrency achieved using atomic method on database data • Buttons disabled for short time to prevent spamming
  15. 15. LECTURER FLOW – BRIDGE SEARCH • Lecturer will automatically search for bridges • Found bridges displayed • Select bridge and press push link to authenticate • If session exists, navigate to this session page • Else navigate to session creation page
  16. 16. LECTURER FLOW – SESSION CREATION • Lecturer enters details of the session such as session name, date etc. • Certain fields such as bridge IP and Mac are already filled in • Triggers before save function on server side code • Checks if session with this name already exists, in which case it returns an error message. • Else it initialises the session with a 5 character session code generated from a domain of letters and numbers.
  17. 17. LECTURER FLOW – DASHBOARD (1) • Page which controls Hue • Invokes algorithm which converts votes into a hue value passable to the bridge • This value will be translated into a colour displayed by the bulb • Hue value will lie between 0 – 18000, with 0 being red, 9000 being yellow/amber and 18000 being green
  18. 18. LECTURER FLOW – DASHBOARD (2) • Conversion done by taking negative and positive votes from the database and summing them • The max range (18000) is the divided by this sum in order to give a weight of each vote • This will depend on heavily on how many students are participating in the current vote. • The more number of votes, the lesser the weight of each one.
  19. 19. LECTURER FLOW – DASHBOARD (3) • This weight is then multiplied with the total number of positive votes, thus giving the final hue value • Special case : If no votes have been currently placed then the hue value will default to 9000 as opposed to 0 which the algorithm would result in otherwise
  20. 20. EXAMPLE HUE VALUES • Session just started. Positive and Negative votes = 0, thereforeTotal = 0; Hue value would be 9000 because of if statement. • Positive votes = 18, Negative votes = 12, withTotal = 30. Hue value would be 10800 via the calculation, therefore bulb would lean towards a greenish colour. • Positive votes = 0, Negative votes = 8, withTotal = 10.Via the ratio and positive vote value, the hue value would be 0, ensuring the value does not go below 0.
  21. 21. CLOUD JOBS • Cloud functions which run on a regular basis via Heroku • deactivateSessions : Function which runs every hour. Deactivates all sessions which have been running for more than 4 hours. • DeleteExpiredSessions : Runs every 24 hours. Destroys all sessions which are deactivated. • Both effectively clean up the sessions table
  22. 22. LIMITATIONS • Verify that user is a lecturer • Functionality for lecturer on the website • Session search not constrained to location etc.
  23. 23. FUTURE WORK • Expand to other universities • Implement location based search e.g. based on campuses • Archive results • Better design