Just a Thought...

The Pragmatic Programmer folks have a new book out called Domain-Driven Design Using Naked Objects which caught my attention. The title caught my attention, and I figured the author was using Naked Objects in the same vein as Jamie Oliver as “The Naked Chef” (old series on Food Network). Essentially, the ingredients are used to their full potential, complimenting each other without the heavy use of spice. So I decided to do some research on where this came from. My suspicions were confirmed, and made even more sense when I found the original thesis came from someone at Trinity College, Dublin.

I found the original thesis by Richard Pawson entitled Naked objects where he details the principles behind the concept. The thesis is very readable, as theses go. It is broken up into an introduction, a case study, guiding principles, etc. What I found more interesting was the forward written by the pioneer of the MVC pattern, Trygve Reenskaug. The concept of Naked Objects isn’t exactly new, and it should be lauded for its intent of getting back to the proper intent of object oriented design and programming. Of course, as a technology, and as some of the design constraints of naked objects, the thesis is not without detractors. For example a short paper by Larry Constantine called The Emperor Has No Clothes: Naked Objects Meet the Interface .

The true value in something like Naked Objects is to get you to adjust the way you are thinking. The main concept is to build the complete logic of the system using a finite set of domain objects. The framework is designed to take care of database persistence and user interface. According to the forward in the thesis, the spirit behind MVC is that each view is mapped to only one object, although each object might be mapped to many views. The controller is responsible for mapping the events of the view (inputs, etc.) to the domain model. Essentially the domain model (or model) uses views for output and controllers for input. This is different from the way it was originally described to me and I originally understood the pattern. Pawson argues that the framework can generate the user interface views and controllers automatically. Further advances in the concept also automatically maps the domain model to a relational database using Hibernate .

The software developer side of me likes this concept. It’s less plumbing to worry about. I don’t have to know how to code a user interface. I can get my work done quicker. However, the user interface design side of me loathes the concept because the user interface (admittedly by Pawson) is not easily grasped without training, nor is it particularly accessible. The architect in me is thinking about how I can have my cake and eat it too. Ignoring the problem of database mapping for a moment, the real challenge is in the view/controller (VC) layer. Pawson sites arguments from advocates of Object Oriented User Interface (OOUI) design that there is only one true correct way of representing an object. Yet turns around and presents two: an icon to represent the object and a dialog box to represent the content in the object. In my own project I am working on now, there are at least two representations of every object: the view in a list, and the view of the full content of the object. Nevertheless, there still remains concepts I can leverage.

In some respects Wicket would be an ideal candidate for dynamic generation of VC code. Or at the very least, due to its attempt to treat the view layer in an object oriented manner, some extensions to the application can dynamically generate the controller side. I have some reservations about pursuing that too far at the moment. The real conundrum is in the presentation layer. Managing information and behavior is something that object oriented languages are designed to handle. It is right and good to take advantage of the features of your language to properly model the business domain. However, representing that same information to the user in a way that makes sense to the user is a completely different discipline. I can argue against the principles in OOUI till I’m blue in the face, but that doesn’t solve the fundamental problem.

What we need is a way for the programmers to create the functionally complete object oriented domain model, while your user interface specialists concentrate on their responsibility. While frameworks such as Wicket have tried to address that very problem, it is my personal opinion that they fall a little short. I don’t think the fault lies with Wicket. The fault lies within the current set of W3C standards and differing levels of browser compliance. The W3C is still stuck on a model that prefers static information. If the W3C were to truly pursue a model where the user interface layer is bound to certain objects and the browser makes calls to the server to render these objects we might have a better solution. We’ve already started down this path with AJAX and the myriad of Javascript frameworks to make this work. Needless to say that there is a lot of future work that has to be done in order to truly see a synergy from functionally complete domain models and an object oriented user interfaces.

The goal of such an endeavor should be to allow user interface designers these freedoms:

• Create the representations of the objects as they see fit
• Create the rules of how to select the correct view from the different possibilities.

The controller logic should be built into the browser already, in terms of invoking the domain model (or representations of a remote object).

