Archives

Anybody who has been to our office knows I am an Android fan. My prediction is that the Android platform will end up with a much, much larger install base than iPhone OS. Originally, I felt this way because you can get a Android phone on every carrier for a lower cost than the iPhone – many of them are now free with a contract. This is good enough, but I have a new insight. The Android OS does a great job of directing your attention to highly important information. As such, its easier for new users to pick up and for busy people to use. How can this be? You should argue that the the Android OS so similar to the iPhone OS. You are right. However, it comes down to usability. The majority of people out there won’t explore their device to find information. They just want the phone to do the work for them. If it doesn’t smack them in the head it might as well not exist. Android has two crucial features that make it a helper more than just a smart phone.

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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.

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.