SPTV 2.0 Log

Written on May 10, 2016

I was hired to be the Web Master for SPTV in September of 2015. Our initial priorities had me look into setting up a form. Forms are normally easy to setup if you have a server and little Javascript knowledge. My thought going into the project was that this would be no problem. Later I would learn that SharePoint uses in-house modules or functions to create different “features” like a form, photo gallery, or “slider.” And though these functions are fully available to those trained and given enough resources, those with only front-end web design knowledge would not know how to add these features or how to add them. These features may or may not be turned off at any time, and no one at the organization or the greater portion of the campus knows what functions are usable and what have been removed.

All information was closed, and it was impossible to make much progress without spending many hours hacking different front-end solutions to see what stuck and what broke.

The first thing I did was update all information every week. This was a laborious process as there were many elements to edit throughout the site. No one thing updated all others. This caused me to spend most of my work load updating my pages. This would continue to be a problem all year.

Next, I sought to create new features on the site. My manager wanted a form on the contact list. I noticed the original Web Master had already set groundwork for this, but he could not make it work and thus never published his work. I spent two weeks on the project. My final attempt was to create a custom script that would send information to my private server. The solution was blocked by SharePoint as the code was obviously insecure.

Having no access to an in-house server, I moved on. Saying the request couldn’t be accomplished on SharePoint to our configuration of SharePoint to my knowledge. This began our discussion about creating a new website early in the year. By September I began looking into different affordable options in my free time.

My next project was to create a “slider” that would show the most recent stories. After two weeks, I had gone through three different sliders. The first was made from the SharePoint modules. The manager didn’t like it. He disliked the aesthetic. There I should’ve told him otherwise, yet I dug deeper and made my own. He disliked this one too.

After the second attempt, I tried to use Bootstrap for the first time. And at this point I learned a lot about CSS libraries. What they can do and how they can be implemented. But I would not use the Bootstrap styles here. Instead I found a simple jquery slider and used that.

Next I made some buttons using the knowledge I gathered from Bootstrap and made the front page – along with buttons for “recent articles” that all were written and published by hand, adding another hour to my weekly maintenance.

The work can be found here today: SPTV 1.00.

Once this was figured out, the spring semester began, and I was given a budget and a request to build our new website. That week too I learned that we did not win site of the year award. Disappointed, I put my energy into the new project. I decided to use GitHub as a way to publish my code. I then decided to use Jekyll to handle our updates. This would make things more automated, I thought. And the idea of having a static website that updates itself was appealing to me as someone who worked hard to simply update once a week. I published the code here.

How Jekyll works on our site is that it takes input from our config.yml file and serves the site to users visiting. Users may visit the server by accessing it from http://sptvonline.com/.

As you notice, the site is HTTP not HTTPS. The original GitHub site enables HTTPS, but the current setup does not. This may bite us in the rear later when Google refuses to index non-SSL enabled sites.

Another issue is that the live stream does not work on the GitHub server. This may be a security issue – as our server may not be allowed to query the stream. This may be a built-in function to prevent stream thieves. The current proposal is to have YouTube serve the stream instead. This would be a better alternative as it would allow iOS and Linux users access to our stream. Users would not need to rely on flash compatible browsers.

Now my contract comes to a close this week. To prepare for my departure, I spent many hours configuring the video-data program to grab data from YouTube and insert it into separate markdown files to archive in our website. Currently the GitHub server refuses so many files, but in the future, we can archive these posts in a new web server that supports a similar configuration of Jekyll.

For now, I use the video-data tool to simply grab many video IDs and plug them into the data I need. This automates the most tedious portion of the job.

Take me home.

Check out the archive.