There are a lot of painful implications to how requestNavigateTo works
within OpenSocial that should be addressed asap. Failure to fix these
issues will hinder developers and business models on the platform.
Here is my suggestion.
Currently applications emit at the server or rewrite on the client
simple links into complicated javascript calls. For us in iLike,
instead of generating:
Going through container javascript to navigate isn't the worst thing
in the world, but the fact that there is no real URL in the browser
has several perhaps non-obvious implications to the user experience,
business model, and technical layering which are worth thinking about
and fixing:
1) when links are real HREF's in the browser, users can see where
they are going when they hover over things, and they can copy/paste
links and send them to friends. They can DIGG them, they can post them
to facebook, they can copy them into google bookmarks. They can save
them in their browser favorites. They can open links in new tabs. They
can do none of these things in opensocial containers right now.
2) Links to canvas pages from activity stream items and any kind of
container notifications are also not going to work trivially -- gadget
javascript is not involved, we need to embed specific links into
activity streams, notifications, and messages. we can't do that right
now.
3) From a development perspective, the links are not only more
readable for us and lead us to the code backing them more quickly, but
we can also paste such links into our ticketing system and find and
resolve issues more quickly rather than needed to create tickets that
describe the steps to get to a sub-page. We can also concatenate
suffixes from production links onto our private workspace or staging
links to test out fixes. Partners can send us links that are broken or
that they have a question about. Customers can point us at particular
pages that have a problem, or our help buttons can automaticaly send
us the page the user was on. We can use simple site performance and
uptime monitoring tools to see how our opensocial application is
performing if we have URLs. When we don't have real URLs in some
fashion, all of this stops and our development process slows down and
our customers and partners do not bother taking the time to send us
feedback, or they are frustrated by the process, and we can't easily
monitor the uptime or performance of our application from an end-user
perspective. We get reports like "on the NNN artist page on Orkut
there is a link to a concert on July 3rd at the Gorge amphitheatre..."
we can ping our web cluster for basic uptime/performance, but we can't
ping specific user or canvas pages to see whether something is broken.
This makes developing for and supporting OpenSocial painful.
4) Also from a development perspective, when we use real URLs a whole
class of URL-signing and parameter-passing bugs that have plagued each
container and which continue plaguing us daily here would have been
eliminated or minimally easier to track down. Encoding & signing " "
and "+" was broken. UTF8 characters like Mötley Crüe weren't working.
All this because containers don't know exactly what to encode or how
and are doing it within JSON blobs. It's unclear why this wheel of URL-
encoding is being reinvented.
5) if there are javascript errors anywhere on the page and javascript
stops running, navigation simply breaks, which is a horrendous user
experience. They can refresh, but they can't go anywhere within our
content -- not good and makes our applications and opensocial feel
flaky. This happens regularly.
6) Finally from a business model perspective, real URLs give us the
ability to create ads and external references that refer to our canvas
pages. It allows us to cross-promote our applications and our canvas
pages between different opensocial containers and facebook and our own
sites. It allows applications to cross-link with one another within a
containers, for promotional or other reasons. It allows us to email
users and give them a link to visit Hi5, Orkut, or MySpace versions of
iLike and add our application, and it allows us to do conversion-
tracking for installs from ads or email pointers and to optimize our
conversion to installation. We have none of this without URLs. The
most trivial example of this kind of utility which opensocial recently
lost traffic from is that we launched a new REM album for free
streaming on 3/24 exclusively with iLike. We were able to point users,
the press, record labels, and bands (including the band itself, REM)
to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem.
We have no URL to point press/analysts or the band to on Orkut, Hi5,
MySpace. On REM's "artist dashboard" on ilike we can point them to
their iLike-generated artist pages in non-OpenSocial containers so
they can preview how the songs and videos they are posting will appear
to their fans. We can't point them to their OpenSocial canvas pages.
You may think that this level of url cross-referencing is only useful
to complex/deep apps with many canvas pages like ours. This is not the
case -- even the smallest applications benefit from the business model
and development implications of URLs that can fall back on pure
navigation.
So, in a nutshell, here's the ideal API from my perspective: users can
copy-paste the URLs and we can construct urls offline or server-side
(given a known root, which ideally would be http://apps.<container>.com/ilike,
but fine with us if it's anything fixed like http://<container>/app_100)
and end up back in our application, but we actually use
requestNavigateTo under the covers which does all the good things
containers apparently need in all the different contexts and we can
support zany things like desktop/offline containers.
(the latter if the iframe host puts our docroot into place as they
host our manifest, or we could do that ourselves given a fixed base
URL)
Note that I would prefer this was shortened to take an URL instead of
making us do all the path, options crud to indicate a GET -- this is
just code that each application duplicates over and over again and we
should optimize the most common case. If you couldn't do that we could
stick with the longer convoluted arguments -- I don't really mind,
though I think it creates an irritating barrier to entry for
programmers to figure out for this API -- we would probably be
rewriting this content on the client by looking for rel="nofollow" or
some such on <a tags, like:
I think that, fundamentally, Nat is right. Links should be links. They've served the web quite well for decades. I'm personally quite annoyed with the way navigation works (or doesn't) in most widgets on the web, whether we're talking about opensocial gadgets or not. A lot of this is just tied to differences between normal web navigation and the javascript-heavy approaches being favored lately, and the architecture of opensocial is such that it strongly favors a javascript-heavy approach, to a certain extent at the expense of simpler applications that are more like traditional web pages.
This means that if I'm developing a widget that is more "application"-like, such as an email or IM client, the opensocial model works quite well, but if I'm developing something more "web page" like, such as a directory of artists, a simpler html-based approach is really more ideal.
Some other problems:
1. Not all containers have the same format. For a fixed container, it's trivial to dictate url format, because you only have to worry about one container and their url structure is all that matters. This works fine if you're only targeting just facebook or just myspce, but it stops working when you have to deal with 10 different containers, each with their own format.
We could mandate that all containers have some fixed url format, but I have a feeling that getting containers to agree on the format would be difficult at best. Rewriting is a pretty good idea, but it falls down when you have dynamically generated content, so we'd still have to come up with a function to generate dynamic links as well.
2. Gadgets are in iframes
This is probably a more fundamental issue. Navigation when you're in an iframe is difficult, because you've got two types of navigation: changing the parent page, and changing some iframe parameters. The former problem can mostly be solved by opening the link in a new tab. This doesn't quite cover situations such as linking to a different gadget or a different viewer, but it covers a lot of other situations. The latter problem is more complex.
3. Some containers don't want to allow navigation at all, or at least not in certain contexts.
On Thu, Mar 27, 2008 at 11:49 PM, Nat Brown (ilike.com) <nat...@gmail.com> wrote:
> There are a lot of painful implications to how requestNavigateTo works > within OpenSocial that should be addressed asap. Failure to fix these > issues will hinder developers and business models on the platform. > Here is my suggestion.
> Currently applications emit at the server or rewrite on the client > simple links into complicated javascript calls. For us in iLike, > instead of generating:
> Going through container javascript to navigate isn't the worst thing > in the world, but the fact that there is no real URL in the browser > has several perhaps non-obvious implications to the user experience, > business model, and technical layering which are worth thinking about > and fixing:
> 1) when links are real HREF's in the browser, users can see where > they are going when they hover over things, and they can copy/paste > links and send them to friends. They can DIGG them, they can post them > to facebook, they can copy them into google bookmarks. They can save > them in their browser favorites. They can open links in new tabs. They > can do none of these things in opensocial containers right now.
> 2) Links to canvas pages from activity stream items and any kind of > container notifications are also not going to work trivially -- gadget > javascript is not involved, we need to embed specific links into > activity streams, notifications, and messages. we can't do that right > now.
> 3) From a development perspective, the links are not only more > readable for us and lead us to the code backing them more quickly, but > we can also paste such links into our ticketing system and find and > resolve issues more quickly rather than needed to create tickets that > describe the steps to get to a sub-page. We can also concatenate > suffixes from production links onto our private workspace or staging > links to test out fixes. Partners can send us links that are broken or > that they have a question about. Customers can point us at particular > pages that have a problem, or our help buttons can automaticaly send > us the page the user was on. We can use simple site performance and > uptime monitoring tools to see how our opensocial application is > performing if we have URLs. When we don't have real URLs in some > fashion, all of this stops and our development process slows down and > our customers and partners do not bother taking the time to send us > feedback, or they are frustrated by the process, and we can't easily > monitor the uptime or performance of our application from an end-user > perspective. We get reports like "on the NNN artist page on Orkut > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > we can ping our web cluster for basic uptime/performance, but we can't > ping specific user or canvas pages to see whether something is broken. > This makes developing for and supporting OpenSocial painful.
> 4) Also from a development perspective, when we use real URLs a whole > class of URL-signing and parameter-passing bugs that have plagued each > container and which continue plaguing us daily here would have been > eliminated or minimally easier to track down. Encoding & signing " " > and "+" was broken. UTF8 characters like Mötley Crüe weren't working. > All this because containers don't know exactly what to encode or how > and are doing it within JSON blobs. It's unclear why this wheel of URL- > encoding is being reinvented.
> 5) if there are javascript errors anywhere on the page and javascript > stops running, navigation simply breaks, which is a horrendous user > experience. They can refresh, but they can't go anywhere within our > content -- not good and makes our applications and opensocial feel > flaky. This happens regularly.
> 6) Finally from a business model perspective, real URLs give us the > ability to create ads and external references that refer to our canvas > pages. It allows us to cross-promote our applications and our canvas > pages between different opensocial containers and facebook and our own > sites. It allows applications to cross-link with one another within a > containers, for promotional or other reasons. It allows us to email > users and give them a link to visit Hi5, Orkut, or MySpace versions of > iLike and add our application, and it allows us to do conversion- > tracking for installs from ads or email pointers and to optimize our > conversion to installation. We have none of this without URLs. The > most trivial example of this kind of utility which opensocial recently > lost traffic from is that we launched a new REM album for free > streaming on 3/24 exclusively with iLike. We were able to point users, > the press, record labels, and bands (including the band itself, REM) > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem. > We have no URL to point press/analysts or the band to on Orkut, Hi5, > MySpace. On REM's "artist dashboard" on ilike we can point them to > their iLike-generated artist pages in non-OpenSocial containers so > they can preview how the songs and videos they are posting will appear > to their fans. We can't point them to their OpenSocial canvas pages.
> You may think that this level of url cross-referencing is only useful > to complex/deep apps with many canvas pages like ours. This is not the > case -- even the smallest applications benefit from the business model > and development implications of URLs that can fall back on pure > navigation.
> So, in a nutshell, here's the ideal API from my perspective: users can > copy-paste the URLs and we can construct urls offline or server-side > (given a known root, which ideally would be http://apps. > <container>.com/ilike, > but fine with us if it's anything fixed like http://<container>/app_100) > and end up back in our application, but we actually use > requestNavigateTo under the covers which does all the good things > containers apparently need in all the different contexts and we can > support zany things like desktop/offline containers.
> (the latter if the iframe host puts our docroot into place as they > host our manifest, or we could do that ourselves given a fixed base > URL)
> Note that I would prefer this was shortened to take an URL instead of > making us do all the path, options crud to indicate a GET -- this is > just code that each application duplicates over and over again and we > should optimize the most common case. If you couldn't do that we could > stick with the longer convoluted arguments -- I don't really mind, > though I think it creates an irritating barrier to entry for > programmers to figure out for this API -- we would probably be > rewriting this content on the client by looking for rel="nofollow" or > some such on <a tags, like:
> There are a lot of painful implications to how requestNavigateTo works > within OpenSocial that should be addressed asap. Failure to fix these > issues will hinder developers and business models on the platform. > Here is my suggestion.
> Currently applications emit at the server or rewrite on the client > simple links into complicated javascript calls. For us in iLike, > instead of generating:
> Going through container javascript to navigate isn't the worst thing > in the world, but the fact that there is no real URL in the browser > has several perhaps non-obvious implications to the user experience, > business model, and technical layering which are worth thinking about > and fixing:
> 1) when links are real HREF's in the browser, users can see where > they are going when they hover over things, and they can copy/paste > links and send them to friends. They can DIGG them, they can post them > to facebook, they can copy them into google bookmarks. They can save > them in their browser favorites. They can open links in new tabs. They > can do none of these things in opensocial containers right now.
> 2) Links to canvas pages from activity stream items and any kind of > container notifications are also not going to work trivially -- gadget > javascript is not involved, we need to embed specific links into > activity streams, notifications, and messages. we can't do that right > now.
> 3) From a development perspective, the links are not only more > readable for us and lead us to the code backing them more quickly, but > we can also paste such links into our ticketing system and find and > resolve issues more quickly rather than needed to create tickets that > describe the steps to get to a sub-page. We can also concatenate > suffixes from production links onto our private workspace or staging > links to test out fixes. Partners can send us links that are broken or > that they have a question about. Customers can point us at particular > pages that have a problem, or our help buttons can automaticaly send > us the page the user was on. We can use simple site performance and > uptime monitoring tools to see how our opensocial application is > performing if we have URLs. When we don't have real URLs in some > fashion, all of this stops and our development process slows down and > our customers and partners do not bother taking the time to send us > feedback, or they are frustrated by the process, and we can't easily > monitor the uptime or performance of our application from an end-user > perspective. We get reports like "on the NNN artist page on Orkut > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > we can ping our web cluster for basic uptime/performance, but we can't > ping specific user or canvas pages to see whether something is broken. > This makes developing for and supporting OpenSocial painful.
> 4) Also from a development perspective, when we use real URLs a whole > class of URL-signing and parameter-passing bugs that have plagued each > container and which continue plaguing us daily here would have been > eliminated or minimally easier to track down. Encoding & signing " " > and "+" was broken. UTF8 characters like Mötley Crüe weren't workin > g. > All this because containers don't know exactly what to encode or how > and are doing it within JSON blobs. It's unclear why this wheel of > URL- > encoding is being reinvented.
> 5) if there are javascript errors anywhere on the page and javascript > stops running, navigation simply breaks, which is a horrendous user > experience. They can refresh, but they can't go anywhere within our > content -- not good and makes our applications and opensocial feel > flaky. This happens regularly.
> 6) Finally from a business model perspective, real URLs give us the > ability to create ads and external references that refer to our canvas > pages. It allows us to cross-promote our applications and our canvas > pages between different opensocial containers and facebook and our own > sites. It allows applications to cross-link with one another within a > containers, for promotional or other reasons. It allows us to email > users and give them a link to visit Hi5, Orkut, or MySpace versions of > iLike and add our application, and it allows us to do conversion- > tracking for installs from ads or email pointers and to optimize our > conversion to installation. We have none of this without URLs. The > most trivial example of this kind of utility which opensocial recently > lost traffic from is that we launched a new REM album for free > streaming on 3/24 exclusively with iLike. We were able to point users, > the press, record labels, and bands (including the band itself, REM) > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem. > We have no URL to point press/analysts or the band to on Orkut, Hi5, > MySpace. On REM's "artist dashboard" on ilike we can point them to > their iLike-generated artist pages in non-OpenSocial containers so > they can preview how the songs and videos they are posting will appear > to their fans. We can't point them to their OpenSocial canvas pages.
> You may think that this level of url cross-referencing is only useful > to complex/deep apps with many canvas pages like ours. This is not the > case -- even the smallest applications benefit from the business model > and development implications of URLs that can fall back on pure > navigation.
> So, in a nutshell, here's the ideal API from my perspective: users can > copy-paste the URLs and we can construct urls offline or server-side > (given a known root, which ideally would be http:// > apps.<container>.com/ilike, > but fine with us if it's anything fixed like http://<container>/ > app_100) > and end up back in our application, but we actually use > requestNavigateTo under the covers which does all the good things > containers apparently need in all the different contexts and we can > support zany things like desktop/offline containers.
> (the latter if the iframe host puts our docroot into place as they > host our manifest, or we could do that ourselves given a fixed base > URL)
> Note that I would prefer this was shortened to take an URL instead of > making us do all the path, options crud to indicate a GET -- this is > just code that each application duplicates over and over again and we > should optimize the most common case. If you couldn't do that we could > stick with the longer convoluted arguments -- I don't really mind, > though I think it creates an irritating barrier to entry for > programmers to figure out for this API -- we would probably be > rewriting this content on the client by looking for rel="nofollow" or > some such on <a tags, like:
I think it will be difficult to standardize URLs across containers, even given a common server base. One particular problem will be with more AJAX-y applications - even if we all agree, some will want to navigate to http://container.com/*#ilike?params* and some to */ilike?params* (the # allows you to fake navigation without an actual browser navigation request). It's worth starting the discussion to see if we could all agree on a convention, but I'm not sure we'll converge.
Would it work if we had an API for getting a URL for a given container, i.e.: opensocial.getUrlFor(app, path, params). This would allow containers to have their own URL schemes but also support getting a URL you could actually put into links. It's a bit less convenient, as you wouldn't be able to easily generate per-container URLs from your own servers, but it avoids trying to get consensus on URL structures which seems a little daunting.
On Fri, Mar 28, 2008 at 3:51 AM, John Panzer <jpan...@google.com> wrote:
> +1 - blogspot, for example, really really wants real linkable urls > wherever possible.
> -John
> On Mar 27, 2008, at 11:49 PM, "Nat Brown (ilike.com)" > <nat...@gmail.com> wrote:
> > There are a lot of painful implications to how requestNavigateTo works > > within OpenSocial that should be addressed asap. Failure to fix these > > issues will hinder developers and business models on the platform. > > Here is my suggestion.
> > Currently applications emit at the server or rewrite on the client > > simple links into complicated javascript calls. For us in iLike, > > instead of generating:
> > Going through container javascript to navigate isn't the worst thing > > in the world, but the fact that there is no real URL in the browser > > has several perhaps non-obvious implications to the user experience, > > business model, and technical layering which are worth thinking about > > and fixing:
> > 1) when links are real HREF's in the browser, users can see where > > they are going when they hover over things, and they can copy/paste > > links and send them to friends. They can DIGG them, they can post them > > to facebook, they can copy them into google bookmarks. They can save > > them in their browser favorites. They can open links in new tabs. They > > can do none of these things in opensocial containers right now.
> > 2) Links to canvas pages from activity stream items and any kind of > > container notifications are also not going to work trivially -- gadget > > javascript is not involved, we need to embed specific links into > > activity streams, notifications, and messages. we can't do that right > > now.
> > 3) From a development perspective, the links are not only more > > readable for us and lead us to the code backing them more quickly, but > > we can also paste such links into our ticketing system and find and > > resolve issues more quickly rather than needed to create tickets that > > describe the steps to get to a sub-page. We can also concatenate > > suffixes from production links onto our private workspace or staging > > links to test out fixes. Partners can send us links that are broken or > > that they have a question about. Customers can point us at particular > > pages that have a problem, or our help buttons can automaticaly send > > us the page the user was on. We can use simple site performance and > > uptime monitoring tools to see how our opensocial application is > > performing if we have URLs. When we don't have real URLs in some > > fashion, all of this stops and our development process slows down and > > our customers and partners do not bother taking the time to send us > > feedback, or they are frustrated by the process, and we can't easily > > monitor the uptime or performance of our application from an end-user > > perspective. We get reports like "on the NNN artist page on Orkut > > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > > we can ping our web cluster for basic uptime/performance, but we can't > > ping specific user or canvas pages to see whether something is broken. > > This makes developing for and supporting OpenSocial painful.
> > 4) Also from a development perspective, when we use real URLs a whole > > class of URL-signing and parameter-passing bugs that have plagued each > > container and which continue plaguing us daily here would have been > > eliminated or minimally easier to track down. Encoding & signing " " > > and "+" was broken. UTF8 characters like Mötley Crüe weren't workin > > g. > > All this because containers don't know exactly what to encode or how > > and are doing it within JSON blobs. It's unclear why this wheel of > > URL- > > encoding is being reinvented.
> > 5) if there are javascript errors anywhere on the page and javascript > > stops running, navigation simply breaks, which is a horrendous user > > experience. They can refresh, but they can't go anywhere within our > > content -- not good and makes our applications and opensocial feel > > flaky. This happens regularly.
> > 6) Finally from a business model perspective, real URLs give us the > > ability to create ads and external references that refer to our canvas > > pages. It allows us to cross-promote our applications and our canvas > > pages between different opensocial containers and facebook and our own > > sites. It allows applications to cross-link with one another within a > > containers, for promotional or other reasons. It allows us to email > > users and give them a link to visit Hi5, Orkut, or MySpace versions of > > iLike and add our application, and it allows us to do conversion- > > tracking for installs from ads or email pointers and to optimize our > > conversion to installation. We have none of this without URLs. The > > most trivial example of this kind of utility which opensocial recently > > lost traffic from is that we launched a new REM album for free > > streaming on 3/24 exclusively with iLike. We were able to point users, > > the press, record labels, and bands (including the band itself, REM) > > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem. > > We have no URL to point press/analysts or the band to on Orkut, Hi5, > > MySpace. On REM's "artist dashboard" on ilike we can point them to > > their iLike-generated artist pages in non-OpenSocial containers so > > they can preview how the songs and videos they are posting will appear > > to their fans. We can't point them to their OpenSocial canvas pages.
> > You may think that this level of url cross-referencing is only useful > > to complex/deep apps with many canvas pages like ours. This is not the > > case -- even the smallest applications benefit from the business model > > and development implications of URLs that can fall back on pure > > navigation.
> > So, in a nutshell, here's the ideal API from my perspective: users can > > copy-paste the URLs and we can construct urls offline or server-side > > (given a known root, which ideally would be http:// > > apps.<container>.com/ilike, > > but fine with us if it's anything fixed like http://<container>/ > > app_100) > > and end up back in our application, but we actually use > > requestNavigateTo under the covers which does all the good things > > containers apparently need in all the different contexts and we can > > support zany things like desktop/offline containers.
> > (the latter if the iframe host puts our docroot into place as they > > host our manifest, or we could do that ourselves given a fixed base > > URL)
> > Note that I would prefer this was shortened to take an URL instead of > > making us do all the path, options crud to indicate a GET -- this is > > just code that each application duplicates over and over again and we > > should optimize the most common case. If you couldn't do that we could > > stick with the longer convoluted arguments -- I don't really mind, > > though I think it creates an irritating barrier to entry for > > programmers to figure out for this API -- we would probably be > > rewriting this content on the client by looking for rel="nofollow" or > > some such on <a tags, like:
> I think it will be difficult to standardize URLs across containers, > even given a common server base. One particular problem will be with > more AJAX-y applications - even if we all agree, some will want to > navigate to http://container.com/#ilike?params and some to /ilike? > params (the # allows you to fake navigation without an actual > browser navigation request). It's worth starting the discussion to > see if we could all agree on a convention, but I'm not sure we'll > converge.
> Would it work if we had an API for getting a URL for a given > container, i.e.: opensocial.getUrlFor(app, path, params). This would > allow containers to have their own URL schemes but also support > getting a URL you could actually put into links. It's a bit less > convenient, as you wouldn't be able to easily generate per-container > URLs from your own servers,
> but it avoids trying to get consensus on URL structures which seems > a little daunting.
> Evan
> On Fri, Mar 28, 2008 at 3:51 AM, John Panzer <jpan...@google.com> > wrote:
> +1 - blogspot, for example, really really wants real linkable urls > wherever possible.
> -John
> On Mar 27, 2008, at 11:49 PM, "Nat Brown (ilike.com)" > <nat...@gmail.com> wrote:
> > There are a lot of painful implications to how requestNavigateTo > works > > within OpenSocial that should be addressed asap. Failure to fix > these > > issues will hinder developers and business models on the platform. > > Here is my suggestion.
> > Currently applications emit at the server or rewrite on the client > > simple links into complicated javascript calls. For us in iLike, > > instead of generating:
> > Going through container javascript to navigate isn't the worst thing > > in the world, but the fact that there is no real URL in the browser > > has several perhaps non-obvious implications to the user experience, > > business model, and technical layering which are worth thinking > about > > and fixing:
> > 1) when links are real HREF's in the browser, users can see where > > they are going when they hover over things, and they can copy/paste > > links and send them to friends. They can DIGG them, they can post > them > > to facebook, they can copy them into google bookmarks. They can save > > them in their browser favorites. They can open links in new tabs. > They > > can do none of these things in opensocial containers right now.
> > 2) Links to canvas pages from activity stream items and any kind of > > container notifications are also not going to work trivially -- > gadget > > javascript is not involved, we need to embed specific links into > > activity streams, notifications, and messages. we can't do that > right > > now.
> > 3) From a development perspective, the links are not only more > > readable for us and lead us to the code backing them more quickly, > but > > we can also paste such links into our ticketing system and find and > > resolve issues more quickly rather than needed to create tickets > that > > describe the steps to get to a sub-page. We can also concatenate > > suffixes from production links onto our private workspace or staging > > links to test out fixes. Partners can send us links that are > broken or > > that they have a question about. Customers can point us at > particular > > pages that have a problem, or our help buttons can automaticaly send > > us the page the user was on. We can use simple site performance and > > uptime monitoring tools to see how our opensocial application is > > performing if we have URLs. When we don't have real URLs in some > > fashion, all of this stops and our development process slows down > and > > our customers and partners do not bother taking the time to send us > > feedback, or they are frustrated by the process, and we can't easily > > monitor the uptime or performance of our application from an end- > user > > perspective. We get reports like "on the NNN artist page on Orkut > > there is a link to a concert on July 3rd at the Gorge > amphitheatre..." > > we can ping our web cluster for basic uptime/performance, but we > can't > > ping specific user or canvas pages to see whether something is > broken. > > This makes developing for and supporting OpenSocial painful.
> > 4) Also from a development perspective, when we use real URLs a > whole > > class of URL-signing and parameter-passing bugs that have plagued > each > > container and which continue plaguing us daily here would have been > > eliminated or minimally easier to track down. Encoding & signing " " > > and "+" was broken. UTF8 characters like Mötley Crüe weren't work > in > > g. > > All this because containers don't know exactly what to encode or how > > and are doing it within JSON blobs. It's unclear why this wheel of > > URL- > > encoding is being reinvented.
> > 5) if there are javascript errors anywhere on the page and > javascript > > stops running, navigation simply breaks, which is a horrendous user > > experience. They can refresh, but they can't go anywhere within our > > content -- not good and makes our applications and opensocial feel > > flaky. This happens regularly.
> > 6) Finally from a business model perspective, real URLs give us the > > ability to create ads and external references that refer to our > canvas > > pages. It allows us to cross-promote our applications and our canvas > > pages between different opensocial containers and facebook and our > own > > sites. It allows applications to cross-link with one another > within a > > containers, for promotional or other reasons. It allows us to email > > users and give them a link to visit Hi5, Orkut, or MySpace > versions of > > iLike and add our application, and it allows us to do conversion- > > tracking for installs from ads or email pointers and to optimize our > > conversion to installation. We have none of this without URLs. The > > most trivial example of this kind of utility which opensocial > recently > > lost traffic from is that we launched a new REM album for free > > streaming on 3/24 exclusively with iLike. We were able to point > users, > > the press, record labels, and bands (including the band itself, REM) > > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem > . > > We have no URL to point press/analysts or the band to on Orkut, Hi5, > > MySpace. On REM's "artist dashboard" on ilike we can point them to > > their iLike-generated artist pages in non-OpenSocial containers so > > they can preview how the songs and videos they are posting will > appear > > to their fans. We can't point them to their OpenSocial canvas pages.
> > You may think that this level of url cross-referencing is only > useful > > to complex/deep apps with many canvas pages like ours. This is not > the > > case -- even the smallest applications benefit from the business > model > > and development implications of URLs that can fall back on pure > > navigation.
> > So, in a nutshell, here's the ideal API from my perspective: users > can > > copy-paste the URLs and we can construct urls offline or server-side > > (given a known root, which ideally would be http:// > > apps.<container>.com/ilike, > > but fine with us if it's anything fixed like http://<container>/ > > app_100) > > and end up back in our application, but we actually use > > requestNavigateTo under the covers which does all the good things > > containers apparently need in all the different contexts and we can > > support zany things like desktop/offline containers.
> > (the latter if the iframe host puts our docroot into place as they > > host our manifest, or we could do that ourselves given a fixed base > > URL)
> > Note that I would prefer this was shortened to take an URL instead > of > > making us do all the path, options crud to indicate a GET -- this is > > just code that each application duplicates over and over again and > we > > should optimize the most common case. If you couldn't do that we > could > > stick with the longer convoluted arguments -- I don't really mind, > > though I think it creates an irritating barrier to entry for > > programmers to figure out for this API -- we would probably be > > rewriting this content on the client by looking for rel="nofollow" > or > > some such on <a tags, like:
> > Which we would convert/rewrite at the client to have the onClick= > > within them.
> > Thx, n@
> --~--~---------~--~----~------------~-------~--~----~ > 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-spec@googlegroups.com > To unsubscribe from this group, send
We could have a JS method and/or a RESTful method for returning the template, but the template would be assumed to be effectively permanent so apps wouldn't actually have to query it at runtime. That way they could build URLs on the server side.
On Fri, Mar 28, 2008 at 8:14 AM, Evan Gilbert <uid...@google.com> wrote: > Nat - all really good points.
> I think it will be difficult to standardize URLs across containers, even > given a common server base. One particular problem will be with more AJAX-y > applications - even if we all agree, some will want to navigate to > http://container.com/*#ilike?params* and some to */ilike?params* (the # > allows you to fake navigation without an actual browser navigation request). > It's worth starting the discussion to see if we could all agree on a > convention, but I'm not sure we'll converge.
> Would it work if we had an API for getting a URL for a given container, > i.e.: opensocial.getUrlFor(app, path, params). This would allow containers > to have their own URL schemes but also support getting a URL you could > actually put into links. It's a bit less convenient, as you wouldn't be able > to easily generate per-container URLs from your own servers, but it avoids > trying to get consensus on URL structures which seems a little daunting.
> Evan
> On Fri, Mar 28, 2008 at 3:51 AM, John Panzer <jpan...@google.com> wrote:
> > +1 - blogspot, for example, really really wants real linkable urls > > wherever possible.
> > -John
> > On Mar 27, 2008, at 11:49 PM, "Nat Brown (ilike.com)" > > <nat...@gmail.com> wrote:
> > > There are a lot of painful implications to how requestNavigateTo works > > > within OpenSocial that should be addressed asap. Failure to fix these > > > issues will hinder developers and business models on the platform. > > > Here is my suggestion.
> > > Currently applications emit at the server or rewrite on the client > > > simple links into complicated javascript calls. For us in iLike, > > > instead of generating:
> > > Going through container javascript to navigate isn't the worst thing > > > in the world, but the fact that there is no real URL in the browser > > > has several perhaps non-obvious implications to the user experience, > > > business model, and technical layering which are worth thinking about > > > and fixing:
> > > 1) when links are real HREF's in the browser, users can see where > > > they are going when they hover over things, and they can copy/paste > > > links and send them to fr
