May 4th, 2009
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.
Tags: dev
Posted in feature | No Comments »
April 19th, 2009
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.
Tags: extension
Posted in feature | No Comments »
April 14th, 2009
These allow more filtering on friend-activity stream (/stream when logged in).
New GET parameters:
- noannounce
- hides announce-type updates entirely from friend stream. (announce-type updates broadcast an experience state; ie user is watching title)
- unspoil
- adds announce to class, and does not include message in h3 tag, rather it is in the title attribute. (message can be seen by hovering over the item)
- noself
- show only friend/follow updates, hides logged user’s messages. Previously known as self=0
Other updates:
- The stream now perceives and handles ! (group) and # (hashtag) operators accordingly with separately indexed tables.
- Views and statistics on these operators are not yet built.
- URLs over 48 characters in length are shorted with the is.gd service.
- @ operators convert to inline links in message formatting
- @ operators inline are not yet perceived/indexed in a table (the table exists).
Tags: microstream
Posted in feature | No Comments »
April 11th, 2009
Context-designated microblogging, as described here, is generally a superset of the OpenMicroBlogging specification. The notion comes from the concept of contexts which are microblogged about.
Assumptions
We assume the non-grammatical understanding of the word, context, and point towards the notion of context within a computer system or application. In this light, context will represent the topic or target of a user’s notice or an event stemming from a user action. For our purposes context, topic, and target may be used interchangeably (terminology is adjustable, but the idea stands as topic/target/context sensitive/aware/designated microblogging).
Read the rest of this entry »
Tags: microblogging
Posted in technical | No Comments »
April 11th, 2009
While viewing friend activity is a relatively simple find (/stream or /dashboard), the question of replies must also be answered.
Because the stream is contextual, users are treated as a context and thus replies can be viewed through the api as a normal activity call.
http://dev-api.melative.com/xml/activity?user=RyanA&style=1
style=1 is added for xsl processing. In this way, replies are quite easily retrieved.
Tags: microblogging, stream
Posted in Uncategorized | No Comments »