Final blog

The presentations were yesterday! We got to present in front of judges not related to the class, and our group came up... short! We didn't get one of the two awards handed out, but overall I still think we presented a good project. Ours was the only mobile app, while everything else was a website. We also had a video in our presentation which nobody else did. Finally, I think our one-sheet was the most unique, since we made a brochure instead of a normal one-sheet. So, while we may not have won, I think we presented the most unique project.

We slipped up a couple of times while answering the judges' questions, but this was expected since it was a high stress environment. Though we said a couple of things we shouldn't have, overall our we answered our questions knowledgeably and effectively.

The two winners were Visual Scheduler and Mechanapp, and they were both excellent. Visual Scheduler, I believe, was the best idea. It had a clear and direct function with little to no competition, and as a student I know the customer base is very interested. Mechanapp had the best presentation, with a well rehearsed speaker (James Vickers) leading the show. Both of these projects were great, and my hat is off to them.

The semester has been a good one. Even though we didn't win our project was my favorite of all of them. I learned a ton about Android and developing in general, and I wouldn't do it any differently. To all my readers, this is my last blog, but thanks for checking in!

I will update if I start a new CS blog on this account.

Thoughts on Other Projects: Demigod

Demigod is a stat tracking app online that allows you to track personal stats about yourself. Basically, you can track stats about your fitness, nutrition, or brain (or mental exercises). There are certainly a lot of other stat tracking apps out there, but this one tries to combine all self improvement stats into one convenient website where you can go to track everything. Their presentation did a good job of convincing me that the United States (myself included) should do a better job of tracking their nutrition and fitness, and how this site can assist in that.

The site looks very slick and it does look easy to pick out exercises for you to do for a week. It also seems that it does encourage you to do these exercises by "leveling up" your character the more stuff you do. This gives you a sense of accomplishment when you finish one of the challenges and puts it permanently into your profile, making you want to do another challenge for the next week. I think it's really cool how they split the challenges into three categories (nutrition, fitness, brain). This makes it easy for someone who's really only interested in one of these things to still use the website. The site even has challenges for quitting smoking, or other unhealthy vices, which seems really nifty.

My main problem with the site is that it requires manual data entry on your computer, i.e. you have to log on to the site on your computer and enter that you actually followed up on the challenges. The problem with this is it makes people not want to use it if they did do a challenge but forgot to input that they did. Or if they don't use the computer much, it can be tough. I really do think this should be a mobile app. It's easier for people to pull out their phone right after working out or something and entering that they did than it is to log in at home. However, this is a very minor complaint. Most people who wouldn't want to enter their stats on the computer probably wouldn't sign up for it in the first place so it is unlikely a target demographic.

Overall, this is a very nifty app. I could see myself using this if I was trying to get a bit healthier, which I may need to do. The team worked super hard on the site, and it definitely shows, it looks very polished and professional. Watch out for these guys at the final presentation.

Thoughts on Other Projects: G.E.R.A

G.E.R.A., or the Global Emissions Reduction Alliance, is a gamified carbon tracking website that allows users to input real data from their actual carbon emissions, and also encourages them through mini-games to reduce these emissions in real life. What's really great about this site is that it is trying to make a difference in the real world. Some of the apps are for convenience or entertainment, whereas this app is actually trying to address a real world problem, and that's admirable.

The stat visualization on the website looks really good. Since users can enter their data, the team has created tools to help visualize their carbon emission history, and I think this will help users to see how much they've improved, or if they have. Most of the users on the site will want to improve their carbon emissions, it's unlikely that people will be playing the game without any motivation. This tool just helps them keep track of everything, and gives them little directed incentives, which is really all people need to get going in the right direction.

The site is a little too dark sometimes, which makes the text a little hard to read. The team slightly fixed this by making a translucent background, but the site (at certain points) doesn't look super visually appealing, mostly because of color rather than art style. As well, I wish I knew what the games looked like. From what I can tell, the "games" are just something like "reduce your carbon by 2% this week" with data entry from the user, which isn't super exciting. Though, I don't really know how you could make it more exciting, so I can't really blame them.

Overall, I think this app is very good. I think it is the most beneficial app to mankind out of all of the projects in the class, since it is actually trying to do good for the world.

Thoughts on Other Projects: Automaton

Automaton has succeeded in making a game that looks professional, and better yet, like something people would want to play. The idea for Automaton was to make a game that's fun but also teaches about computer science, not necessarily in a way that's strictly educational, but more in a way where you don't even realize you're learning. It looks like a puzzle game mixed with fundamentals of CS. You have to manipulate the pieces to create a for loop, or take the mod of a number, stuff like that.

I think what I really like is even if it's not teaching people how to program, it's teaching them how to think like a computer scientist. In computer science, you really have to think of things in a step by step fashion, and that's what the game is all about. Manipulating a system in a step by step way to get your desired result. No, it won't teach you the correct Java syntax, but it will teach you how to think about problems when you're writing Java.

The only thing I don't like about it, is that it looks very similar to Spacechem, another game like it that I've played. The gameplay is extremely similar. However, they've recognized this, and after all it's in the same genre, since the genre is a specific type of puzzle game. Automaton certainly has its own look and feel to it, it is nothing like a complete copy, so this is not a big issue.

