The Influence of Youtube

This week was mainly dedicated to working on the SRP presentation in the office. It's beginning to take some rough shape, but is still a definite work in progress. However, that doesn't mean that I didn't discover anything particularly intriguing while working.

As Matt, the web designer of the LoopLogic company, has his desk right next to mine, I often get drawn into the discussions he would have with other colleagues regarding the appeal of the web design and how intuitive the site has to be to really grab the consumer's attention. This week, there was a particularly engaging conversation that really grabbed my attention.

Remember how I mentioned that YouTube had such a powerful influence on the common mindset? Well, it seems that it does have flaws: for one, there's Google Plus (which incidentally is slowly being shuffled out of the Internet). But the major issue we all agreed that YouTube had was just how it kept stacking videos on top of one another.

Of course, normally, YouTube is meant for you to just click, sit back, and enjoy whatever you wanted to watch. However, it really lacked any serious method that would allow for professional user feedback that is not the abhorrence of the comments section. This issue though is not high on YouTube's concern of to-fix list.

For LoopLogic though, this is an opportunity. To fix this link, the program designed sacrifices the bulk video accessibility and adds in ways for any potential business partner to check on media feedback, such as surveys or questionnaires. This draw parallels to YouTube's like/dislike system, but with actual and proper information about the potential consumer and how they can get eased into making a deal with the provider.

It's all psychological stuff. Probably a thesis paper one day, detailing how the mind has been shifted by how easy things are in the modern day.

Well, till next time.

On the Importance of Bots

Well, good news: I finally finished up my original project regarding creating bots for LoopLogic. I've now created an automated system that will run through all of LoopLogic's functions while logging in and set up a program in which Mr. Legay and I will be alerted when something errors within the script. That way, the issue can be quickly resolved.

As an anecdote, on Monday, the login portal for LoopLogic through Twitter was not working. The bots reported this problem and we immediately set out to find a solution. Later that day, we discovered the issue (Twitter had changed its API tools without making a full out public announcement), and was able to repair the login portal.

Also this week, we talked about user interfaces even more. Specifically, we talked about how popular and comforting the YouTube layout was in the eyes of the public. The thing about YouTube is that it is insanely popular, definitely something that any consumer would be familiar with. While designing a sample channel page for LoopLogic, we kept making comments about how everybody seemed to prefer a style similar to that of YouTube. We have changes and our own style added to it of course, but the basic layout seemed to be a distant echo to that of our more popular competitor. But then, we realized a major factor.

What we were doing was setting up a video channel for a business contact, so they would have something like 20 videos and then a questionnaire section. This was to focus and maximize information absorbed in a short period of time, giving a very professional feel about the channel. In comparison, YouTube does it more lax, with multiple videos being displayed at once and seemingly having no end to the material.

That brings me to my next major point of the streaming market: target audience. Video companies can easily gain more consumer participation and product consumption by appealing to a certain demographic; that demographic depends on what the primary purpose and what features the video service provides.

Well, till next time!

Translating from GitHub to Website

Hello everybody! I've been on Spring Break this week, so I haven't gone to work at the office this week. However, as suggested by Zachary Ginsberg last time, I'll show you with some pictures how the GitHub code goes into the LoopLogic API site, as well as how the interface can affect user experience!

First of all, here is a quick screenshot of what it looks like on the GitHub page of codes:

Not much huh? But you have to understand, these are like how your computer organizes documents. There are folders within these with even more files, and each file contains a bunch of complicated code. When we link a website domain to the GitHub page, GitHub will then take the code within these folders and then run them. So all the code that is within here....

....becomes this! Pretty neat huh?

Now, in my last post, I talked about how important user interface is right? Well, above is a good example: colors. Each of the interactable subsection is color coded in a way that pops out and grabs the user's attention. With some nifty code, we were able to do the same thing as well within the subsection!

See how vibrant the page is? It will hopefully make it a lot easier for the user to get comfortable with how to navigate around the API toolkit. This will boost the likelihood that the user then becomes a consumer, which is the ultimate goal of having a good interface.

Well, till next time!

Final API Calling

This week, compared to the last couple, was positively productive. I actually felt like I was doing something major and learned a lot from Stephane and the other programmers. We managed to finish up the API site!

Well, of course, it's not officially released yet, there are still a few bits here and there to fix up. But the major structure and layout codes are complete. The placeholders are gone.

Oh, I'm getting ahead of myself. I should explain a bit how web development works. First, you have to create a placeholder script for the site, using GitHub as your script runner. That way, you can be sure that the code you input on GitHub will transfer over to the linked site's actual code. Once that's been confirmed, actual work can begin on writing the real script.

The LoopLogic API site was built using three subsections, one for each coding style. However, it was housed in one general site with a homepage linking to each subsection. We built each subsection first before working on the general site, so that when the homepage is finally complete, we can already start checking to make sure the subsection links aren't broken.

But work still needs to be done to improve the user's experience. We have to make it seem appealing to any potential programmers who want to use LoopLogic API to create a business channel. That's how it all links back to my proposal and points out a key factor: user interface. If a web streaming site is unfriendly and rather stiff on its API flexibility, it would possibly confuse or disheartened businesses working with it.

Customer happiness is linked to business; ergo, a good user interface is necessary to keep them happy. That's something that I'll have to take into factor when comparing the web streaming market.

Till next time!

Bugging me out!

This week, I worked on a rather mundane but necessary task for LoopLogic: debugging scripts. Hardly the most exciting of ventures, but certainly an important one, especially when you're working with various API programs. Reviewing three scripts of about 9000 lines each is not easy.

To explain, let me describe what debugging is: a simple proofread of a program's script. It's like proofreading an essay, but a bit longer and a bit more tedious. Of course, a lot of modern programs have built-in runtime script checkers, such as Eclipse or Selenium Webdriver. An apt comparison would be to Microsoft Word, which automatically checks your document for you while you type.

However, the script was written on GitHub, which lacks a runtime script checker. Therefore, I've had to comb through each script carefully and check out everything. Even the slightest semicolon omission can topple an entire script, so it's very important that the script is flawless of anything that would throw a major error.

On the other hand, while proofreading, I've discovered that Internet Explorer doesn't support a lot of basic browser features in programming. A lot of code in the script was dedicated to just figuring out what to do in the case of a user with IE. Go figure. It's amusing in an odd way to know that despite being the oldest web browser, Internet Explorer is the one that gives the most trouble to websites.

Well, that's pretty much my entire week summarized. My eyes are kinda strained and I'm now thinking in lines of conditional codes. Hopefully this comes in handy next week!

Till next time!