Difference between revisions of "GnukeBox/design"
< GnukeBox
Jump to navigation
Jump to search
(saving work) |
(moved nontech stuff back to main page) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | {{title|GnukeBox Design Specification}} |
| − | + | ==Status== | |
| − | + | This is a first pass at laying out the overall design and fleshing in some of the details. It has not yet been reviewed by any other team members, and I expect it will change and evolve considerably before implementation. | |
| − | + | ==History== | |
| − | + | * '''2013-09-17''' key features discussed in email | |
| + | * '''2013-09-22''' started work on first wiki page version of design spec | ||
==Introduction== | ==Introduction== | ||
[[GnukeBox]] is a software application intended for multiple platforms, with emphasis on mobile devices and entertainment hardware. It will have both standalone capabilities and capabilities requiring support from a server back-end. As many features as possible should remain available when the internet is inaccessible. It will also have the ability to generate collections of media which can be played without the application, subject to licensing restrictions. | [[GnukeBox]] is a software application intended for multiple platforms, with emphasis on mobile devices and entertainment hardware. It will have both standalone capabilities and capabilities requiring support from a server back-end. As many features as possible should remain available when the internet is inaccessible. It will also have the ability to generate collections of media which can be played without the application, subject to licensing restrictions. | ||
| − | + | ==Design== | |
| − | + | * [[/client]]: the client will be available on multiple platforms | |
| − | + | * [[/server]]: each server is a "node" to which clients can connect; servers share data with each other | |
| − | + | * [[/db]]: database design | |
==Features== | ==Features== | ||
Its features can be broadly categorized as: | Its features can be broadly categorized as: | ||
| Line 20: | Line 21: | ||
* play tracks | * play tracks | ||
* play videos | * play videos | ||
| − | + | * artist-configurable: | |
| − | * | + | ** restrict playlist |
| + | ** customize presentation layout | ||
| + | ** skinnable | ||
===Commerce Features=== | ===Commerce Features=== | ||
* sell mp3s | * sell mp3s | ||
| Line 28: | Line 31: | ||
* sell event tickets | * sell event tickets | ||
* show advertisements from 3rd parties | * show advertisements from 3rd parties | ||
| + | * crowdsource investment in artist projects | ||
| + | ===Informational Features=== | ||
| + | * performance schedules | ||
| + | * artist catalogue and planned releases | ||
===Social Features=== | ===Social Features=== | ||
| − | * build fans using Facebook, G+, and Twitter | + | * build fans using Facebook, G+, and Twitter (how?) |
* interoperate with G+ Hangouts somehow | * interoperate with G+ Hangouts somehow | ||
* listener ratings | * listener ratings | ||
* listener commenting | * listener commenting | ||
| − | We will probably need some kind of reputation management | + | We will probably need some kind of reputation management too... this could easily turn into its own social network, complete with a need to minimize spam, trolling, and other abuse, so this aspect of the design should be approached with caution. It may be that we will want to make that a separate phase of the software's development. |
That said, as simple way to minimize trolling, as a stop-gap, might be to only allow ''customers'', or those who have paid memberships (e.g. to make the ads disappear), to post comments. | That said, as simple way to minimize trolling, as a stop-gap, might be to only allow ''customers'', or those who have paid memberships (e.g. to make the ads disappear), to post comments. | ||
| − | There are open-source | + | There are open-source swarmable social networks that could be adapted, which would further allow us to take advantage of the network effect to gain publicity. [http://friendica.com/node/59 Red]/[http://getzot.com/page2.html Zot] looks especially promising, and should be ready to use by the time we are ready to implement social networking. |
| + | ==Data Design== | ||
Latest revision as of 23:06, 9 February 2014
Status
This is a first pass at laying out the overall design and fleshing in some of the details. It has not yet been reviewed by any other team members, and I expect it will change and evolve considerably before implementation.
History
- 2013-09-17 key features discussed in email
- 2013-09-22 started work on first wiki page version of design spec
Introduction
GnukeBox is a software application intended for multiple platforms, with emphasis on mobile devices and entertainment hardware. It will have both standalone capabilities and capabilities requiring support from a server back-end. As many features as possible should remain available when the internet is inaccessible. It will also have the ability to generate collections of media which can be played without the application, subject to licensing restrictions.
Design
- /client: the client will be available on multiple platforms
- /server: each server is a "node" to which clients can connect; servers share data with each other
- /db: database design
Features
Its features can be broadly categorized as:
- media
- commerce
- informational
- social
Media Features
Gnukebox will play individual tracks and videos as well as playlists.
- play tracks
- play videos
- artist-configurable:
- restrict playlist
- customize presentation layout
- skinnable
Commerce Features
- sell mp3s
- sell physical goods (music/video media and tie-in merch)
- collect email addresses
- sell event tickets
- show advertisements from 3rd parties
- crowdsource investment in artist projects
Informational Features
- performance schedules
- artist catalogue and planned releases
Social Features
- build fans using Facebook, G+, and Twitter (how?)
- interoperate with G+ Hangouts somehow
- listener ratings
- listener commenting
We will probably need some kind of reputation management too... this could easily turn into its own social network, complete with a need to minimize spam, trolling, and other abuse, so this aspect of the design should be approached with caution. It may be that we will want to make that a separate phase of the software's development.
That said, as simple way to minimize trolling, as a stop-gap, might be to only allow customers, or those who have paid memberships (e.g. to make the ads disappear), to post comments.
There are open-source swarmable social networks that could be adapted, which would further allow us to take advantage of the network effect to gain publicity. Red/Zot looks especially promising, and should be ready to use by the time we are ready to implement social networking.