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.