Final Post: Parting Thoughts

After a few weeks of solid blogging, it is time for the end. My idea has progressed significantly, starting out as little more than a LinkedIn imitator for musicians, and ending up as a more robust, original musician-oriented professional networking tool, with the ability for users to search for bands, band members, and gigs.

Throughout the lifetime of this blog, we’ve covered possible challenges we could face, including privacy issues and developing a user-friendly but powerful GUI. We’ve discussed media integration, allowing users to post videos and record sound clips for auditioning purposes; a powerful feature that would serve as a musician’s equivalent of a resume.

The most powerful feature discussed over the progression of this idea is the development of a mobile app, and integration with a Foursquare-style tool that allows users to track various important elements, such as attendance at shows, merchandise sales, and perhaps even travel routes. This would give bands a more complete view of their success in specific regions, and the potential for future gigs. A mobile app would also make it extremely convenient for a venue to book last-minute entertainment, or for a band to hire a replacement band member at the last minute.

Overall, some solid ideas have been discussed in this blog. While such a service is far from completion, or even completion in formulation, I look forward to the day when such a network can be implemented and help the thousands of musicians left isolated and stranded on the web.

                These are the blogs I’ve commented on:

http://aburnet.blogspot.com/2011/09/my-entrepreneurial-idea.html

http://istblogbcougz.blogspot.com/2011/09/laundry-view-iphoneandroid-application.html

http://omniexp.blogspot.com/2011/09/introductionweek-one.html

Entrepreneurial Review of SlashGear

Co-founded by Ewdison Then and Vincent Nguyen, Slashgear.com provides reviews and highlights of the latest tech gadgets and digital lifestyle trends. With a hierarchy much like a magazine’s, consisting of editors, columnists and writers, the site is well-organized and its articles are extremely well-written.

The site is organized by reviews, columns, videos, and articles dedicated to “super phones and tablets”; the latest, most powerful smartphones and tablets. It has sections for trending topics within its comments and articles, and integration with Facebook and Twitter. As with most blogs, Slashgear can be subscribed to with an RSS feeder.

One cool feature about the site is its encouragement for users to “tip” them; that is, contact them with suggestions for new stories regarding new hardware of software.

               

Check the blog out here at http://www.slashgear.com/

Integration Of Other Social Networking Services

A recent comment brought up the possibility of integrating other social networks into my service, lowering the entry barrier for new users, and allowing faster adoption and growth. Integration of a widely used network like Facebook would certainly be beneficial, and would allow for a wider audience to adopt this service.

This could also work the other way around, developing this service as an application within Facebook, allowing users to use already existing accounts and information and simply add to them. There are benefits and costs to both ways of handling integration of several networks into this service, or making this networking subservient to other, larger entities. An application based in Facebook could make use of architecture already laid in place by their developers, and could even work to ease integration with other services. However, I would lose the ease and ability to create some of my own routines for databasing, as well as creating my own user interface. It could also affect performance of features available in my service. Striking out on my own would certainly raise the entry barrier, limiting the spread of the network. Developing all of my own elements could also lead to potentially disastrous results: a GUI that is not up to par, or applications that do not function well.

Overall, I do not think there’s a clear cut answer as to how to implement integration between services, but one thing is clear: it’s essential that it happens. 

Mobile App

This week, I would like to talk about the possibility of building an application for mobile platforms, enabling musicians to use our tools while on the go. In a comment a few weeks ago, someone mentioned integrating a foursquare-like service for active gigs, to allow for tracking and trending within communities. That would be a very useful tool, but why stop there? A full-fledged mobile application would allow users to go to a venue, have a band member injure himself prior to the show, and then hire a replacement while waiting for their set time.

A mobile app with full functionality, much like Facebook’s application, would be great for musicians, since users are generally on the go, and not at a static terminal. Being able to hire a substitute band member while at a venue would completely change the dynamics of temporary posts for musicians, giving more musicians more opportunities to work. Such a feature would not even necessarily have to be limited to musicians: venues could book entertainment on very short notice, perhaps when another act cancelled.

Foursquare integration could be used in a mobile application for a variety of purposes. Venues could track crowd attendance, feeding it back to musicians and bands, which would use it for booking purposes. It might also be useful to track local artists performing radii in a certain area, helping them visualize their spread and plan out the logistics behind possible expansion or relocation.

The most obvious platforms for such an application would be iOS and the Android OS. All in all, mobile functionality for this network would transform communication dynamics between musicians and supporting institutions in the community, such as venues and booking agents.  

Recording Song Samples

Input and output are integral to the services I want to deliver with this project. One of the key features I want to offer is the ability for musicians to upload music samples displaying their work. An integrated music player would be placed on profiles, and searchers could hear work done by individuals before even contacting them.

