Triptych

I originally had an idea to create this article many moons ago, but never got around to it because during my interaction with Google Spreadsheets led to much frustration. However, it appears that a very smart fellow by the name of Martin Angelov wrote an article for Tutorialzine called “Dynamic FAQ Section w/ jQuery, YQL, and Google Docs” which cut through a lot of the complexity I was inadvertently adding to my version. I highly recommend you take a moment and read that article before proceeding, because frankly I’m lazy and I’ll assume you did!

My version of this code changes very little except that we will use YUI – and dispense with the quote removal aspects, because YUI takes care of that for you.

Start out by making a spreadsheet like this one.

You can try out the YQL query yourself with this link.

Now publish it as a web page like the linked article describes and get the CVS share url.

Check out the code below and replace the spreadsheet url that you have created with the default one of mine:

Hit run and you should see your spreadsheet data showing up on the fiddle!

This is very powerful and way moreso than the linked article suggests. First of all you can also link a FORM to a spreadsheet. You might do this to allow certain users to input data into your spreadsheet in a way that insulates them from actually seeing the spreadsheet, or accidently making destructive changes. You might also create a very simple blog this way by creating a spreadsheet form that includes the title, content, etc. When you submit the form it would update your spreadsheet. You then have a website that grabs the output of that spreadsheet and displays either say the list of titles (a certain YQL query) or say the page details. You could get pretty elaborate with this.

Another use-case might be say a data-drive web game. You have all the monsters’ images, hit points, colors, locations, etc defined in your spreadsheet. Then you could consume that information on the fly with say a canvas-based web game.

The key idea I want you to get here is that you can now easily do: Form->Spreadsheet->YUI+YQL->JSON->Website with basically no complicated server database. Huge idea!

If you haven’t ready part 1 yet, no sweat. Just jump to the bottom of this post and click away, I’ll just hang out here till you are done.

Back now? Great. I enjoyed that short break.

This week it’s about getting back to the basics. I’ve been trying to get this app built for quite a while now, and I’ve managed to distill down the concepts I want to create for the first version. Essentially, you will have a set of “cards”. These cards represent the games that you might want to play at any given point in time. Each card will have a brief description as well as some stats about how many times you’ve played this game (if you launched it through Thwakr). You will also have a concept of a profile, which will allow you to set up your name, perhaps store user ids if you want (no passwords though).

For now, that’s it. Sign up. Log in, see some cards (that are games), click to play them, and record the play stats. This may seem like a trivially small feature set, but we will see just how much work it’ll take to get this far. For today I basically created the base HTML page with some markup for the cards, the profile, the about panel, and.. that’s about it.

You can see the source here.

What I am hoping to do is get the functionality working first. Before I even think about the UI, and getting it all prettied up. The first step in this is working on the HTML semantics. If you do this first, it helps you to think about the logical groupings in your app. What things are related, what kinds of clickable elements you want, etc etc. If you can get this down first, you will be a long way toward making your app a reality. Dont try to think about all the fancy CSS, or javascript interactivity. Think about how you want things to relate to one another, and how to organize them.

I’ve also decided to no use an special framework outside of just plain YUI + some gallery items for convenience. Perhaps in a later iteration but for now I really really just want to get it to “work”. Also, we havent talked much about the Chrome app aspect of this at all yet. That will come later, as it actually is only a small part of the overall development thanks to browser makers working to make extensions to their browsers work as regular HTML, CSS, js pages. We’ll also cover some promising sites like Crossrider which is kinda like PhoneGap only for cross browser extensions.

Next steps will be to begin building up some basic javascript objects which we will subsequently be using to harness together our application. I am conflicted about this because I know of a way that is “comfortable” to me, and I know of the way that is more “right”. (Via YUI Base). I’ll keep you posted as to which way I go with this.

Previous article: Part 1.
Next Article: Not yet.

I am a big fan of simplicity. Code you can just drop into a page and get going is way more useful than code you have to sit down and figure out all the configurations, different files to include, etc etc. I ran across this snippet while looking at the javascript libraries that Google now hosts (including YUI3 now!).

Basically, if you want an easy way to insert dynamic web fonts on to your page, you can simply find the names of the fonts you want, and drop a variation of this code below into your site. Of course you need to do some CSS styling as well – but it takes out much of the tedious boilerplate code you may have had to write. Before using this code, however you should read up a bit on the Loader Library details, so you understand what’s going on and potentially set it up to better suit your needs.

A while back I was hoping to start a series of posts about “make it with YUI”. I wanted to feature fun mini-widgets and components built with YUI that would be useful to website builders. But the thing is, I was never really motivated to build anything – because I was not using it myself. It was an example for its own sake, which in the end leaves you sorta hollow. Instead I’ve been wanting to build a website that also lives as a “Chrome App” or “web app” – meaning it should behave like an application, but live at a certain URL. (And perhaps even have some elevated capabilities). I knew I was going to build this completely with YUI, so why not use this time as a way to teach more about YUI at the same time?

Why not indeed. So starting today I’ll begin posting a kinda developer diary / tutorial as I try to build an application called “Thwakr”. What does this app do? Well, as I build this app, it will become pretty obvious. So, for today I simply have a few links for you:

Recipe for a YUI Application
Building Reusable Widgets with YUI3
Alloy UI

I’m basically in the planning stages. I will need to use localstorage, drag and drop, and several things like toolbars, etc. This has led me to consider using Alloy UI for the intial version. I can get pretty far with this, as well as maintain my own code in YUI3.3.

I’m also going with a concept of “it always works” – though I don’t know the technical term for it. But what it means is that no matter what I check in, the basic premise always works and you do not see broken links, or have dead-end behaviors.

If you want to follow development of the SRC for this app, then bookmark this github link: https://github.com/triptych/thwakr/tree/master/src/alpha/web

Once again as I dig deeper into YUI, I have unearthed another gem. This one will be very useful to you if you work with iframes at all. And you probably will if you ever decide to create embeddable content into other websites – because iframes give you a convenient way to insulate your own code from the CSS and JS of the “host” site. This module is called Y.Frame and is currently buried inside the HTML Rich Text Editor. I don’t know why these useful components are often placed inside another larger element, but I imagine it has to do with the fact that Editor probably is the first bit of code to use Frame. Eventually, if other components use it as well, it’ll probably be moved up to its own level.

Regardless, you can take advantage of it Today, given that you can just .use() it. Here’s some code:

Now for a brief explanation. There are several config settings that can simplify most of how you’d want to create an iframe. Y.Frame goes beyond this however an allows you to include CSS, linked CSS, set the DOCTYPE, insert some initial HTML and fire an event back when it is finished. You can even set it up so that any events that are triggered in the child iframe get sent up into the parent YUI instance so it can do interesting things like mess with the DOM, etc.

I’ve only barely scratched the surface of this component myself, but it already will replace a bunch of my own code. Note that it’s still in “beta” and even has some bugs (for some reason the “name” ATTR is supposed to set a classname on the iframe, but right now does “nothing” However the beauty of YUI is that you can file bugs since it is OSS). I encourage you to take a look at the source, and of the editor source as well to see an example of how this is being used, and I encourage you to take advantage of this component yourself instead of hand-coding because it takes care of many IE specific problems.

Have you found a “hidden gem” in YUI? Let me know!