August 7, 2009

Recent Profile Changes

Today we added a couple new preferences to user profiles, timezone and language. There is currently no use for these, but the likely uses are as follows.

Language

Languages are internally defined using ISO-639 and this originally applied to the title names. Eventually, there will linkage between a user’s language preference and the primary titles that appear on various pages (except on another user’s Experience Library).

A second usage of the ISO languages will be in variations (pages), which we will be able to select the proper page based on language preference. This is nothing new/special and it might be wise to route entire subdomains to various language versions of the site (similar to Wikipedia). It’s still undecided, but the page data will be portable.

Timezone

There are only a few areas which allow custom timestamping, but timezone selection will aid in adjusting properly to UTC. Currently, user-timestamped entries are expected to be adjusted to UTC (or rather, the system does not compensate if the ts is not UTC). This preference is more of a helper function, rather than a feature, and simply adds a bit of transparency to user location.

Notes

Custom timestamping is currently available through Microupdates and setting Experience. All other events should be timestamped to UTC.

July 26, 2009

What Is Melative?

I had a chat conversation with blogger, ghostlightning, discussing melative, and one piece that stuck in my mind was this.

if you don’t mind me saying, the principal problem is that melative is competing with many services

primary value proposition being its one-stop shopness, full-service

I understand this, because it appears that every feature which exists on melative, is enabled for 15 major forms of entertainment*, thus competing with the music sites, the book sites, the movie sites, anime, manga, whatever.

This is the wrong focus. Melative, as a whole serves only a few purposes:

  • express and catalog experiences on entertainment works
  • semi-semantically index meta information on entertainment works
  • do it socially [on entertainment works]

The problem is, users go to 5-6 different sites to accomplish the same task; log an experience, note about it, rate it, tag it, and find other works to experience. All the while, melative can and does exactly this, in new and conceptual ways; we’re always thinking of new ways to interact with entertainment media.

The real question/problem is, are users compelled to separate their experiences between mediums? It is rather questionable because, experience is not bound to medium. Once an experience has become part of the viewer/reader/listener, do we honestly contemplate it as a seprate ‘kind’ of experience? Is there any need to do so?

A great album. A great book. A great film. A great manga. A great opera. A great …

Experience is Boundless

Melative is about the Experience.

Notes

*Is this arguably not a benefit?
Entertainment works, should generally not include ‘Events’, but as with entertainment, arts and events, such as competition or live experiences, still provide an experience.

July 23, 2009

Late July Addendum

Items on the waiting list.

  1. New front page layout and information
  2. Creator/Character pages (via search and relation)
  3. remove.association API method
  4. Stream extension bugs (0.1.4.8)
  5. User statistics on /timeline
  6. Insert tracking (partially the additions API method)
  7. Variation data/field sizing (which titles are most complete)
  8. Cron jobs to remove invalid @replies
  9. Apply new stream parsing class
  10. Reflections view (similar to associations)
  11. Stream item editing (context, timestamp, message)

Various involvement level, but I’m terrible at judging what to do first versus what will accomplish the largest gain. So let’s see if we can be vocal. Some of the more important issues are items 1, 4, 7, and 8, because they affect currently operating methods (although a front page is needed for aesthetics… important, but I’m terribly inefficient. New items would be 11, 9, 5, 3, and 2. These tend to take the longest time because they lack API methods and the interface (having a method makes things quicker). So what’s left? Items 6 and 10, both which have existing methods, but need interfaces.

Now let’s take a look at the important ones, in terms of time-consumption (I’m sitting here wasting time writing this.. lol).

  • Front page: This will take a while given that styling is not my forte in any situation (even if my life was on the line).
  • Extension: I actually enjoy this, and though development goes very quick, there is a tendency to over-progress for the good of time. Still, these are quick fixes.
  • Data completion rating: This would be 1-2 days for the proper db scheming, but it only requires GET methods. Given this would be useful for editors, I’m sure they could work with a very basic XSL overlay (hopefully).
  • Removing phantom @: Right, this would be rather quick, since it is all in the DB and there is no need to have proper classes etc to perform maintenance (nothing would get finish otherwise).

Taking care of @replies, the extension, and the front page seem to be the most immanent and reasonable on time.

Updated 2009 Aug 28: crossed items which have been taken care of.

July 21, 2009

Quantity Scrobbling

We’ve been thinking much about scrobbling. Melative will not, in the foreseeable future, be a scrobbling site, though given the API of the contextual microblog, it could very-well be used in such a fashion at the moment. This decision comes after pondering the nature of scrobbling, while simultaneously defining the stream as textual scrobbling. From here, scrobbling refers to quantity scrobbling, the type generally used on Last.fm and elsewhere.

So what is the problem with scrobbling on melative?

  1. Generally, while we may be competing with sites like Last.fm, development sees no advantage in competing with scrobbling. If you like listening to music, we advocate Last.fm, but if you like expressing how you feel about music, you may enjoy melative’s textual scrobbling. In short, scrobbling is thoroughly developed elsewhere and information resulting from scrobbling is available through APIs.
  2. Scrobbling is quantity based, and therefore must be assessed on the basis of popularity and favorites, rather than the focus of quality. The albums we experience most often, are generally not the ones we have the highest regard for. Melative is about assessing quality versus popularity, though popularity is addressable in similar ways.
  3. For music, scrobbling is quite fitting, but when we take into account the 15 other forms on melative, quantity loses meaning. Thinking about the experience of art, theatre, or events, expressing more than one encounter does not add value to a user’s experience profile; experiencing a work once is often sufficient.

And what of textual scrobbling, where lies the advantage?

Textual scrobbling is a matter of expression through actions and words. While experience may be implied, there is an accompanied assessment either through simple actions or reflective sentences within the textual scrobbling event. This is perhaps the major intent of the melative stream, though fully, it is intended to provide a consistent method for interacting with works of art and entertainment.

May 4, 2009

Stream Item Visibility

Working on the various modes, but here is the gist and features!

What we want

Single-item visibility toggles allowing users to set an item visible to a given set of users or group. On top of this, we want users to have default preferences based by the 14 media, creators, characters, and possibly when replying to users.

Suggested Visibility Modes

everyone
update can be seen by anybody in any stream view
user
update can be seen by all users in any stream view
follower
update is only visible to followers (1-way friends)
friend
update is only visible to friends
hidden
update is visible to friends, but not displayed on their stream view
locked
update is not visible to any other party
group
update may be public, but only displayed in the group view

Now we can see that group posses a problem, since the user may wish to have the item posted only to a group, but not viewable in their public stream, or the group stream view. What this allows is that friends within a given group may share updates without joining the entire group stream. (This would require the friends be part of the given group)

At this time, there is no integration between the friend stream view and group views. This may continue as two separate views; the user viewing all or one of the groups to which they subscribe and the user viewing their friends’ activity.

It is necessary to mention the default user preferences when they post. Given the 14 media, creator, and character contexts, it is possible to set the default visibility per context-type. A user may have all their events visible by default, but can specify certain contexts to be friends-only or entirely private. In this situation, the default preference should be submissive to an override field in the action/announce API methods. Thus allowing select items to have a visibility outside of the user’s prefs.

I like it. Now writing the backend to change a user’s updates when they switch preferences will not be fun for the db, but it’s entirely doable. It should also be noted that the user needs the ability to change stream item visibility at will, though changing from public to private will not be advised since the visibility may still exists through feed caches or other node subscriptions.

« Older Entries
Newer Entries »