OpenSocial and Google+

[Troy A. Griffitts]

PS. Thank you for the google blog entry on removal of social
functionality from iGoogle in lieu of Google+. Do you have any idea
of Google's intent to include OpenSocial functionality in Google+?

On Mon, Nov 7, 2011 at 5:53 PM, Troy A. Griffitts <scri...@gmail.com> wrote:
> Evgeny,
>
> Thanks for the comment.  I think we agree on my primary concern:
>
> o   If OpenSocial is going to provide a gadget configuration
> mechanism, the configuration should be done by the Owner and the
> Owner-selected configuration should be used for all Viewers.
>
> I believe this is by far the intention of gadget developers.
>
> To reiterate, our project here is not developing a container.  We
> developing a suite of gadgets targeted primarily to Humanities
> departments at Universities which we would like to work consistently
> across their choice of OpenSocial containers.
>
> If the OpenSocial specification does not define something as
> rudimentary as what kind of configurations for which UserPref is meant
> (Owner or Viewer-- which fundamentally changes the function of the
> configuration drastically), then as a gadget suite developer-- who
> intends for a gadget Owner to select components from that suite and
> configure them to be used together for a particular purpose on a
> page-- we cannot use the undefined configuration mechanism; it is
> worthless for us.  The configuration options change the displayed
> information of our gadgets.
> ___________
>
> Imagine a user who creates an article in a portal and writes about how
> well a stock should do this coming new year and who places a Stock
> Gadget on their article pages, opens UserPref and configures the stock
> symbol and date range to pertain to their article.
>
> The inclusion of this Stock Gadget is worthless if the configuration
> is Viewer related.  Yes, all UserPref configuration options I've ever
> seen made available in a gadget are meaningless in a
> different-Viewer/Owner experience if the configuration is tied to the
> Viewer.
>
> I believe this is a very important decision.  Either UserPref becomes
> worthless and should simply be deprecated to avoid giving false hope
> of a useful configuration mechanism, or it is more specifically
> defined to Owner Preferences and remains a viable configuration option
> for gadget developers.
>
> I'm not too concerned how the configuration is stored.  Your
> suggestion to back the configuration selection with appData sounds
> great to me if it will prevent a gadget refresh and makes it easier
> for portal developers.
>
> Troy
>
>
>
>
> On Mon, Nov 7, 2011 at 10:51 AM, Evgeny Bogdanov
> <evgeny....@gmail.com> wrote:
>> Hi Troy,
>>
>> You are completely right that in iGoogle viewer==owner, this is why they do
>> not differentiate the userprefs between owner and viewer.
>> It is not that popular to look at somebody's profile page in iGoogle (viewer
>> looks at owner), maybe this is also the reason they plan to remove
>> completely social functionality
>> from iGoogle by 2012 and leave only UserPrefs
>> (http://googleblog.blogspot.com/2011/10/fall-sweep.html)
>>
>> In social networks (Facebook, Google+, etc) it is very common to see a
>> profile page of somebody else and see his gadgets (viewer looks at owner),
>> so you need to save data for both. There are two ways, extend UserPrefs with
>> two levels (viewer/owner) or go with AppData.
>> In first case you will have to manage this functionality in your gadget
>> container, because the UserPrefs pass via your container and not via
>> shindig.
>> With appdata it is done for free, you just plug shindig inside and it works.
>>
>> There are few things why I prefer appdata over userprefs. I like when user
>> provides his geographical location or rss feed directly in the widget,
>> rather than going to a separate preferences page.
>> I think it is better from usability perspective. Another thing is ajax, if I
>> am not mistaking, if you update the UserPrefs the gadget will have to be
>> reloaded while with appdata you receive ajax response
>> and it is up to you what to do with it.
>>
>> I agree that UserPrefs is a nice and simple way to configure a gadget. With
>> it gadget developer could quickly create simple configurable gadgets such as
>> google map for example with specified location. I think userprefs should
>> belong to gadget owner and only he should be able to change it. Actually, I
>> would do it this way: create a feature user_prefs, that can be added into
>> gadget by providing a settings popup, back it up by appdata for storage on
>> behalf of gadget owner.
>>
>> Best
>> Evgeny
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OpenSocial and Gadgets Specification Discussion" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/V_ED1WF6kwgJ.
>> To post to this group, send email to
>> opensocial-an...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> opensocial-and-gadg...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>

[Evgeny Bogdanov]

I don't know for sure, but I think it makes sense since it was in Orkut, iGoogle, for example.
Now the focus is on Google+, I think it can be a super alternative to Facebook's apps.

[Ryan Baxter]

I am sure Paul knows the answer to this question, whether he can tell
us is a different story :)

[James Snell]

Hint.. Look at the hangouts api.... And the javascript for the g+ page.....

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.

[Paul Lindner]

As has been noted already the Google+ platform uses OpenSocial features in new and interesting ways. You'll find partial Gadget support in the Hangouts and Games APIs; portable contacts used in the people API; OpenSocial v2 ActivityStreams for the various activities API; full-blown OAuth2, etc.. 

In some ways the Google+ platform doesn't map quite as you'd expect -- the APIs we offer are intentionally limited in scope and dont' always map to OpenSocial semantics.

However, over time, you will see the Google+ platform converge with the future direction of the OpenSocial APIs and other Open APIs. I'm excited about the possibilities and grateful for being able to participate in this wonderful community that keeps OpenSocial alive and vibrant!

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.

To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

--
Paul Lindner -- lin...@inuus.com -- linkedin.com/in/plindner

[Ryan Baxter]

This great to hear Paul thanks for posting this!

> Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner

[James Snell]

It is good that you note that the mapping of OpenSocial into Google+
isn't as clean or clearcut as one may expect. In our own adoption of
OpenSocial, we have been experiencing the same general issue... there
are just many places where the existing opensocial apis and data
models do not map cleanly into our social business applications. The
goal is to incrementally evolve OpenSocial based on the lessons
learned during practical implementation and achieve greater alignment
over time.