UserPref

[Troy A. Griffitts]

OK, so here's the start of my questions...

Use Case:

Alfonso Edwardo Valera Nuñez is a portal user.
He creates his own new page in the portal,
drops 3 gadgets on the page and arranges them how he likes,
configures the UserPref settings so the gadgets display the data he
wants and function how he intends for his new page.
He has everything tuned just how he likes it. Everything looks great.
Al tells the world about his new page and posts the public link:
http://portal.com/al/coolpage/

Sarah Grace is excited and immediately clicks on Al's link,
to find that nothing works the way it should because all of the
gadgets have gone back their default UserPref settings.

Q1: Al is the OWNER and Sarah Grace is the VIEWER in this scenario, yes?

Q2: Shouldn't UserPref settings be tied to OWNER and not to VIEWER?

Other supporting use cases would be:
a page intended to show 5 tech stocks which use 5 instances of a
generic stock gadget.
a page which intends to show a map to a party which uses a generic
Google Maps gadget.

Suggestion: Could the UserPref configuration screen presented to the
OWNER have a column of [x] boxes before each option under a column
heading: Viewer Configurable. This would allow the OWNER to lock the
configuration options he desires.

Bottom line: I need a way for configuration options of gadgets to be
tied to the person who placed them on the page-- not tied to the
person viewing the page.

Troy

[Ciancetta, Jesse E.]

>-----Original Message-----
>From: opensocial-an...@googlegroups.com [mailto:opensocial-
>and-gadg...@googlegroups.com] On Behalf Of Troy A. Griffitts
>Sent: Thursday, November 03, 2011 6:27 AM
>To: opensocial-an...@googlegroups.com
>Subject: [osgs] UserPref
>
>OK, so here's the start of my questions...
>
>Use Case:
>
>Alfonso Edwardo Valera Nuñez is a portal user.
>He creates his own new page in the portal,
>drops 3 gadgets on the page and arranges them how he likes,
>configures the UserPref settings so the gadgets display the data he
>wants and function how he intends for his new page.
>He has everything tuned just how he likes it. Everything looks great.
>Al tells the world about his new page and posts the public link:
>http://portal.com/al/coolpage/
>
>Sarah Grace is excited and immediately clicks on Al's link,
>to find that nothing works the way it should because all of the
>gadgets have gone back their default UserPref settings.
>
>Q1: Al is the OWNER and Sarah Grace is the VIEWER in this scenario, yes?

Yup -- that's my understanding too.

>Q2: Shouldn't UserPref settings be tied to OWNER and not to VIEWER?

As far as I know, this is not something which is defined in the spec -- although I'm definitely not an expert on the spec so hopefully others will correct me here if I'm wrong.

So I think it is up to the OpenSocial container as to how it would like to handle this scenario.

>Other supporting use cases would be:
>a page intended to show 5 tech stocks which use 5 instances of a
>generic stock gadget.
>a page which intends to show a map to a party which uses a generic
>Google Maps gadget.
>
>Suggestion: Could the UserPref configuration screen presented to the
>OWNER have a column of [x] boxes before each option under a column
>heading: Viewer Configurable. This would allow the OWNER to lock the
>configuration options he desires.

Sounds good to me!

Again -- I don't think there is anything in the spec that addresses this so I think you're free to do as you please in your container implementation.

>Bottom line: I need a way for configuration options of gadgets to be
>tied to the person who placed them on the page-- not tied to the
>person viewing the page.

What container are you using? Have you built your own or are you working off the /samplecontainer/examples/commoncontainer in Shindig?

>Troy
>
>--
>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-and-gadgets-
>sp...@googlegroups.com.
>To unsubscribe from this group, send email to opensocial-and-gadgets-
>spec+uns...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Matthew Marum]

I think we are walking a fuzzy line between AppData and UserPrefs here.

As I recall, AppData is something that would not change from user to user, but there are some limitations there.  I believe only Owners can manipulate AppData.  User Prefs are intended to allow a viewer to personalize the app without changing how others see it.

