[Ideas] Wishlist/Togetlist/Towatch list [DONE]
Moderator: AniDB
[Ideas] Wishlist/Togetlist/Towatch list [DONE]
Well,
this is one of the top entries on my todo list atm, but i don't have the perfect idea how to implement this yet.
so feel free to spam all your crazy ideas into this thread.
BYe!
EXP
this is one of the top entries on my todo list atm, but i don't have the perfect idea how to implement this yet.
so feel free to spam all your crazy ideas into this thread.
BYe!
EXP
Last edited by exp on Thu Sep 04, 2003 10:55 am, edited 1 time in total.
-
- Posts: 1296
- Joined: Sun Nov 17, 2002 9:08 pm
- Location: The Pampas, The land of the Gaucho!
- Contact:
Wish = desire to get it
Needed:
- A new 'wish' table @DB where you relate User ID and aniDB ID.
- A myWishlist page where you list this values in a nice way (with links to anime's pages).
- The list must have a check-box selection to remove animes or they can also be removed automatically when adding an anime to your list.
- You can set any anime as a wish with a new button in the anime page.
There is no need to have a Towatch if you don't have the anime. IMO this fits in the 'wish' feature.
Making it more complex is not needed IMHO. I think most people want to have a list of animes they will get in some time (when they have bandwidth or wishing to see something new).
If we're talking about anime not added to aniDB that's another thing... and quite complex I think.
Needed:
- A new 'wish' table @DB where you relate User ID and aniDB ID.
- A myWishlist page where you list this values in a nice way (with links to anime's pages).
- The list must have a check-box selection to remove animes or they can also be removed automatically when adding an anime to your list.
- You can set any anime as a wish with a new button in the anime page.
There is no need to have a Towatch if you don't have the anime. IMO this fits in the 'wish' feature.
Making it more complex is not needed IMHO. I think most people want to have a list of animes they will get in some time (when they have bandwidth or wishing to see something new).
If we're talking about anime not added to aniDB that's another thing... and quite complex I think.
Why so complicated? Just abuse the mylist... 
Add a new state-value along with unknown and deleted: "to do".
Files that are "todo", as well as episodes and animes that consist exclusively of "todo" files are hidden from the mylist. These files also do not count towards the EP and Seen count and are excluded from the MyStats. In other words, files that are "todo" don't show up in the mylist and don't change any of the stats anywhere on anidb.
As an addition to the mylist, add a "MyWishList" header to the right part of the list with a "show wishlist" link. When clicked, the wishlist's behaviour is inversed: Only those animes and episodes that contain "todo" files and of course these files are shown in the list. The "MyList" part of the right menu collapses into a single "show mylist" link and instead the "MyWishList" menu is expanded to show the usual mylist links, minus "hide incomplete", "hide complete" and "hide viewed".´
Unless I forgot something terribly important, this should satisfy everyone's needs, while it's at the same time very easy to implement in the DB (alter a single enum?) and requires only a few superficial UI changes. Most of the logic for hiding mylist entires is apparently already there (the "hide (in)complete" feauture), so it looks like that part is a copy&paste job. The biggest problem will be updating all other elements of AniDB that read the mylist, such as the various stats.

Add a new state-value along with unknown and deleted: "to do".
Files that are "todo", as well as episodes and animes that consist exclusively of "todo" files are hidden from the mylist. These files also do not count towards the EP and Seen count and are excluded from the MyStats. In other words, files that are "todo" don't show up in the mylist and don't change any of the stats anywhere on anidb.
As an addition to the mylist, add a "MyWishList" header to the right part of the list with a "show wishlist" link. When clicked, the wishlist's behaviour is inversed: Only those animes and episodes that contain "todo" files and of course these files are shown in the list. The "MyList" part of the right menu collapses into a single "show mylist" link and instead the "MyWishList" menu is expanded to show the usual mylist links, minus "hide incomplete", "hide complete" and "hide viewed".´
Unless I forgot something terribly important, this should satisfy everyone's needs, while it's at the same time very easy to implement in the DB (alter a single enum?) and requires only a few superficial UI changes. Most of the logic for hiding mylist entires is apparently already there (the "hide (in)complete" feauture), so it looks like that part is a copy&paste job. The biggest problem will be updating all other elements of AniDB that read the mylist, such as the various stats.
That's true, in the end it doesn't matter if the thing is integrated into the mylist or if it's a separate feauture.
Now the question is whether it should work for entire animes or single files. Single files has the advantage that you have a much finer granularity and can, for example, use it to queue up your future eMule downloads. If it works for entire animes, you don't have to figure out which files to download when you just want to remember yourself to get that anime.
Both sides are certainly of interest, so maybe the "best" would actually be a combination of the mylist hack, the separate wishlist and the notifies. (Ouch, this is getting adventurous...)
Let me develop that idea from the start once again...
First, add a file state to the mylist that makes it ignore that file in all stats. Add a show/hide feauture so that users can easily view all these ignored files separately from the rest of their mylist.
Second, the wishlist can easily supersede the notifies feauture. Simply hack the notifies feature sp that the notification can be turned off for single animes and modify the UI: Instead of notifies or wishlist, call it watches. The "notify" link in the anime view gets a companion to make it two links, "remember" and "remember and notify". When an anime is remembered, nothing happens. It simply appears in the "mywatches" list. When the notification is on, the "watch" behaves just like the notify does now.
I'm just trying to get the most out of the already existing feautures...
Now the question is whether it should work for entire animes or single files. Single files has the advantage that you have a much finer granularity and can, for example, use it to queue up your future eMule downloads. If it works for entire animes, you don't have to figure out which files to download when you just want to remember yourself to get that anime.
Both sides are certainly of interest, so maybe the "best" would actually be a combination of the mylist hack, the separate wishlist and the notifies. (Ouch, this is getting adventurous...)
Let me develop that idea from the start once again...

First, add a file state to the mylist that makes it ignore that file in all stats. Add a show/hide feauture so that users can easily view all these ignored files separately from the rest of their mylist.
Second, the wishlist can easily supersede the notifies feauture. Simply hack the notifies feature sp that the notification can be turned off for single animes and modify the UI: Instead of notifies or wishlist, call it watches. The "notify" link in the anime view gets a companion to make it two links, "remember" and "remember and notify". When an anime is remembered, nothing happens. It simply appears in the "mywatches" list. When the notification is on, the "watch" behaves just like the notify does now.
I'm just trying to get the most out of the already existing feautures...

A per file toget list is really overdoing it, while it might be useful sometimes it generally wont be imho.
When I think of what I want of a togetlist it's basically a notify without the popups, ie a separate list from the notifications where I can check what I've spotted and should download next.
What I'd imagine would be needed for that is:
- An add/remove toget link on the anime page.
- A link to a separate toget list in the myplace.
When I think of what I want of a togetlist it's basically a notify without the popups, ie a separate list from the notifications where I can check what I've spotted and should download next.
What I'd imagine would be needed for that is:
- An add/remove toget link on the anime page.
- A link to a separate toget list in the myplace.
Call it personal taste, but I'd love it. When I decide on which anime I want to eventually get, I add all the files I want to download to my mylist.PetriW wrote:A per file toget list is really overdoing it, while it might be useful sometimes it generally wont be imho.
Since having more then 30 concurrent downloads would stress the server too much (and get me banned from many busy servers), I usually have 6 animes downloading at the same time, 5 episodes per anime, in order to get a decent amount of sources. That means that when one anime is down to four episodes, I can go to my anidb mylist and have the next files to download listed right there...
As I said, it's probably just my personal taste, but a per-file todo list is easily implemented (probably easier then a separate wishlist), so I thought that exp would get the best effort vs. usefulness ratio by choosing that way.

-
- Posts: 312
- Joined: Sat Aug 02, 2003 3:22 am
- Location: Québec, Canada
My vision of Wish-/Togetlist
There is only one Wishlist. It is separated from Mylist. However, it looks like it. The only different is the state: other, on plan, on download and on dramatically download for Wish-/Togetlist. (The state's names should be changed, but I have no idea yet.)
other - The file isn't downloading and it won?t be. Someone is going to the cinema or buy a DVD Video or VHS.
on plan - The file isn't downloading, but it will be.
on download - The file is downloading and there are no problems with sources.
on dramatically download - The file is downloading, but there are problems with sources.
If someone turn on "on dramatically download", every owner of this file see special icon in his Mylist. There is special ranking displaying files with state "on dramatically download" too. I don?t see any need of displaying "on plan" and "on download" publicly. However it could be displayed in file detail.
My vision of Towachlist
There is no need to create separate list. The additional state for "Wached" is enough.
There is only one Wishlist. It is separated from Mylist. However, it looks like it. The only different is the state: other, on plan, on download and on dramatically download for Wish-/Togetlist. (The state's names should be changed, but I have no idea yet.)
other - The file isn't downloading and it won?t be. Someone is going to the cinema or buy a DVD Video or VHS.
on plan - The file isn't downloading, but it will be.
on download - The file is downloading and there are no problems with sources.
on dramatically download - The file is downloading, but there are problems with sources.
If someone turn on "on dramatically download", every owner of this file see special icon in his Mylist. There is special ranking displaying files with state "on dramatically download" too. I don?t see any need of displaying "on plan" and "on download" publicly. However it could be displayed in file detail.
My vision of Towachlist
There is no need to create separate list. The additional state for "Wached" is enough.
That's a good description of the user interface, zaufany, but since you say yourself that the mylist and wishlist look the same, they must obviously track the exactly same data. From a coder's point of view, that means that it wouldn't make much sense to separate them into different lists.
However, even if mylist and wishlist entries are in the same table, that doesn't mean that the user interface can't be split up. I'm all for a separate wishlist page, I was just pointing out that the underlying code is mostly the same for both, so why reinvent the wheel?
However, even if mylist and wishlist entries are in the same table, that doesn't mean that the user interface can't be split up. I'm all for a separate wishlist page, I was just pointing out that the underlying code is mostly the same for both, so why reinvent the wheel?

Well,
I guess the main question is if a wishlist should be anime or file based.
The anime based approach would be the easiest to implement and would prolly end up in a modificated notification page which allows you to enable
and disable notifications and maybe order animes by priority?
would a field for a user comment be usefull too?
the file based approach would mean quite some work, however the main focus here should not lie on the work needed to implement it but on the benefits it would bring to the users.
on the other hand if almost no one would actually use a filebased wishlist anyway that would be something else.
maybe we should think a bit about how different ppl use (would use/would like to use) a wishlist feature?
BYe!
EXP
I guess the main question is if a wishlist should be anime or file based.
The anime based approach would be the easiest to implement and would prolly end up in a modificated notification page which allows you to enable
and disable notifications and maybe order animes by priority?
would a field for a user comment be usefull too?
the file based approach would mean quite some work, however the main focus here should not lie on the work needed to implement it but on the benefits it would bring to the users.
on the other hand if almost no one would actually use a filebased wishlist anyway that would be something else.
maybe we should think a bit about how different ppl use (would use/would like to use) a wishlist feature?
BYe!
EXP