Social Viewer — Wrapup and Reflection
My name is Ben Meyer and I am a 2016 graduate of The College of New Jersey with degrees in both Interactive Multimedia and Computer Science. I love to do web design and development as it serves as a practical and creative purpose for learning otherwise dry programming skills. I’ve always liked working with computers and knew that in the future I would want to continue with that passion as a career. Since IMM focuses on design and CS focuses on development, it is only natural for me to take an interest in web development, which centers around both.
My senior thesis project for IMM highlights my interest in web development. My project, titled “Social Viewer” is a web-based platform that allows users to display a rotating stream of tweets that can be specified through parameters and search terms. These tweets can be displayed on a separate screen, such as a TV or projector, using different themes and designs. While this idea is not new, it’s execution and purpose is. Most of the free software that does similar functions is very limited in function and does not give the user much control. There is paid software that has many features and many customization options but can be expensive for one time events or small companies that need custom functionality. Social Viewer aims to solve that by providing an extendable platform for free that matches the functionality and flexibility of paid software. The final product was shown off at the annual IMM senior showcase, where seniors and sometimes other IMM students show off their thesis work and other projects to their peers and industry members.
The development of Social Viewer took place over three stages. I would definitely recommend this approach to anyone who would be taking on a similar project. The first was the planning stage. During this time I identified the major functionality that the platform would need to support. This included user accounts with different levels of access, multiple keywords and search terms, supporting multiple screens showing different tweets, and installing themes. Each group of search terms that dictate what tweets are to be display on a screen would be called a “stream” and Social Viewer would need to handle many of these streams for allowing different tweets on different connected displays. I also knew that I wanted to be able to stream tweets in real-time, which helped me to select the software needed to build the platform. Node.js, RethinkDB, and Socket.io are used to build the real-time functionality and PHP, HTML, JS, and CSS are used to build the interfaces.
The second stage of development was building the Social Viewer platform. This consisted of core functionality such as users, pulling tweets from Twitter, sorting them based on keywords, storing them in the database, and sending them to desired endpoints. In order to handle all of the functionality, Social Viewer is divided up into a client-server architecture. The server handles the connection with Twitter as well as all of the sorting of tweets before sending them to each client. The client only handles the actual displaying of the tweets and can run in any modern web browser. One of the issues that I ran into at this stage was a limitation of Twitter’s API. With one account, only one connection to Twitter is allowed at a time to pull in tweets based on keywords. My original design was to open a new connection on the server with Twitter for each stream that I wanted to create. Because of the limitation, I needed to group all streams into one connection and sort them out once they hit the Social Viewer platform. This introduces a bit more processing overhead but does allow for streams to share tweets if they match multiple search terms. This also brings up the question as to how much processing power is needed to run the platform. In testing, I was able to run the platform easily on Digital Ocean’s lowest level offering, which only comes with 512mb of RAM.
The third stage of development is where the extra features are added on. This was the easiest stage because the platform is designed to make it easy to add features, but the hardest stage to get to because the platform takes a long time to develop and make it correct. The features that I was able to implement for the spring show were moderation and themes. For moderation, tweets were sent to a main control panel instead of being shown directly onto a screen. A designated person can then scroll through and choose which tweets should be displayed on the screen. For the theme functionality, a user can build a theme in HTML, CSS, and JS and import a small JS library that connects to a Social Viewer server to pull in tweets that are sent over. This library also allows for a lost network connection so if the client gets disconnected from the server, the tweets can still loop on the screen. The major challenge at this part of the stage was getting the tweets to where they needed to be. This is where Socket.io shines. Socket.io is a javascript library for node.js and websites that allows you to pass data around in real-time. This means that I could pass data from the node.js processes to the user interfaces and database all using one form of communication and not having to use forms or periodically checking for new data. New data was instantly available as soon as it was needed. Many new features can be built on top of the platform, such as remote client controlling, automatic theme switching, and tweet scheduling.
If I had to do this project over again, there are a few things that I would do differently. First, while planning is very important, I got caught up in unnecessary details. How the interface is built may not matter as long as it works in a web browser. PHP, Ruby, or Node.js could all be used to build it, and each would be perfectly fine. As long as the end product will work, you use what you are the most comfortable with. There is no need to re-learn everything when under a tight schedule to finish a project. Another piece of advice would be to keep everything realistic. While planning out what features I would need to support for the Social Viewer platform, I kept thinking of obscure features that only a select few would want, but would take a long time to support and build. Trying to incorporate these features did not prove to be a valuable way to spend my time when there were other tasks that needed to be completed. My advice to to prioritize based on importance and how much time and effort is needed to implement. A few necessary and well thought out features is better than a bunch of small features that no one will use. At the same time, many small but important features are better than one big feature that won’t do much for the target group of users. A balance has to be found between importance and allotted time.
Overall, I am pleased with the final outcome of the project over the course of the semester and learned a lot about working with the specific technologies and project management. This was definitely a project that requires a lot of time for planning and development, which I was able to get with my thesis class.
