Google I/O 2011: Building a Business Web Presence using Blogger APIs

ArticlesBlog

Written by:


Morgan: Okay, I’m Brett Morgan. I’m the developer relations
engineer for Blogger, and we’re here this afternoon to talk about building
professional web sites using Blogger as
the back-end infrastructure. So what are we gonna cover? Firstly,
why you should use Blogger. Then we’ll look at a couple
of ways of doing so, and then finally,
we’ll have Pat Coleman here do a live coding exercise showing you how
one of these approaches works in practice. So a question you might
validly be asking– why would I use Blogger as a back-end infrastructure for a web site
that I’m building to serve myself
or for a client? So let’s start with a– a reason that kicks it
for me. Blogger is big, probably bigger
than you’d imagine. Here’s some statistics to help
you get a feeling for that. We have 400 million active monthly read–uh, users– readers. Um, up from 300 million actives
just a year ago. Blogger is growing. We’re a truly
international platform. We’re localized
in 50 languages, and 75% of our traffic comes
from outside the U.S. of A. And finally,
this is the statistic that does it for me– our users are putting
their thoughts, their dreams, their–their daily
annotations into Blogger at a rate of 250,000
new words a minute. This means that Blogger
is truly scalable. It’s stable, and it’s
the platform of choice for millions
of people out there. I did mention that
we were stable, right? So what do I– what do I base this on? Well, in a recent survey
of, uh, all of the top
blogging platforms, uh, our friends over at pingdom
ran a survey, and Blogger
was the only platform for the entire survey period to maintain 100% uptime. This means that we’re stable. We’re dependable,
and you can use us for both yourself and for your clients’
web sites. Now walking back
in history, I remember the first administration interface I handcrafted for my client, matching him up
with the web site I was creating for him. But, you know,
time moves on, and I learned that
there’s more to it than just figuring out
the mental puzzle. There’s–there’s engineering. There’s user interface concerns, and these days,
I’ve come to understand that these things really matter. I’m showing off Blogger’s
new admin interface that we’re currently rolling out
to our–our users. As you can probably see
in the URL bar, this is draft. So if you are using Blogger, you’ll start seeing this appear across all–
everyone coming up. Now hopefully I’ve impressed you to try Blogger out, and you might be validly asking, “Okay, how would I do that?” Let’s have a look
at three ways. First thing, I’d look at
Blogger’s templating system. Then I’d show you what
you can do with JavaScript, and then finally, we’ll have a look
at the RESTful APIs. So firstly, templates– Blogger’s templates are solid.
They’re stable. They’ve been with us
for quite some time. They’re well engineered,
well bedded in. Let’s have a look at one. This is actually some XML that’s pulled out of
one of my–my blogs– mouserants.blogspot.com– slightly simplified, but let’s–
let’s walk through it and actually have a look
at what’s happening here. Firstly, we’re using
name spaces to demarcate where our– the parts of our templating
language is. The B name space is used
for our conditionals and for our, um,
modularity, which you can see
on the screen here, and it’s also used
for looping constructs. Next, we have
an expression name space, which here is being used
to calculate some style for div, and the third one is our data name space, which is used to pull data out of the underlying
data store. But what’s all this doing? Well, if a user
is on a mobile platform, as you can probably tell, this
is serving out the blog header, serving out
the title of my blog and the description
underneath it. And if they’re not
on a mobile platform, well, there’s a nice little
image that goes behind that. As you can see, our templating language
gives you the ability to totally, um, customize the look and feel of your blog. So once you’ve created that,
your next question is, “Okay, I’ve got this template. How do I put it into Blogger?” Well, again back
to our swanky new U.I. There’s a template tab
on the left, and what you’ll see is this, and if you scroll down
the page– the red box is not there
on the production. This is to draw
your attention to it. Okay, you can do
a couple of things here. You can download
your current template. This is useful if you’re
making some changes in the admin interface
that you’re not sure if you’re gonna like or not, so you can download it,
play around, and then step backwards, or as in the case here,
where we’ve created a new one, turn around and upload it. Blogger will then validate
what you’ve uploaded, and once it is happy
with that, it will refresh
all your sites, and everything will be available
in your new library. So next question is, what advantages come from
using templates? Well, our administration
interface deeply understands
the templating system. So, for example,
what we’re looking at here is a layout view of my blog without all the content in it. And what we can see
on the–the bottom left is where the content
that I enter through the admin interface
will appear, and it says
that’s where it’ll be, and on the right
we’ve got gadgets. So gadgets are things
like open– OpenSocial gadgets, which you may know from places
like iGoogle, Orkut, or our Apps Marketplace. We also have widgets, which are using our ability for third party, um, companies to integrate with Blogger using the Blogger XML templating
language I showed you before. Another advantage–
and, well, who here has had
that wonderful call– you’re deep into figuring out
a deep technical problem, you’ve been working on it
for like an hour, you’ve got it all loaded
into your head, and your client rings you up
and goes, “I’d really like
the line at the top to be in a different color,
and, you know, a bit bigger,” and you’re just
sitting there going, “I really could have not done
with this phone call, because I just lost
what I was thinking about”? Well, we’ve got a wonderful
template editor, a template designer, which you can then
train your customer into how to make things
different colors. What I’m showing here
is changing my heading font to use the Google Fonts API
impact font. So you can have
your customers come to you with these wonderful problems,
and you can go, “Here you go.
You can do it yourself.” saving you from losing
all that context, so you can actually
get some coding done. Okay. Time to look
at approach number two. There’s a couple of ways
to use JavaScript with Blogger. First one, obviously, is putting JavaScript
in the template you were crafting
back in step one. The other way is we can render a completely new user interface using just HTML
and JavaScript and CSS, and pulling the data from the data store using JavaScript. Okay, I’d like to show you
some examples of–of this sort of technique. What you can see here is that
it’s dynamically loading, and, boy, your machine’s slow, Bro. We’ve got this– this ability
to dive into things, maybe–yes. I love demoing things live. What we’re looking at here
is the ability to have a blog,
or any web site that isn’t the traditional
main line of content with a sidebar. We’ve got navigability. We’ve got the ability
to dive into things. Scroll down, and–that’s right,
we’ve got a few tabs open. And here is exactly
the same content. Nothing’s changed
on the back end. Totally different
look and feel. What I’m actually
showing off here is a feature that Blogger
released fairly recently called Dynamic Views. But there’s nothing
actually stopping you guys from doing this, and we’ll get to that
in a second. Oops. I should probably go back
to the presentation. Did I just close
the presentation? No. Okay, part number three– using RESTful APIs
with Blogger. And here’s where we get
to announce something– well, actually,
announcing a preview. What we’re doing is we’re releasing
a new API in the coming short term… um, that will allow you to pull in all the content
that we were seeing before using JavaScript, um, and we’ll have,
as you’ve probably seen in the other API talks
we’ve had on this track, we’ve got client libraries for Java, PHP, python.net, and I’m missing one–Ruby. So you’ll be able to grab
all the content that your users have put in
using the admin interface, pull it out,
and re-render it in various different ways. So what can you do with this– what parts of Blogger
can you get to? Well, you can get
the–the blog information, the actual posts, either
in a list or individual format, comments, and the static pages. Static pages are usually
used for things like, uh, “about us,” “contact us,” “FAQs.” This means that not only can you have your clients
entering, say, constantly changing information, as blog posts, but you can also give them
the ability to edit content that would be so linked
from the– the top right of the page– the–the–the stuff
that’s always, uh, relevant. This means that you can give
the ability to your, um, your clients to change the look
and feel of their site without needing
to bother you constantly. So let’s actually have a look at the APIs that we’re giving. Firstly notice it’s on HTTPs. All of the new APIs
that Google are doing are all over HTTPs. They’re all also based on
googleapis.com. The part that’s different
is Blogger v2 blogs and underneath. So this one is pulling back
a specific blog. So first line, “kind,” is constant–is in all
of the data we’re returning, tells you what
you’re looking at. This means you can write
some generic code to pull this into whichever
format you prefer and basically switch off that. The next line is the primary key
of the object you’re looking at. The next one is,
in this example, would be the blog title, and the next, the description would be effectively used
as a subtitle. Then we’ve got “created”
and “updated” as time since Epoch, uh, the link where it’s actually
hosted on BlogSpot, so on and so forth. Now under a specific blog, we can get all the posts
in a paginated fashion. There are a list of them, [speaking indistinctly] because we can also get them
individually, and it’s using
exactly the same format. So again we’ve got “kind,” then we’ve got the primary I.D.
of this post and the blog
that it’s related to, and then we’ve got the name,
which is the post title, and the actual content,
which is the HTML that you’ve entered
through our admin interface. And then we’ve got the author
who created it. Useful for things
like bylines. Now we’ve also got comments, available as a list,
again, same format. So here we’ve got “kind,”
Blogger comment, we’ve got the primary key
of the comment, the post that it’s related to
and the blog and what was actually said. And now static content, again, as a list,
as individual pages. So now that I’ve walked
you through three ways of integrating with Blogger, it’s probably time for
that live coding exercise, where Pat shows us
how it is done. Coleman: Thanks, Brett. Okay, so now Brett’s
walked us through what sort of resources
we give you access to in this new updated Blogger API, um, so what
I will be doing is taking sort of a scenario where we want to build, like, a small web site for a business, and we’re storing their data
inside Blogger, and then using these APIs–
one for each resource– to grab that information
back out and display it in a web client. Um, now just briefly, for this demo
I’ll be using GWT. Uh, for those who aren’t
too familiar with it or haven’t used it before, um, how this works is
I’ll be writing Java code, which then gets compiled
into JavaScript, and then can be served up
from a static HTML page, um, with CSS or whatever
you like applied to it. So the nice thing about this is you could easily, say,
once you finished it, [speaking indistinctly]
within a day, and the overhead of actually
serving up that HTML and JavaScript content
is really, really low. And the way it will be
structured in this case is for every resource– uh, Brett’s already
walked you through what the model looks like
for that resource, so that’s all the content
that’s stored, um, for each bit of information
that you get back. What we then have
is a presenter, so that’s gonna be talking
to our API, uh, making
the Asynchronous Fetches of this model information
for the data we want, and finally, the bit
that we’re really interested in is the views, so how this, uh, common model information
can be presented inside a JavaScript client. Okay, so imagine this– you’ve got a business
that’s come to you, and they want a web presence. But, say, they’ve spent money
on advertising, or maybe they want
to lower their overheads or even, um, cut the costs
of all the products they’ve got, so you want to base it on a way that’s
easy to update, but also low overhead of maintenance of the site. And for this instance, uh, we’re using Blogger to say, uh, the business
that we’re running could be one where
you’ve got products overall, so each post that they make
matched to a product and vice versa. And then, uh,
for this example, say you’ve got a product that you have that
is a special for a week, so the most recent post
is the most recent product, and that’s on special
for this week, and you want to grab that
information and display it. But then, uh, it might
also be useful for customers to, on their site,
go back over the list of posts and examine what previous
content you’ve got, or previous products
you’ve been selling, and maybe even what users have
said about their experience either buying with you
or using your products. So let’s see if this works. Sorry, my thing was down
last time I checked it. So fingers crossed. Um… This should eventually load
as the blog where we’re storing the data. And just in case, I’ll try and load it
from a different area. Okay, and what
we will see here is just a normal
Blogger looking blog. There we go. So as I said,
imagine we’ve got– we’ve got a business
which is running their products through their blog,
and in this case, uh, just for this example,
we’ve got a business who are selling vases. What they do is
for each product they create, um, they–
one of their authors, or one of the people
in the business can go into
the Blogger admin API, create that post, hit publish,
and it will appear on this blog. As you can see,
they’ve got a name. They’ve got a little
description, but it’s not really–
it might not be stylized to what their product– uh, what their company
wants to look like. So it doesn’t have
their logo yet. We haven’t customized
the template any further than the original. Okay, so what we want to do
is now set up this client, uh, in GWT to grab this content and render it how we like. So what I’ll do
is I’ll switch over to, uh, the GWT client. Make sure it’s running. And what I’ve started off with is a really basic page. It’s just all the overhead
that you need to, once the page loads,
start executing the JavaScript that you’re coding up
in your client. So for now, we’ve got
[speaking indistinctly] but later we’ll end up
talking to the API and populating this data. Right, so the first resource
that Brett was talking about was his blog resource. Uh, the model is exactly
as shown before, so you’ve got the I.D.
You’ve got the name in HTML. Um, we support HTML
on descriptions as well, and you’ve got things like
post count, which, in this case, could be used to say
how many products you’ve got. Um, you’ve got
when it’s updated, in case you want to, say,
cache the results and not have to talk
to the API all the time. And then to get
this information, we go to that base HTTPs
googleapis.com/blogger/v2 for this version
of our API, and then at the end of that,
we add /blogs, and then the blog I.D.
of the blog that we’re using to host all of our data. So that’s the URL
we get this information from. Finally, the view that we’re
gonna use in this case, or, uh, in–we might just like
a splash landing page. So you’ll have the logo
of your business added. Um, you can also have
the name stylized and the description stylized, so we’ll use those as our
initial page for the view. Okay, switching back
to the client itself. Uh, I’ll open up the view in the GWT code that– I will be skipping
over these, mostly. Um, it’s sort of– the views are defined by
this templating language, which looks like HTML,
but gives you– and can be styled like HTML. It can have HTML elements
inside it, but it also lets you
point out certain elements in your HTML where information will go. So it’s not the easiest
to understand, but for here, we’ve got,
like, the splash page. We’ve got a section of HTML
for our name, section of HTML
for our description, and an image for our logo. Um, what might be so easy is switching to the Java, which compiles
down to JavaScript, which then forms that view
in our client. So what we do
when we’ve got a blog, we take that model, we find the information
that we are interested in– in this case,
it’s the HTML of the name and the HTML
of the description– and then we find the areas
in the HTML that we want to add that–
those labels to and just set them outright. So what I will do is
once we make the API call, the model resource
will come back, and then we’ll build the HTML
on the client. Okay, so finally,
to get this all running, um, I probably should remove
the windowed alert and instead replace that with– once the client loads, we add that overall view to the root of our HTML. So their whole page
will be filled with this initial
landing page. So I’ll kick off a compile. And just to remember, um, all of this is run
in JavaScript, apart from the initial,
like, serving of the HTML. So what will happen is
we’ll get a skeleton of a page loaded up first, and then the API fetch will go and talk
to the Blogger APIs. Um, it will do that through, uh, in the GWT library that does
JSON PECLs for you. And then once that result
comes back, we’ll fill out the parts
of the HTML with the information
that we want from our model. Okay. So we’ll run this. Now when I hit refresh,
you see the image loads, ’cause that’s part
of the framework. Uh, you get the page
at the top, and then once the information
comes back, you get the name
of the company– um, here we’ve just added
a bit of web font styling– and then the byline. So that’s the information
from a blog, but, say you’ve got
regular customers, they’ll probably know your logo
and your name already, and this content might not
change very much, so what we really want
to get in there is the product information
for everything that you have. So instead of doing it based off blog information, we now switch to using our model as being the posts. As before, you’ve got
the post model, which is the–the I.D.
of the post, um, the name–
so that’s the HTML that the post is titled. Uh, you’ve got the HTML
content of the post direct from the Blogger
back ends. You’ve also got this nice thing,
which is the author, which applies to anything
which is authored inside the Blogger API,
so it gives you the name, their profile picture,
if they have one, their link to their profile, um, and then the number of comments on the post. So we do it this way
just because the comments themselves
have different resources, so rather than serving
them up with, like, a large overhead on the posts, we give you the number
of comments, and it’s possible to form
the URL to fetch those later. But the URL for the posts
is exactly as before, so because the post was
[speaking indistinctly] in a blog, the start of the post
URL is the same. You’ve got the Google APIs
and then Blogger v2, uh, then followed by
/blog/blog ID for the blog
that the posts live in. And then finally, we want
to get one particular post of the product
which is special this week. So there we add /posts
and then /post ID for the I.D. of that post. We make that call, get back
the information from the APIs, and now we need a way
to display this to the user. And just as before, we set up the HTML template with areas for where the name
of the pa–uh, post goes. Same with here, where you can add an area where
the name of the author goes, in case, like, uh, different authors might publish
different types of product. And then finally,
we have an area where the HTML
of each post goes, so that will be information
about the product, the pricing, how to buy it, um, all that information. As with before, we create a view
to display our posts… and in this case,
we render the post similar to how we
rendered the blog. We find where on the HTML page the post name goes. We format the name to say–
in this case, we can link it
to the original blog post, and then we push that
into the page. Same with the, uh,
the content of the post, and we just grab that
straight from the model, and similarly,
we now grab the author, and we get their name and put that
where we want on the HTML. Uh, finally,
in our overall view, how we’ll display this page is rather than having
a splash landing with the one tab at the top,
we’re gonna add a second tab, which is this week’s,
uh, special, uh, product. And so now we’ve got
a second tab for that. Um, as before–I’ll just
kick off this compile. Uh, that’s all right,
I just have to, once we grab that information,
push it into the view, so that it updates
once the fetch comes back. Okay, so once we run this, it will have the same initial
load as before, so that HTML framework
of the page, but with new information. Um, it will then do the call
to get the blog’s name and the blog’s description and put that into
the splash landing page. And then simultaneously,
it will grab the most recent posts
information and put that, uh, invisibly, into the second tab on the page. So here we go. We’ll serve our client locally. I’ll go to this.
Refresh it. You get the same
frame as before, but you can see
there’s now, uh– not too easily on this screen– but there is a second tab
at the top left here, um, with the special. So once you click on it,
you get today’s special, which, uh, is grabbed straight from
the blog post HTML. We can style this however
we like on the client, so if your authors have gone in
and not applied any stylings, then this–
the HTML that they published, will get whatever styling
is from its parent. So say our business had
a particular font they liked, any post could be rendered
in that font here. Similarly, you can add
information around the outside
of this post. So here we’ve added, like,
a “buy now” button, so that would then contact,
in this case, our Google Checkout account, um, the user–the customer would
then go be able to send us a purchase request, and we could process that, uh, with however way we’ve got
set up for our company. Okay, now a third type
of resource that Brett was mentioning was these lists of posts. So in the new Google
infrastructure for APIs, the lists work nicely in that they sort of just wrap
the existing resources. So here our list of posts is just a list
of these post models that we’ve already–
know how to load. We already have defined
a view for. So what we’re doing
for this section is, uh, the model
is effectively the same, the API call, instead of
to a single I.D. Post, now we’re doing it
to the entire collection, um, which we can paginate
if we–however we like. And so we do /posts, and that gives us, uh,
quite literally, just a list of these
post objects. And–sorry–as we expand
on this, we’ll be able to add
query parameters. So you could say give me all
posts that have a certain label, so maybe it’s
“half-price” label, or, uh, “blue vase” label, or whatever labels you’re adding to help you categorize
your products. You’ll be able
to grab that category out of your
product information. And then the nice thing
with the same model is that we can reuse
the same view. Uh, in this case,
we will have the product and then sort of navigation, so you can sort of
traverse through time to go–to delve
into past products. Now the code for this is very similar to before. So we’ve reused the views. Um, we’ve got a– uh, one view for doing
the list of posts, but really that’s just comprised
of this single post view and navigation, um,
plus some events, so you can click left or right
to go back and forwards. Um, how we display this
on the main page is similar to how
we did before. Uh, rather than adding a tab
to get the most recent deal, we can add a tab to get
the list of previous deals. And then once that API call
comes back, we take that list, uh, push it into the HTML, and then it will get rendered, uh, whenever
the fetch comes back. Okay, so the difference here is the initial landing page
will look the same, but there will be a third tab,
which you probably, again, won’t be able to see
under this black screen. Um, but yeah,
so that information, once we fetch it from the API, will then be displayed
into our page, uh, and be able to be viewed
one page at a time. Okay, let’s see if that
picked it up. Probably not yet. Okay. So looking at the new client. Yep, you’ve got the same
introduction page as before, um, you’ve got the same
single deal as before, but now we’ve added, like, a little stylized
reflection here. You can navigate
through previous deals. So these are the ones
that we’ve had. And as you can see
from this page, that’s exactly the content
that’s come from the blog. Now one advantage
that you get from this is that if your–
your clients, or the people running
the business, say, they’re visiting
their own web site, and they see maybe
they had a– there’s a spelling incorrect
in one of the products, or maybe the price
that it’s been offered at, they want to adjust it slightly ’cause, say,
it’s really popular, what they can do is go to
our Blogger editing– uh, publishing U.I., so long as they’ve been added as an author
or an admin of the blog, they can then go and correct
out the content their selves, in either, uh,
HTML editing mode or in our WYSIWYG, uh, NicEdit editing experience. Plus, as we’re pushing out new features to this new U.I., so, for instance, now we’re
making it look slightly nicer, act faster, we could be adding
features to our editor– that entire publishing
experience will be improved
for your clients, So they can add links. They could add videos, um, even custom JavaScript
inside each product. Um, they could have
an original template which each product
is based off, and so they could then
pull in the image, uh, pull in
the short description, and then it would only take,
say, a few minutes to get one of these product
pages up and running. Okay, the final resource
that we haven’t covered yet that I’ll be using
in this demo is displaying feedback about
each of your products. So the resource
we’re using here is the collection
of comments, which, as before, is just a list of these comment model objects. So that includes, like,
which products they are on, um, which blog they are on, which would be the same
in this case, uh, their HTML content, and the person who wrote it. So we do support
anonymous commenting, so it might not
always be there, if the comment
was made anonymously, but for most users, you’ll get, like, their name, a profile picture
if they have one, and things that let you display
the comment in a nice way. Uh, finally, to display it, we’ll just add a section down at the bottom of each post. So because the comment data isn’t available at first, we’ll sort of start this out,
uh, collapsed, if there are comments
on the post, and then once it’s expanded, we can basically go off,
do that call. Once that data comes back, we can fill out all the comments that have been made
on that product. Okay, so translating this
into the code. Uh, for each post, we want to enable this little comment section
down at the bottom. That’s what this, uh,
bit of the template that I’m uncovering there is– it’s the section that will
expand out once you click on it. Hooking them up–
that up to the post itself, uh, firstly, we need to add
a bit of event logic to handle making the API call once you, uh, expand it out. But once that’s done,
we’ll get just a simple list of this comment
model object back and push that into the HTML one after another. And for those who are curious, this is exactly what
our comment model looks like. So, uh, because the way that
GWT is written in Java, uh, you sort of need accesses into this JavaScript
that’s returned, ’cause you can’t easily, uh, use it just as JavaScript. Um, but in this case,
we have small wrappers that go across
each of the attributes, so for our content
in our comment, we just have this “get content”
model–or, method. The one other nice thing
about this is for those who saw
the talk earlier today, um, part of the common
APIs infrastructure that we are launching
this API on is a discovery document, which tells you
for each resource you have exactly what these properties
will be. So you can think, for each
of our model objects– so here I’ve got like
blog, comment, post– all of that code can be
automatically generated for you. You don’t even have to worry
about any of that, and it will give you typed
access to all of the values that you’re pulling back
from the blog. Okay, so once we’ve got
this comment data, um, we make no change
to the overall view, because if you remember, this is only being added
to the–each post, um, and so the initial view– the initial load
will look very similar. You’ll get the blog information,
the blog description, and because of the way
that we set it up here, uh, any post that doesn’t– or any product that doesn’t
have any comments won’t have that section
down at the bottom, but for the ones that we do, you’ll get this new, uh,
expandable div. Okay, so I switch
back to our client. You get the same
initial page. Uh, you get today’s special. And as you can see, just–
now it does have comments. We’ll navigate
to this area, and for whichever pages
have comments– remember, the comment data
hasn’t loaded yet, so even if it had
50 comments, that wouldn’t have slowed down
our initial page load. But once we click it,
we’ll go off to the API call to blog–Blogger API–sorry,
googleapis.com/blogger/v2, and then /blog/blog ID, /post/post ID, and now /comments. Grab that information–
that comment data back, and then use it
to fill out this HTML. So we expand it,
we get the comment, and there you go.
There’s the comment data. Um, you can even add caching,
so that every time you load it, uh, the comments
are still there. And this is the same
for any post. So now we go off.
There’s that comment data. And we can navigate through. So there you have it. It’s like a small GWT app
that you can use to display, uh, for the use case
of having a business which has, like,
a list of products and one that’s on special, but you can imagine taking this and applying it to whatever
blog you are interested in. So you could–if you had, uh, tolls for the views
that you have, you could easily run, say,
three different business blogs. Or in the case
of the dynamic views, um, if you make it
general enough, you can, in fact,
apply that client view to whatever blog
you’re interested in. So if I change the blog I.D.
that this is pointing at, um, to, say,
my own personal blog, I’d be able to read my blog
in that format instead. Now as Brett said,
we haven’t, uh, launched this API on the googleapis.com
site yet. Uh, the interesting thing
about today was opening a discussion to see what sort of information people would like on, uh, attached to each resource. So we have blogs.
We have posts and pages for the more static content,
um, plus comments, but we’re still solidifying down what information
will be available. And similarly, for now,
we’re concentrating more on, like, a read-only API, so as you have seen, we’re fetching
information from Blogger, um, and– but we don’t yet
have exposed ways to put content back in. Uh, but that’s more of a matter
of we’re hoping the solidify the model objects first
to really see what sort of visualizations
people want, whether it be for a business
or for an overall blog. And then once that’s settled, we can see at ways to be able to publish that new content from whatever visualization
you like. So you can imagine setting up, uh, your business
publishing page, where you’ve got maybe
four forms– uh, I’m sorry–
a form with, say, four fields like image, uh,
medium description, price, uh, longer description. You hit a button, publish that information
to the Blogger API. That will get added
to the overall blog, which has the–
say you have customers that use RSS readers, or use our new e-mail
subscription to the blog feature, they will get that information
as soon as it’s posted. But then additionally, if you have
one of these clients, you’ll get that information
as soon as it’s there. Um, and so, say,
we had a new post– once you load today’s special, that will grab the most recent
post from the blog, so you don’t
have to worry about updating your overall
business web site. Okay, that’s it from this demo. I’ll throw you back over
to Brett to close out. Morgan: Okay. [speaking indistinctly] Okay, so what did we
show you today? First off, I talked you through
why you should use Blogger. Then we looked at three ways
of using Blogger, including our new upcoming API, which we’ll be getting out there
really soon now, and finally, we had
a live coding exercise. Um, if you’ve got some feedback, or you’re twittering about us, please use those hash tags
so we can all follow along, and I’d really love it if you’d
give me feedback at that URL. But it’s now time for Q & A, so there’s a couple of ways you can get hold of me. There’s my e-mail address,
[email protected] Second part–
I’m on Twitter, oh, my God, and finally, there’s
a Google group that I run for people developing
on top of Blogger. But we’ve got some
microphones in the room, so questions, please? man: Hi. Thanks for
the presentation. Um, uh, this new API, does this, uh, is this an additional API,
or does it replace the old one? ‘Cause, uh, I’ve been using
this whole kind of model for a couple of years now,
I think. Um, so what does that–
what happens to the old– I think it’s been a while
since, uh, I believe it’s Google data… Morgan: The Google data APIs. man: And, um, what else? Uh, it’s ATOM or RSS,
pretty much… Morgan: yep.
man: if I remember right. So I’m assuming that this will have every… Morgan: Okay, so what’s
happening here is Google data APIs are the solid–everyone
knows how to use them. We’ve got them well tuned. They’re–
they’re in their platform. This is effectively
our experimental area, where we’re looking at– Google data is all XML. It’s kind of heavy.
It’s kind of– it’s kind of nasty to use from
JavaScript in a web browser. What we’re trying to do here with all these data models
and JSON is allow people to experiment,
play on the web browser or on the android phone
or so on and so forth, be able to deal with their APIs
in a light way that’s, you know,
buzzword compliant, um, and talk with us and go, “Okay, I’ve got this wonderful
new use case. How can you help me
make it a reality?” so that’s the discussion
we’re looking to have here. man: okay, so it doesn’t really
replace that whole thing? Morgan: No. Coleman: You’ll still
be able to use that. Um, but as Brett was saying,
this is like a very lightweight approach.
man: Yes. Coleman: So we do encourage
people to use this new system, especially as it will gain
any advantages that are written into
the overall APIs infrastructure. So, like, all the server
side libraries that are written for you, um, you’ll be able to use them all
with this new API. Morgan: Yep.
man: Thank you. Morgan: So basically
to cover it back, the new API structure
is a Google-wide thing. We have got new API libraries
coming out, client libraries coming out,
so on and so forth. So if you’re developing
something new–yeah. man: Um, two questions…
Morgan: yes. man: Where do you want
the feedback for the API? Not for the presentation–
Morgan: Oh, for the API, you can either talk
with me directly, or take one of those
three methods. Probably the bottom one’s
a really good one, ’cause that way
you can have a discussion with the other users who are
also developing atop Blogger. Coleman: Mm-hmm.
man: Um, and conceptually, I’ve done client work before, and a lot of clients
like to think of having a CMS to manage their content…
Morgan: Yeah. man: is that the kind
of paradigm here? Is that what you’re thinking?
Morgan: Blogger is a CMS. man: Right.
Morgan: It’s a very light one, but, yes, it is a CMS. man: So is it–
is there any way to, um, to–to structure the content
in the CMS, um, beyond what a blog post is? You know, you’ve got your title,
your content, your comments. Morgan: At this point, no.
man: All right. Okay, thanks.
Good presentation. Morgan: Thank you, Jonah. Any other questions? Or are we all
rushing to the bar? I think we’re done.
Thank you very much. Coleman: Thank you.