While I’m on the subject of Naked Objects and domain models, I’d like to make a minor rant on Object/Relational Mapping tools. One of the problems is that ORM tools tend to require accessor and mutator methods (getters and setters) for every field that is going to be persisted to the database. While you are technically encapsulating the internal state of the object, in 99.44% of the cases there is no difference in using the accessor and mutator methods and directly accessing the underlying attributes of the class. In a properly designed object, you only need to expose information via accessors that the user is allowed to see, and you only provide mutator methods for what the user is allowed to change. ORM tools require you to violate those principles if you want to persist the information down to the database. Some ORM tools (ActiveRecord) generates these accessors and mutators dynamically for you. That’s great for convenience, but terrible for a properly designed domain model. For the time being, there really is no alternative unless you write the ORM layer yourself. Not recommended if you can help it.

I’ve been spending a lot of time looking into accessibility for web sites to finally get a grip on what needs to be done. Sadly, it is overlooked by the big guys when it doesn’t really have to be so hard. There are several types of disabilities including:

• Visual (full, partial, or color blindness; Photo-Epileptic Seizure [PES] susceptibility)
• Motor control (full or partial disabilities preventing the use of a mouse)
• Cognitive disorders (dyslexia and the like)
• Auditory (full or partial deafness)

The main issue with accessibility is the lack of knowledge and reasonable resources available to help. In particular, the tools that are needed to support people who have the disabilities are expensive and complicated. There are tools available that everyone can have at their fingertips that will help. Most are Firefox plugins, some require you to use an external site. Below are a few of the resources I’ve found:

• Fangs screen reader emulator
• Color contrast analyzer
• Total validator
• Colorblind Webpage Filter

The folks at WebAIM have several good recommendations. For example, you know those “edit in place” controls on Flickr? You can make them keyboard accessible by applying the attribute “taborder=’0’”. The control will be in the page’s natural tab order. I did a little experimentation and the control supplied by Script.aculo.us can take care of all these things for you. The only issue is that IE 6 won’t put the control in the tab order unless it is in the original markup. Dynamically changing the DOM to put it in won’t put the control in the tab order with that browser.

This is a departure from the film and darkroom printing posts, so apologies and I’ll be back on that later.

I’d like to think I’m a pretty good application designer, although some of the things that I’ve seen on other sites have left me a bit jealous. Face it, I didn’t have a background in web design. I know what I should be able to do, and what it ends up looking like. The problem is familiar to anyone who has designed for the web: IE and non-standard implementations of HTML, JavaScript, CSS, etc. The way it’s supposed to work is you whip open the standards, see what CSS can do for your style, and do it. When you see impressive use of CSS from the CSS Zen Garden you start thinking, why can’t I do that?

I come from an application development background, where we can design our desktop apps with nice grid based layouts and do all kinds of fancy things. From there I went on to web development, and have always been frustrated with my inability to escape using tables for layout. Tables are great for lining things up, but they can cause their own issues when you start incorporating AJAX and other goodies. Then you have to worry about what your client’s browsers can do and what they can’t do. At least I don’t have to worry about Netscape 4 and it’s 30 second lag time to sort out nested tables anymore.

So, I think I’ve solved the worst of my problems. I solved the nonstandard JavaScript implementation problem by using Prototype.js which really made it easy to take care of AJAX support for tags and made some of my complex form handling easier. I was still doing my own JavaScript implementations of type-ahead controls and the like. Then I discovered Scriptaculous which took the pain out of 90% of the more advanced control issues I had.

But what could be done between the presentation hell that Internet Explorer puts me through compared to other browsers on the market? IE positioned things just a bit off, and handled the positioning of divs a little crazy as well. If I was going to both have a nice visual grid layout and use markup the way it was intended, I needed a solution like prototype and scriptaculous to help me out. Enter Blueprint CSS to take away the pain and suffering of using divs to align your content. Now blueprint provides some nice little “plugins” that use CSS to do pretty buttons or decorate links with graphic icons all with pure CSS. The graphic icons degrade gracefully as IE 6 does not support the type of selectors it uses. However, the library included a couple PNGs with transparencies. So what does one do about the fact that IE 6 does not render that nicely? Fix it up with Unit PNG Fix of course.

