Topic: Design Patterns

Bean of the Devil: Tally-Ho CMS

beanLast time we came this way we looked at the misuse of a getter in the java.io.File. Not that it was wrong to have a getter in File, just that it led to misuse of that information in a UI control to determine what file encoding needed to be used to store the model.

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.
Continue reading »

Bean of the Devil: Arguing the Affirmative

I've gotten lots of feedback, much of it asking "what's the alternative?" to using beans and getters and setters. I'll make a deal with my skeptical readers. I'll argue the negative, with examples, if they argue the affirmative. In other words, you show me some places where you can't get around using getters and setters and I'll show you all sorts of places for the next few weeks, from real open source projects, where people have screwed the pooch with unnecessary getters and setters.

Continue reading »

Bean of the Devil: Why Getters, Setters and Such are Evil

I felt like I'd already gotten this rant out of my system, but every time I come across the object oriented wreckage that the Java Bean and it's decendents have wrought, I get all heated up. The problem is, simply stated, that the getters and setters that get used for things like system boundaries -- Hibernate for persistence, Spring for dependency injection, Java Beans for UI components -- end up being misused for things that break basic OO principles.

Continue reading »

PureMVC, Spanning the Platform Spectrum?

PureMVCAt Pathfinder we do a fair amount of desktop style development -- iPhone/Cocoa, WebForms, Swing -- and web application development -- Grails, Rails, JSP, ASP.NET, etc., etc.. In the last two years we, like a lot of other software development shops, have experienced a convergence in our efforts. The web is coming to the desktop in the form of Air and the Desktop is coming to the web in the form of RIA's. Now web MVC, which used to be a pretty benign pattern mostly concerned with app flow and validation, is starting to resemble desktop MVC, which has to deal with document-centric models and long lived views and all of the plumbing that requires.

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.
Continue reading »

GWT and the Discipline of MVC

When you're developing a desktop or GWT application you're going to go through a bunch of iterations, tweaking the UI, adding components, etc. Sometimes in all of that work it is very tempting to take a shortcut and update a view directly from a controller (label.setText(model.messsageString)). That way lies madness. Before long you've got your view code strewn across the length and breadth of your application. Change the view or some aspect of the model and you're on a refactoring of biblical proportions.

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?
Continue reading »

Topics: , ,

Implementing linked multiselects with jQuery, LiveQuery, and Low Pro: Part 2: First pass at the actual code

Low Pro for jQuery

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:

Continue reading »

Design Pattern 7: Required fields

Reqall1

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;
}

Topics:

Design Pattern 6: Definition lists : point/counterpoint

I encountered a similar situation to Noel's when developing a site recenty. The design called for, or made reference to, a opening and closing header with details shown or hidden by a click on that header. I approached it in a different way, which may be interesting to compare the two, but leave it out there to debate the merits of each. When solving a problem, I normally begin with the same axiom that was mentioned in an earlier post - What is it? What is it's nature? HTML markup, as you may know doesn't have much in it, a mere 20 or so tags, but with the addition of ID's or classes, you can uniquely identify everything the web has to deliver, which is pretty powerful.

Directory_list
Listcode

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.

Topics:

Design Pattern 4 – Inline help

I just had quite an enjoyable spring break trip with the family to Washington DC. For a town with lots of visitors, it was important to help people manage the different ways to get around, or more importantly get out of the way of the residents. Among many places, within the beautifully designed metro stations, there was often voice over assistance on different helpful topics. While I was surprised at the lack of multi-language support amongst these alerts, there was a particular custom that made me think of a similar pattern in software design, the help system.

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. Steps

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.

Topics:

Two Years of Agile Ajax: Web Killed Off GUI Techniques Just in Time for Ajax to Need them Again

Hourglass
I launched this blog just a little over two years ago, on March 21st, 2006. Appropriately enough, my first post was about User Experience (UXD) and Ajax. The blog has come a long way since then -- we've added another full-time blogger (Brain Dillard), published nearly 700 articles of original Ajax and Agile related content, and covered the major new innovations in Ajax and Web 2.0 -- but in many ways Ajax technology is still struggling with the same issues that I wrote about back then:

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.

Continue reading »

Design Pattern 3 – not page flips

In interaction design it is considered a noble pursuit to find metaphors that take real life interactions and mimic them onto the computer screen. There are some notable successes such as the desktop metaphor, as well as some notable failures, such as the desktop metaphor. It reminds me of a friend who was experiencing trouble with their hard drive (this was a macintosh) so they dragged all their files 'out' of the hard drive onto the desktop and then reformatted the drive. After doing this he understood that the metaphor didn't hold up to this kind of use. As computer users become more savvy, metaphors that exist only in the computer realm are becoming more common and accepted.

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.

Topics:

Design Pattern 1 – faded breadcrumbs

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.

Agnostic lightboxing

The memo may not have gone out yet, but for a year or so now the scourge of popup windows has been erased from the user experience. I know that it has been blocked by browsers for quite a while but UXD designers once and a while need this modal stalwart, the dialog box to get their business done without distractions. Thanks to great coders out there, we have a replacement we call "lightbox" which you experience probably daily as the darkening out of the screen and the overlay of that modal box. Its very quick to implement, easy to code, and with some variations, can hold music, slideshows and other nifty content types. I use it constantly, but it has one drawback, the reliance on either prototype or jquery as a backbone to do it's magic.

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!

Topics:

Save That Duck!

So, while most of you were off celebrating the holidays, Dietrich was off killing a duck, or at least Duck Typing. Personally, I always thought that the goose was the traditional holiday bird.. shows what I know.

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:
, ,

The Curse of Knowledge

You can never know too much about something, right?  Wrong, at least according to a December 30th article in the New York Times.  As we become experts in a particular domain, our ability to innovate diminishes.
"Andrew S. Grove, the co-founder of Intel, put it well in 2005 when he told an interviewer from Fortune, “When everybody knows that something is so, it means that nobody knows nothin’.” In other words, it becomes nearly impossible to look beyond what you know and think outside the box you’ve built around yourself."

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.

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com