request: dialog api

[Nat Brown (ilike.com)]

(hopefully this doesn't already exist and i've just missed it?)

interacting directly with users as they are manipulating your gadget
in profile mode can be limiting due to width/location constraints in
your iframe. navigating them to a canvas page so you have more space
can be heavy-weight and irritating. users prefer direct manipulation.

on facebook we have a javascript dialog box apis (http://
wiki.developers.facebook.com/index.php/FBJS#Dialogs,
http://wiki.developers.facebook.com/index.php/FBJS/Examples/Dialogs)
which we can plumb to ajax-fill a dialog with remote content. it
creates standard OK (optionally CANCEL) dialogs styled to the
container (semi-transparent border shadow, centered on the viewport,
etc) and fires events back to us for OK or CANCEL.

in opensocial ideally the container would style a dialog and place it
in the viewport in an appropriate place (centered on the profile area
or over the whole page when in canvas mode?). at its most generic this
would be a pop-up iframe -- the container would simply construct a
dynamic iframe and we'd provide just perhaps a makeRequest parameter
block to and it would fills the content for us. but, there are many
ways this could be done differently.

in any case, i personally would put many things into these simple
dialogs modelessly to increase the direct-manipulation of our app --
inviting friends, picking which friends to message, or playing a video
a friend has sent you would all pop-up rather than navigate away.

[Cassie]

Nat - This does not exist yet, so thanks for the proposal. Do you think you could come up with a spec definition for the javascript function you want to add? Like opensocial.requestSomething(param1, param2, ...) with a js doc to go with it?

Thanks.

- Cassie

[Brian Stoler]

+1 to dialogs, but I think this belongs at the gadgets layer. Something like:

/**
 * Creates a dialog UI that can show the requested other gadget.
 *
 * @param {string} gadgetUrl URL to gadget spec of the gadget to show in the dialog
 * @param {Object} opt_params Various params. Things I imagine:
 *     width, height, which view to show, is modal or not, params to pass to gadget
 *
 * @return some object that lets you control the dialog. Show, hide, add listener for its
 *     closing, get back some kind of return value when it closes, etc.
 */
gadgets.window.createDialog(gadgetUrl, opt_params)

-brian

[Louis Ryan]

Nat,

Two of the use-cases that you mention (invite & friend picker?) are covered by the spec. The third play-content you could imagine the spec providing explicit rather than generic support for.

The argument that this is necessary because of the constraints of profile mode displays is no doubt valid in specific cases but providing an all-purpose dialog mechanism is a usability concern for containers. If containers can't control behavior by use-case they will end up having a black or white policy on this or very detailed TOS that will vary and be hard for gadget developers to stay in compliance everywhere.

Orkut for example would likely require that no dialogs can be displayed on profile pages except in response to user interaction

Thoughts?

-Louis

[Evan Gilbert]

There are a few use cases here. Here's a more detailed proposal that may cover them all:
- gagdets.window.confirm(params). Equivalent of HTML confirm() (OK/cancel dialog), but looks nicer. Similar API as messages/activities - supports setting text directly or by message ID, may optionally support opensocial.MediaItem. Would also allow customization of OK & cancel text. Needs a callback as it is async.
- gadgets.window.alert(params). Same, but for HTML alert()
- gadgets.window.createDialog(url, params). What Brian said - two of the params would be an success and failure callback.
- gadgets.util.hasFeature('gadgets.window.xxx'). Whether the container supports these features - may return a different value by view.

Evan

[Paul]

+1 to this general idea.

Details need to be hammered out....maybe consider enum value for
dialog type (CONFIRM, ALERT, INFO, YES_NO_CANCEL, INPUT, etc), but
something is better than nothing here.

~Paul

[Cassie]

This thread is not converging enough for 0.8 and will be delayed until 0.9.
In the meantime sites are free to add this as a container specific extension.

Thanks.

- Cassie