Now my header looks like this:

    <head>
        <title>My Site</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <link rel="stylesheet" href="css/screen.css" type="text/css" media="screen, projection">
        <link rel="stylesheet" href="css/print.css" type="text/css" media="print">
        <!-- Fix nonstandard IE spacing -->
        <!--[if lt IE 8]><link rel="stylesheet" href="css/ie.css" type="text/css" media="screen, projection"><![endif]-->

        <!-- Site CSS -->
        <link type="text/css" href="css/mysite.css" rel="stylesheet"/>

        <!-- Fix IE6 PNG transparency issues -->
        <!--[if lte IE 6]><script type="text/javascript" src="lib/unitpngfix.js"></script><![endif]-->

        <!-- Prototype.js/Script.aculo.us  -->
        <script type="text/javascript" src="lib/prototype/prototype.js"></script>
        <script type="text/javascript" src="lib/scriptaculous/scriptaculous.js"></script>
    </head>

It seems like a lot, but it makes my life so much easier. I highly recommend Head First Web Design as it covers all these wonderful concepts and more.

Adobe Lightroom is a vast improvement over Photoshop Elements, to which a hundred of you will chime in and say “no duh!” and another hundred of you will chime in and say “wait till you try Aperture!”. The truth is that all the adjustments I need are taken care of in Lightroom and Aperture. I’ll have to wait to try Aperture until I get my own Mac. The family Mac is used all too much for me to have time with it. My wife is doing transcripts, my son is creating and editing music, and my daughter is playing with video and her own canned music. That says something about the utility of the Mac out of the box. Dell, HP, Gateway, Sony, etc. pay attention, the set of software included in a Mac is both fun and useful for a family. Not the load of crap that slows down the PC and gets in the way.

Back to Lightroom. All my complaints about tagging and organizing my photos has been addressed in this piece of software. It’s how things should be. Of course, it does highlight a problem I noticed about my tags—over time some of the supporting players on my son’s team had their jersey numbers change. I shouldn’t have included the numbers in the name tags. The cool thing is that I was able to tag and organize my pictures from a game in about half an hour. Considering I am tagging the pictures with the players that can be seen, that’s better than Flickr. I’m sure that Aperture is equally cool in this regard. I just can’t play with it yet.

It’s important to point out that when you make things that people have to do fun, they are in turn more productive. They also have a certain loyalty to the brand. I thought it was interesting to point out that with the O’Reilly experiment to have their Lightroom columnist try Aperture for a week, and vice versa, that both columnists were loyal to the app that first made managing their pictures fun. They appreciated several features of the application they weren’t used to, but because they work differently they had to relearn how to do the same things they already knew how to do—which is never fun. It’s like a baller fixing their shot. They already know they can shoot, and they continually fall back into their old shot until they have practiced so much that the new shot becomes natural. It’s work and work is not fun. The only thing that will help them pursue the change is that they will become even better. With both Aperture and Lightroom, they suit different styles of working with your pictures. Aperture is very non-linear, and Lightroom is more structured. One avoids forcing a workflow on the user, and the other encourages a workflow.

Structure can help people make sense of their world, but the wrong structure can get in your way more than it supports you. If your discipline is to organize the pictures before you spend any time touching them up, then you will enjoy Lightroom. If you like to make multiple passes and organize on the fly as you touch up the pictures (a much more organic process), then Aperture will better suit you. Lightroom forces you to adapt to its way of thinking before you can enjoy it. Organize, then touch up. I tried organizing, and touching up the pictures one by one and that took too long. I adapted by organizing, selecting the top 10 and then touching them up one by one. It was annoying to have to change modes to change pictures, but it was more productive that way. I prefer a more organic approach. I’ll definitely try out Aperture (which is at a nicer price point anyway) in the near future.

The bottom line is that when the cost per picture is fairly low you will take more pictures. You then have to do something to manage them all. With large format photography, you have a much lower production pace because it takes longer to shoot, costs more per frame, and you usually don’t have to compromise to get a “close enough” picture. You can manage it efficiently with proofs and notes on paper. The whole idea of a program like Aperture and Lightroom is unique due to the demands of digital photography.

Adobe Photoshop Elements provides “visual tagging” to make organizing your photos easier. Once the tags are created, using the tags is pretty cool. The problem is the process of tagging. First, let’s consider the parts they’ve done correctly:

• You can organize, rename, and annotate your tags
• Tags include a photo, which is automatically assigned the first time you use it
• You can have several tags on each picture

Now, what’s wrong with that? Nothing if you can accept the limitations of assigning tags. Yes you can select several photos at once and assign the same tag to all the pictures, which can save some time. But to add each and every tag you have to go through this sequence of events:

1. Right click on the photo in the organizer
2. Navigate to the “Attach Tag” sub-menu
3. Navigate to the tag you want through your tag hierarchy

Now, imagine going through this process after photographing your son’s basketball game. I’d like to be able to give a set of photos to his teammates and the cheerleaders, but to do that I have to tag each picture with who’s in it. Any picture will have between 1 and 5 teammates or up to the whole cheerleader squad (about a dozen girls). The pictures are in the order they were taken throughout the game, so they aren’t neatly grouped based on who is in the pictures (unlike family outings). To top it off, each game has over 100 pictures with some around 200 pictures. Imagine going through your collection and organizing things by tag in this situation. My hierarchy has People->Team->person and People->Cheerleaders->person. The event tags are not a problem, as are the subject tags. It’s the people tags.

So, since complaining without thinking how it could be better is useless, let me describe how things can be better: Flickr Organizer. Using the Flickr Organizer, I can grab any arbitrary selection of pictures with some nice search features to find the ones I want. I can then easily add the same set of tags to all the photos in that collection. That’s right—set of tags. Not one tag at a freakin’ time. I can then clear my working group, and set up a new one. It’s not perfect, but it is much better than what I have to do for Adobe Organizer.

Maybe that was a little too trite. What can we do within the confines of the Adobe Organizer app? The three things I mentioned at the top are good things. They help after the tags are assigned, and offer some advantages over online tagging applications. I just don’t want to navigate a complex menu hierarchy to assign one tag. In fact, I don’t want to navigate a menu hierarchy at all. What should happen then?

• I type a keyboard shortcut (which would be for the right-click menu option “Attach Tags…”
• A small dialog box pops up with key focus on the tag entry text box.
• The entry box has type-ahead so I can select the tag as the list narrows
• I can add as many tags as I want at one time
• When I click “Apply” or some equivalent button, all the tags I selected are applied
• If I create a whole new tag, the dialog will let me add it to a category later. This allows the set of tags to grow naturally, yet still maintain order.

When I have to add 12 tags, this will be a real time saver. It will even save time when I only need to add one. Right clicking and navigating a menu hierarchy requires a lot of mouse movements, and sometimes the menu opens to the right and sometimes the menu opens to the left. Sometimes the mouse goes outside the menu, and I have to start all over again. With a dialog box that allows me to add one or more tags at once, I only have to worry about one thing—and since focus will automatically be on the tag entry box I won’t need to move my mouse at all. After all, tab order will let me get to the button I want which will save me time as well.

Sometimes, all it takes is a subtle shift in your viewpoint to open your eyes to new possibilities. The big problem with many existing programming languages is that they don’t always lend themselves to natural parallelization. Yes, that includes Java, C++, C#, and Ruby. It’s not impossible with those languages, it just doesn’t come for free. The reason it’s a big deal nowadays is that multi-core chips are hear to stay. Architectures like the PS3’s Cell architecture are likely to become the norm. The result is like fitting a round peg into a square hole. It’s not impossible, it just requires a lot of work.

So how do social paradigms work to allow an expressive and powerful language with a natural ability to be parallelized? I’m not fully sure, but it might work for the expressive and powerful part. Think about the concept of tagging. A tag is just metadata, and what that metadata means is up to us to decide. Of course, as soon as I use the word metadata, I’m sure I lose a part of my audience. I know my ears turned off the first time I heard that word. It didn’t mean anything to me, and it was an intangible concept that didn’t hold any value. Until, that is, we introduced the concept of tagging.

Metadata is the adjectives your language uses. It’s how you tell a fast car from a slow car.

So if objects are actors, and methods are verbs, how do I make these adjectives work for me. Who assigns these adjectives, and when can they be assigned? Here’s where the social paradigm comes in. Anybody, the developer, the actors (classes), environment, can assign these adjectives to any other actor or thing in the system. So what does that buy me? The purpose for tags is to find things again. What if we do something special with the tags? If a piece of code tags another piece of code, it’s because it wants to do something with it later. In fact the system can use that same mechanism.

For example, what if the language could tell dynamically whether the flyweight pattern was more applicable for you, and you don’t have to do a thing? If the runtime environment can determine how long it takes to create an instance of an object, it can tag the class as “Fast”, “Slow”, or “Average”. With that information, the environment can determine whether it is worth it to keep creating new instances of the object or switch context with the same memory resident object. Alternatively, it might decide to turn a reference to that object as a Future or asynchronous object. Sure you can send messages to the object, and expect the messages to be answered in the order you need them, but the application doesn’t have to stop in its tracks while you are waiting on an answer from a remote source.

OK, so now that we’ve seen something potentially useful, what about the powerful part. Sure it’s pretty cool to use asynchronous calls without declaring that you want something to be asynchronous, but what about other useful things like being able to perform the same function on all objects that were tagged specially? You know, kind of like telling all the stealth enemies to come out of hiding when they’ve been located? Rules engines work this way. You tell the rules to monitor all the objects with certain facts and do something when they match. Oh, isn’t this Functional Programming? Why, how astute of you. Then shouldn’t we use Scala? Scala requires you to be too explicit, and I can’t see any examples of it actually making life easier or easier to understand.

One of my frustrations with the Java Virtual Machine is its security model. In most cases, it is to inflexible and difficult to be used, so the application just runs unprotected—relying on the underlying operating system to enforce any security constraints. It might work for Unix based machines, but Windows machines are usually not protected as well by default. Also, if the application were run as the super user, you can cause some serious problems. Sometimes you want to be able to set up a sandbox, set some attributes for it, and run things inside of that. Kind of like setting up a virtual world for a set of components, or plugins. You can allow that plugin to access only the things you want it to access, and nothing more. What’s better to decide this than code you already trust? You can set up a separate work directory, and have the plugin use it as if it were the default system work directory (or temp directory). The code that set up the world for the plugin to do its job can decide by how often the code bumps into the security constraints if the plugin is behaving nicely.

The concept of the sandboxed little worlds fit well into the “Groups” concept that is present in the social applications. Everyone that is part of a group has a common goal and function. Of course, the same actors can be a member of several groups, and they all have to obey the rules of the group they are in. It’s the same exact instance, it’s just that the context that it is working in is different.

There’s some more possibilities, but this is enough to chew on for now. Of course, many of these things can be done without the need for a new programming language—it’s just that a new syntax would make it easier to work with and hide the implementation details. The resulting language shouldn’t be strictly object oriented, or functional. It should be designed in a way where the language can optimize at runtime based on the resources being used. It should also be designed in a way where it should be readable, understandable, and predictable.

I’m sure it seems odd for me to question this after I’ve doted on its merits and how easy it is to do. How many people use the bookmark tools like Ma.gnolia.com or del.icio.us? How many people have used something like Flickr, etc? When you think about it, the number of sites like this are surprisingly small. Even though there are a number of users, few are there because of the tagging. It’s because they get some value out of the site that they don’t get somewhere else. Flickr works because of the communities, where you can find groups to shoot the breeze or perfect your craft—whatever you want.

Even now, the only thing I use Ma.gnolia.com for is to manage the list of links on my blog. I don’t participate in the groups or anything like that. Quite frankly, I don’t have enough time to read a whole bunch of blogs or follow links like I used to. Tagging the links are less important in that case. Sometimes I want to find an old link, and I can use the tags to get back to the article I wanted. However, after you’ve applied the knowledge in the article a few times, there’s no real value in keeping it around. Yet, there’s effort required to go back and remove it. Since I only list the most recent X number of links on my blog, that’s usually enough for me.

There are some places where I really think that tagging would be the right solution to find things again. One example would be iTunes, or whatever you use to manage your music. Setting up play lists based on tags is a great feature, so I’ve kind of forced that model on iTunes. Of course, I fear such a feature would go wasted on a great number of people because they don’t really see the value in it. Once you get over a certain number of songs you are managing, you really do need a better way to sort and organize your music than just the artist, genre, album type information.

There are some common elements of tagging software such as all the tags are displayed on the right. Sometimes they are shown in clouds, and sometimes they can be combined to narrow the selection more. However, things can become messy when you have the common left side navigation elements along with right side tag information. What’s the right thing to do? Should you mix the functionality of bookmarking sites and information providers?

Honestly, since bookmarking sites make it relatively easy to integrate with other sites, I think that they should handle the bookmarking features, and what you are doing should work on the content. It can get messy quick. Really quick. Should you allow multiple identical tags on an object from different users? How do you display them? If someone deletes a tag, and it’s just their version that goes away and someone else’s tag is there, what should the app do?

Truth be told, tagging is still the realm of power users. I wish it weren’t, but there’s still a lot to be discovered about how people use tags, and the types of things you can do with them.

For us power users, the benefits of folksonomies are self evident. The metadata we apply to something , whether it is a picture, an article, a movie, or something else assists us in a variety of ways. It can be used to help us find that thing again, or it can help us understand what went into making that thing, or something that only benefits you. Of course, those tags can help other people as well, but that benefit is by coincidence and not necessarily design. However, for people who are completely new to tagging, the benefit is elusive. There is some user education that needs to go on. If a third party creates a cool thing that consumes a set of tags, that is enough to educate the newbies.

The wide disparity of user experience makes it hard to design systems properly. On one hand, there is a distinct education gap that needs to be there for the uninitiated. The folks who just don’t seem to get it aren’t necessarily Luddites (AKA technophobes). Just like anything, nobody is going to do something unless they get benefit out of it. Tags do help with refindability, notations, and integrating separate sites together via mashups.

The issue that social site designers face is balancing ease of use, education, and supporting all the baggage that seems to come with these sites. After all, there is a certain expectation that power users have of a “web 2.0” social site. They expect to be able to use their information across several sites, pulling data in through loose, but well defined interfaces. It’s also near mandatory to provide some way for users to find and talk to each other. All these functions have to be accessed in some way.

The danger in letting the power user define the user interface, is that they want nearly every feature at their fingertips. It’s just a physical impossibility. A screen has only so much real estate, and only a handful of features are necessary right there. Simplicity and negative space go out the window, and you get a crowded interface that will scare away any new users. You really need something that gives normal users the impression that they can use the site. Negative space is reassuring to people. Having only the right tools available at your fingertips also helps. I think that Flickr has done a good job for doing this for people sharing pictures, but borrowing the design wholesale for something completely unrelated probably won’t work so well.

The danger in designing to the lowest common denominator is that you provide an interface that is too restrictive, and becomes painful to do anything cool. You want to give your users the feeling that they can do cool things with your site. That includes the power users and the newbies as well. Too much negative space, and simplisticness don’t provide enough of a clue for what a user can do. Sure they get over the “I suck” stage pretty quickly, but they never reach the “I rock” stage. Worse, if it is too hard to figure out how to do advanced things your users will sink into the “you suck” stage and leave.

As always, the balance is difficult to work out—but not impossible. But to add to the design challenge is the nature of social interaction. When you design a site for social interaction at any level, you have to address a few issues. First, a community that is too small can’t sustain itself. People need to find other people that they can trust to help them improve in some way. Second, if a community gets too big, it will collapse under its own weight. When there are too many people the individual voice gets drowned out and people lose interest when their voice can’t be heard. Sure you might have a couple shining stars, but breaking the barrier to become a star becomes near impossible unless you started in that position when the community was small. It’s the nature of human interactions. When the only currency that you can trade is ego, we need to create a way for that currency to get you as far as possible. Just creating new groups for discussions isn’t the best. It’s hard to break the small community barrier. There needs to be something bigger than personality to generate interest. There has to be a common goal, which is more difficult to achieve than common interests. Sure you may like to see sunsets, but how much can you really talk about them?

Finally, I apologize for taking so long to post. I’ve been very busy with design meetings with my client. There are things we may not see eye to eye on, but we will eventually get to a happy medium where we can both be happy. That’s the longest part of the design process when the customer has their own opinions. At the end of the day we have the same goals, and we both want the users for the system to be happy. We just have different ideas of how to achieve those goals.

How do you handle disputes with design decisions? There’s a few different strategies, including drawn out discussions, giving them rope, or “I am god, hear me roar”. They all have their pros and cons. There are a few facts that can’t be denied:

• Design is a creative process
• One design does not fit all problems
• No matter what you choose, there will always be a better way
• There are drawbacks and risks to every design (submitted by Doug)

So, what about driving consensus with long, drawn out discussions? After all, if two heads are better than one can’t we avoid bad decisions by having everyone agree on a solution? This is what makes design by committee fail flat on its face. In essence, the consensus based design is driven by compromise and making the wrong people happy. The people that need to be happy are the ones using your software (not necessarily the same as the ones paying you to create the software). That’s another challenge that isn’t the same as today’s topic. The people that don’t need to be as happy with the user interface design are the people who write the software. Everyone has their own opinion and their own idea of what’s best, and when you try to please everyone you have a project that looks like Frankenstein’s monster. Worse, it works about as well.

Ok, so many times consensus among opinionated people doesn’t work out. What’s another approach? Well you can give people some rope to hang themselves with (and hence, the name of the article). One of four things will happen: the dissenting opinion will run out of energy trying to prove the point with code, the attempt to try something new will completely fail, one of the alternate solutions will succeed, or you will have more than one correct solution. But the point is you now have something more concrete than windbags throwing their weight around. If the dissenting opinion runs out of steam, or the idea fails, you have some experience pointing to the fact that the proposed alternate solution wasn’t a good idea to begin with. If the alternate solution succeeds, and the main solution fails, you are not stuck. If they both succeed, you can now choose the most elegant of the two and move forward. Of course, at this point you may have to resort to the last option…

We’ve all dealt with the type: “I am the design god, hear me roar!” I’m sure, if we were honest with ourselves, we’ve all been that person. Honestly, there are times where we need this person. A strong person to move the team forward with something . We all know that it’s not the best way because of the third point above, but it may be the best option right now . There’s going to be some dissension at different points, and there does need to be someone who will make the determination. This person should be fair and unbiased, choosing what is best for the project. The danger of the design god personality is that there is always the possibility of only pushing their own preferences, regardless of whether it is right for the project or not.

One of the nice features of Ruby on Rails is the ability to mix in helper classes with your controller. This works seamlessly because of the design of the Ruby language. When you try the same approach in Java it’s just plain impossible. For one thing, Java has no way to mix things in properly. You could have a setter/getter for the helper class, but you run into type issues if you want to do it automatically. Either you have to explicitly cast all helpers when you use them, or you have to rely on Java’s broken generics approach. It’s twofold the problem because the controller needs to access the helper, and the helper also needs to access the controller.

Now, Ruby on Rails uses the same helper class mixed in to the controller as well as into the view. At this stage in the game, I think that’s pretty much a pipe dream. I mean, it’s possible to add the helper class instance to a “helper” request attribute, but JSTL and JSP EL doesn’t allow you to call methods with parameters so it’s kind of a moot point. I’d like to fix these limitations in an Java ActiveView project, but that’s in the future.

Without worrying about all the niceties of the way I would prefer to work, I still need to work within the constructs and design mindset of Java. Sometimes the straitjacket forces you to be creative, but I can’t think of any clean way that will work without hijacking the compiler. That’s not really an option because it creates the need for tools just to work with the framework. It’s highly invasive, and it would make me less likely to use the tool—and I’m the one writing it.

The short term solution is to make all the protected support methods in the controller public. That allows users to pass the controller to the helper class, and the helper can invoke whatever methods it needs. That also means that I need to make the “layout” property have setters and getters. Perhaps a medium term solution would be to create a Request Package that included the request object, session object, response object, and all the helper methods to manipulate them (like “redirectToAction” and “sendMessage”). The controller would either use this object directly, or the same methods would simply delegate to the request package object. That object would then be used for both the helper and the controller. That will allow you to have a series of static methods that consume the request package or the controller directly. It’s up to you how you want to do it.

I haven’t really finished my decision process, but I’m all for any ideas that any of you may want to throw my way.