Overall, I think Automaton looks amazingly polished for what it is. Nobody else made a game (at least a video game) for their project, likely due to the inherent obstacles that come with building a game from scratch. These guys have not only pulled it off, but they've made something excellent, despite the difficulties. This project will definitely be one to look out for in the final presentations.

Thoughts on Other Projects: Mechanapp

This application looks really good. The visuals are really nice, their seem to be pleasurable animations on everything which I really like. The idea is a good one, basically it helps you diagnose problems in your car based on a series of yes or no questions. It also uses weighted likelihoods to try to diagnose your problem more accurately and more quickly.

I really like this product, and think it has real market potential. Their idea is to make money by putting in targeted advertising into the product, which makes a lot of sense since their product is already targeting a specific demographic. The problem there is you have to gain momentum to get the attention of anyone who wants to advertise with you before you can make any money, however this is a problem for a lot of startups.

The presentation for these guys was great! They felt very relaxed and comfortable with their product, which is good. It makes me feel more confident in the product when I see them so comfortable with it. Also, it seemed that they had rehearsed the demo a few times so it went very smoothly and demonstrated all of the features quite clearly.

One question that I have, (and a reservation I have about the product) is how are all of the trees going to be implemented? Are all of them going to have to be manually entered? Are there separate trees for every car or are they all pretty much working with the same tree?

Despite all this, I think the product is great, and think it's a real contender for the best project award. Good luck to Mechanapp and its team!

Thoughts on Other Projects: Visual Scheduler

These guys certainly made a product that people want. To be honest, I knew the scheduling tool for UNM was a pain but I didn't really know I wanted a new way to do it until I saw the visual scheduler. It just seems like it makes it so easy, compared to the current method. The schedule generator is genius and is definitely a feature I would use in the future.

The first presentation for this group was a bit weak. The demo was fine, the site (mostly) worked, and it certainly looked like a strong product, but I felt like the presentation wasn't super rehearsed and they demo'd a bit too long just to fill in time that they didn't use.

All that being said, the second presentation from them was way better. The demonstration didn't feel forced, the time felt natural, and they demo'd the schedule generator which was super cool. Overall, I think it was super improved and I'm confident it will be even better going into the final investor pitch.

I really like this group, and wish them the best with their final presentation!

Project wrapping up

It's interesting to view the project now that it all is wrapping up. It's no longer a looming fear in the distance, it's quite nearly an obstacle overcome. I'd be lying if I said there weren't nights when I thought we wouldn't finish it. I've had to pull quite a few all nighters working on this project, but it's unbelievable how much we've been able to accomplish in such a short time span. Sure, we only got one "simple" Android application done in 3 months time, but none of us even had Android experience going into this project. We jumped in head first, and I for one came out with a much better understanding of Android and how to use it.

