This time we are looking at the Tally-ho CMS project. This is perhaps a more pernicious example of the shortcomings of getters and setters. We're not having to remember rules about changing state here (that's for an upcoming post), but we are exposing the implementation details and thus repeating code and making our application harder to change.

There are many places where ArticleBean is unpacked in the application. Here are just two examples.

First, from net.spatula.tally_ho.ui.article.ArticleHome we have

 
 
        protected void populateItem(ListItem item) {
            ArticleBean article = (ArticleBean)item.getModelObject();
            Fragment headlineFragment = new Fragment(fragmentName, "headlineFrag");
            BookmarkablePageLink articleLink = new BookmarkablePageLink("articleLink", ArticleRead.class, new PageParameters("0="+String.valueOf(article.getId())));
            articleLink.add(new Label("title", article.getHeadline()));
            headlineFragment.add(articleLink);
            headlineFragment.add(new Label("author", article.getCreator().getUsername()));
            headlineFragment.add(new Label("date", article.getCreateDate()));
            headlineFragment.add(new Label("summary", article.getSummary()));
            item.add(headlineFragment);
 
        }
      }

Note that we yank the state out of the article bean and its fields. And from net.spatula.tally_ho.ui.admin.ApproveArticles we have

 
            @Override
            protected void populateItem(ListItem item) {
                if (!(item.getModelObject() instanceof ArticleBean)) {
                    return;
                }
                final ArticleBean article = (ArticleBean) item.getModelObject();
                item.add(new Label("alias", article.getCreator().getUsername()));
                item.add(new Label("title", article.getHeadline()));
                final ModalWindow articleWindow = new ModalWindow("articleWindow");
                articleWindow.setTitle("Article Display Window");
                articleWindow.setCookieName("articleWindow");
                articleWindow.setCookieName(null);
                articleWindow.setUseInitialHeight(false);
                articleWindow.setResizable(true);
                articleWindow.setCssClassName(ModalWindow.CSS_CLASS_GRAY);
                articleWindow.setContent(new ArticleDisplayPanel(articleWindow.getContentId(), item.getModel(), null));
                item.add(articleWindow);
 

Again, we unpack the ArticleBean and jam its contents into something else. Multiply this by a dozen and you see the problem. Any change to the implementation of ArticleBean and we have to grovel around several code files and make changes to this code. At the very least it violate the DRY principle, at the very worst it puts us into Structured Design territory and the terrifying solutions to the awful problems it considers.

What are our options? This is a system boundary, i.e. we are going from model to UI, so we will have to expose the implementation at some point. Well, we could put this logic in ArticleBean and have it take a parameter to be modified. But that would put UI logic into the model. Not so good.

A better solution here would be a helper object that consolidates all of the logic in one place. Imagine a change to the implementation of ArticleBean (maybe we can stop calling it a bean, eh?), where we go to a variable state mode, i.e. a map of key-value pairs. Now we can change our helper object without having to change our two dozen or so collaborations with the ArticleBean.

OK, tag, your it. Disagree? I want to hear your arguments. Agree and seen similar things? I want to hear about that too.

Related posts:

1. Bean of the Devil: Arguing the Affirmative
2. Bean of the Devil: Why Getters, Setters and Such are Evil
3. Many Varied Components, or… Multi Variable Complexity, or… Mainly Vanilla Coding

For my first trick, I give you JChemPaint.java from the JChemPaint project:

  if (file.getName().toLowerCase().endsWith(".cml"))
  {
    FileUtils.saveModeltoCMLfile(file, getCurrentModel());
  }
  else
  {
    FileUtils.saveModeltoMDLMolfile(file, getCurrentModel());
  }

This little beauty sits inside a Swing Action's actionPerformed() method. Sweet. There's similar logic for loading and renaming files as well. The point is that this logic shouldn't be sitting in the UI layer at all. It should probably reside in FileUtils. If you want to go a touch farther, you could have a working document model that contains the file name, whether the model has been modified without being saved (a "dirty" flag), etc. This would wrap the base model and intercept calls that might necessitate updating the dirty flag.

There are other ways to go here, but I think you can see how the tempting getName() led to introduction of file name extension logic here.

OK, tag, you're it. I look forward to seeing cases where getters and setters are absolutely necessary.

Related posts:

1. Bean of the Devil: Why Getters, Setters and Such are Evil
2. Bean of the Devil: Tally-Ho CMS
3. Ruby Internals: Overriding Object.require() to watch files as they are loaded

How do these pernicious little getters and setters undermine OO? Let me count the ways.

1. Encapsulation: the detailed implementation of an object is hidden from the rest of the system. Yes, yes, 99.99999% of all getters and setters are just fronting a private field and that's bad enough, but this is more about the getters, pulling data out of the object and doing things with it outside the object. They leak out, bit by bit, until you repeat yourself all over the place with slightly different manipulations of the data. Before you know it, you are looking at a siloed procedural applications that spurred the invention of OO in the first place.
2. Polymorphism: one type can substituted for another. If your implementation is out there flapping in the breeze, it's hard to swap types. Even if you do, the application of polymorphism is usually pretty weak. Leaking implementation into the collaborating classes really ties your hands.
3. High Cohesion: responsibilities of an object are strongly related and focused. If you pull information out of objects and deal with it in the collaborating objects, the cohesion is going to be progressively more diffuse.
4. Low Coupling: low dependencies between classes, low impact of changes in a class on other classes and high reuse potential. This is a killer. Again, you have your implementation info spread all over the countryside like in a procedural application. You change the implementation and you are in for a mega refactoring.
5. Information Expert: the responsibility goes to the object with all the relevant information. When you leak data into the collaborating classes, how can you identify the information expert?

There's more, of course, but the worst part is that in a system with getters and setters, the rot gets worse the longer the system is under development. A little enhancement can be done so easily by pulling an integer here, a string there and doing a little dance in a method without arranging the collaboration of necessary classes. You need to refactor and refactor to stem the tide. It is a problem of your own making that costs you time and budget.

So, think twice before you expose everything with getters and setters. I would argue that they be the exception and not the rule. A rare sprinking to season the system boundaries.

Related posts:

1. Bean of the Devil: Arguing the Affirmative
2. Bean of the Devil: Tally-Ho CMS
3. Scriptaculous and Why ‘extends’ is Evil

So we recently had a powwow between all the different parties to talk about MVC and this convergence. With the exception of the insufferable Mac and iPhone developers and their disgustingly mature Cocoa framework, we all agreed it would be nice to have an application level MVC framework for each platform. We also agreed that Swing is a great example of what happens when the vendor doesn't provide such a thing -- spaghetti code that relies on component level MVC and hard wiring at the application level. There are a few MVC frameworks for Swing, such as TikeSwing and Spring Rich Client (soon to be superseded by Spring Desktop), but for every Swing app that has this sort of design, there are hundreds that are just a mess.

Most of us felt that RIA's, including Flash and Flex apps, were suffering from the same framework vacuum. Wouldn't it be nice, we thought, if there was a common framework between all of these platforms, that brought application level MVC to the party? Sasha, our Flex lead, mentioned PureMVC, a "simple" framework that has its origins in ActionScript. It now has ports to Java, GWT, C#, Objective-C, PHP, Python and JavaScript. We'll be evaluating this framework over the next few months to see if it is suitable as a general solution for our RIA's and desktop apps.

If any of our readers have experience with PureMVC or any other cross platform MVC frameworks, feel free to comment.

Related posts:

1. Learning PureMVC the Hard Way (is there any other way?)
2. Using Flex Code Generator (FCG) with Flex & PureMVC
3. Flare on PureMVC in Flex example

In fact there's never a good time to break out of MVC, but sometimes you just don't know what sort of Observable your model should be. Will you be using a table, a tree, some custom component? In those situations I try to preserve MVC while punting the hard decision until later. To this end, I've written a little set of utility classes called SimpleModel. How do you use SimpleModel?

Label error = new Label("");
SimpleModel errorModel = new SimpleModel();
 
errorModel.addSimpleModelListener(SimpleModelListener () {
    public void onChange(SimpleModelEvent event) {
        String oldModel = event.getOldModel();
        String newModel = event.getNewModel();
        error.setText(newModel);
    }
});
 
// wire up the GUI here
 
// now change the model
errorModel.setModel("This should show up as an error");

Very simple. No deltas, no change, remove or insert events. But it does get you hooking up your V to your M without clogging up your C. If, at some later point, you decide to move to a Tree, you will need to wire up the MVC a little differently, but at least the separation is already there. No serious refactoring necessary.

Ideally you'd like to have the listener code resident in your view, but for purposes of illustration, I used a simple Label rather than a Composite widget.

My SimpleModel has a special SlicedSimpleModel that uses timers to dispatch each listener separately. That shields against long running listeners.

public class SlicedSimpleModel extends SimpleModel {
    public void fireSimpleModelEvent(final SimpleModelEvent event) {
        if (listeners == null) {
            return;
        }
        for (final SimpleModelListener listener : listeners) {
            Timer t = new Timer() {
 
                public void run() {
                    listener.onChange(event);
                }
            };
            t.schedule(5); // run right away
        }
    }
}

Anyhow, if there is interest, I can add SimpleModel to the jsonwrapper project. But whether you use my utility code or write your own, make sure to wire your GUI's up as MVC even when you're just spitballing.

Related posts:

1. Remove/Cancel Bubbling for an Event in Flex3
2. Adding a Timer Component to Echo2
3. Bean of the Devil: Tally-Ho CMS

In last week's post, I introduced the linked multiselect widget I was asked to implement on a tight deadline for an unexpected project assignment. I showed some demo code in action and discussed the user experience issues that shaped my requirements. This week, I'll walk through the actual code - or at least my first pass at it.

Like a lot of developers who should know better, I sometimes shirk the technical design phase on quick projects, then regret it later. The code I handed off for this project got the job done, but it wasn't very DRY or elegant. Luckily, I've continued to refine it into something I'm not ashamed to blog about. Next week, I'll show off the final, refactored code and try to draw some conclusions about the entire experience. But first - the original, unrefactored code:

The good

Working with new jQuery plugins always makes a project more interesting. I decided now was the time to get started with Dan Webb's Low Pro for jQuery, a library that adds class-based inheritance and other syntactic conveniences to the jQuery object, including an attach method for linking DOM nodes to prepackaged behaviors. The best, most reusable code I wrote for my initial pass at this project was constructed using Low Pro.

One requirement for my project was the creation of a simple color fade effect to signal DOM updates to the user. Using Low Pro, I was able to abstract this single behavior into its own reusable class for deployment within my larger application. The code looks like this:

//a reusable class to add
//a classic Web 2.0 yellow fade
//to DOM elements that have changed
SignalChange = $.klass({
  defaults: {
    //length of the fadeout
    duration: 1250
    //baseline and highlight colors
    , defaultBorderColor: "#ccc"
    , defaultBackgroundColor: "#eee"
    , highlightBorderColor: "#000"
    , highlightBackgroundColor: "#ffa"
  }
  , initialize: function(options) {
    var opts = $.extend({}, this.defaults, options);
    $.extend(this, opts);//just copy over all the options
  }
  , onredraw: function() {
    var that = this;
    this.element
      //cancel previous events of this type
      .stop("onredraw")
      .css({
        backgroundColor: that.highlightBackgroundColor
        , borderColor: that.highlightBorderColor
      })
      .animate({
        backgroundColor: that.defaultBackgroundColor
        , borderColor: that.defaultBorderColor
      }, this.duration)
    ;
  }
});

$('.multiselect .scrollbox').attach(SignalChange);

jQuery pros will notice that the CSS magic in my onredraw method relies on jQuery Color Animations, a tiny little add-on by jQuery creator John Resig that extends the library's core FX mechanism to handle color transformations. In fact, I had to hack the plugin itself, since it handles borderBottomColor, borderLeftColor, borderRightColor and borderTopColor - but not borderColor. Strange, that, but I got over it. I wanted my color fade effect to support borders as well as backgrounds, and it seemed easier to add a single item to an array in the plugin than to handle each section of the border separately in my own behavior.

The syntax of Low Pro's klass method looks pretty similar to Prototype's Class mechanism, which makes sense. The original Low Pro is a library for making Prototype more like jQuery, while Low Pro for jQuery is designed to give Prototype-style support for large, complex and subclassable objects to jQuery.

Notice some of the elegance in Webb's syntax: Any method that conforms to the onwhatever naming convention is assumed to be an event listener - even if it's a custom event such as my own onredraw. Once I've pointed my SignalChange behavior at a DOM node using the attach method, I just need to fire that event to trigger my custom listener. The same is true for native events.

Given the simplicity of my behavior, it could easily have been constructed as a plain old jQuery plugin. But even for such a low-level behavior, Low Pro offers some advantages:

• If Live Query is running, then any calls to Low Pro's attach method are routed through Live Query so they'll be applied to all matching DOM nodes, even those constructed subsequently via DHTML or Ajax.
• I can also subclass my behavior more easily using Low Pro than jQuery's built-in plugin mechanism.

This inheritance becomes all the more important when your behaviors are more complex, with multiple linked event listeners. Because you can just subclass a Low Pro klass, you don't need to overload it with some insane options hash. You can just create a new subclass for each slightly different implementation. I'll take advantage of this mechanism in the refactored code I show off next week.

The not-so-good

In the meantime, I have to take responsibility for the other Low Pro klass I created in this initial version: Subscriptions, which you can view in full in the source code. Before I get into this code's deficiencies, let's look at what it does right:

• It makes great use of jQuery Templates to simplify the construction of DOM nodes. Templates such as the following keep me from having to concatenate strings to create my on-the-fly markup:

    this.tmplMemberView = $.template(
      '<div class="item">' +
        '${name}' +
        ' <span class="info">(' +
        '${groupCount:pluralize(group)})</span>' +
        '</div>'
    )

  I even added some useful helper methods to the template method so I could customize the formatting of my templates:

  //add some additional template helpers
  //for the template plugin;
  //use these to format our markup
  $.extend($.template.helpers, {
    addConditionalClass: function(value, trueClass, falseClass) {
      return value === true ? trueClass : falseClass;
    }
    , addIfTrue: function(value, conditionalText) {
      return value === true ? conditionalText : '';
    }
    , addIfFalse: function(value, conditionalText) {
      return value === false ? conditionalText : '';
    }
    //only works for standard plurals
    , pluralize: function(value, label) {
      return value + " " + label + (value != 1 ? "s" : "");
    }
    , count: function(value, label) {
      var r = value.length || 0;
      if (label) {
        r = $.template.helpers.pluralize.call(this, r, label);
      }
      return r;
    }
  });

• It leverages Live Query to attach permanent behaviors to DOM nodes that get destroyed and recreated many times over the application lifecycle.
• It does a good job of wiring up the complex interactions between two interdependent linked multiselects.

However, my code accomplishes most of these things in a most inelegant way. Looking back, I should have modeled a more complex object hierarchy with some sort of reusable LinkedMultiselect object. My Subscriptions object should have been responsible solely for wiring together two of these LinkedMultiselects and enforcing data dependencies between them.

By starting with one great big all-encompassing class, I ended up having to everything four times: once each for the "selected" and "unselected" states of each of the two linked multiselects. The result is code like this, in which I have to create a single method and then create four more methods to bind it to different circumstances:

, getSubGroup: function(coll, prop, state) {
  return $.grep(coll, function(n) {
    return n[prop] === state;
  });
}
, getSubscribedMembers: function() {
  return this.getSubGroup(this.members, "subscribedNow", true);
}
, getUnsubscribedMembers: function() {
  return this.getSubGroup(this.members, "subscribedNow", false);
}
, getEligibleGroups: function() {
  return this.getSubGroup(this.groups, "eligibleNow", true);
}
, getIneligibleGroups: function() {
  return this.getSubGroup(this.groups, "eligibleNow", false);
}

By now, we've all been exposed to enough proper object-oriented JavaScript to do better than this. I know I certainly have, but I fell into the trap of coding rather than designing first. I look forward to showing you the refactored version next week.

Related posts:

1. Implementing linked multiselects with jQuery, LiveQuery, and Low Pro: Part 1: Requirements and interaction design
2. Writing reusable jQuery modules: Make everything a plugin
3. jQuery 1.3: Plugins continue to migrate to the core

It is one of the first problems of HTML markup that had no standard way to communicate to the user what they should do, I'm talkin' about the required form field. Personally, I have used some sort of asterisk in the past, coloration can work as well, but anything eye catching can distract from an error state (hey, you didn't notice we required that field, try again). So it caught my eye that the good people at reqall have an interesting pattern. In this case, make required fields have a bottom that is different from the non-required fields. This is fairly subtle, it took me a moment to figure out what it meant, but I give them kudos for trying something new. This is a long neglected design pattern of how to handle this in a consistent way, and this is a good a place to start. Its also a way to give a shout out to this service which mashes up text-to-speech, reminder lists, task distribution and has a nifty iphone interface as well, check it out!

How to do it

Here's a capture from their stylesheet, an interesting element here is I didn't know that you could restyle the drawn box of an input, so there is room for much variation. I also like the way they specified 'solid' to get rid of the horrid default 'picture frame' style of merging borders when they don't match, which always makes me flashback to 1998 web design.

input.essential {
border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 3px;
border-left-width: 1px;
border-top-style: solid;
border-right-style: solid;
border-bottom-style: solid;
border-left-style: solid;
border-top-color: #016098;
border-right-color: #016098;
border-bottom-color: #990000;
border-left-color: #016098;
}

Related posts:

1. Design Pattern 1 – faded breadcrumbs
2. .NET Interface does not allow static/const/readonly fields
3. Design Pattern 4 – Inline help

In looking at the elements controlled by another element, the most fitting markup is a definition list. For some reason these elements are mysterious and not too often used. It is a list <dl> that can contain two elements <dt> and <dd>. Normally they have a default display of one element being bigger and the other slightly indented, as to look like a directory. So, with little or no work we can describe the two types of list elements, the 'header' - <dt> and the information that can be 'opened' the <dd>.

So having my markup, well, marked up, I can set aside the HTML, produce some styles for the list, but what about the complicated part? Adding the behavior to hide/show, make the <dt> clickable, swap the GIF's that indicate opening and closing, and while we're at it why not a 'expand all' or 'close all'. Finding it was no mean feat, but with some very creative google searching I found the script - http://www.tjkdesign.com/articles/toggle_elements.asp. So this handles all the heavy lifting, and basically degrades nicely in a non-javascript situation to show all elements. Problem solved.

The satisfying thing about this solution is that the code is clean, and easy to change, and any presentation issues are handled within CSS, along with any behavior in javascript, and handled by the client. I think the two approaches compliment and contrast each other nicely, add your own solutions to the comments if there are even better ones.

Related posts:

1. Design Pattern 3 – not page flips
2. Design Pattern 7: Required fields
3. Design Pattern 1 – faded breadcrumbs

Often designed separately, help in software systems is almost always out of sight of the actual user experience, and thus out of mind. On my projects I make it the habit to make room for, and design with inline help in mind. Inline meaning the help topic is written out on the page next to the area where it will be consumed. I find it keeps people from having to take fingers off the keyboard and mouseover a "?" icon to see if it anything helpful is there hiding. During planning, if the final text is missing, placeholder text is substituted. It helps show the developers that labels alone cannot help users determine how to proceed with completing the task. It also reminds us of what kind of help will be needed eventually in each interaction. I'm surprised at how much reaction it spurns in design meetings and helps clarify confusing procedures amongst other benefits. In short, the pattern is to provide some help where we are looking, rather than make users hunt, or worse, ask for it.

Back to DC, in the Smithsonian, as well as the metro, there are many escalators, and if you pay attention to the voice over, the helpful message is to "stand on the left and walk on the right". Having been plowed into more than a dozen times by people trying to get past me, it finally dawned on me that this is lacking inline help. I took this (blurry) picture in the Smithsonian, which it had two footprints on each side of the tread. The 'help' actually contradicted the rule. With some bad photoshop I erased the footsteps to the version shown here. While reminiscent of some ancient dance chart, I thought if this was the way it was stenciled, that people pick up on the intended behavior because it is where their focus is, not on the announcement, but on their feet.

Related posts:

1. Design Pattern 7: Required fields
2. Design Pattern 5: Can u rd this?
3. Design Pattern 1 – faded breadcrumbs

As it stands, Ajax is still in its infancy (or in its wild west phase -- pick your metaphor), and Bill's simple three part "patterns" are emblematic of this.

Even two years later, Ajax is still in its infancy. At the AjaxWorld Conference East, I had the privilege of sitting next to Douglas 'JSON' Crockford
on the final panel. As my parting wisdom to the assembled masses in the
ballroom of the Roosevelt Hotel in Manhattan, I said that the web had
taken us a step back, from desktop GUI's to the equivalent of the
mainframe green screen, and that Ajax was reintroducing the event
driven GUI concepts to the web. So web developers were going to have to
learn a whole new bag of tricks if they wanted to make full use of the
new technology.

Where to learn this different way of designing
GUI's? The success of the web has sucked the air out of the room for
GUI design books. Most of the books on the subject are either old, not
very good, or both (see "Java GUI Development: The Authoritative
Solution" or any Swing book for a typical example). There are some
books over in the ActionScript/Flash and WinForms departments that do a
better job. Online, most of the relevant projects have also died off
(see this post I did from 2006: MVC and RIA - Learning From Desktop Apps).
Probably the best thing to do is to see which of your current web
developers have experience from a past life developing desktop GUI's.
Maybe I should crack my old Mac GUI programming books (fat chance of
that).

P.S. When we were delivering our parting wisdom, I
quipped that I shouldn't make any predictions because I had originally
argued against the inclusion of the image tag in HTML, but I was
starting to think that I might have been right. Douglas later asked me if I
had removed some of the vowels from IMG in spite, and
that the image tag was really the reason why the web succeeded. It's
good to know that I was able to inspire one of his lesser blog posts.

Technorati Tags: ajax, gui, desktop, event driven, mvc, ria

Related posts:

1. More Articles Needed on How to Design Ajax Apps, not Just How to Program Them
2. AJAX: Only Large Corporations Can Play?
3. Upcoming Talk at RIApalooza: Fast. Smart. Agile. User Experience Driven Agile Development

I was perusing an online catalog, IKEA, and noticed they had dismissed the odd, yet well used idea of a page 'flipping' or 'dog-earing' when you clicked on the corner to advance. As seen in the movie, the advance takes place, shifts the page, then switches it with the next page. Not only does this transition take less time, it effectively communicates in shorthand the idea of 'flipping' without using a direct paper metaphor. Nicely done.

When to use

Pagination seems most useful when transitioning print to screen. Since many magazines and newspapers have abandoned the fidelity to print, and removed the need to screen capture print ready art, this is becoming rarer and rarer. I do think paginating between photos in an album is an experience not well handled in many photo sites web interfaces (I mean you flickr!).

How does it work?

Since this is flash, you can get away with the movement out of the constraining box, which is tougher in HTML, since absolute sizing is not as common, moving and swapping is probably available within a DHTML library, but movement across frames seems to be very flash specific behavior.

Related posts:

1. Design Pattern 1 – faded breadcrumbs
2. Design Pattern 4 – Inline help
3. Design Pattern 5: Can u rd this?

Preface: in my travels around the interwebs I often encounter a neat interaction design that I use my handy Skitch tool to capture. As of now, they sit there until I encounter a project to use them in. To make them more accessible I'm going to post them here, please add comments, since many times I'm not sure how to actually implement these!

Apple's faded breadcrumbs

In (Leopard OS?) search windows, when a list is presented and an item is selected, the path to that item is shown as breadcrumbs in the footer. Because these items can be anywhere, the structure can be very deep, when horizontal room is at a premium, and folder names are long the display truncates the display to a fixed width and fades out the name to white. On mouseover, the title stretches open to show the entire label.

What can it be used for?>

Windows offers the ability to "ellipses" a label that gets too big for it's container. On mouseover, a 'tooltip" window pops up showing the entire label. The fade approach is more elegant, and the animation is actually useful since you don't obscure the other information like popup tooltips do. Websites hopefully have flatter navigation structures nowadays, but horizontal space is always an issue, as it is always finite. Techniques to maximize horizontal space are welcome.

How to do it?

Apple.com is showing this behavior on their footers, go to any page and look at the footer breadcrumbs, click on one and you get the animation effect. However, the fade is not possible in HTML. Also, apple seems to use some 'safari' behavior in their page I don't see in IE 6. Any ideas or libraries? Post below.

Related posts:

1. Design Pattern 6: Definition lists : point/counterpoint
2. Design Pattern 3 – not page flips
3. Design Pattern 4 – Inline help

While I put myself kind of in the prototype + scriptaculous crowd, the battle between these libraries makes it hard since you can only include one of them. Thus someone writes some "perfect for your audience" lightbox effect, but you need to change to jquery to use it. This happened on my own site where some lightboxes needed to play mp3's and others needed to show image slideshows, I had to make compromises and change from page to page, which was extra work, and kind of weird.

No more, thanks to Mr. Jackson, we have a new lightbox (that uses the correct attribute 'rel') that can take advantage or either library, or even mootools or YUI, neato! Look forward to delving into it, check out the download at http://mjijackson.com/shadowbox/ and cheers for choice!

Related posts:

1. My IBM developerWorks series makes it debut
2. jRails: Ruby on Rails with the Prototype guts ripped out
3. JRails: Scriptaculous on top of JQuery

Deitrich's argument is that Duck Typing does not allow "Dead Duck Typing", being able to restrict access to part of an object's state or functionality. The classic case here is keeping a display layer from getting at the persistence layer. (Maybe we can call this Stephen Colbert Typing, since you're declaring part of the object as "dead to me"...)

Dietrich closed his post with:

Some will argue this is a Java-ism creeping into Ruby. I say this is just plain old-fashioned good OO design.

Which I think is my cue.

I understand the theoretical argument for having strict (or stricter) access control in a system, and I certainly understand why having small, high cohesion classes is a good thing. My problem is that it's very rare for me to have a practical issue in a system because of loose access control or overly generous interfaces (granted, I've had a good run of working with smart people). On the other side, I commonly find that when I'm writing a program with access control I'd like to do something more flexible with an object, but I can't, because the original writer of the class did not anticipate the usage.

Specifically on the Ruby side, it's actually not hard at all to restrict access to an object. ActiveRecord objects can easily be made read only called before being passed to a view to protect from inadvertent changes.

In the more general case, it's not hard to do something like this, which only allows certain methods of an object to be called:

class ArbitraryProxy

def initialize(object, *methods)
@object = object
@methods = methods
end

def method_missing(method, *args)
if @methods.include? method
return @object.send(method, *args)
end
super
end

end

x = ArbitraryProxy.new("abcd", :size, :gsub)
p x.size
p x.gsub("b", "---")
p x.upcase

This returns:

4
"a---cd"
NoMethodError: undefined method ‘upcase’

The interesting thing is that, by and large, Rails developers don't feel the need to do this. I don't think I've ever seen an authoritative source suggest that it's best practice to make ActiveRecord objects read only before passing them to the view.

There is a Rails plugin called Liquid that enforces the use of proxy objects before being passed to the view. It's not very widely used (in part because creating the proxies is kind of a pain).

I don't see that Ruby and Rails programmers see this issue as a practical problem facing them (it helps that Ruby tends to encourage small classes in other ways). That said, there are clearly cases where you need to be extra careful. Liquid is used as user-facing templating engine for a blog tool, which is clearly a case where you'd want to limit the damage that your template writers can do.

But I see that as the exception, not the rule. Long live the Duck!

Coming Soon: Professional Ruby on Rails -- available in bookstores Mid-Februrary.

Technorati Tags:
ruby, OOAD, Duck Typing

Related posts:

1. Dead Duck Typing and High Cohesion
2. Live Ruby: Testbed, part two
3. Hide, Seek, and Stay Dry, part two: Controllers

Reading the article, I couldn't help but think back to my own experiences with this same sort of issue.  I blogged recently about two related ideas: how interface designers are sometimes guilty of thinking as designers--when they should be thinking as users, and about the mixed bag that is competitive research, which can limit the designers creative thinking by boxing them into predefined solutions.   

Now I see that it's part of a larger problem of expertise and creativity.  The more expertise one exhibits in a particular field, the harder it is to think creatively--to so called think 'outside the box', and the harder it is to imagine not knowing what you do.  The problem affects whole companies, as a certain way of thinking becomes entrenched, and it gets harder for it to adapt to a changing landscape.  The article cites the example of Eveready, the flashlight maker, who's powers-that-be couldn't imagine that their product could be effectively marketed to anyone other than men shopping at hardware stores.

According to Cynthia Barton Rabe, author of “Innovation Killer: How What We Know Limits What We Can Imagine — and What Smart Companies Are Doing About It,” the solution for Eveready, as for any organization bogged down in its own expertise, is an infusion of outside thinking.  Bringing the so called novices--the non expert users--into the discussion at the early stages of design, weather it be product or strategy design, opens the door for new ways of thinking that experts have long been insulated from.

Powered by ScribeFire.

Related posts:

1. Innovation Through “Crowdsourcing”
2. 2 approaches to design…
3. DUX2007 – Ubiquitous Computing

Case in point.  I use Yahoo Finance to track my stock portfolio and stay financially abreast of the day.   I choose Yahoo over the many others out there because I'm used to it.  It has a simple interface and I know where everything is located.  It also has great tools, and it aggregates information from many many other sources in one place, which I find invaluable.  However I just recently noticed that Yahoo Finance is serving some text ads on the site now.  I wouldn't otherwise be too bothered by them, but they've been designed for the express purpose of looking like real (un-sponsored) content.  They're right up there on the right hand side of the page, occupying the top of one column in a three column layout.  The ad titles are just about the same color as the headlines and links on the rest of the site.  And while the other section titles are all orange and bold--designed to give structure to the page and let you know what section your in-- the only way you can tell that your reading ads is from the truly inconspicuous (light-grey on light blue, thin, all caps) 'Advertisement' header.  

This really infuriates me, especially because it's a finance site, and I can't help but notice the content of the ads.  For instance, right now I'm looking at the front page, from left to right I see a snapshot of the Dow's performance today, a headline saying 'Stocks mixed ahead of jobs report' and a couple of blurbs on 'Hottest China Stock' and '16 Hot Dividend Stocks'.  Now I'm sure you can guess which ones are ads.  And yet I can't help but see the ads and incorporate them into my understanding of the days financial news.  They were designed to be scanned, and that's exactly the kind of information I need to be able to filter out when I'm scanning a page like this.

The fact that these ads persist is a clear indication that Yahoo is concerned less about an informed public and more about using its real estate to extract as much equity as possible.

Powered by ScribeFire.

Related posts:

1. Stock ticker entry fields and usability
2. Ajax and Design
3. Facebook Connect

In David Pescovitz’ keynote address on Monday, he mentioned that since the 1980s we’ve seen three waves of technology: PC Computing, communicating, and sensing. We’re now in the fourth wave which is sense making -- how do we make sense of all the data that’s out there. How do we deal with search queries that return hundreds of thousand of lines of results. How do we start to make connections between the data.

One way we deal with sense making is through data visualization -- a concept which is starting to filter out beyond the research labs into the commercial space. Through data visualization, we can take huge sets of information and present them in such a way that it:

• allows us to immediately see how items are related to one another;
• gives us a more immediate way to see patterns;
• becomes a default to try and understand huge amounts of information.

In addition to visualization, Pescovitz touched a bit on how we're using collective filtering to try and make sense of all this data. We turn to social networks we may trust, such as Digg, to take advantage of the filtering layer created by that network’s society. Anything to help us get a head start on parsing the data.

Later on in the conference, Nick Cawthon talked about aesthetics and efficiency in visualization of data. His talk referenced research he had done using different types of data visualization in order to determine what participants thought of the graphic (pretty or ugly) and whether or not it worked (they could complete a task such as finding a file). An interesting outcome was that the higher the user-rated aesthetic, the more reluctant the user was to abandon that particular data visualization. At a basic level, if the interactive graphic was perceived as “pretty”, the user was willing to spend a bit more time trying to learn how to use it.

Fascinating ideas and I know we're just scratching the surface of its potential.

Technorati Tags: Design, Information Architecture, Usability, DUX07

Related posts:

1. Nice List of Data Visualization Tools
2. DUX2007 – Simplicity
3. DUX2007 – Ubiquitous Computing

1. The Christmas Tree Approach - decorate your Web 1.0 app with Ajax widgets and simple backend JSON or XML services. Pro: doesn't require major investment. Con: app still mostly suffers from the Web 1.0 downsides -- postbacks, CRUD, etc.
2. The Refrosting the Cake Approach - transform all of your views from HTML to JSON or XML. Develop a client side GUI that calls your applications controllers and views. Pro: doesn't require full rewrite. Con: control flow moves from server side to client side; won't take full advantage of RIA opportunities, such as direct manipulation or document-centric interfaces; really just a nice face on CRUD.
3. The From Scratch Approach - take the opportunity to rethink your application as something other than the web equivalent of a green screen. Imagine Photoshop or Word as a traditional webapp. Pro: unencumbered by the old system. Con: costly; you may lose your way in reinventing your app.

I think approach #2, Refrosting the Cake, is actually quite appealing. You can make using that dowdy old webapp quite a bit more pleasant with a quick coat of Ajax. There was a really interesting article on this written by Brian Walsh back in July of 2006. It sort of got lost as a pure Tibco GI article, but it has much wider applicability. In it, Brian uses XStream to convert the views of a SpringMVC sample application from HTML to XML. He then uses Tibco GI to build a UI that talks to the controllers and views on the back end.

I used a similar approach to convert a dowdy old application -- mwhois -- to Web 2.0. Instead of Tibco GI, I used GWT. And instead of XML, I used JSON.

The old application looked somewhat homely...

...and suffered from the kludgey flow and heavy postbacks typical of Web 1.0. I proceded to identify the different views and converted them (via mwhois' templates) into JSON.

simple search: domain=agiledev&ext=com

{ "isAvail" : false,  "domain" : "agiledev",  "ext" : "com",  "whoisServer" : "whois.crsnic.net" }

raw record: domain=french&ext=biz&show_raw=1

{ "domain" : "french",  "ext" : "biz",  "raw" : "Domain Name:                                 FRENCH.BIZ\nDomain ID:                                   D2708502-BIZ\nSponsoring Registrar:                        COMMUNI GAL COMMUNICATIONS LTD.\nSponsoring Registrar IANA ID:                418\nDomain Status:                               clientTransferProhibited\nRegistrant ID:                               GC683CO965021\nRegistrant Name:                             jamil akhtar\nRegistrant Address1:                         Regent House\nRegistrant Address2:                         24-25 Nutford Place\nRegistrant City:                             London\nRegistrant Postal Code:                      W1H 5YN\nRegistrant Country:                          Great Britain (UK)\nRegistrant Country Code:                     GB\nRegistrant Phone Number:                     +44.7729391052\nRegistrant Facsimile Number:                 +44.2075693152\nRegistrant Email:                            jamil@cityfinancialcorp.co.uk\nAdministrative Contact ID:                   GC683CO965021\nAdministrative Contact Name:                 jamil akhtar\nAdministrative Contact Address1:             Regent House\nAdministrative Contact Address2:             24-25 Nutford Place\nAdministrative Contact City:                 London\nAdministrative Contact Postal Code:          W1H 5YN\nAdministrative Contact Country:              Great Britain (UK)\nAdministrative Contact Country Code:         GB\nAdministrative Contact Phone Number:         +44.7729391052\nAdministrative Contact Facsimile Number:     +44.2075693152\nAdministrative Contact Email:                jamil@cityfinancialcorp.co.uk\nBilling Contact ID:                          GC683CO965021\nBilling Contact Name:                        jamil akhtar\nBilling Contact Address1:                    Regent House\nBilling Contact Address2:                    24-25 Nutford Place\nBilling Contact City:                        London\nBilling Contact Postal Code:                 W1H 5YN\nBilling Contact Country:                     Great Britain (UK)\nBilling Contact Country Code:                GB\nBilling Contact Phone Number:                +44.7729391052\nBilling Contact Facsimile Number:            +44.2075693152\nBilling Contact Email:                       jamil@cityfinancialcorp.co.uk\nTechnical Contact ID:                        GC683CO965021\nTechnical Contact Name:                      jamil akhtar\nTechnical Contact Address1:                  Regent House\nTechnical Contact Address2:                  24-25 Nutford Place\nTechnical Contact City:                      London\nTechnical Contact Postal Code:               W1H 5YN\nTechnical Contact Country:                   Great Britain (UK)\nTechnical Contact Country Code:              GB\nTechnical Contact Phone Number:              +44.7729391052\nTechnical Contact Facsimile Number:          +44.2075693152\nTechnical Contact Email:                     jamil@cityfinancialcorp.co.uk\nName Server:                                 DNS.INTER.NET.IL\nName Server:                                 NS.COMMUNIGAL.NET\nCreated by Registrar:                        COMMUNI GAL COMMUNICATIONS LTD.\nLast Updated by Registrar:                   COMMUNI GAL COMMUNICATIONS LTD.\nDomain Registration Date:                    Wed Mar 27 00:01:00 GMT 2002\nDomain Expiration Date:                      Wed Mar 26 23:59:59 GMT 2008\nDomain Last Updated Date:                    Mon Mar 12 16:25:34 GMT 2007\n\n>>>> Whois database was last updated on: Sun Oct 14 17:51:14 GMT 2007 <<<<\n\nNeuLevel, Inc., the Registry Operator for .BIZ, has collected this information\nfor the WHOIS database through an ICANN-Accredited Registrar. This information\nis provided to you for informational purposes only and is designed to assist\npersons in determining contents of a domain name registration record in the\nNeuLevel registry database. NeuLevel makes this information available to you\n\"as is\" and does not guarantee its accuracy. By submitting a WHOIS query, you\nagree that you will use this data only for lawful purposes and that, under no\ncircumstances will you use this data: (1) to allow, enable, or otherwise\nsupport the transmission of mass unsolicited, commercial advertising or\nsolicitations via direct mail, electronic mail, or by telephone; (2) in\ncontravention of any applicable data and privacy protection acts; or (3) to\nenable high volume, automated, electronic processes that apply to the registry\n(or its systems). Compilation, repackaging, dissemination, or other use of the\nWHOIS database in its entirety, or of a substantial portion thereof, is not\nallowed without NeuLevel's prior written permission. NeuLevel reserves the\nright to modify or change these conditions at any time without prior or\nsubsequent notification of any kind. By executing this query, in any manner\nwhatsoever, you agree to abide by these terms.\n\nNOTE: FAILURE TO LOCATE A RECORD IN THE WHOIS DATABASE IS NOT INDICATIVE\nOF THE AVAILABILITY OF A DOMAIN NAME.\n" }

global search: domain=agilesoftware&do_global=1

{ "domain" : "agilesoftware",  "avail" : [{ "domain":"agilesoftware","ext":"biz" },{ "domain":"agilesoftware","ext":"be" }],  "unavail" : [{ "domain":"agilesoftware","ext":"com" },{ "domain":"agilesoftware","ext":"net" },{ "domain":"agilesoftware","ext":"org" },{ "domain":"agilesoftware","ext":"co.uk" },{ "domain":"agilesoftware","ext":"info" }] }

wizard search: do_wizard=1&company=pathfinder&keyword1=uxd&keyword2=agile&ext=com

{ "whoisServer" : "whois.crsnic.net",  "avail" : [{ "domain":"pathfinderuxd","ext":"com" },{ "domain":"pathfinder-uxd","ext":"com" },{ "domain":"uxdpathfinder","ext":"com" },{ "domain":"uxd-pathfinder","ext":"com" },{ "domain":"pathfinder-agile","ext":"com" },{ "domain":"agilepathfinder","ext":"com" },{ "domain":"agile-pathfinder","ext":"com" },{ "domain":"uxdagile","ext":"com" },{ "domain":"agileuxd","ext":"com" },{ "domain":"uxd-agile","ext":"com" },{ "domain":"agile-uxd","ext":"com" }],  "unavail" : [{ "domain":"pathfinder","ext":"com" },{ "domain":"pathfinderagile","ext":"com" },{ "domain":"uxd","ext":"com" },{ "domain":"agile","ext":"com" }] }

Then I wrote a simple, tabbed interface using GWT and the MyGWT widgets and slapped the two together.

I'll have more details on the code details in part 2 of this article. For now, you can look at the old and new interfaces.

Technorati Tags: ajax, gwt, mygwt, tibco gi, JSON, XML, web20

Related posts:

1. Application Watch – Domain Lookup with AJAX
2. That Giant Sucking Sound is Ajax Turning Your Site into an Application
3. Grails and JSONP: How Easy is That?

Patino, a respected contributor to the YUI mailing list, makes a strong case for the usefulness of his library on larger, more event-driven webapps. For one thing, it can reduce the overhead of handling IE memory leaks. For another, it can simplify the process of attaching custom JavaScript behaviors to dynamically loaded content. Best of all, it can be used to improve performance of really complex apps.

Of course, such an abstract approach isn't for every developer or every application. Patino is pretty frank about both the pros and cons of his approach for specific situations. Even if the actual technique isn't for you, though, the post is a fantastic primer on the intricacies of DOM events and the publisher/subscriber pattern.

• Read the post
• Check out the library

Related posts:

1. DOM methods, document.write and the art of library design
2. A Useful Resource: Ajax Pattern Wiki
3. Design Pattern 1 – faded breadcrumbs

One of the things I struggle with most as a designer is the urge I have to make things consistent, or symmetrical.  I prefer order over chaos, I'll admit.  I constantly have to catch myself from spending too much physical and mental energy on removing what I see as chaos, and replacing it with structure, consistency, balance and symmetry.  It's not that these aren't worthy goals, but my experience is that sometimes those characteristics aren't the key, or even an important element on a particular interface screen or widget.  In fact, in many instances I have found that what I consider order is quite an undesirable solution, or at least, not what the doctor ordered.  
By instinct I look at my work through a designer’s lens.  It is a macro view.  I see the overall structure of the interface.  I slave over task flows and wireframes, structuring them and fine tuning them so they please my aesthetic and philosophical sensibilities.  I judge them by their adherence to my design rules-symmetry, balance, structure, consistency.  
But for the judges that matter, the users, the interface is simply a tool that they will use to accomplish a task (or set of tasks).  They will judge its success not by any theoretical characteristics, but by how well it allows them to accomplish those tasks.  They won’t look at the blue prints.  They’ll never get a look at the task flows generated in the design process, nor would they have any desire to.  
Internalizing this distinction--the difference between my view, and the user’s view--and embedding it into my design process is one of the challenges I face, and one of the determinants of a successful design.

Powered by ScribeFire.

Related posts:

1. What are Task Flows?
2. User Task Flows Help Developers:
3. Use a Task Flow to Show “How do I ___?”