1,633
edits
mNo edit summary |
mNo edit summary |
||
Line 1: | Line 1: | ||
{{TOCright}} | {{TOCright}} | ||
This page is for general ideas/thoughts about the future of AniDB. How should it evolve, what do we want, what should we prioritize, etc.? | This page is for general ideas/thoughts about the future of AniDB. How should it evolve, what do we want, what should we prioritize, etc.? | ||
Line 19: | Line 20: | ||
==Features== | ==Features== | ||
Also see [[Development]]. Most important | Also see [[Development]]. Most important ATM is [[Generic PersonCompany DEV]]. | ||
===Reviews=== | ===Reviews=== | ||
Our reviews are not considered to be very good (citations needed..). The problem might be that we currently fail to separate the good ones from the bad. Since the reviews are sorted by rating it is important that the rating system work, which it doesn't | Our reviews are not considered to be very good (citations needed..). The problem might be that we currently fail to separate the good ones from the bad. Since the reviews are sorted by rating it is important that the rating system work, which it doesn't ATM (at least with few votes). ''Latest reviews'' shows the low interest for review rating. How can this be improved? | ||
Suggestions: | Suggestions: | ||
* Higher visibility of reviews: New reviews have high | * Higher visibility of reviews: New reviews have high visibility on the main page already, but the question is how high visibility does the main page have? It might help to improve the anime page too. For example, show parts of one random review, show latest reviews for that anime, Ajax, etc. | ||
* Allow titles for reviews and display them in ''latest reviews'' and possibly on the anime page. Gives the reviewer the ability to "sell" his/her review. | * Allow titles for reviews and display them in ''latest reviews'' and possibly on the anime page. Gives the reviewer the ability to "sell" his/her review. | ||
* Reward users that provide constructive feedback. Possibly a new ''review moderator'' role / karma. | * Reward users that provide constructive feedback. Possibly a new ''review moderator'' role / karma. | ||
* Hide disapproved reviews from the default review page to lower the visibility of the crap reviews. | * Hide disapproved reviews from the default review page to lower the visibility of the crap reviews. | ||
* Add ''quick reviews'' or ''anime comments'' to give the less | * Add ''quick reviews'' or ''anime comments'' to give the less committed the ability to share their thoughts without attempting to write full reviews. | ||
* Give the | * Give the reviewers the ability to customize the style (CSS) of their reviews. | ||
===TCP API=== | ===TCP API=== | ||
The content of AniDB should be open and free for everyone to use. We should therefore also make the TCP API public, or at least parts of it. Instead of worrying about people "stealing" our data, we should rather | The content of AniDB should be open and free for everyone to use. We should therefore also make the TCP API public, or at least parts of it. Instead of worrying about people "stealing" our data, we should rather appreciate the users we have and "give something back" to them. Our strength is not the current content, but the users who contribute with new data every day. And if we were to be considered the most serious source of information related to anime (open and free), we would surely only gain contributors, not lose them. Scrapers would have a "right" way to do it, instead of leeching here and there, now and then, by using the site / MyList export / UDP API. | ||
We could alternatively define a new API. | We could alternatively define a new API. | ||
Line 39: | Line 40: | ||
Suggestions: | Suggestions: | ||
* Open the API (or parts of it) and remove the requirement to encrypt stored data. | * Open the API (or parts of it) and remove the requirement to encrypt stored data. | ||
* Separate file info from the rest of the data: The file info stands for the biggest chuck of data and is for many not really interesting. By separating we lower the barrier for implementing | * Separate file info from the rest of the data: The file info stands for the biggest chuck of data and is for many not really interesting. By separating we lower the barrier for implementing TCP API clients and open for possible performance gains. (The file part could remain non-public if wanted.) | ||
* If performance is a issue we could constrain the open part to only support dumps and not 100% up to date data. Possibly introduce hourly dumps. | * If performance is a issue we could constrain the open part to only support dumps and not 100% up to date data. Possibly introduce hourly dumps. | ||
edits