There is a need to address more use cases than AppData, UserPrefs, DataContext, etc. currently allow.  I think some containers have hacks that deviate from the spec.  We discussed creating a better unified model in the OS 2.0 timeframe but it fell off the table.  When I have time, I can pull up the old discussion.. maybe this is something worthwhile for OS 3.0?

Matt

On Thu, Nov 3, 2011 at 11:56 AM, Ciancetta, Jesse E. <jc...@mitre.org> wrote:

>-----Original Message-----
>From: opensocial-an...@googlegroups.com [mailto:opensocial-
>and-gadg...@googlegroups.com] On Behalf Of Troy A. Griffitts
>Sent: Thursday, November 03, 2011 6:27 AM
>To: opensocial-an...@googlegroups.com
>Subject: [osgs] UserPref

>
>OK, so here's the start of my questions...
>
>Use Case:
>

>Alfonso Edwardo Valera Nuńez is a portal user.

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.

[Ciancetta, Jesse E.]

I think you may be confusing AppData visibility with AppData storage.

AFAIK AppData does indeed change user from user to user (viewer to viewer) – but can be *visible* to anyone. This is what I found in the spec about AppData visibility:

"This data store can be read by anyone who can see the gadget, but only the VIEWER's data is writable."

--Jesse

[Craig McClanahan]

On Thu, Nov 3, 2011 at 10:17 AM, Ciancetta, Jesse E. <jc...@mitre.org> wrote:

I think you may be confusing AppData visibility with AppData storage.

AFAIK AppData does indeed change user from user to user (viewer to viewer) – but can be *visible* to anyone.  This is what I found in the spec about AppData visibility:

"This data store can be read by anyone who can see the gadget, but only the VIEWER's data is writable."

The way we (Jive) implemented this was that all users could see the appdata *if* viewed from the same gadget.  Only the viewer can change his/her appdata, and no user of a different gadget can see or modify appdata for it.

User preferences, on the other hand, or only visible to and modifiable by the viewer.

Craig McClanahan

[Matthew Marum]

Ok.  I've found the old discussion I was thinking about.

https://groups.google.com/d/topic/opensocial-and-gadgets-spec/Qi4VdJhF_OQ/discussion

Issue 1182 was created but deferred from OS 2.0.
http://code.google.com/p/opensocial-resources/issues/detail?id=1182

Wiki for UserPrefs vs AppData
http://docs.opensocial.org/display/OSD/UserPrefs+vs+AppData

Matt

[Troy A. Griffitts]

Thanks for all the discussion guys. Maybe I'm simply not oriented
correctly in the OpenSocial way of doing things. Let me tune my use
case by shortening it and making it more specific:

Al is having a birthday bash and creates a crazy page with balloons,
streamers, and glitter, and embeds 2 gadgets on the page:
1) a Google Maps Gadget, where he opens the configuration and places
his address in the "Location" UserPref.
2) a Guest Registry Gadget, where he opens the configuration and adds
his comma separated guest list of email addresses to the "Invitees"
UserPref and "Al's Birthday Bash" to the "Event Name" UserPref.

The Guest Registry Gadget sends emails off to all the invitees
announcing the glorious event and provides them with a link to Al's
Birthday Bash page at http://portal.com/al/birthdaybash/, where the
gadgets reside amongst the glitter.

The invitees visit the page, see Al's wonderful Invitation and the map
to his party, all select "Certainly Will Attend" on the Guest Registry
Gadget and post their comments reflecting their eager desire to
celebrate with their beloved friend Al.
A good time is had by all.

Is this not a Use Case which OpenSocial attempts to meet?

If so, how would you suggest the configuration information for the
gadgets is stored? There is no other configuration mechanism provided
by OpenSocial, except UserPref items, yes?

I still say these reflect the choices of the Owner and Not the Viewer.
In iGoogle, these are always one and the same. I cannot make my
iGoogle page available to a Viewer other than me, the Owner. But in
the more complex world of different Owner, Viewer actors, the gadget
page typically is not even going to be configurable by the Viewer, so
why should the Gadget UserPref options be configurable? Thus
concludes my case for the "User" being the Owner. :)