6 Replies to “Google I/O 2011: Building a Business Web Presence using Blogger APIs”

  1. Matheretter says:

    Blogger is a great service, and thanks for the API.

    But unlucky with promotion this time: Right after the video Blogger went down (and is still down) for nearly 2 days, and our new posts are gone…

    If the posts can be recovered, our confidence will return! We are all human 😉

  2. Matheretter says:

    To make Blogger ready for business:
    1. Possibility to rename URLs (no date in URL!)
    2. Extend post options to provide meta-tags directly (esp. description meta-tag!)
    3. Extend post options to decide if next-previous-buttons are displayed or not
    4. Make the template fully editable, i.e. remove automatic (script) inserts by blogger (e.g. let us remove the body navbar)
    5. Add a breadcrumbs system
    6. Provide a chunk system like modxcms
    Experience: 2 years of Blogger usage.

  3. Dan Denno says:

    Gosh I attended Google I/O and am now checking out blogger video. I use wordpress currently but don't know java and python although know php and a bit mysql. This looks promising but heavy knowledge needed to develop. I think what I like is that if you learn GWT you learn how to work all the products of google where as wordpress you just get wordpress. I like the template design part and possibly hook up to Web Purchase store. WordPress has a huge following and a ton of material out there.

  4. JeeShen Lee says:

    These guys help customize blogger – blogmakeover,net

  5. Chrissy Carter says:

    Could google create an app for everyone to have a personal bank/account independent of any other bank..completely ours that our pay could be transferred into n we have complete control and access of our money..not the big banks

  6. BawaGrafix-ITSolutions BGITS says:

    got an good idea to user blogger wisely. Thanks for video

Leave a Reply

Your email address will not be published. Required fields are marked *