hypermedia affordances
recently, i started thinking more about the concept of "affordances"
and how that relates to my experiments in hypermedia designs. the
trigger for these recent thought was a
post by
@danja
and a few subsequent page entries to the W3C Wiki on
RDF affordances. Danny's wiki entries point to a handful
of other folks who have wrtten about affordances recently, too.
all good stuff.
affordances
it's a funny word; made up word, actually:
The affordances of the environment are what it offers ... what it provides or furnishes, either for good or ill. The verb 'to afford' is found in the dictionary, but the noun 'affordance' is not. I have made it up (page 126).
The Ecological Approach to Visual Perception (Gibson, 1986)
not long after Gibson made up the word, Donald Norman used it, too:
...the term affordance refers to the perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used. (pg 9)
The [Design|Psychology] of Everyday Things (Norman, 1988)
years later, when trying to clarify what he meant by "hypermedia", Roy Fielding offered this:
When I say Hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions (slide #50).
Slide Presentation on REST (Fielding, 2008)
hypermedia affordance
if i follow the Gibson and Norman POV, i come to the point where "hypermedia affordances" should be recognizable "things" in the "landscape" that offer "actions." and these actions should be (IMO) related to hypermedia itself. so what would be the characteristics of hypermedia affordances? what would they "offer"? and how would they offer it?
right now i am of the opinion that a single set of aspects of hypermedia affordances can be identified. that this set would be universal to all hypermedia designs; no matter the protocol used (HTTP, FTP, etc.), the data format used (HTML, JSON, etc.). and that set of aspects should be enough to "construct" any hypermedia control needed in order to support a particular action in a distributed application.
the meaning and use of these affordance aspects must be shared by both client and server in a distributed network. IOW, when a server crafts a message that contains hypermedia affordances, the client has the same understanding of the meaning of that affordance as the server. to make that work, both parties need to know how to interpret the affordance. that's where the aspects come in.
i claim there is a stable set of aspects that can be found expressed in every affordance. and i claim that the set has only four members.
hypermedia affordance aspects
so here goes; my list of universal hypermedia affordance aspects:
- Safety
-
the affordance offers either a safe action (
HTML.A) or an unsafe action (ATOM.LINK@rel="edit"). - Idempotence
-
the affordance represents either an idempotent action
(
HTML.FORM@method="get") or a non-idempotent action (HTML.FORM@method="post"). - Mutability
-
the affordance is meant to support modification (mutable) by the client
(
HTML.FORM) or the affrodance is immutable (HTML.LINK). - Presentation
-
the result of activating the affordance should either be treated as
a navigation (
HTML.A) or as a transclusion (HTML.IMG).
that's it. these four aspects appear in every hypermedia control and can be used to create any hypermedia control needed in a dist. net. app.
examples
here are some examples:
HTML.IMG[safe, idempotent, immutable, transclusion]HTML.FORM@method="post"[unsafe, non-idempotent, mutable, navigation]HTML.A[safe, idempotent, immutable, navigation]HTML.LINK@rel="stylesheet"[safe, idempotent, immutable, transclusion]HTML.LINK@rel="rss"[safe, idempotent, immutable, navigation]
and the list goes on. this, i claim, works for any existing hypermedia type
(Atom, SVG, CSS, etc.). i have been experimenting and i think, in some cases,
the "aspect values" of some hypermedia controls are a bit vague (i.e.
ATOM.LINK@rel="edit" = [unsafe, idempotent, mutable, navigation?]).
right now i am of the opinion that this shows a vaguary in the control and/or
documentation of that control, not a shortcoming in my set of aspects.
so...
so why is this interesting?
if the general theory holds true (that there is an invariant set of aspects shared by all hypermedia affordances, regardless of data format or protocol), then it should be possible to express the same hypermedia control in any format, for any protocol. IOW, code can be wrttten that "understands" the aspects, "understands" each hypermedia control, and can "act" accordingly.
it should be possible to create a matrix of controls and aspects. it should be possible to create a single client application (agent) that can properly recognize and parse any hypermedia type as long as the agent has access to the list of affordances and their aspects for that hypermedia type.