2012/Web Actions: A New Building Block for the Web

From Open Source Bridge Wiki
Jump to: navigation, search

A web action is the user experience, code, and service for taking a specific discrete action, across the web, from one site to another site or application. You’ve all seen the buttons: Share, Read later, Follow, Like, Favorite, etc.

More than any one social site or service, web actions are the emergence of a whole new hypermedia building block.

This talk will give an overview of the anatomy of a web action, discuss web action user flow, and highlight best practices for both publishers and service providers.

Speaker: Tantek Çelik

Return to this session's details

Contributed notes

Speaker

This session will include a short presentation and then discussion led by Tantek Çelik.

Notes

Real-time collaborative notes:

Welcome to Web Actions: A New Building Block for the Web at Open Source Bridge 2012!

This document is licensed using CC0 - No Rights Reserved. By editing it, you agree to license your contributions with CC0 as well.

Details:

  • #osb12 #webactions

2012-06-28 16:45-17:30 Room B302/303, Eliot Center, Portland, OR

slides:

URLs:


Questions:

faddah here. some questions, playing devils advocate to your presentation yesterday? —

the blog article you wrote on the same subject starts with examples of early interactions between different servers using ajax. yet the rest of your talk seems to eschew the use of javascript. while i agree with your observation of the huge amount of marketing/demographic information facebook, google+ and others pull from clicking the share buttons (you like NASCAR, i like “chiclets”), that not only invades privacy, but bogs a system down. are you taking an anti-javascript stance?  this does not bode well for those of us who _like_ to code our client side (with some server interactivity) with javascript.

you call for the use of the “<action...>” tag, in some future iteration of HTML (HTML 6??), which is fine, but i have to ask, what is the difference between that and just putting javascript scripts within the body of your HTML? as far as things like "POST" and button actions, i'm not really seeing any huge difference between saying it in the syntax of an “<action...>” tag and doing it with javascript, in the body of the HTML or as a separate file? also, isn't HTML, per w3c best practices, supposed to be just for structure, and formatting (CSS) and scripting or “<action...>” events meant to be separated out, for cleaner, readable code?

the main argument you seem to have about using things like "rel=me" and “<action...>” is the nascar/chiclet share button effect, the huge amount of marketing/demographic it contains (privacy issues) and the memory/performance costs due to that. but are there any other server to server ajax-like interactions _besides_ that, which are other examples of why your proposals are better to do it all in HTML rather than javascript and/or PHP? i ask because i don't feel that complaining about one issue only, however valid, will _not_ contribute toward making the changes you seek. broad language changes like is require that they are solutions to several or many issues, not just one.

i agree with you that it is abhorrent to deal with facebook/google (and others) monetization of us for marketing and demographic purposes, but unfortunately, that is just the nature of the beast. we get to use those services for free, or free in the sense that we willingly give over our private browsing habits being exposed for monetization business purposes. we can choose not to use them, but the pull from friends and family using these services due to both their relative ease of use and popularity is too strong — we may not like them or like using them, but it's what we have to get updates and content from those we care about. even if things like your proposed “<action...>” tag are implemented, or everyone now uses personal web blog sites as log-in id through the “rel=me” tag and one of these relevant services, there will always be large corporations lobbying browser manufacturers and the w3c to add more scripting elements to allow for the tracking they want even through those very tags. it's just how they roll, and you can try to create new code around them, but eventually they get savvy, co-opt that code or lobby for scripting additions that will let them accomplish what they want, disgusting to us though it may be. so how can there be changes in this beyond escalating code tag additions??

and again, i ask, is there any other purpose to these proposed changes and tags you and indieweb want other than the nascar/chiclet share buttons and their accompanied marketing resources bloat?