TheDailyReel.com - good example of Plone-based social networking site
Nate Aune
I think this is one of the best examples of using Plone to provide social networking functionality. There is a chance that the company that paid Alec Mitchell to build this site might open source the code, but in the meantime, it's an interesting site to look at just to see their use cases, and what's possible with Plone. I believe Alec is using plone.relations to make associations between filmmakers, producers, actors, fans, etc.
Nate
From: Alec Mitchell <ap...@columbia.edu>
Date: Sat, Mar 22, 2008 at 12:14 PM
Subject: Sorrento
To: Nate Aune <na...@jazkarta.com>, Rocky Burt <ro...@serverzen.com>
Hey guys,
Sorry to hear you won't be in Sorrento. Do you know if any of the
remaining attendees will be capable of leading teams on
Multimedia/Calendaring? Should I remove those from the topics page
and the survey I'm about to send?
BTW Nate, Balazs and I have setup a copy of the TDR site at:
http://thedailyreel.greenfinity.hu
I hope that's of some use to you. There are a bunch of missing
images, so the site is not as pretty as it once was, but the
functionality should be intact. The server is petty underpowered
though, so don't spread that around too much.
Thanks,
Alec
--
Nate Aune - na...@jazkarta.com
company: http://jazkarta.com
blog: http://nateaune.com
twitter: http://twitter.com/natea
Dylan Jay
Plone.relations would be my top choice for implementing a social graph in plonesocial.
The join feature is busted so I can’t see what a member can do L
So if there existed opensocial.socialgraph module for instance. Something that gave a default add, remove to a list of friends. Possbily let you catagorise friends. Would that have helped them? Or would they have had to customize it too much to be useful?
Patrick
Is this done on Plone ? It IS pretty extensive from what I can read in
the description. So looks quite interesting... only all dailyreel
sites are down right now.
What happened to them... read on mashable they've been down forever ?
Quantcast also gives it almost 0 visitor rate ?
Christian Scholz / Tao Takashi (SL)
http://mrtopf.de/blog/plone/plone-conference-2007-video-alec-mitchell-about-ploneapprelations-relationships-in-plone/
So at least plone.app.relations is in the open which is maybe the main part of it.
-- Christian
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T
Nate Aune
Nate
Patrick
Is there a chance they are willing to share ? What would convince
them ? Perhaps good to find out before the Paris Sprint ?
Nate Aune
I suggest that you contact Alec Mitchell directly to see if he can talk to them about open sourcing the code.
Nate
Alec Mitchell
Yes, the site is unfortunately down; though some possibility exists
that it may return, I have no real control over the matter.
Fortunately, most of the stack upon which it was built is open source
and publicly available. The user and group objects were pretty
straightforward objects based on collective.borg/membrane, with
customized registration workflow. The video embedding and uploading
was done using p4a.videoembed and p4a.revvervideo (both developed for
the The Daily Reel). All the discussion areas ("crews", "community
blog", etc.) were based on Ploneboard. The user relationships, "crew"
to user relationships, and the video to user/crew relationships were
managed with plone.app.relations (created in part for The Daily Reel).
During the Naples sprint plone.app.relations further gained the
ability to make user relationships without the need for content-ish
users; so these sorts of relationships should be even easier to
implement now. There are also products like remember and teamspace,
which facilitate some social networking features, though they were not
used by The Daily Reel.
The drag and drop UI used for managing relationships (among other
things) were developed by Balazs Ree using KSS. The plugin used
script.aculo.us, which turned out to be ill-suited for a generic
open-source KSS D'n'D plugin, however the experience gained from that
has likely influenced the new YUI-based KSS D'n'D plugin, which is
publicly available. The inclusion of base2 in KSS was partly a result
of work done in optimizing The Daily Reel.
The things which aren't already open-source are mostly specific to The
Daily Reel's deployment (skins, registration and relationship
workflow, ...) or developed partly outside of Plone (facebook
integration, integration with proprietary video upload services). The
site made heavy use of Zope 3 patterns: Archetypes and other Plone
infrastructure were only used for things that were clearly "content".
I hope the above information is useful. I think developing a generic
Social Networking product on Plone (or any platform) is a much much
more difficult task than developing a specific social networking
product with concrete and limited goals. Tools exist for doing the
latter without too much complexity, the former will require a lot of
new infrastructure and well defined customization paths. In the end,
Social Networking means different things to different people.
Alec
Patrick
Thanks so much for the lenghty explanation. I also feel that to start
with a huge social layer would be a mistake, and I think more on this
forum prefer to grow incrementally and possibly make use of what's
already been developed.
Since you said most of it is open source: would this imply all these
applications can be found on plone.org site ? Is there any
documentation with it as well ? Do you refer to e.g.
plone.app.relations as being open source, or the specific application
developed for dailyreel as being open source ? Likewise with the other
applications you developed already. Or.. are they too specific to be
of any use to anybody else ?
Thanks so much
Dylan Jay
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Patrick
> Sent: Friday, 4 April 2008 6:11 AM
> To: Plone Social Networking
> Subject: Re: TheDailyReel.com - good example of Plone-based social
> networking site
>
>
>
> Thanks so much for the lenghty explanation. I also feel that to start
> with a huge social layer would be a mistake, and I think more on this
> forum prefer to grow incrementally and possibly make use of what's
> already been developed.
Yes. And we'd love to know what else would help people create a another
daily reel.
For instance I'd see Plone.relations as a great base for storing the social
graph but it would be great to have a default implementation of UI for the
users friends list and perhaps searching the graph. Perhaps more than one
implemention. I know there are many ways to make a friends list for instance
the one I have in mind for my site would not be a good default one, I want
the user to be able to specify special kinds of relationships and those
relationships are asymmetric, as in just because you're my friend, doesn't
mean you've added me as your friend. But perhaps if we try we can come up
with a UI that works in enough cases to be useful.
Is the friend list UI in dailyreel generalisable at all?
After we tackle inviting and socialgraph UI, then I think we could tackle
activities....
Alec Mitchell
actual user interfaces are not though. plone.app.relations is on
plone.org and in PyPi, and has comprehensive documentation and tests.
It is a set of APIs for building and querying relationship graphs.
The use of it in The Daily Reel was quite straightforward, most of the
complexity was in the UI. The most complex part of The Daily Reel
which is not open source is the happenings infrastructure, which was a
pluggable system for determining what a user has been doing recently
within the system. I'll try to get at least the interfaces we used to
define this system available publicly, because it may be useful. The
actual implementation is pretty specific to the way The Daily Reel was
setup though.
Building a simple system on top of plone.app.relations with a simple
UI shouldn't be difficult, and I'd be glad to offer advice and
assistance.
Alec
Alec Mitchell
I think. There's some custom formlib widgetry, but the forms
themselves should be better architected (with better separation of
presentation and logic into adapters) for a public project. The UI
itself came directly out of customer requirements and mockups, and I
don't think it could be generalized easily. It shouldn't be too hard
to make a simple UI and then KSS-ify it, which is essentially what we
did.
> After we tackle inviting and socialgraph UI, then I think we could tackle
> activities....
useful. I'll try to publish the interfaces and perhaps some general
implementation info.
Alec
Christian Scholz / Tao Takashi (SL)
http://mrtopf.de/blog/plone/plone-conference-2007-video-alec-mitchell-about-ploneapprelations-relationships-in-plone/
-- Christian
Dylan Jay
I think the trick here is to make a UI that is neutral enough to be
generally useful. Ie is "friend" the most general case? Is allowing the user
to pick the relationship type the most general case, and then have
integrators lock down the relationships types for specific sites.
This is where we really need your experience in a real life system.
So let's say there is another user in the system that you come across. And
you want to bring them into your realm... whatever that means for now. There
is a button next to their name.
In the most useful yet generic UI, what would it say?
"add to friend list"
"create relationship"
"add person to list" with a popup to pick a list (and/or create new list)
??
> > After we tackle inviting and socialgraph UI, then I think we could
> tackle
> > activities....
>
> We had an infrastructure for "Happenings", which I think may be
> useful. I'll try to publish the interfaces and perhaps some general
> implementation info.
Is this what opensocial calls activities and facebook calls stories?
I'm thinking that this comes after friend list type stuff in order of
importance. It could be very useful for Plone. I've had customers want to
see logs of user activity. If we had activity being recorded all over the
show (rather than just how was the last to modify an object), and then could
filter that via relationships and show it in portlets on the users
dashboard. I can think of plenty of CMS applications and collaborative
applications where that is useful.
How hard would it be to track the happenings and store it?
> Alec
>
Alec Mitchell
I'm not sure my experience helps too much here, since I was developing
a highly constrained system. There were only two social
relationships: contact (originally collaborator) and crew (which is a
sort of group), and the infrastructure wasn't designed for plugging-in
more in a trivial way.
It may be possible to allow TTW creation of relationship types,
essentially a persistent adapter registration with a title,
description, and associated workflow. The `plone.contentratings`
package that I'm in the process of polishing for initial release does
TTW adapter creation, this may be quite similar. That adapter would
then be the entry point for a generic set of factories and forms for
the relationship.
> > > After we tackle inviting and socialgraph UI, then I think we could
> > tackle
> > > activities....
> >
> > We had an infrastructure for "Happenings", which I think may be
> > useful. I'll try to publish the interfaces and perhaps some general
> > implementation info.
>
> Is this what opensocial calls activities and facebook calls stories?
I think so, it was designed to implement what facebook calls a feed.
Though the entries were not stored persistently, but queried
dynamically (though this was an implementation choice, not a
requirement of the architecture).
> I'm thinking that this comes after friend list type stuff in order of
> importance. It could be very useful for Plone. I've had customers want to
> see logs of user activity. If we had activity being recorded all over the
> show (rather than just how was the last to modify an object), and then could
> filter that via relationships and show it in portlets on the users
> dashboard. I can think of plenty of CMS applications and collaborative
> applications where that is useful.
> How hard would it be to track the happenings and store it?
The happenings stuff simply provides a mechanism for collecting,
ordering, and presenting data from a pluggable list of data providers.
Those providers could get their data from stored objects (presumably
stored during events), or from dynamic queries the aggregator doesn't
much care.
We were just querying relationships and the catalog for recently
created content, relationships, etc.. We displayed activity in the
portlet and also on each user's profile. Additionally, we had a box
on the front page which showed what the people and groups you knew
were up to, which used the same mechanism.
As far as storing these goes, I'd think something like a central
repository of stories with relationships created between the users
involved and the story object might work well. Then each user could
control the visibility of the story by managing the relationship
workflow (a feature which we did not have, but an important one).
Alec