Thanks for listening,

Troy

[Evgeny Bogdanov]

Hi Troy,

the best (IMO) way for your scenario is to use AppData. We develop quite a lot of widgets that save some data for OWNER, some save data for VIEWER.
There is no any particular need to use user preferences.

Example for your case (widget)

1. getOwner
2. getViewer
3. get AppData for Owner ("Location": "London")
  - if update => update appdata for owner
4. get AppData for Viewer ("attend" = true)
  - if update
    => update appdata ("attending") for viewer
    => update appdata ("list of attendees") for owner

Examples we have
  1. wiki widget, Owner can remove and clean items, viewer can edit wiki page
  2. IFrame widget - owner can change url of the iframe, viewer only sees the content
  3. rating widget - viewers can add ratings
  4. calendar widget (owner addes events, viewers can see them and say "attend/not")

I can share urls with source code if you are interested.

[Troy A. Griffitts]

Thank you for all of the replies. So, let me summarize my understanding:

Recommendation is not to use UserPref for Owner Configuration
settings, but instead to build my own configuration dialog boxes and
save to appData.

Reason: The "User" in UserPref is not specified to be either Viewer or
Owner, so the container can decide which.

Thank you for the answer. I can move forward now, but can I plead for
a specification change on this?

You have given us an elegant configuration mechanism which is simple
and handy and straightforward-- with Bools and Enums, and String types
which containers translate into very nice configuration dialogs
uniform with the container experience. It's all lovely and has met
100% of all of our configuration needs, thus far. We have never
needed to write a configuration dialog inside any of our components.
I can see why some complex components may need to write their own
configuration dialog, but I would guess the current UserPref mechanism
meets the need of 90% of all Gadgets (I have never seen a gadget write
its own configuration panel in the numerous iGoogle components that
I've used there).

Please do not render this wonderful mechanism useless in a complex
environment where Owner/Viewer are not typically the same person. I
can see no compelling use case where a Viewer should be able to change
the configuration of a Gadget when that Viewer is not also the Owner.

Simply specify that: UserPref is tied to Owner and not Viewer. You
haven't changed anything in the simple "same-Owner/Viewer" world of
the iGoogle-like experiences, and you've guaranteed a usable interface
for gadget developers targeting not "same-Owner/Viewer" experiences,
like portals where users can create pages with gadgets, configure
them, and publish those pages to be viewed by others.

As it stands now. I cannot use UserPref at all because I cannot know
the behavior of the container my gadget will live inside. This forces
me to write custom dialog boxes for configuration in every one of my
gadgets-- even ones with a single, simple dropdown choice, or a single
[x] option-- because all my options are intended for the Owner.

Heck, at least change the name to either OwnerPref or ViewerPref, but
please don't let this remain undefined.

Without making a decision on this, UserPref is emasculated outside
same-Owner/Viewer containers.

Thanks for listening, and again, thanks for the responses and solution.

Troy

> --
> 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/-/KgGcjfdVr-kJ.

[Ciancetta, Jesse E.]

The Jive AppData implementation Craig described below matches what I ended up implementing for Apache Rave – the Rave implementation can be found at the following location for anyone interested:

 

https://svn.apache.org/repos/asf/incubator/rave/trunk/rave-shindig/src/main/java/org/apache/rave/opensocial/service/impl/DefaultAppDataService.java

 

--Jesse

[Evgeny Bogdanov]

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

[Troy A. Griffitts]

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

> --
> 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.

[Evgeny Bogdanov]

Hi Troy,

IMHO, you can write a small proposal similar to this:
http://docs.opensocial.org/display/OSD/Space+Proposal

about clarifing the userprefs within OpenSocial.
Then you can post this proposal to the list and see the feedback.

I'd vote for "userprefs for owners".

Evgeny

[Tim Wintle]

+1 - That's what I got from my first reading of the specs, and how I
implemented it.