Android wasn't what I was expecting. I will say that. It uses Java, but it definitely isn't Java. If you've used Java, it doesn't give you enough knowledge to just know Android, and may be quite confused going into it. However, I have started using a little bit of Java FX and it seems to use some of the Android paradigms. Since it Android is a very visual language (or perhaps I'm just taking advantage of a lot of the visual aspects) this relationship makes a lot of sense.

Being so close to the end makes me excited, and sad. Sad for the end of all the memories, excited for the prospect of moving on to new projects! Good luck to everyone working on their projects.

Developing for Mobile

Hi there, I'm back today talking about developing for mobile, and what its advantages and disadvantages are.

First off, they're mostly disadvantages, to be honest. The biggest frustration is testing code. The easiest way that we've found is to run the application on your phone through a USB, since the emulator is horrible and slow. Once running on the phone, you can set up a console to give you error output and standard output on the computer. In this way, you can see what went wrong if anything, since the phone does not give verbose output. The problem here is that we need to test outside sometimes. Since our application is motion and GPS based, a lot of the time we need to go outside and run around with it to test if features we implemented even worked. Needless to say, this makes it difficult to bring the computer with you to debug.

Another issue is artificial data. With computers, it is much easier to set up a system to feed your program false data so that you may test your code. With mobile, we are often pulling from sources on the phone itself and does not make sense to fake the data from it. Overall there are many difficulties developing for mobile since you are developing on a different platform than what you are developing for.

One positive aspect is that your program is as mobile as your phone. This means if you want to test data on a mountain, you don't need the computer just your phone, which is highly portable.

I like developing for mobile, because I think it's an important skill to know and it's so popular right now. There are so many apps being developed, but there are a lot of low quality apps developers have a chance to stand out from the crowd.

Intellij... You weren't the way

Hey there, today I'm going to be talking about JetBrains IntelliJ. You can find their website here.

We picked IntelliJ because we thought it would be the robust path. Though it's new, we read much high praise for it and that it was the future of android development. We knew going in that there would be more support for Eclipse, but really how many problems can an IDE cause?

More than I thought, certainly.

Adding libraries is a key part of the IDE, and it is not at all clear much of the time how we are supposed to do this correctly in IntelliJ. Because all of the tutorials were written for Eclipse, I assumed they would pretty much be the same in IntelliJ, because why would they reinvent the wheel? However, the project structure files are different, so much of the process is different enough to invalidate tutorials. Basically, it's just different enough to cause problems.

I would not recommend using IntelliJ for someone thinking about doing Android development. Use Eclipse. The features are all there. It has better support. And mostly, it's what everyone else uses.

Setting up IntelliJ

We chose intelliJ because it seemed like the IDE to use. It's the IDE of the future! This means that learning how to use it will be a valuable skill. The developers of IntelliJ IDEA definitely had Android in mind when making the IDE, which made it seem to us that it would streamline out development process.

The problem is that IntelliJ is relatively new, so there aren't nearly as many tutorials out there for setting it up. This means that anything that we want to use, plugin-wise, has to be figured out without much help. A lot of tutorials out there skip steps, assuming you know what they mean. This is troublesome because it adds a lot of time to setting up basic things, like repositories in the IDE itself.

As frustrating as it is, it helps me learn things better when I have to figure it out myself. I would like to make things faster, but I'm actually learning better so it is probably worth it in the long run. If I ever need to set up things again, I will know exactly what to do.

My Thoughts on Android

We've begun programming our project, Powderade, which is an app for Android OS. This is my first time working with Android, which I am very excited for since the app market is huge. All I had heard from everyone was that Android was just Java, and if I knew Java it would be no problem.

Well, those people were wrong. Android is not "just Java." Certainly, Java is incorporated into the language, and it's important to know. The complex parts of the program are going to be written in Java, but it uses Java more like a script. The program is put together in .xml files, which is something I had never encountered before. It makes assembling the program really strange, since there are a bunch of different files that point to each other for layout purposes. Putting together a GUI in android is certainly not like putting together one in Java.

I'm not saying that it's necessarily more complicated than Java is when it comes to GUIs. The IDE I'm using (IntelliJ IDEA) even comes with a GUI builder that allows you to visually put the GUI together, making the process a little simpler. But what I am saying is, just because you know Java does not mean you know Android. They are very different environments to program in.

I am glad to be working on this, though. I wanted the experience and now I'm getting it. I'm excited to know once we finish this project I will be an Android veteran!

Unit Tests, Why Use Them?

I'm here talking about Unit Tests, and why companies use them. Specifically, I want to talk about this paper.

Unit tests are basically tests that plug something into a program and expect a certain output. If they do not receive that specific output, then the test is "failed." These can be useful because people who didn't necessarily write the program can test the program by knowing what outputs should be. This can give useful information to the programmer if something has broken, or is not working correctly. A suite of unit tests should provide information to the programmer whether the program is running correctly or not.

What James Coplien is arguing in this article is that, in his words, "The cure is worse than the disease," meaning of course that the time spent writing unit tests is greater than time spent debugging code. He goes into a multitude of reasons why, including unit tests being over-required, and too many tests provides less information than the correct tests. I think he makes valid points, and what I like about this article is that he talks about the problems, but tries not to generalize unit tests being "bad" or "useless." He instead talks about how the original vision for them has become outdated as programming goes to new places, and requirements for unit tests are ridiculous in the workplace to the point where sometimes the tests are more complicated than the original program.

I have always thought that unit tests were not all that useful, but I assumed that this was because I was working on projects alone, and when you have a plethora of coders working on the same program, things could get complicated to test without a unit test. I still think that is the case. The problem with the solutions boasted in this article is that they rely too heavily on the competence and similar thought of everyone on the team. Not everyone will be able to write their programs to be testable, and generally, that will just be how it is. It is simpler to have unit tests, which are dedicated to testing the program, than have everyone be able to test their own code, and test within the program itself. This solution is certainly better if it is only a team of 4 to 5, but how could you expect a team of 80 programmers to be able to test together like that? I think it's unrealistic.

Overall, I think the writer is correct, unit tests are used incorrectly and inefficiently a lot of the time. But that is simply the way it is with software engineering, there is inefficiency when business and computer science interact. Hopefully, we will get to a point some day where enough people understand computer science in similar fashions where these problems won't crop up, but it seems unlikely.

Working with a Team

Getting thrown into a group of people that you don't necessarily know is quite the  experience. Add that to immediately getting assigned tasks and expected to work together, you have an interesting challenge.

Getting in my group, I was lucky, because I knew both Brandon and Kishore pretty well. Brandon and I are good friends, and Kishore and I have worked together in previous classes. John I didn't know, but he is quite the pleasant fellow and was easy to get along with. All of us were quite willing to work together, which made the initial experience enjoyable and painless.

I could imagine working with strangers or just peers that you don't like could be pretty tough. Not only do you have to work with your partners, you have to trust them to do their part of the workload. If you have a team member you can't trust, you have an entire team you can't trust and then you have a team that can't produce anything.

Like I said, this is not the case for me. Hopefully it's not the case for any group. But this experience has taught me how important the group is. Therefore, in the future, I think when selecting a group, you should be able to choose based on who else is going to be in a group. For example, if someone I don't want to work with is going to be on a project I want to work on, it might change my mind.

Now, I realize, in the real world, you won't always get to choose who you work with. You're going to have to deal with the partners you're assigned to in a lot of cases. But, if you're offered a job with a peer or group of peers that you don't want to work with, you have the choice of not accepting that job. However, in this class, if you're put in a group with people you don't like, you have no choice in the matter.

Thoughts on Project Proposals

Hey guys, it's been a while. I'm here today talking about my thoughts on proposing and project and the whole process thereof.

So my project, WorldBand, was not chosen. I'd like to say I was relieved, but that was not quite my feelings on the matter. To be honest, I felt ambivalent. On one hand, I was relieved. My proposal, which felt like I made up information (like the timeline) that was not necessarily going to be accurate, was not going to be held accountable to me.

On the other hand, this project which I had put so much effort into was just going to be discarded, probably not to be picked up again. As much as I like the idea, I doubt I will have the opportunity or resources to work on a project like this again. As much as I am excited to work on my assigned project, I will always have personal feelings toward the project I came up with. And, in fact, I still feel like it was a good idea. I feel like a website done right in the vain that I came up with could be a top 50 website in the world.

C'est la vie. You will always be attached to your own projects, but that doesn't mean you shouldn't realize when there are better ideas. My project proposal was good, I think people understood my vision, and I got a decent amount of votes. In the end, I am not upset, because I think the project I'm working on is better for the scope of this class.

WorldBand Proposal: Round 2!

Hi guys, I have taken the feedback that I received from my proposal for WorldBand, and updated my proposal, which can be found here.

Please, feel free to comment or review! Thanks for your input! Special thanks to Kishore and James for reviewing my proposal version 1.

Software Design Patterns: How useful are they?

Hi there, I'm here tonight discussing the article on wikipedia for Software Design Patterns, that article can be located here.

A software design pattern is basically something you can design or draw out as a template for a piece of software that you are currently developing. This template cannot be followed instruction by instruction to achieve the desired result, rather it is more of a general direction to begin in, with milestones along the way. This is important because it gives some structure to the overall design of what you are doing, aiding you to not be lost when looking for the next step in the program.

I have user software design patterns before, mostly for outlining object oriented related objects. Diagrams I have done detailed how classes interacted, helper classes, and their basic designs. This is cool because when you start programming a class, you have it outlined before it's even done. This means if you have two classes interact with each other, you can program one before the other since you already know what functions the other will have that need to be interacted with. This was very important in a project where a group of us were working on a program together, and we didn't necessarily all work at the same time. Since we knew all of the basic class outlines, our programs could interact with each other quite easily, even if we weren't in constant communication.

Some criticism has come from the fact that these diagrams oversimplify things and this becomes a problem when you're actually implementing according to simplified diagrams. These problems can arise from thinking you needed extra functionality that wasn't necessary, or not foreseeing a certain problem. Though both of these things can happen, I don't think it is valid criticism. Problems will always arise when programming something complicated, and I think it's very useful to have an overarching structure to the program before you delve into the nitty gritty.

So, overall, I think software design patterns are awesome. I think they are useful and you will almost always be very happen you decided to make them before you get into the full body of code.

My ideal project team

Here I am today, once again talking about the project proposal I have put fort, WorldBand. You can read that proposal here.

If I were to describe the perfect team for this project in three words, those words would be:

Knowledgeable, communicative, and inspired.

Knowledgeable because the work that I'm looking to do is going to be quite complicated. They don't necessarily need to know everything before the project starts, but they need to be able to learn fast and teach others.

Communicative because the whole team needs to work together to make a project work. Everyone needs to be communicating for the site to be made correctly. This does not mean that they need to be talking more than coding. Part of being communicative means knowing how to be concise and direct, making the process easier and less time consuming.

Inspired because you have to want to work on a project to work on it. Some inspiration will come from it being a requirement for the class, and therefore to graduate, but I'm hoping a lot more inspiration will come from actually wanting to complete the project to the best possible degree. With this kind of inspiration I know the team will work hard without anyone having to enforce it, they'll all enforce themselves.

Some other contenders were thorough and hard-working.

Thorough because the team should care about all aspects of the site and should not just be throwing the site together as quickly as possible. I did not choose this because if you're communicative and inspired they will definitely be thorough.

Hard-working is obvious, of course I want team members who are actually going to work on the project and not slack off. However, I didn't choose this word because if they are inspired, hopefully that will force them to be hard-working.

What it Means to Review a Proposal

How is it that someone can read a 15 page proposal, and summarily score it in less than a page? A few concise sentences is all that it deserves? Well, maybe not, but it is pointless to restate the entire proposal in a proposal review. In fact, though it may seem harsh when there is less content in the review, this often is a good thing (for your proposal, at least) because it means there wasn't as much to talk about. If you have a solid project, then there just isn't as much to talk about. This cuts the other way too, though. If you have a truly horrible project, then there won't be much to talk about either, even if there is plenty to rant about. You usually know when a project is truly horrible though, so if you don't think this about your project chances are nobody else does either. This also doesn't mean, though, if there is a lot to talk about, your project isn't good. Sometimes, there are great projects that could almost be perfect with a few changes, and then the reviewer might just be enthusiastic to talk about these changes and why they need to happen. Sometimes, this will mean extra criticism or extended thoughts, but that does not necessarily show a decreased amount of interest in the product, sometimes it shows more.
So, in summary, the length of a review doesn't necessarily mean much. You have to look at the content of it. If the reviewer is saying this isn't going to work, then maybe you need to rethink it.. Or maybe the reviewer is just bad. But it's something you need to consider at least.

Proposal Review: Mechanapp

I'm here reviewing a proposal put forth by James Vickers, a fantastic fellow student in the cs department. You can find the proposal here.

Review of Proposal: “Mechanapp”

Proposal author: James Vickers
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create an application that can assist in the diagnosis of a car problem using probabilistic diagnosis based on other entries into the system. This will help for both professional and amateur car owners and enthusiasts to fix any problems on their own, while paying as little as possible.

Part 2: Reviewer reaction

The idea is a good one. Car repair is a mystery to a large majority of the populace and even the good ones are shooting in the dark a lot of the time. I kind of like to think of it as a “WebMD” for cars, a simple diagnosis tool so that you can get quick and easy advice.

Part 3: Quantitative scores

Format: 4

The format was good, though some information seemed to be repeated. Nothing too drastic though, and easy to look through and know the scope of each section.

Writing: 5

Very easy to read, and explains the project very well. Solid writing.

Goals and tasks: 4

The target audience was well defined, and the product was well laid out from a front end perspective. I think more analysis needs to go on on what needs to be done behind the scenes though, on the technical side.

Scope: 3

I think more thought needs to go into the platform and the technical side of the project (even if you're not sure on the platform, pick one and if your team decides to change it once you form, that's fine), but the scope of the marketing and attracting customers is good.

Plausibility: 5

Everything talked about could easily be done and is being done for different applications already.

Novelty: 4

Similar to other diagnostic tools out there, but none that I know of for cars. Seems like a very solid and novel idea.

Stakeholder identification: 2

The stakeholders are not identified, though the target audience is outlined very well.

Support and impact: 4

This could easily make an impact on anyone who works on cars, so good job there. But how will the application be supported once the product is done, and the twelve weeks are up?

Evidence: 4

You did a good job of talking about other tools out there for mechanics, but you also could have talked about other diagnostic tools out there.

Challenges and risks: 3

Technical challenges weren't addressed. A lot of marketing and viability challenges were though, such as having customers enter previous solutions into the database, which was good, since that will be a major problem upon starting up.

Proposal Review: Backpacker

Hi there, today I will be reviewing the proposal put forth by Alan Kuntz, a very talented and intelligent individual, that can be found here.

Review of Proposal: “Backpacker”

Proposal author: Alan Kuntz
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create a mobile app that will specifically gear to a backpacker's needs. These include tracking consumables, keeping battery life low, and the possibility of sending out an emergency broadcast. This application would be a lightweight accessory for a relatively new market.

Part 2: Reviewer reaction

This idea is simple and lightweight, and exactly the kind of mobile app that will hit a niche market. Because the proposer has experience in backpacking, he clearly knows the needs that should be met when developing a mobile application geared to backpackers. The emergency broadcast alone, though not new, could be extremely helpful when applied to backpackers. I really do think that this idea has potential to change the world.

Part 3: Quantitative scores

Format: 4

The format is easy to read, though sometimes sections seemed to be repeated and it was not clear upon referencing which section I read something in. However, there were still clear sections that the writer did not write outside the bounds of.

Writing: 4

The writing is clear, and very conversational. I really like how the proposer didn't get caught up in the technical aspects of the proposal (that being said, there were some issues with this I will address later), and the whole thing gelled very well. Sometimes I felt the proposer was repeating himself, however.

Goals and tasks: 5

This section was excellent. The proposer clearly thought through his target audience, and exactly what he wanted to achieve. The different features of the application are well defined and fleshed out.

Scope: 4

The features are fleshed out very well, as mentioned previously, but one thing that bothered me was there was not a mention of what platform would be used, or how the thing would be programmed. Given, though, in the timeline there was time dedicated to discussing with the team, but I would say you should pick a platform and it can be changed later.

Plausibility: 5

Everything proposed is very doable on a mobile platform, and there are other services out there that perform similar functions.

Novelty: 3.5

On one hand, it seems like the application of this to backpacking is actually very new and I would like to applaud that. On the other, I feel like many other applications out there can do very similar things. Still, though, I think that it is different enough it can find a niche market.

Stakeholder identification: 1

The stakeholders are not identified, and this needs to be addressed.

Support and impact: 4

Great job talking about how this could impact, with the emergency broadcast system having the possibility of saving a life, there will always be impact. Not much about supporting the application was covered though.

Evidence: 5

You gave evidence of other applications, all of the functionality is clearly capable with mobile technology, and just well justified in general.

Challenges and risks: 3

Technical challenges weren't really addressed, though this could be because you did not really see them as a challenge. Still, they should at least be mentioned.

Proposal Review: A/V Synthesizer

Hello all, today I will be reviewing a proposal set forth by Trent Small, a brilliant programmer in my software engineering class. You can find his proposal here.

Review of Proposal: “A/V Synthesizer”

Proposal author: Trent Small
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create a synthesizer that incorporates both audio and visual components, as to streamline the process of creating a visual presentation for performers.

Part 2: Reviewer reaction

This is a seemingly great idea, though admittedly I know very little about the product's market and why this is necessary. I think what's really missing here is a better explanation of what the product is and why people would buy from a non-technical standpoint. Though the proposer does talk about current problems with the industry, it's very hard for me to understand these problems because I do not know much about how these synthesizers work in the first place. I'm assuming what the proposer is saying is that this synthesizer will automatically create a visual “show” based on the music that is played, but I'm honestly not sure.

Part 3: Quantitative scores

Format: 5

Extremely clean and professional looking. Everything is separated nicely and it has a table of contents for easy reference.

Writing: 4

The writing is very good, concise and to the point. That being said, some fields could be expanded and described a bit more in-depth.

Goals and tasks: 3

Obviously a lot of work has gone into the thoughts of this project, and the reviewer has the technical aspects of the product down quite well. However, a lot of questions remain to be asked. How will people here about the product? Why will people want to buy this beyond its technical superiority?

Scope: 2

I'm confused as to what the product does and does not do, so this area should be fleshed out more.

Plausibility: 4

This seems very realistic, though some of the hardware might be difficult to get a hold of or incorporate.

Novelty: 4

I'm not very sure of the current state of the industry, but this seems like a novel and useful concept.

Stakeholder identification: 4

The stakeholders are clearly identified, although I feel like there are other stakeholders not represented, like shareholders or investors.

Support and impact: 2

The proposer could go into more detail about how this will affect the music industry, and what kind of lasting support the product will offer.

Evidence: 4

The proposer provides evidence of similar products, and he is using realistic technology, so it seems that this product is plenty realistic.

Challenges and risks: 3

A lot of the technical challenges are addressed, but the risks of investing in hardware and marketing aren't addressed.

WorldBand: A Social Music Website

UPDATE: I have uploaded the pdf for easier viewing here.

1. Project Drivers

1a. Purpose of the Project

There are plenty of socially uploaded media sites out there, but none that focus on the needs of bands. One thing that I've always thought was necessary was a site that could act as a banding together of musicians from around the world and allow them to work together through the internet. There are millions of musicians in the world, just waiting to be recognized or just wanting to express themselves. However, it is not easy to form a band with a person in another city, let alone another country. The internet lets us connect these people in a novel way. In my site, people can upload music they've recorded or record it fresh, and tag it with an instrument and their unique username. In this way, they can upload an guitar part, for example, that they have written and thought was very cool. In a different part of the world, a drummer may listen to this piece and make a drum part and attach his part to the guitar part, forming a duo but with each part being credited to its respective writer. People can sample each others work without stealing it, and still give credit to the authors. The idea of an international band is realistic, with members each from a different country in the world.

1b. Goals

1b.1

Purpose: We want to attract users who want to create content to the site.

Advantage: More content will attract more customers

1b.2

Purpose: We want to attract users who want to listen to content generated by other users

Advantage: More customers means more money from ad revenue

2. The Client, the Customer, and Other Stakeholders.

2a. The Client

Users who are looking to upload music and work with others around the world.

2b. The Customer

Users who are looking for new sources of music, and are willing to purchase them.

Ad agencies looking to advertise on the site.

2c. Other stakeholders

2c.1 Positive stakeholders

Users looking for free content

Investors in the site

The programmers

Users uploading music

Users selling uploaded music

2c.2 Negative stakeholders

Pandora

Soundcloud

iTunes

2d. Users of the product

Music creators

People who want to listen to music

3. Constraints

3a. Solution constraints

For the environment of the site, we will be using HTML5 for the front end with a PHP and SQL back end. HTML5 is very robust with a lot of functionality and we want to take advantage of this to make a very nice looking site without sacrificing capability. PHP is a popular language to write a site's backend in, though we could just as easily use Ruby on Rails or Django. PHP was chosen because of a likelihood of more people being familiar with it, which means less familiarization time necessary for the programmers. However, this could easily be changed once the project group is chosen. SQL, similarly, was chosen because of the likelihood of programmers being more familiar with it rather than other languages.

3b. Time constraints

Timeline:

In-depth timeline:

For each week, I will budget 75 hours of time based on the assumption of 5 members of the group. This means a half hour meeting will take 2.5 man hours as it is .5 hours for 5 people.

Week 1:

Budget:

Introductions and learning each other's skill sets: 5 hours

Weekly client meeting - 5 hours

Concept and Basic Design: 20 hours

Basic skills acquisition (understanding AWS, learning HTML5, figuring out what algorithms, including Fourier transformation, are necessary, etc.): 40 hours

Setting up server: 5 hours

Goals for end of week:

Finish initial design blueprint for the site

Make final decision of framework and skills needed for site

Set up the AWS server

Week 2:

Budget:

Weekly client meeting: 5 hours

Design development, including planning out features very fully, and modeling site: 30 hours

Code development and documentation: 40 hours

Basic framework for site in html5: 25 hours

Back end and AWS: 15 hours

Goals for end of week:

Finish framework of site (not functional, but a bare bones of what we want it to look like)

Week 3:Budget:

Weekly client meeting: 5 hours

Sound file manipulation design, how we're going to save files and attach headers: 45 hours

Algorithm implementation: 20 hours

Documentation: 5 hours

Goals for end of week:

Have a better idea of how we're going to save sound files and how the algorithm will work

Week 4:Budget:

Weekly client meeting: 5 hours

Sound file implementation programming and documentation: 50 hours

Algorithm implementation: 20 hours

Goals for end of week:

Have significant code for the implementation of recording or converting sound files to be compatible with site

Week 5:Budget:

Weekly client meeting: 5 hours

Sound file implementation programming and documentation: 50 hours

Figure out how to manipulate lengths of files to change beat of songs uploaded: 20 hours

Goals for end of week:

Finish up the code for sound file manipulation, ready for implementation in week 6

Week 6:

Halfway mark

Budget:

Weekly client meeting: 5 hours

Implementation of sound code onto website: 25 hours

Working with site and AWS to make sure clients can upload files: 40 hours

Documentation: 5 hours

Goals for end of week:

Working prototype released

Will be able to upload files through the site

Will be able to manipulate files through site

Will be able to mash sound files through site

Week 7:

Budget:

Weekly client meeting: 5 hours

Front end touching up, making UI nicer: 35 hours

Back end reinforcing, bug fixing, making more robust: 30 hours

Documentation: 5 hours
Goals for end of week:

Website looks good, performs well

Week 8:

Budget:

Weekly client meeting: 5 hours

Bug testing, content creation and bug fixing: 50 hours

Marketing, and seeing market response: 15 hours

 Documentation: 5 hours

Goals for end of week:

Get a market response

Measure market response (positive/negative and why)

Week 9:

Budget:

Weekly client meeting: 5 hours

Adding new features based on market response: 50 hours

Continuing marketing: 15 hours

Documentation: 5 hours

Goals for end of week:

New features implemented

Week 10:

Budget:

Weekly client meeting: 5 hours

Finishing new feature implementation: 35 hours

Testing and bug fixing: 30 hours

Documentation: 5 hours

Goals for end of week:

Version 1 released

Full version with all features wanted

Should be relatively bug free

Go live with site to public

Week 11:Budget:

Weekly client meeting: 5 hours

Bug fixing from new release: 20 hours

Testing public response: 30 hours

Any additional features requested by client or users: 15 hours

Documentation: 5 hours

Goals:

Attempt to handle the amount of users on site

Fix any user problems in a timely manner

Week 12:

Budget:

Weekly client meeting: 5 hours

Touch up front end: 20 hours

Finish all back end and server code to make sure users have no problems: 30 hours

Testing and bug fixing: 15 hours

Documentation: 5 hours

Goals:

Final version released

4. Scope of the Work

4a. The Current Situation

Currently, music creators are uploading their music to sites like Youtube and Soundcloud, where people can view it. On sites like this, there is no functionality of using the internet to connect with other music creators, only listeners. Furthermore, if someone were to mix someone else's song, the mixer would get all money from ad revenue and downloads, because there is no way to credit the original artist. There are programs like GarageBand that allows music creators to create different tracks for parts of a song, but users are limited to working with other musicians that they know. There are sites like iTunes, where bands can display their songs for others to download, similar to the projected way on this site. However, once again there are no ways to collaborate with other's work, or at least do it without stealing someone else's work. Though iTunes is able to connect to a person's iPod or other mp3 player, the files downloaded from the site proposed will be able to connect into iTunes and still have the same functionaliy. There is no current platform that allows the display of music while simultaneously allowing users to work with each other and still give credit to the original artist.

4b. Context of Work

This model shows how the different stakeholders can interact through the site.

4c. Work Partitioning

The following table partitions the site into 5 business events.

No.	Event Name	Input	Output
1	User streams music	-Chosen Music	-Streaming music
2	User downloads music	-Pay for Music	-Download music
3	Creator gets paid for content	-Upload music	-Get paid for downloaded songs
4	Creator collaborates with other creators	-Collaborate with other users	None
5	External companies pay for advertising space	-Funding	-Advertising

4d. Business use case scenarios

Business event 1: User streams music

Business use case: Stream music for customer

Trigger: Play music request from user

Preconditions: User must have account on website, must be logged in

Active stakeholders: Programmers, user

-The user requests to play a song either automatically through a playlist, or manually by pressing play button

-The website loads music stored on server

-The site streams music to the user's computer

-Once the song ends, the song stops streaming or moves to next song in playlist

Business event 2: User downloads music

Business use case: Download music to user's computer

Trigger: Download request from user

Preconditions: User must have paid for song

Interested stakeholders: programmers, user, content creator

-The user requests to download song

-Site loads song from servers

-Site uploads the file to the user's computer

-Portion of payment goes to content creator

Business event 4: Creator collaborates with other creators

Business use case: Allow creators to interact through site

Trigger: Creator requests to collaborate with another creator's content

Preconditions: Creator must have an account on site, must be logged in

Interested stakeholders: programmers, content creators

-Content creator requests to collaborate with another creator's work

-Site retrieves requested track from servers, streams to creator's computer

-Creator uploads track tagged with own username and releases song with both tracks

-Song is displayed on creator's page for public to listen and download if desired

Business event 5: External companies pay for advertising space

Business use case: Business provides ad space and receives funding

Trigger: Company requests ad space from website

Preconditions: Ads must be reviewed by team running the site, the company must pay fee

Interested stakeholders: investors, company advertising, users, programmers

-Company requests ad space

-Team examines the proposed ads

-If acceptable, site places company ads for users to see

-Company pays for advertising space for an agreed-upon amount of time

4e. Overview of site functionality

An example of how the site will work is as follows: a user, who styles himself a producer, uploads a track of his own making. It has a basic rhythm with a few instrumental and vocal additions, but a very vague track without much appeal by itself. A friend of his on his page, a DJ who has worked with the producer before, decides to take the track and mix in some electronic music he wrote. Another user, a follower of the DJ, decides he wants to add his own part to the track once the dj has modified it. Then with the three users combined, a full track is completed and other users begin to listen. When a user listens to the track, all three artists are credited. Though these people may not know each other, they have created a very popular song that gets thousands of views, and they may want to work together again in the future. If they ever decide to monetize the song and sell it, they would all get a portion of the sales from the song, and would all profit.

5. Project Issues

5a. Risks and Solutions

Of course, there are drawbacks to this idea. It's very complicated, and would require some knowledge of sound file manipulation. This is addressed in the timeline by giving our programmers plenty of time to familiarize themselves with the content. Another problem is that servers would be required to hold user generated content, which in turn would cost money. However, once a user base gets off of the ground, it should be an exponentially growing model with more people joining the site the more users there are. And of course, the main problem would be getting it off of the ground. Because all of the content is user generated, before there are many users there would not be very much content to attract new users. This is always a big problem with sites that are community driven. We can use several methods to address this though. Eventually we will get to a point when users will be able to upload music that they sell through the site and get a portion of each sale. We will also give rewards to users who upload more content. The more content you upload or listen to, or even the more friends you have, the higher your “user level” is. A higher user level will provide incentives to the user, like adding additional flair to their user page where people can see their music. There will also be community contests where users can submit songs for specific contests that are on a weekly or monthly basis. This will allow fans to listen to a variety of songs based on a theme and be able to vote, and users to have changing community goals to go along with their own personal or band projects.

5b. Costs

Funding is always required with sites like this. Servers cost money, so the site will obviously take some funding beyond the programmers compensation. However, this is going to be a variable cost, based on the amount of traffic to the site. Initially, if we are using AWS and we are students, we will likely be able to get away without paying while we are still working on the site. Eventually, once we have a project ready to show, investors will hopefully chip in to get it up and running. Once we are established and have reached an acceptable user base, we can begin putting ads on the site. Also, the music created on the site will eventually be able to be downloaded for a small fee, which a percentage of will go to the site for every transaction. A percentage will also go to each artist who contributed to the song. This makes it so artists are incentivized to create more music and are more likely to want to use the site as a platform to release their music rather than other competing sites or platforms.

The following table gives an itemized list of items that will cost money in order of their level of projected cost:

No. of Item	Item name
1	Servers
2	Programmers
3	Marketing
4	Domain name

6. Marketing

6a. Target Audience

The target audience we want is people who are looking for a different way of listening to music. The music on the site will not necessarily be high production value, but rather independent in production and creation. The site will introduce listeners to bands and musicians who would not necessarily be able to stand out otherwise. There are people who are interested in this sort of “free market” for independently produced content. On YouTube, for example, the content creators are making new formats to videos and movie never thought viable before YouTube's popularity. It is very plausible that a large number of people would enjoy being the explorers on a new horizon of music release.

On the other hand, we also want to attract the content creators to the site as well. This will be important because there is no tool like this for bands out there right now. This site could potentially revolutionize the way people look at and delve into the music industry. Rather than messing with producers and record labels, you can write a popular song and have producers come to you. Of course, that was always the ideal situation, but this site could make it a democratic system of determining popularity compared to what is played on the radio.

6b. Marketing strategies

One of the most important parts of starting the site will be getting a starting audience. How can we attract people to the site before there is any content? Ideally, we will reward the early adopters. Since we will be able to recognize mp3 files and convert them to our own, this will allow new users to use content that they have already created to add to the site. As well, we will give them featured spots on the front page so new users will immediately be able to see their work. Of course, the lower quality content will immediately be rated poorly by other users, and then removed from sight, but the initial front page views will give content creators a good shot at being recognized.

Since every song is tied with the creator's unique username, every artist will be getting credit for his or her work, which makes it desirable to put on the site. The idea of getting credit for each song that you're mixed in with gives incentive to both mix in with other songs and have your songs be desirable to be mixed with, because the more songs your parts are in the more chance of recognition and reward you get. This will also help address problems of users who mix minimalist parts with excellent tracks as to “ride their coattails.” Since nobody will want to mix with a track that barely has any content, these users will not likely be rewarded as the other track will get mixed into a lot of songs and their track will not.

There will be tons of incentives once the site has content as well. Popular songs that are responses to site sponsored contests will be featured on the front page and more likely to garner listens from other users. The more content created for a content creator will increase that user's level on the site. The levels will be badges of pride, showing how long an account has been active and producing on the site. As well, listeners will similarly be able to gain levels by listening to music, rating it, and even making playlists. Special badges can be achieved by listeners and creators by participating in the weekly contests. All of these incentives together will work as a sort of gamification, getting the users to use the site more by being invested in their online profile.

Of course, besides the online incentives, the site will also allow users to market themselves and make money through the site through other users downloading. This will provide monetary incentive to content creators who are very popular, thus encouraging them to continue creating content. Because they are being provided a portion of the money paid to the site for downloading their music, this comes with basically no cost to the site. Since it is self-sustaining, the site can afford any amount of users getting paid from other users downloading their work.