Hello, hello! So we are starting to see more user activity, but for new users much of the system may still seem foreign or missing something. So if you have any feature requests about the web interface, a plugin, or extension, do leave a comment.
If you need more assistance with the site, we’re usually available in the #melative channel on freenode.
Dev
Am I really the first? Since August?
Anyway, the first and most important thing, melative must become simpler. The back-end can be however it needs to be, but the front-end must be ‘essential only’ as in web 2.0. There are a way too many things on the screen. I would suggest you to read this post and try to do something.
Then, I think there is no need for the ‘add friend’ function — mutual followship is more than enough.
And for me personally, a better API documentation would be not bad.
And at last, perhaps I can contribute to the project? I was coding my own MAL-clone when I found out about melative, and meanwhile I think I should offer you my help instead of doing something nobody needs anyway.
Well, and everything else I will tell you in the chat if I happen to catch you online.
Simpler indeed. Thanks for pointing to this article I will definite take in.
On the Add Friend function, you are very correct. In fact, the underlying platform (Nuclear) which provides that functionality has been undergoing large changes and the “friend” feature was on the wall. (The changes being Federation) Much clearer with that suggestion.
API Documentation is very important, agreed, since that is generally what the system is.
Ah I see. Well come play, you will be welcomed!
Melative’s goal wasn’t quite like MAL from the start, but it has evolved into more abstract “cores” which is a good thing. I recommend this page for more info http://blog.melative.com/composition-of-melative
And oh, vey!, I have forgotten one of the most important things: Is there watched/max episodes count? If no, there should be, because using a service like melative or MAL is above all using it as a bookmark, to not need to remember where you stopped. The reason why I’m asking, the api/library request doesn’t tell the media’s lenght and the user’s current progress.
It’s very interesting that this wasn’t originally planned, but evolved with the microblog pinning format: /media/name/segment/name. – /anime/Black Lagoon/episode/12.
Within the Context service, media-types are called context-types, and titles, or entities/contexts, are defined by type-name pairing. Multiple names can be associated with a given ID (aliases). That takes care of the overall media, although the system can define any new type (event, food, place, person, etc) very quickly.
The episode/## portion is called a segment, also handled by the context service. Contexts have segments, of which the larger entity is composed. This fits entirely natural for most mediums when we thing about chapters, tracks, episodes, and volumes.
A segment is defined by type-name as well, only it is not handled with contexts. Whenever these are referenced in the system, they are automatically defined/identified.
One of the recent goals is to enabled identification of segments, so they pre-exists, and completion ratios may be achieved. (Of course it is more technical, but we can discuss in chat). Partial solution atm http://melative.com/RyanA/library/anime/Saki