2007 / March 9^th/ Visual Scripting Patterns Investigation

I’ve been thinking a lot about visual scripting lately — manipulating the display of objects over time, mostly through CSS & Javascript. I know the Actionscripters of the world have been at this for ages, and us JS guys are just coming in blindly to an advanced art, but that’s why I’d like to gather some intelligence. I’m looking for more information about patterns.

Let’s talk about organization. I just recently launched a massively visually scripted site. Over 7,000 lines of CSS, 1500 lines of javascript (not including libraries). The issue is that I didn’t have a clear organization structure for visual scripting. I mean, sure, the site is very well organized by any standard I’ve read or written about. All the CSS files are split up by sections and commented throughout. Javascript functions are split into core classes, triggers, and widget-based files. It works immensely well for smaller sites, with a couple of core visually scripted areas — but on this site where almost every page has visual scripting of some sort, it starts to fall apart. CSS organization techniques used for 3,000 lines of CSS do not hold up at 7,000 lines of CSS.

So let’s talk about patterns. I’m looking for input, ideas, and samples of good visual scripting patterns. For web apps we’ve got patterns galore. Take a look at the glorious MVC structure of a rails project and everything just feels right. Files never get out of control, methods feel right — it just works. Even when projects start to get huge — the wonderful flow of Models, Controllers, Views, Partials, and Helpers just feel right.

An example

Let’s start off with a real-world example. Let’s take a gallery. Now, let’s scatter-brainily throw the features & aspects of this gallery out there:

• Navigation: The gallery will have a navigation structure that will include animation and multiple-tier categorization. The gallery will interact with the galleries, animating in and out of view when galleries are selected.
• Click handlers for the navigation
• XHR: Each gallery will be loaded via XHR bringing in snippets of HTML.
• Loading graphics for loading galleries
• Parser / Initializer after XHR is recieved
• Connection manager: Make sure only one request is happening at a time
• Default “big thumb” view of the gallery
• View detail of an asset with smaller thumbs and a medium size image of the detailed thumb
• View description (text)
• Download wallpapers (multiple sizes)
• Enlarge to full-size view (aka lightbox)
• Close (& go back to default view)
• Switch between medium sized images withe the smaller thumbs
• Loading graphics while loading switching / loading assets
• Paging of thumbnails on every level
• Animations of each thumbnail from Default view to View detail size
• Animations of paging
• Animations of opening a gallery

Now, we’ve got click handlers, effects, event handlers, and different behavior based on context (i.e. when I click on a thumbnail it acts differently if the gallery is in the default state vs the view detail state). How do we organize this so it’s easy to navigate, modular, and flexible? Keep in mind this is one widget out of half a dozen that might appear on this page.

So let’s start a dialog and figure out how we can come up with some logical coding patterns for visual scripting. I’d love to hear your input. I’ll be giving my input on this subject later on when I have some free time to condense my thoughts.

1. 

   Tobie Langel

   March 9^th | #

   Hi,

   Great post. Funny you bring that subject up, I’ve been dealing with similar issues again quite recently

   While clear design patterns have been established for server-side code, client-side development is still too often thought of as scripting. What worked with a single CSS page clearly doesn’t in the type of situation you describe.

   One of the key – for me – to this issue has been, quite surprisingly, to use a microformats-like approach.

   By using classes to actually describe the data, rather than to think of classes as hooks for your CSS, one of your major separation concern is dealt with.

   So for example, rather than adding a context-menu behavior to all elements whose class name is “context-menu”, you add that behavior to all elements who you know need a context menu. This could be for example, all images with a class of “editable”, along with all divs with a class of “help-section”.

   In a sense, your actually considering your HTML/XHTML for what it is: data.

   Regarding CSS, I’m a strong advocate of “namespacing” it, along with using a reset.css file like the one found in YUI. What I mean by that is to make sure that your CSS rules are always contained within the namespace provided by an id and that you target the element’s you want to style precisely:

   #navigation li.current a { color: #333; }
   

   rather than:

   .current a { color: #333; }
   

   This will save you a lot of trouble down the road.

2. 

   Emil Stenström

   March 10^th | #

   Hi! I tend to think of my sites a component trees when I organize them. Print out a couple of your typical pages on the site and put them site by side. Now start by making a node for each main part of your site. Could be navigation, header, footer, content, your choice. Now if you find differences between two of your pages you just add both the different elements to the tree, but with some kind of OR in between them. You keep adding components until you have a full tree that represents your site.

   Now. To use the tree you simply need to give the path to the node certain code is affecting. In the CSS you write: “#root #navigation ul li a.selected” and you’ll know exactly what your code is affecting (see my article on CSS strucutring). I have not yet tried it with javascript but I guess you could just use nested closures or a simple comment before your functions that give a path. What’s important is that you base your structuring on the tree.

   Thing is, when you split up your file, you do it by components, or if you want bigger parts, subtrees. For me, it has worked great.

   The component tree is great visual documentation too, making it much easier for the next person to understand what your code is doing…

3. 

   Frans?zca tercüman

   February 26^th | #

   Your comment contains very useful information about all thank you fransızca tercüman

4. 

   Emlak musaviri

   November 25^th | #

   The only thing it doesn’t do is test the code to make sure it isn’t broken! emlak musavirleri emlakci haberleri

Name

Email (will not be published)

Website (optional)