Flash Cards with Google Spreadsheets

I slapped together a flashcard javascript library. The library pulls data from Google Spreadsheets and displays responsive and swipeable flashcards.  I use it on my android phone: I have two icons, one to quickly add new words to my spreadsheet and the other for viewing the words in flashcard format.

Here’s a live demo:

http://www.dittyjamz.com/samples/flashcards/

This library is open source and is a part my samples repository on GitHub.  You can check it out here:

https://github.com/shaun-moen/samples

Screenshot_20160306-003756

Screenshot_20160306-003811

Screenshot_20160306-003745

The Markup-invocation Approach

Over my career as a Web Developer I’ve come up with some pretty clever ways to achieve things (sometimes too clever, as a colleague would say :). But the following process is something I’d definitely use again, it’s thoroughly tested, critiqued by peers, and relatively clean.

Many JavaScript libraries that extend DOM (Document Object Model) functionality, also provide out-of-the-box components (sometimes called widgets or objects).  Often, these libraries will ship with HTML markup which is used throughout their components. These components parse and use this markup to create or shape existing nodes in the model.  Together these nodes compose and enhance UI components (menus, buttons, etc..) which make for an all-a-round more sophisticated webpage and user experience.

These frameworks often have an abstraction layer that makes it fairly easy to create, extend, and use components. Generally speaking, one would use the library’s methods to create objects and attach them to elements in your markup structure using selectors (often IDs). While this sounds trivial, it’s also repetitive. In practice, the use of these libraries tend to support the idea of stuffing markup into JavaScript for UI enhancements. This practice, when applied to custom written libraries, can subtract from the knowledge a server already has gained by rendering HTML markup structure in the first place.

I’ve developed JavaScript libraries using a different idea which allows the server to render most or all the markup needed for an enhancement, so that JavaScript, in many ways is reduced to binding/handling events and displaying a server-shipped structure. I think having markup which is primary sourced from the server encourages the re-usability of markup by the server.

At the root this process is an invocation layer I call an AutoInitter, (which could be a name for a lot of things), but the job of this code is to construct JavaScript objects, (or invoke functions) using class and data attributes provided by an HTML element.

Here’s an example of how it works:

Lets say you have some HTML element and you’d like to have some action – maybe a toggle of some sort. And when the page loads you want some content to be showing (state = “open”).

I might structure my HTML markup like so:

And my javascript might look something like this:

In Action:

Click Me!
Here I am :) …some content…

So, what’s nice about this setup, is the logic above is all I have to think about.   The trivial (but repetitive) stuff involved with actually finding my HTML elements, in JavaScript, disappears and is abstracted away. Infact, there is rarely a need to define an element ID attribute.

So how is the above code fired off? Like this:

This kinda of markup-invocation approach promotes an object oriented library design and keeps both JavaScript and HTML in their places. JavaScript code also executes only when needed (which includes binding events).

Even more, there is power gained with AJAX using the HTML response type because new functionality can be easily added (or removed) by responding with a new .auto-init element and respective data.

But I love JSON you might say!!!!? No problem, just pass your data through as an argument!

So, this means I can send an AJAX request to the server and replace the toggle’s content block with totally different markup and evolve the user experience on-the-fly, by invoking new functionality with markup provided by the server.

Here is an example:

Click Me!
Here I am :) …some content…

 

The above code integrates seamlessly on wordpress, but you can view an isolated example here:

To see the PHP code you’ll have to download full sample here:

As you might gather, this markup-invocation approach becomes particular useful when chaining several HTML forms together. AJAX server-side error checking can easily replace most, or all of client side error checking which eliminates the need for redundant logic.

Things can be said about HTML degradability as well. While this idea is becoming increasingly dated, with this approach, you will find HTML degradability to be as natural as it is graceful.

Enjoy :)

Shaun Moen