API design
Timothy Green
For a javascript-driven Ajaxy skin, we would need an API. For a
smartphone app, we would need an API. And smartphone apps matter, as
they're far more usable than browsing the web directly on a smarphone:
http://www.useit.com/alertbox/mobile-usability.html. And I'd like an
Ajaxy skin.
One way or another, then, we need an API. Does an API exist?
I'm the sort of freaky weirdo who actually likes reading technical
documentation. And, even weirder, likes writing it. So if an API
doesn't exist, and you want one designed, I wouldn't mind giving it a
shot. (In fact, I designed a certain amount of it in my head while on
a 22km walk down the canal on Saturday.)
Should I write that up (and fill in the numerous gaps which are
inevitably left when you design something in your head)?
TRiG.
P.S. As I have a degree in chemistry, I still think of an API as an
active pharmaceutical ingredient.
Steve Dunkley
Basically, all the old skins are XSLT on top of a .net driven api cache. As you can imagine, fun.
Sent from my Etch-a-Sketch
Timothy Green
the very least, return valid HTML.
Shall I play with it, so? Generally, I'd prefer JSON, but XML might be
more appropriate in this instance.
Meh. We probably won't end up using it, but it'd be fun to do anyway.
TRiG.
Steve Dunkley
Timothy Green
idea of fun.) If it actually ends up being useful, then so much the
better. It'll be a good exercise for me anyway.
TRiG.
Steve Makin
Timothy Green
Application programming interface.
Basically, a standard for two programs to talk to each other. If h2g2
has a smartphone app, that app is going to need to ask questions like
"Any new posts on this thread?", or "Am I logged in?" and send
instructions such as "Unsubscribe me from this conversation (by the
way, this is my credentials so you know which user I am)" and "Log me
out". An API provides a method for doing that. So the API
documentation says "When you want to log in, you send this
information, in this precise format, to this URL". API documentation
has to be quite detailed.
XML and JSON (and YAML, which is a superset of JSON) are two standard
formats for sending information. Either could be used as a basis for
such an API.
TRiG.
Timothy Green
And not just a smartphone app. If you have an Ajaxy skin, it'll need
an API too. Ajax (asynchronous javascript and XML, though it's not
necessarly asynchronous and not necessarily XML), basically means
sending information between the browser and the server in the
background. So when you click somewhere, or press a button, the
javascript tells your browser that, instead of doing what it normally
would when you click here or press that button, it should instead send
information in the background to the server (using the API), await the
server response (using the API), and react accordingly. This would
mean that the browsing experience can be smoother. Facebook uses a lot
of Ajax, so when you submit a comment it doesn't reload the entire
page. And even when you click links it doesn't reload the entire page.
Gmail too uses a lot of Ajax. Click "Archive" or "Send", or follow a
link. The page doesn't reload (unless you're in "Basic HTML mode").
An Ajaxy skin would be nice. And that too would require an API. (And
since JSON is easy to parse in javascript, a JSON-based API would
probably be a good idea. Though for full articles an XML-based API
might be simpler. But that's the geeks' problem, not yours.)
TRiG.
Steve Dunkley
Timothy Green
TRiG.
Steve Dunkley
Timothy Green
> programmatically I find json soooo much easier, rather than having to parse
> a file you're referring to object elements. makes xml redundant as far as
> I'm concerned.
>
I think XML is better for markup. That is, after all, what it's
designed for. (What it wasn't designed for was SOAP, which I'm very
glad to say I've never had to use.)
<P>This is running <I>italicised</i> text.</P>
How would you do that in JSON? No, don't tell me. I don't want to
know. I suppose you could wrap the GuideML in JSON, but that just
seems messy. And pointless.
For anything that can be done in JSON, yes. Definitely. It's easier
and leaner. But GuideML is a form of XML, and I don't see any good
reason to turn it into anything else.
Should we be discussing this somewhere else, where we're not scaring
other people?
TRiG.
Steve Makin
Timothy Green
staying late in the office. And the ducks will be getting hungry, so I
really should go home. I'll be back online sometime tomorrow.
Bye for now.
TRiG.
On 26 September 2011 22:41, Steve Makin
Mark Faben
that might be (or on whatever device it might be), can be rendered
into HTML (or something very much like HTML), purely for accessibility
so there's some markup and scamantics on the 'page' displayed to the
user, which adaptive technologies can picup and pass on to the user,
in whatever format that user wants (Braille display, speech via a
screen reader, etc., etc.,).
<2cents>
(as you were... most the really techy bits are way over my head,
naturally. <blondemoment>)
2legs/mark
--
Mark Faben
Web: http://www.accessibilitytester.com
Music: http://www.music.accessibilitytester.com
E-Mail: mark....@gmail.com