November 29, 2009

Segment Ratings

After suggestions from @kokuun and @chikorita157, segment ratings were considered and the schema was modified to allow such ratings. Today, a hook was added to the microblog which checks for rating text within an update on a segment.

Microblog Parse

In order to make a rating through the microblog, the update must include ‘rating:’ (case-insensitive) followed by a rating. The format for segment rating varies, but the rules are basic.

Rating Format

First, it should be addressed that segment ratings are normalized to a 100-tier system, s.t. 88% = 88/100, 8.8/10 = 88/100, etc. The numbers which are used in the rating do have effects, especially when the /Max is not included.

When /Max is included:
The rating is calculated as Value/Max and normalized to Max=100. If rating 8/10, this will equate to 80/100.

When /Max is not included:
If the Value is less-than or equal-to 10, the base is considered to be Max=10, then normalized. If the Value is greater than 10, the base is considered to be Max=100.

Unless your Max is always out of 10 or 100, it is best to use the /Max for accurate ratings.

Valid Rating Examples:
6/12 = 50/100
5/15 = 33/100
18/20 = 90/100
47/50 = 94/100

8.1/10 = 81/100
3.51/10 = 35/100

Note: If a decimal results, the value is floored.

What is a segment? A segment is a sub-section of a context, or title, such as a track to an album, an episode to a tv/anime series, or a chapter to a book/manga.

October 4, 2009

Micros in Federation

As previously noted, Micros is the microblogging running inside Melative, and one of the major goals is cross-domain compatibility and fluidity; aka Federation. Rather than build something similar to OpenMicroBlogging protocol, we decided to design a specification protocol which the microblog will use to solve this problem of cross-domain following. (Just for reference, any publishing software can use the specification, it’s open and being fleshed)

Here, I’d like to address 4 aspects of the service to help enrich the understanding of this Federated specification, as well as the solution and benefits it provides.

What problem does Federated micro-publishing solve?

  • Social services may only be used with valid usership
  • Social relations may not be established without mutual usership (centralization)
  • Social services are closed, by nature (one must have an account)
  • Social services are centralized (e.g. thedomain.com)
  • Users are following other rules (e.g. site agreements)
  • There is no freedom, as there are always requirements (e.g. usership)

How is this a unique solution?

  • Decentralized (users on any domain may be part of the social-sphere)
  • Federated (users may establish relations without regard for central usership)
  • It’s a specification
  • It’s an open protocol
  • It’s adaptable and customizable

We are only implementing a version of what is possible through the API specification. Other developers may create their own platforms which will interact in the same fashion. The aim with Micros is a publishing platform, similar to a blog, but extensible through theming and plugins. The core of Micros will be a hooking environment in which 3rd party scripts may execute.

Is there evidence that this works?

What sort of business model does it cater?

  • No central ownership
  • Specification provides an infinite platform
  • Open development
  • 3rd party applications
  • 3rd party features
  • Potentially massive user-base (the Internet)

The importance in the business model is that the specification allows developers/vendors to create their own pay/private services, which still enables interaction with the social-sphere. Also open is the area of customizations, similar to Wordpress’s flourishing theme/plugin base.

In summary, we are modularizing the microblog to fit this specification in hopes of building a larger, open social publishing network that may be used regardless of usership and domain.

September 19, 2009

Micros, Melative’s Microblog

For now, the name is Micros.

The microblog on Melative is perhaps one of the most familiar features for users, but with the amount of attention and development that goes in, there must be something more.

What is the Micros?
Micros is a textual interface for micro-updates, which also allows inline commands on context-types, or what we call textual scrobbling. Textual, for the scrobbled update (e.g. ‘listening to /music/Crooked Rain, Crooked Rain/track/Gold Soundz.’) may also have a message appended to the event (e.g. ‘listening to /music/CRCR/Range Life. We should all strive for a range life.’).

It may be seen as a status-update type interface, but there is special nuance between “status-update” and “microblog” (here is a clear explanation which I find handy). When we consider textual scrobbling containing message content, it is much more fitting to be called microblogging than status-update. The key here is “content,” or more specifically publishing content.

At the top level, Micros aims to be more akin to WordPress, in that it allows content publishing, but in a micro manner. This similarity also is aligned with the notion of being open-source and allowing decentralized installations.

Why is Micros important?
As we develop this feature more, we are aiming to extract and modularize it as a standalone application, while still allowing interface commands to have value on the Melative experience engine (organizing, categorizing, interacting with a user’s media library).

At the same time, the system will be built for near-real-time notifications across domains, yes cross-domain following/subscriptions/@replies.

We feel, that in this age of communication, there is little reason to centralize micropublishing to a few large, closed1 channels (Facebook, Myspace, and Twitter), where there is no inter-channel communication without valid usership on each service.

Simply put, Micros is a blog which will notify subscriptions in near-real-time, without the need for centralization (those who are subscribed on various domain/nodes will receive the content directly).

Notes
1 – Closed in the sense that non-users may not interact, this is the opposite for Wordpress, which allows non-user commenting. Micros will allow non-user following, where the event (an XML packet) is sent to subscribed nodes.
-There are other features behind the system, such as scrobble-anything and exact context-referencing, but they are slightly more specific to the experience engine (allowing logging, linking, rating, tagging, wishlisting all from the microblog).

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.

April 19, 2009

Firefox Stream Extens

Version at 0.1.3.4

Will use this post as a feature/bug track (really shouldn’t).

Download is here. Extension is update aware, so further versions will be available without direct download.

Some initial issues:

  • stream is blank when not logged in
  • not aware of disconnect/no auth
  • no way to announce to stream (see note)
  • cannot delete update directly from extension
  • no title suggestion on context box
  • no preference dialog
  • relative time does not update (no time shown)

Anything else?

  • There is no method of filtering announce vs non-announce updates (client-side)
  • There is no smart message length awareness (with http-link calculation)

Features

Announce

Currently the extension supports actions and announce. Announce may also be given basis/range by way of title format. The benefit of announcing is that it is treated as a special action, and though it is intended for media player plugins and scripts, there is no issues using manually.

To announce an experience, the action must be from the -Announce- section of the select box. The context type must be of a media-type, and a title must be give. The format for including basis/range (ie. episode 06) is as follows:

TITLE@BASIS:RANGE

Where TITLE is the name of the work, BASIS is of:

  • arc
  • chapter
  • episode
  • issue
  • part
  • season
  • segment
  • track
  • volume

RANGE is allowed variable characters up to 32. Example:

Gone With The Wind@chapter:05

Announce is important, as the stream can be filtered of announcements or unspoiled, in order to hide messages contained within announcements. While these filters are not available yet in the extension, the backend supports it. Announce is also important as it is a way in which to inadvertantly log experiences to corresponding states. One example would be if a user announces they are watching a series at given episode it will set their experience to current if there was no previous experience state.

Sticky

As of 0.1.3.4, there is a Stick checkbox, which is suitable when wishing to update on the same context (esp. announce) multiple times. Stick keeps the panel open and does not clear the context-name, type, or action fields upon posting. Minimizing/hiding is also disabled when sticky.

The advantage is that title@basis:range information need not be entered more than once. This does not change the necessity of a title Suggest panel, but it does help.

« Older Entries