Pathfinder Blog
Topic Archive: Design Patterns

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

Brian Dillard, Monday, August 25, 2008 @ 2:54 pm

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 »

Topics: , , ,

agile ajax Agile Ajax

Design Pattern 7: Required fields

Michael Dain, Thursday, May 8, 2008 @ 11:20 am

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:

user experience design User Experience Design

Design Pattern 4 - Inline help

Michael Dain, Monday, April 7, 2008 @ 2:15 pm

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:

user experience design User Experience Design

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

Dietrich Kappe, Thursday, March 27, 2008 @ 5:17 am

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 »

Topics: , , , ,

agile ajax Agile Ajax

Design Pattern 3 - not page flips

Michael Dain, Wednesday, February 20, 2008 @ 11:27 am

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:

user experience design User Experience Design

Design Pattern 1 - faded breadcrumbs

Michael Dain, Tuesday, February 12, 2008 @ 11:48 am

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.

Topics: , ,

user experience design User Experience Design

Agnostic lightboxing

Michael Dain, Friday, January 25, 2008 @ 6:34 pm

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:

user experience design User Experience Design

Save That Duck!

Noel Rappin, Friday, January 4, 2008 @ 4:57 pm

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

Topics: , , ,

agile ajax Agile Ajax

The Curse of Knowledge

Sholom Sandalow, Friday, January 4, 2008 @ 11:38 am

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.

Topics: , , , , ,

user experience design User Experience Design

Design can be Used for Good and Bad

Sholom Sandalow, Thursday, January 3, 2008 @ 4:49 pm

Every so often I'm rudely reminded that much of the information I get comes from a source who's goal is to sell rather than inform.  It is those times that I'm also reminded of the critical role that design plays in supporting the goals of the organization (wether they be to inform or to sell) by shaping user behavior.

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.

Topics: , , , ,

user experience design User Experience Design

DUX2007 - Data Visualization

Alice Toth, Wednesday, November 7, 2007 @ 9:14 pm

Data visualization was touched upon a number of times throughout the DUX07 conference.

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

Topics: , ,

user experience design User Experience Design

Pimp my Webapp: Turning Web 1.0 into Web 2.0, Part 1

Dietrich Kappe, Tuesday, October 16, 2007 @ 12:54 pm

Everyone wants the Web 2.0. But how to get there, especially if you have a dowdy old Web 1.0 application? Will I have to spend the annual GDP of a smallish Central American nation on the rewrite? There are three general approaches that evolved over the last year:

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

Topics: , , , , , ,

agile ajax Agile Ajax

YUI Bubbling Library: a seriously cool design pattern

Brian Dillard, Wednesday, September 19, 2007 @ 5:15 am

Caridy Patino recently posted to the YUI Blog about his event-bubbling library, which uses the subscriber/publisher design pattern to abstract an entire webapp's event binding into its own unobtrusive behavioral layer. Instead of attaching events to individual DOM nodes using addListener, you intercept and process all events near the document root, then use CSS classes or other criteria to match up individual events with the correct handlers. In effect, you end up with a big, global switch statement for handling mouse clicks, mouseovers, keydowns and other events.

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.

Topics: , , ,

agile ajax Agile Ajax

Chaos and Order

Sholom Sandalow, Friday, September 14, 2007 @ 5:30 pm

The process of designing (guis/websites/apps what have you) can be very exciting, and ultimately, when a design goes well and achieves its purpose, it can be highly rewarding.  But it's also a challenge.  Every designer has their own set of struggles that they go through during the design process.

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.

Topics: , ,

user experience design User Experience Design

An Event Apart: Wrap-Up

Brian Dillard, Friday, August 31, 2007 @ 5:30 am

The dust has cleared from An Event Apart Chicago 2007. Now that I've gotten the basic reportage out of the way (here and here), on to the editorial page.

Three things I loved

  • The wide range of topics: Despite increasing specialization in the web-development field, jacks of all trades still dominate our industry. An Event Apart offered sessions by and for designers, information architects, writers and developers alike. The most interesting sessions were often the ones that didn't cover my own specialties. Dan Cederhom and Jason Santa Maria both tackled visual design. There was little overlap between their presentations, yet each offered up practical device for folks who have to wing it with graphical design without much formal training. Similar cross-functional advice dominated the agenda.
  • The skepticism about rules: Presenter after presenter - most especially Liz Danzico - prioritized guidelines over rules, research over dogma, and attention to one's own audience over one-size-fits-all solutions. One thing that usually distinguishes a great developer, or at least a mature one, is the ability to juggle a host of competing concerns without getting lost in the weeds. Accessibility vs. Ajax, beauty vs. usability, power users vs. Great Aunt Tilly - everything is a tradeoff. If there was on overriding message to An Event Apart, it was that we have to think deeply and often about our audience, our business and our objectives and make informed decisions.
  • The focus on end users: It should surprise nobody that the ALA folks are usability nerds, standards geeks and champions of the end user. But it was inspiring to see how the speakers translated that well-worn agenda into series of discrete, actionable tips for everyday developers. As with any complex human endeavor, web development is all about picking your battles. With a potentially limitless number of improvements that could be made to any site or application, it's easy to feel overwhelmed. Most speakers showed how simple steps could provide incremental improvements in usability, accessibility, compatibility and profitability - all without starting over at the ground level.

Three things I didn't love so much

  • The absence of concurrent sessions: Packing all 500 attendees into one room for the same 12 sessions (picture here) allowed ample cross-pollination. I'm an RIA developer, but I got the most out of the design, IA and BI sessions. Nevertheless, I longed for the ability to choose from multiple sessions, split off from my colleagues, and come back together during breaks to compare notes. It's not that any of the sessions were completely worthless. It's just that most were designed for intermediate skill levels in the same core technologies. I really didn't need to spend 15 minutes having xmlHttpRequest and getElementByID explained to me. It would have been great if some content had been pitched to masters as well as journeymen. The only way to make that work is through careful scheduling of multiple concurrent sessions.
  • The dearth of programming content: A List Apart calls itself a site "for people who make websites," but not for people who make webapps. The broad range of topics very rarely extended to the programming realm. Only one session directly tackled JavaScript, and it was at an extremely elementary level. There was nothing on Java, Ruby, Python or .Net, let alone RIAs, widgets, mash-ups, Flex, Silverlight, GWT or JavaScript libraries. I know, I know, plenty of conferences already cater to those crowds. But as a programmer, I felt shortchanged. Again, concurrent sessions could have solved this, but I'm not sure programming - client- or server-side - will ever be on the ALA crowd's agenda.
  • The lack of schmooze time: The schedule included some after-hours social events and a 90-minute lunch break each day, but I talked to lots of attendees who felt like they didn't get enough time to chat with other attendees. Other than a lonely bulletin board - and a social-networking site opened a few weeks ahead of time - there weren't a lot of structured opportunities to connect job-seekers and recruiters or peers from separate companies. Part of the problem was probably the cramped accommodations. When folks had breaks, they were too busy stretching their legs to schmooze. Still, I would have loved to see breakaway sessions aligned by job or industry categories.

Conclusions

For "people who make web sites," An Event Apart was probably a fantastic chance to hear practical advice and smart prognostication from industry leaders. For people who write client-side webapp code, it was a very good round-up of philosophies and techniques that too often get lost amidst the technical details. For pure software engineers, it probably would have been a waste of time and money.

Topics: , , , , , , ,

agile ajax Agile Ajax

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics