Archives

There are many lessons I’ve learned as a result of working in a more domain-driven way.  My recent work on the UI front has highlighted a few ideas that are just as applicable to other areas of application development (outside the sphere of, say, modeling a complex domain).  Here are three things I believe developers should always keep in mind when designing or implementing code.

1. Hierarchies require coordination between their roots.
2. Uniqueness adds complexity.
3. Null holds meaning, but it’s meaning will never be consistent.

Like learning how to write a good unit test, these are simple concepts to explain, but each requires patience and experience to understand really well. (a good pairing partner never hurts either!)

Hierarchies Require Coordination Between Their Roots
A graph of objects often needs to interact with another graph of objects, and while it is initially faster to build direct dependencies between members of each group in an ad hoc fashion, in the long run you benefit from controlling access to those members through the root of each group/hierarchy.  I see this as an extension to the principle of encapsulation applied to hierarchies of objects (ala: Law of Demeter). 

Consider the general case of one object acting as an observer of another.  If there are notable side effects in the handling of an event up or down the graph, it makes sense to put the root in control of the event.  Refactoring across the hierarchy become easier, adding additional behavior introduces fewer edge cases (thus reducing the need for more complicated testing), behavior more predictable etc– the only exception (as I see it) would occur when the type of messages being passed around do not affect state at all.  Which brings us to our next point:

Uniqueness adds complexity
Stateless systems are invariably easier to grasp and comprehend than stateful ones.  While stateful systems have a temporal dimension to them which is largely absent in stateless ones, this is not the only source of such complexity.  It is the interaction between two or more stateful systems where we begin to see the huge cost in terms of managing complexity (recall your first experience debugging issues in badly written multi-threaded code to remind yourself of this).

This is why value objects are so important as a concept, and why their use is so prevalent in domain-driven design.  While the identity of a value object is determined by it’s state, it’s state is invariant, so it does not have to be managed the way an object with variable state needs to be managed.  But the use of VO’s in domain-driven design is just one manifestation of the broader concept: always strive to reduce the number of parts in an application which rely on uniqueness (even if this requires a few more parts added to the whole), whether you are writing domain logic, UI behavior, etc.

The Meaning Of Null Is Never Consistent
It is easy to miss this point, as witnessed by how often I see code which uses null as a substitute for "I Don’t Know…", "Shouldn’t Really Happen…", "Just Satisfy The Compiler…" or "This Is A Placeholder".  In reality, null (or nil) is often employed as a mechanism for passing the buck to someone else.  Try as you might to ascribe a single meaning to it for all cases in your API, client code will feel free to redefine this meaning on a case-by-case basis, and its meaning will evolve (or devolve, as the case may be) into code which looks defensive, but behaves unpredictably.  Avoid returning null when possible– strive for clarity instead.  While in other languages (such as Ruby) it is possible to add behavior to the concept of null, thereby making it’s contract with the rest of the code a bit clearer, I’d still choose the alternative, and use something else.

That’s it– three little things that come in handy just about anywhere. My initial intent was to write a line or two for each section, but as you can tell, there is so much to say on each topic, and all of this just scratches the surface.

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.

JQuery 1.2 is upon us and, as usual, there’s already tons of carping discussion in the comments section of Ajaxian. I took a wander through the 1.2 release notes and the source code, and while I’m impressed with many of the new features, I’m a little disappointed with status quo of the Effects object. They’ve updated the queue and dequeue methods and made them public,  but effects queues continue to be maintained separately for each element. This was a real stumbling block for me when I took jQuery for a test drive on a demo project last month. Compared to Script.aculo.us’s global effects queue, jQuery’s element-by-element queues provide far less precise control for combinations of effects on disparate nodes. It’s difficult to coordinate the timing of effects when you want, for instance, to pause the processing of all effects globally in response to an event, then restart some or all of them. The queue and dequeue upgrades are a step in the right direction, but I’d love to see a truly global effects queue that can be sliced and diced into named or element-based sub-queues as appropriate. In the meantime, I’m starting to agree with the widespread belief that jQuery is great for quick, unobtrusive effects but less appropriate for complex, large-scale applications. Am I just missing something? Would this feature be overkill for a library with jQuery’s stated aims? Let me know in the comments.

I just came across the MyGWT widget library, a collection of good looking additions to the basic GWT widgets. From the site:

MyGWT is an open source Java library for the Google Web Toolkit. The library helps developers easily create compelling desktop like AJAX web applications. No messing around with HTML, CSS, or images, all MyGWT widgets look great out the box.

They look reasonable, and for those of us that want to avoid messing with CSS and icons, this is definitely an option. Just plug them in and your tree widgets can look like the ones below.

Beyond pretty widgets, the library includes an AsyncTree (i.e. it will show a spinning wheel and dynamically load the subtree just exposed via user action) and a small number of DHTML effects, such as DnD, fade, etc. The site goes on to say that MyGWT was heavily influenced by Ext JS, the slick Ajax JavaScript framework.

BTW, the link on the home page to the demo application is incorrect. You can find it here. In general, the www.mygwt.net host doesn’t work. Just trim off the "www" and you should be good to go.

Technorati Tags: ajax, gwt, widgets

I’m excited to announce that I’ve heard the call and volunteered to tackle maintenance and stewardship of Really Simple History, Brad Neuberg’s intuitive, lightweight Ajax history library. Brad developed RSH a couple of years ago, drawing inspiration from the Dojo Toolkit folks to deliver a standalone library that provides back-button and bookmarking support for Ajax apps in IE6 and various Gecko-based browsers. Since, then, many additional Ajax frameworks have implemented back-button and bookmark support, some of them drawing on Brad’s work.

Meanwhile, Brad’s been too busy with other projects to upgrade RSH for a variety of new and existing browsers: IE7, Opera, Safari/Mac and Safari/Windows. I asked Brad to let me take care of his baby for several reasons. For one thing, I’ve been an enthusiastic user of the library. For another, I’ve been wanting to get involved on a more formal basis with open-source JavaScript projects. But most of all, I believe RSH remains a great tool for folks who want a solution to the Ajax history issue without the overhead of a larger Ajax framework.

I’m currently working with Brad to migrate RSH to Google Code, get acquainted with the bug base, and start tackling the thorny issues surrounding Ajax history support in the 2007 browser landscape. I look forward to shamelessly pilfering the many fine solutions uncovered by a large community of developers since Brad’s initial work. (Brad was kind enough to point me to this blog post from Bertrand Le Roy, which lays out many of the aforementioned fine solutions and thorny issues.)

In the meantime, I’d love to hear from RSH users about their hopes for the future of the framework. Comments, please, or ping me directly at bdillard (at) pathf.com. Thanks!

My colleague Sholom Sandalow’s post about multi-column layout in CSS 3 drew a lot of comments and remains one of our most popular articles two months after publication. Folks are obviously hungry for discussion about the future of CSS. Yet there’s still a lot of fuzzy logic out there about where we’re headed.

Viewport dimensions still matter

Lots of pixels have been burned in the discussion of changing viewport specs. But most of the people talking about the advent of very large viewports are probably designers with Mac Cinema displays – NOT average users. As market penetration for super-wide resolutions grows, so will market penetration for portable devices with resolutions at or below the old-school 640×480. (And I’m sorry, iPhone designers, but reading a full-width web page on a tiny screen isn’t actually all that easy on my eyes. I’d much rather see media-appropriate layouts than tons of pan-and-zoom.) My point being: Assumptions about your audience’s screen resolution have always been at odds with the idea of the Open Web. They still will as user-agents proliferate and diversify. As CSS evolves, it must continue to offer us tools to make content attractive and readable on a variety of resolutions and devices.

Multi-column text isn’t a panacea

I also just don’t get the excitement over multi-column text in the browser. Again, this goes back to assumptions about the viewport. One commenter uses this page as an example of good multi-column type that mimics the eventual CSS 3 spec. Yet on Firefox/Mac and IE6/PC, it’s ugly, unreadable or both when you resize your browser to less than 500px tall or 1250px wide. How is this good design?

The main disadvantage of single-column text – that it’s hard to read when the columns are too wide – can easily be solved by strong design skills and smart use of existing CSS capabilities. And the main advantage of multi-column text – that it makes more efficient use of space – ignores the fact that a browser is not a piece of newsprint. Ultimately, print-style columns work in some situations and don’t work in others. They are neither a universal solution nor an antidote to bad web design. They are simply an additional tool in our CSS arsenal – one useful mostly in print stylesheets. It’s nice that this basic layout feature is finally coming to CSS, but it’s hardly the most exciting part of the CSS 3 roadmap.

Advanced layout: Finally, something to get excited about

No, my favorite CSS 3 spec is the Advanced Layout Module. (Thanks to my buddy Zack for alerting me to its existence.) This "concept album" exploring advanced layout strategies recently received its first refresh since 2005 (discussion here). For anybody who’s ever struggled with CSS layout, there’s a lot to love in this proposed templating system. Basically, the spec calls for a new type of display that combines the best aspects of table-based and float-based layout but provides far more flexibility than either. Of course, implementation is a far-off dream, and many aspects of the proposal haven’t yet matured. But the Advanced Layout Module proves that the standards bodies are attempting to tackle the big picture of CSS layout rather than the little details.

In the meantime, several frameworks and techniques have emerged to tackle the problem of cross-browser, grid-based layout. Notable examples include the following:

• YUI Grids
• YAML (Yest Another Multicolumn Layout)
• Blueprint CSS
• Switchy McLayout: An Adaptive Layout Technique

I’d be interested to know who’s using these tools, how userful they are, and whether they provide the same advantages as JavaScript/Ajax frameworks – that is, less time spent reinventing the wheel and more time creating great websites and webapps. As always, weigh in on the comments.

Yes, yes, innerHTML is "the debil." Direct DOM manipulation is much to be preferred. It’s faster, smells less, and gives you shiny white teeth. But innerHTML, when combined with XHR, can allow you to scrape data from the existing HTML pages of a site.

var div = document.createElement(div);
// do the XHR thing...
div.innerHTML = response.responseText; // contains the full html of a page
// voila, div now is the Root of an HTML DOM tree that can be traversed for screen scraping

Now remember, don’t hook the div node into the page with appendChild. Yes, it is a hack that makes use of the browser’s built-in parser, but it is a useful hack nonetheless. I have seen only a few mentions of this technique (see the references). Maybe it’s because this seems like such a contrary thing to do. If you are in control of an application or site, you have control of the server and what runs on it, after all. You could just write a quick XML service that can be requested and parsed by an Ajax client, right?

Well, that’s not always possible when integrating widgets with third-party or other closed source packages. A common solution has been to proxy and scrape an application with a combination of XQuery and TagSoup (to fix the ugly, broken HTML, dontcha know), but it is possible to do this purely in the browser. And browsers don’t need TagSoup as they are masters on wrangling broken HTML.

Another use of this technique is for injecting a new user interface on top of web sites and applications via bookmarklets or Greasemonkey. I’ve been tinkering with SuperCraig, a makeover of the Craig’s List interface that makes use of this technique.

There are limits to this technique. For example, scripts are ignored and images are not loaded when the div is not hooked into the document, so a site that depends heavily on Javascript for its content. may withhold it’s secrets from the screen scraper. That sort of site is likely to have HTTP requests that produce XML, however, so it will give up it’s secrets in other ways.

Anyhow, that’s the story on tinkering with bookmarklets and interface injection. I wanted to finish SuperCraig for today, but the grind of work sometimes gets in the way.

References

• Scraping Pages with jQuery
• 101 Ideas for JSONP – Idea #3: Scraping HTML With TagSoup and XQuery

Here’s a way to handle your layouts a little differently in GWT. Let’s go beyond the canned tutorials that feature a single Panel layout and imagine the following structure.  Here we are using a DockPanel as a top-level container, with various other panels embedded inside of it:

It’s easy to imagine the contents of each embedded panel changing as a result of actions taken against widgets in other panels, but for purposes of this post, let’s just consider each sub-panel contains a static label.  For the tabbed panel, we define two tabs.

If you consider the way most tutorials and textbook examples are written, you might describe this layout with code like this:

Looks messy, but functional.  There are accessor methods for each panel here since, realistically, you will need them in order to build on this functionality.  And did I mention ‘messy’?  If you keep looking at pages and pages of code like this you might start to have more than a few misgivings about the choice of using Java to code your JavaScript application.  And this is just layout– picture how all of this looks when you start adding dynamic behavior to your widgets.

Due to the nature of GWT, our options for improvement are limited.  We are forbidden from using reflection to build a more descriptive syntax.  We can not use any Java5+ constructs such as generics either.  So left with our options, what we really need is to find a way to abstract the construction of the layout behind some sort of builder mechanism.  We could grab the bull by the horns and write our own, native widgets.  Or we can subclass the existing UI classes.  Let’s take a first stab at the problem through sub-classing:

Interesting, no?  Here we take a rather unorthodox approach by setting up our layout in the first six lines of code and making heavy use of chained method calls to do it.  To reduce the clutter of accessor methods or local variable declarations for sub-panels, we provide a unique ‘name’ for each section which we use later on to look up the panel to work with it after the layout has been determined (in a real application, we would use the same kind of lookup mechanism as a registry to resolve dependencies as we introduced some dynamic behavior into the application).

I won’t go through all of the subclasses which were required to make this example work, but here is enough code to give you a glimpse into what is going on.  We start with the class which extends GWT’s DockPanel:

As you can see, there’s not much to it.  We defined the constants ‘TOP’, ‘BOTTOM’, etc elsewhere, which I think are better than ‘NORTH’/'SOUTH’.  When we ‘setContentAt’ a given spot in the DockPanel, we return an object (poorly named, perhaps, but you get the idea) which allows deferred binding of the layout until the actual content is passed through to the proper method:

Etcetera.  Clearly we can extract a method here or there to make the code more concise.  It would also be possible to reduce the number of methods on MyContainer by parameterizing the Panel type, but I chose to keep the method names distinct for the sake of clarity.  The last piece of the puzzle involves extending each Panel class we have defined in order to keep track of all instances in a Map.  Here’s our custom VerticalPanel class.  The rest of the sub-classes follow the same footsteps. 

As for the overhead involved in all this sub-classing, the difference in generated Javasript ends up to be fairly minimal.  Whether it’s worth it or not may be a matter of taste, but there are cases where you may wish to sub-class panels in order to define additional behaviors (listeners, etc) associated with specific panel instances, so introducing a layout mechanism such as the one above won’t add much more overhead to the equation.

What I described above is just a start.  There’s room for improvement, but I think you are left with a good base to build on.

Related Services:
Ajax Rich Internet Applications, Java Application Development, Custom Software Development

I’m probably not getting the quote quite right, but supposedly at one point during the C3 payroll project where XP was created, a developer said that it was so easy to make changes to C3 that they could turn it from a payroll system to an airline scheduling system without any strain.

Okay, it’s not much of a story, but the idea resonates with the core of what Agile development means: driving the cost of incremental change so low that you can handle whatever the client or customer throws at you at any point in the process.

Gaining Control

There’s two parts to that statement, of course. The first is that it’s great to be able to easily fix bugs and make changes to the software over time. The second is that it’s even better to be on a project that you feel is under control.

This is the paradox of being Agile. Agile dispenses with many of the artifacts that traditionally symbolize control in a development process — big requirements documents, detailed UML diagrams, long-term Gantt charts, that kind of thing. At the same time, I’ve never felt more in-control of the actual day-to-day work then I do when in the midst of an Agile process. By accepting the inevitability of change in a software project, Agile allows the development team a structure by which the effect of changes can be mitigated.

The Boring Software Manifesto

Several years ago, I coined the phrase The Boring Software Development Process, in response to a former employer where project management really didn’t think anything was happening unless we were trying to solve seven crises simultaneously.

The manifesto goes like this:

• Boring software projects favor tacking exciting problems, and focusing our energy on the most interesting and valuable parts by avoiding wasting time on avoidable problems.

• Boring software projects favor automated test suites over the excitement doing all your testing at the last minute and finding bugs after the project is “done”.

• Boring software projects favor frequently integrating work from the whole team as opposed to the excitement of finding out whether you changes work well with the rest of the team after you have been working on them for six weeks.

• Boring software projects favor always having a working, if incomplete, system over crossing our fingers and guessing whether the newest build would compile.

• Boring software projects favor incremental design rather than spending six months crafting a UML document that is thrown out after one week of development. (I’m not exaggerating on this one, I reviewed a project that happened on)

• Boring software projects favor understanding that requirements change over being “surprised” when late change requests come.

• Boring software projects favor putting working, if incomplete, systems in customer hands early to get feedback as early in the cycle as possible rather than finding misunderstandings after the project is done.

I hope that wasn’t too boring… Next time, something a bit more nuts and bolts.

When designing, I frequently find myself thinking like a designer.  I ask questions that a designer asks.  I attempt to find clever design solutions to issues I have uncovered while wearing my designer’s hat.  I rely on design principles to guide me through the process. 
Yet no matter how much experience I have designing, no matter how great a design I think I might have achieved, there will always be something missing if I don’t at some point stop thinking like a designer and start thinking like a user.
This is because if one is not thinking like a user, then no matter how well he or she thinks he has solved a problem, all design solutions are still just conjecture.  The designer has to step out of his designer shoes, where he has been using principals, and what he thinks is good judgment to solve problems, and simply be a user.  He must ask himself not weather the design works in some abstract sense, but weather he can easily do what he needs to do.  If he can answer that question in the affirmative then by definition the design works.  Of course it helps if one has a user base to test the design with, but that isn’t always an option.  And even when it is, it’s still best to incorporate user feedback as soon and as often as possible in the design process.  When the designer doubles as a user he accomplishes this quickly, frequently and relatively inexpensively.
Sometimes it’s hard to switch modes, so to speak—to go from designer to user on the fly.  For me the key principal is this:  to move into user mode, instead of asking myself questions that begin with ‘Would the user’, I begin questions to myself with ‘Can I’.  It’s also important to move quickly through interactions, and trust your first instinct as a user.  Your first moves (where you move your mouse, where you click) are generally what more typical of what a user would do, since you haven’t had time to consciously decide what to do (therefore using the knowledge you have as the designer).