Uploading music samples should always be fast and easy, with the music player optimized to load and play quickly. For that reason, users would probably be limited to uploading only mp3s, as they are much smaller than lossless formats like wav files. The loss in quality in an mp3 should be acceptable, especially since in this case, one is listening to the quality of the musician, rather than the audio.

An interesting feature would be to allow musicians the ability to record right onto their profile. Because this service is meant to be used by both amateur and professional musicians, there should be no reason that a user is limited to purchasing or downloading a Digital Audio Workstation or other recording software to be able to use one of the main features of the service. Again, to optimize for fast load times, a recorder would not be integrated into the profile itself, but would be featured as a separate in-browser application available through the website. A full-featured DAW would take too many resources. Instead, a simple recording interface would be set up, allowing one track to be recorded at a time, and featuring a built-in metronome and pre-click. The user would have to set up their input device, be it a built-in computer microphone, or an external one plugged into the line-in jack. Afterwards, they could choose to monitor the input in real-time while recording, requiring them to utilize earphones or speakers. The last step would be to turn on the metronome if the user desired it, and press record. The recordings would automatically export as mp3s, and the interface would give the user the option of downloading the recording and saving it to their local hard drive.

With a feature like this in place, more users would be able to make full use of the service, without being forced to invest time or money into acquiring a potentially difficult-to-learn DAW. At the same time, those who have these resources would be able to use them without resorting to the simplistic in-browser recorder.

Possible Challenges II: Privacy

In this post, I want to continue my talk on possible challenges this networking site could face; specifically, privacy.

Though not as detailed as MySpace or Facebook, this social network will still contain a certain amount of personal data; data that users might not want certain parties to read. The easiest way to do this, of course, is to set filters on searchable information, much like Facebook has done. With Facebook’s filters, users can set their information to be viewable by a customizable range of people; from the public, to only friends, to even only certain users. Further options enable the user to choose to index his or her profile for search engines, allowing the user to opt out of having his profile show up on a Google search. This works out great on a purely social networking site, as most people you connect with on Facebook or MySpace are (hopefully) people you trust and/or know in real life. Where it gets tricky is a site like this one, where a user has to be able to allow other users to search for him or her and view the profile for compatibility with other musicians, while also being able to restrict certain information from coming up in a search. While a street address is certainly a handy thing to have on your profile, to make sure you’re within acceptable commuting range of another band, you might not want it displayed to absolutely everyone who searches for guitarists in your area. The tricky part is in letting people know how and when to use these tools, rather than the tools themselves. As mentioned before, simple filters can allow for a huge range of customizable privacy options. However, users might not necessarily make use of them fully, and when trouble arises, I, as the creator and manager of the site, could be held liable.

An easy, if annoying solution, would be to force people to go through an interactive tutorial at the time of registration to learn about privacy tools available to them. If that’s asking too much, it’s always possible to make this tutorial optional, and have legal language explaining that if the user opts out of using a tutorial, we are not to be held liable for information that ends up in the wrong places.

Next post, I’ll hopefully get into some input/output stuff; more specifically, the inputting of recorded audio as music samples, and how best to have other users hear this media.

Possible Challenges?

Last week, I briefly touched upon my networking idea facing challenges that were faced by all social network sites, but did not really delve into it too deeply. This week, I’d like to do precisely that: flesh out the kinds of troubles other have faced, question if I’ll face those same challenges, and explain how I would solve them.

Perhaps the largest challenge is building a simple, effective user interface: one that displays all the information a user needs in a concise, uncluttered manner. One of the main turn-offs that sent MySpace on its death-spiral was the messy, cluttered profile layout. With the ability to add HTML instructions, users could customize their profiles with banners, animated .gifs, and embedded video. Added to that were the MySpace music player (a clunky embedded Flash object) and many ads.

The above example illustrates two ineffective solutions to two problems that all sites face: how to provide a user with enough control to personalize their profiles, and how to come up with revenue to sustain the site. As far as customization, I am for the idea of providing the user just enough control to fill in the blanks on a common template, especially when it comes to a service tailored towards working musicians. As stated previously, there would be allowance to put in biographical information, work experience, and a music player for work samples, with the actual files most likely hosted by a third party like SoundCloud.

Obviously, the hope is that this network grows to encompass thousands, if not millions, of people, but handling all that traffic requires revenue. The most common way to acquire revenue is through hosting ads. However, users don’t like ads cluttering their interface. This problem could be tackled in a variety of ways: We could charge a fee for premium services offered by our site: perhaps access to industry databases, assembly of press kits for bands to offer to record labels and management agencies, or even access to professional contacts like printers and graphic artists. This could be supplemented with ad space. A more specific solution to the problem of revenue is hard to give without actual numbers on usage. These are general solutions to a problem that's likely to come up.

I don’t want to write too long a blog post, so I’ll save my talks on privacy for later in the week. Though I doubt anyone but my TA is reading this, I’ll go ahead and say that any comments are welcome; especially those that question my logic and require me to flesh out my ideas more thoroughly.