Observations for RadioTAG Comment Request
André
So, trying to retype a short version of the mail that got lost
yesterday:
1) I think Andy's document is an excellent overview and good
foundation for a protocol.
2) I'd like "JSON all the way" more, but that's just personal & not
important
3) With the feed reader feature, 3 stage tagging mechanism, uuid
generation on the radio device, http, security, browser or workarounds
if it is missing etc it seems we're shifting a lot of work to the
radio device. At the same time we still want RadioTAG to be possible
on the simplest devices. I'm beginning to think that we shouldn't
limit a full specification by this lowest common denominator, but
apply a reduced spec to simple devices. A full blown protocol/spec is
for iPhone or Sensia-like devices that have no problems generating
UUIDS or providing https security.
Does it makes sense to show URLs on a browserless device for example?
even in a "human friendly" form nobody is going to copy that to
another browser/device (we're talking about an event feed, not a
station URL here)
Maybe a minimal spec can be easily embedded in the draft by just
clearly defining what is mandatory and what isn't. I guess that may
have been the idea from the beginning.
4) Syndication: I guess we could have a syndication architecture
without a separate web service for "known tagged services". I have to
think about that. It would probably mean that users can add stations
they tag to their user profile (which is hosted by any broadcaster
website). I can't get the jabber model out of my head here. To be
clear though: I'm not suggesting to change the model at the moment.
André
Basel, Switzerland
Andy Buckingham
A quick reminder for everyone on the team, there's less than 24 hours
now before discussion is closed and I move to look at a draft
specification. We're trying to pick up pace on this discussion as
we're somewhat behind previous goals on getting to a final draft spec
for 1.0 to present to the RadioDNS board.
On 11 November 2010 12:27, André <solil...@gmail.com> wrote:
> 2) I'd like "JSON all the way" more, but that's just personal & not
> important
I think for the relatively simple requests we are attempting within
TAG, HTTP POST already provides a suitable exchange method without
unnecessarily complicating it further with JSON on top.
However, the returned payload needs some structure and I think our
JSON responses are suitably light whilst still having a simple
structure to follow.
> 3) With the feed reader feature, 3 stage tagging mechanism, uuid
> generation on the radio device, http, security, browser or workarounds
> if it is missing etc it seems we're shifting a lot of work to the
> radio device. At the same time we still want RadioTAG to be possible
> on the simplest devices. I'm beginning to think that we shouldn't
> limit a full specification by this lowest common denominator, but
> apply a reduced spec to simple devices. A full blown protocol/spec is
> for iPhone or Sensia-like devices that have no problems generating
> UUIDS or providing https security.
The concept of a simpler level of implementation that sidesteps the
more complicated nature of the new proposals did cross my mind, but
the over-riding concern was that it sets a bad precedent. Allowing a
device to implement an insecure implementation suggests to the
community that the bad user experience of a device being compromised
is OK. This could have more substantial problems with users opinion of
TAG as a whole, rather than specifically with that one device. I'm
undecided on this. Does anyone else have any opinions?
> Does it makes sense to show URLs on a browserless device for example?
> even in a "human friendly" form nobody is going to copy that to
> another browser/device (we're talking about an event feed, not a
> station URL here)
It is quite common for key promotions on air to feature relatively
simple URL's which would normally be read out on air, so why not show
them visually on a device display? For example:
capitalfm.com/competition
> 4) Syndication: I guess we could have a syndication architecture
> without a separate web service for "known tagged services". I have to
> think about that. It would probably mean that users can add stations
> they tag to their user profile (which is hosted by any broadcaster
> website). I can't get the jabber model out of my head here. To be
> clear though: I'm not suggesting to change the model at the moment.
I can't seem to find a reasonable model that overcomes the potential
problem of a user simply not remembering what else they tagged and
where it exists. The only node in the environ that "knows all" is the
device. Letting the device report (with permission) this data allows
everyone to join up the dots. It may not the most refined model, but
it works. Does anyone else have any suggestions for this section of
the proposal?
André
One more question regarding syndication: So, it's always the service
provider (SP) that initiates syndication? Can the user go back to
stage 2 if he confirms but doesn't like syndication? Does every
broadcaster/SP has to ask for confirmation, or does it come via my
user account?
André
On 11 Nov., 14:10, Andy Buckingham <andy.bucking...@radiodns.org>
wrote:
>
> A quick reminder for everyone on the team, there's less than 24 hours
> now before discussion is closed and I move to look at a draft
> specification. We're trying to pick up pace on this discussion as
> we're somewhat behind previous goals on getting to a final draft spec
> for 1.0 to present to the RadioDNS board.
>
Andy Buckingham
> One more question regarding syndication: So, it's always the service
> provider (SP) that initiates syndication? Can the user go back to
> stage 2 if he confirms but doesn't like syndication? Does every
> broadcaster/SP has to ask for confirmation, or does it come via my
> user account?
The way it is currently proposed, the user has the ability to return
to stage 2 by logging in to the broadcasters websites they began
syndicating with and requesting them to stop.
It may be a better user experience to also define a "cease
syndication" method in the web services so a device could implement 2
options:
* Stop syndicating with current service
* Stop syndicating with all services
I like this as a proposal as it means the user is in total control,
device or website they can turn this on and off. Does anyone else have
any views on this?
Paul Fairburn
Apols for the last minute response here!
I like the changes - good work. The user experience is what I focus on, and
I like the simplified user processes. I also like the use of short codes
when the user has to type things into websites.
I suggest the recommended behaviour of service providers be to use URL
shortening techniques to deliver short URLs when using the optional "link"
object attribute in the response. (That Katy Perry example is pretty long
for a small screen, for example).
I suggest that device manufacturers be allowed to take part in tag
syndication (maybe that's your intention).
In the section where you discuss Tag Submission you specify that the device
must order tags in reverse chronological order. What happens to podcasts?
Do we use pubDate... and if so, it that what a user would expect? I suggest
the best user experience is to see the tags in the order in which the user
tagged them. (e.g. if a user listens to a podcast from a previous year the
tag might disappear to the oldest part of their tag list, un-noticed by the
user.) Perhaps podcasts have their own array?
In the Device Registration section, might we make it optional for device
manufactures to enable multiple UDIs on one device? I like the use of
UUDIs, and it would be up to device manufacturers to decide how to make
multiple listener identities work on their device, if they wanted.
Lastly I agree with the comment you made to Andre about "cease syndication"
being possible from the device. It should be up to the user, from the device
itself, to easily turn this off for one or all services. Turning it back on
should also be easy!
Regards
Paul Fairburn
Andy Buckingham
> I suggest the recommended behaviour of service providers be to use URL
> shortening techniques to deliver short URLs when using the optional "link"
> object attribute in the response. (That Katy Perry example is pretty long
> for a small screen, for example).
The purpose of the like attribute was to provide something a user can
read and copy in to their browser easily. The traditional URL
shortening techniques typically generate URL's that are difficult for
users to read and memorise or copy, for example http://bit.ly/a1Cuig
However, I accept that the URL I used in the example probably wasn't
ideal. I'm aware that must URL shortening services also cover off the
read/copy issues by allowing uses to provide an alternative string in
place of randomly generated characters, for example
http://bit.ly/nice-photo Maybe we should put a recommendation in that
the full URL should be under a certain character limit?
> I suggest that device manufacturers be allowed to take part in tag
> syndication (maybe that's your intention).
Absolutely. I'm not sure how explicitly this needs to be spelled out
in the document, but there is nothing to stop an enterprising
manufacturer sitting between device and broadcaster to allow them to
act as a syndication point. They should not, however, use the standard
service-to-service syndication as they themselves will not be
responsible for tagged event resolution (if that makes sense?)
> In the section where you discuss Tag Submission you specify that the device
> must order tags in reverse chronological order. What happens to podcasts?
Well spotted, that was as clear as dishwater in my document. What I
meant was that in the case of "relative" audio (podcasts,
time-shifted, listen again etc.) the device should order it by the
time the interaction occurred. I will add this to the draft spec to
define that when submitting a relative tag event you include both
period and time, where time is the moment the interaction occurred. I
think this is the most logical way of treating these events, if a user
listens to some live radio and tags it, then listens to a podcast and
tags it, then listens to live radio again and tags it the order would
be Live Tag, Podcast, Live Tag. It fits the order that the user
performed the interactions in which seems most logical to me.
> In the Device Registration section, might we make it optional for device
> manufactures to enable multiple UDIs on one device?
Yes. It is probably worth making this clearer in the next release. If
manufacturers implement multi-user modes on their devices, they should
create unique UDI's for each user. I hope by keeping it this way it
keeps the concepts relatively simple. This method still allows users
of the same radio to share tags too by simply linking their "psuedo"
devices back together again. This does remind me too that we need to
talk a bit about recommended behaviour from a service providers
tagging website implementation, for example if 2 users share a device,
deleting a tag on a device from one user should not delete it for
both.
Thanks again, this is all worthwhile feedback for inclusion.