Recently while working on the SME Toolkit, a project sponsored by the International Finance Corporation (a member of the World Bank Group), I encountered a problem with CDATA sections in XML documents.

CDATA sections are used in markup languages to identify general character data -- data that should only be interpreted as characters, and not as specialized markup or commands. In XML, CDATA sections allow XML markup to be embedded, but not interpreted as part of the XML document itself.

For example, CDATA would allow XHTML to be embedded inside a larger XML document without treating the XHTML as part of the parent document:

*Note: This XML document uses a contrived DTD for the purposes of example - these tags aren't really part of the standard XML schema.

Unfortunately, there seems to be a great deal of confusion about the proper usage of CDATA sections. This is probably because they are not often worked with, and the CDATA markers behave differently than traditional XML tags. CDATA sections are defined as beginning with the following character sequence:<![CDATA[ ...and ending with the first occurrence of the following character sequence: ]]>. Unfortunately, this means that CDATA sections cannot be 'nested' hierarchically like XML tags because any occurrence of the ending CDATA marker will terminate any open CDATA section.

This means that the following XML document is invalid because the first occurrence of "]]>" within the style section of the embedded XHTML document terminates the first CDATA section, leaving half of the embedded XHTML document to be considered as part of the larger XML document.

The preferred solution to this problem is to break-up the CDATA end markers when nesting them in a new XML document by inserting markers to close and re-open a CDATA section. Then, when the combined CDATA sections are interpreted, the original CDATA markers will be restored. This is accomplished by utilizing the following character sequence: ]] ]]> <![CDATA[ >

Essentially, while CDATA sections cannot be nested, it is possible to escape ending CDATA markers to prevent a CDATA section from being prematurely terminated during parsing. In the example above, parsing of the parent or container XML document will combine the two separate, yet adjacent, CDATA sections into a single set of general character data as intended, preserving the embedded CDATA markers. The nature of the embedded data will be preserved without having it mistakenly treated as part of the XML markup.

Further Reading:

• The XML Standard, by the W3C:
  Extensible Markup Language (XML) 1.0 (Fifth Edition) § 2.4 Character Data and Markup
• The Joel on Software Discussion Group, by Joel on Software:
  Nesting CDATA sections

A Shared Vision for Product Design & Ownership

"Real artists ship." - Steve Jobs

As a working software designer there is no more exciting, relieving, and depressing moment than the moment you ship a product you've been working on for months. With each client I work with and each product I work on I invest myself fully. The product becomes “our” product.

If all goes well we've worked together to define features, craft experiences, and empathize with end users. We've settled into a shared vision, vocabulary, and collection of dreams for the product. Together, we've given birth to something new.

Giving that “something new” up for adoption isn't easy. Even if the client was a fully-engaged parent. Especially if the client was a fully-engaged parent. It’s these clients who will take a project and continue to push it forward even after the original designer has moved on.

The Agile development process used at Atomic Object encourages fully-engaged clients who are intimately involved in feature definition, prioritization, and the rest of the design process.

These clients are most often a dream to work with. They care, they're invested, they're informed and can contribute their depth of domain experience. And having been involved in the design process from day one they rightfully feel a sense of ownership in the decisions that have been made. They have been, and will remain, the product owner no matter how much I—as a designer—invest of myself into “our” product.

Features will be added, usability issues will be addressed, and new vision will be discovered. If the product is any good the product will change. This is not surprising and should be encouraged. The disappointing part of this is not that the client takes ownership but that some clients will mistake their intimate involvement in these decisions for design.

After launch it becomes much easier to just add this feature or that page. The shoe-horning doesn't become an issue immediately. But ad hoc features grow like weeds and if left untended can choke a product before it has a chance to succeed. In more extreme cases they can even drive away users that have already chosen the product and begin a much slower, but still dangerous, reverse tide (see Facebook's current privacy woes).

Product owners always have a hand in the design process, and even more explicitly in an Agile team. So, it is important for me, as a product designer, to help them find and begin to use a set of feature management tools that will keep “our” baby alive.

Unlike most traditional print designers, as a software designer I’m setting foundations for a product that will continue to evolve over time. And that evolution is bound to happen at a much faster rate than that experienced by other types of product or identity design. The digital world moves—and moves fast.

These foundations begin with practices that will help product owners nurture sustainable design and avoid the kind of post-design feature creep that can eventually poison the bottom line.

Here are five practices I try to follow as a product designer and teach product owners to take ownership of as they continue to move forward:

1. Ask The Five Whys

   When considering a new feature for your product consider The Five Whys. Question your feature until you’re absolutely sure that it should be added. Remember it’s much harder to remove features than it is to add them.

2. Ask Five More Whys

   If you begin by describing your feature with either of the following phrases, “It’d be cool if ...” or “Users have been asking for ...” consider asking five more whys. Both of these can be easy paths to a diluted vision. While users are important and they often think they know what they want, their vision is most often narrowly defined by what they have experienced in the past. You want your product to be focused on the future.

3. Have an Opinion

   Good product design has an opinion and usually a strong one. Only add the features you can fall in love with—the ones that seem essential to the identity of your product and make you want to get up in the morning to see if they’re finished.

4. Say Sorry

   It can be exceedingly hard to do, but sometimes you have to remove a feature or two. Be very cautions but unafraid to kill features that undermine your product. Sometimes you just have to say, “Sorry.”

5. Avoid The Creep

   There is nothing that can help you keep your product vision alive and well like awareness. Never cut corners or say yes too quickly when considering new features. Continuing to ask yourself and your team the hard questions will be key to staying on point.

Apple introduced closure support with the release of Snow Leopard. Plausible Labs has since created a framework and a drop-in runtime that provides closure support for both MacOS X 10.5 and the iPhone SDK. Closure support is a fundamental and important change to the Objective-C language. Functions are now first-class citizens in the runtime environment; they can be saved, copied, and passed around just like any other object.

That being said, much of the existing API in both MacOS X and the iPhone SDK rely on callbacks, selectors, and delegate patterns to cope with lack of first-class functions. But don’t let that stop you from using closures. It is relatively easy to create small intermediary wrappers that bridge the gap between callbacks and closures.

Read the rest of this entry

Last weekend I had the privilege of attending a UX Agile Retreat at Cooper. The retreat was an informal event where ~33 practitioners from the UX and Agile fields came together to discuss how we can better create effective and successful products. The event schedule was loosely defined and it self organized based on the trending topics. We used a variety of exercises and discussion techniques to voice our experiences, concerns and ideas to help build a vision of a better, collaborative future.

Where We’ve Been

The UX and Agile communities have been flirting with how they could integrate their practices more seamlessly and respectfully. Both groups respected one another yet remained uneasy about having to alter their respective approaches for an integrated vision and process. UX Designers were worried that some of their practices would be minimized or marginalized due to Agilistas’ strong belief of minimal upfront design. Fear existed that quality design would be sacrificed to the almighty iteration once an agile project was underway. Agilistas were worried about designers doing too much work up front without creating functioning software. Developers were ignorant of the UX Design process and the immense value it provides. Individuals, like Jeff Patton and Lane Halley, have been working very hard to increase knowledge and respect between the two groups. Anders Ramsey organized and dedicated himself to making last week’s event happen. He did an outstanding job. The UX and Agile camps are coming together because they recognize and respect each other’s dedication to the craft of creating high quality products.

Where We Are

Most of our discussions during the retreat focused on vision, values and principles instead of outlining a strategy for collaboration. I’m glad the group was able to remain focused at such a high level because good process stems from alignment and a mutually shared vision.

We took a stand that the “Us and Them” mentality is dead and that we have to move forward as “We.” Management and business processes have kept our groups apart in the past due to a focus on efficiency and a misunderstanding of what it takes to create successful digital products. Management often times does not know how to ask us for what they want, nor do they know how to properly manage creative teams. We believe that we can create better products more efficiently by focusing on being effective. We believe that effectiveness is increased by working together closely.

The Future

The new vision is forming. The retreat group is committed to evangelizing and furthering this vision. I left the retreat with strong feelings of alignment, momentum and excitement. We are the makers of amazing, complex things and we are taking a stand on how we’ll bring the dreams of others into the world. We’re building a case for businesses to employ design thinking at all levels, to focus on the satisfaction of their customers and and to let individuals who understand the creative process to manage it for effectiveness.

Why in the world would you want to embed JRuby into your application instead of relying on a regular Ruby or JRuby installation? I can think of three reasons.

Note: this is a sister post to my description of the arguments needed to run JRuby via jruby-complete. Here I discuss the rationale for using JRuby like this.

What’s the upside?

You can bundle your Ruby runtime dependence into the application.

If you don’t know what I’m talking about here then you should probably stop reading right now. An old post by Err the blog summarizes the “vendor everything” principle quite well:

Quickly: fix it! Tell everyone to install the gem locally. Install the gem on your staging server. Carefully install the gem on your production server. Phew. Everyone’s got the same version, right? Right. Well, maybe. (At least the build works.)

I like vendoring the Ruby runtime for several reasons:

1. I don’t want to ask my users to install anything outside of my application. I definitely don’t want to count on the end user having something installed. Depending on end users having a compatible version of Java is frustrating enough, let alone a JRuby installation. Depending on the JRuby installation can be annoying for developers as well. Take culerity as an example. You could spend a bunch of time screwing around with getting your system-wide JRuby installation just right. Or you could embed JRuby directly into culerity and be done with it.
2. I don’t need to worry about version incompatibilities between the various runtimes. Incompatibilities can mean features I depend on are unavailable, subtly different, or outright broken. An interesting example of “subtly different” came up in an application I recently developed. At one point the sort implementation in JRuby changed from a stable sort to an unstable sort. As far as I know, Ruby doesn’t guarantee sort stability one way or another, so the change was ok from a Ruby perspective. Not so much for me. It turns out my application assumed a stable sort. Had I been dependent on the user’s Ruby installation, my application may have been using either the stable or unstable sort implementation, which was a variance it could not tolerate. (I’m glad I had automated integration tests that revealed this problem to me. I eventually concluded that the application’s behavior was fine with either the stable or unstable sort.)
3. Using JarJar and a few tricks means you can distribute your Ruby application as a single jar file.

Your application may need to run in a constrained environment where you can’t install much, but Java is available.

A couple of years ago I started development on a new application for monitoring PeopleSoft services. Installing Ruby on the servers I was deploying to was not an option. Java was already there to support PeopleSoft. Thank goodness JRuby 1.0 had just been released.

Managing one file is easier than managing many files.

Copying around one jar file is easier than copying a directory with hundreds of files in it. Yeah, manipulating a directory isn’t always a pain, but the times where manipulating a big directory is a pain can be a really big pain.

What’s the downside?

Your application gets bigger.

jruby-complete is currently (as of version 1.4.0) sitting at around 11.5 megabytes. Do I care? Nope. This can be annoying but it generally doesn’t bother me. Especially when my application is already measured in tens of megabytes.

Figuring out and typing the correct commands to run your application isn’t trivial.

This part sucks. Running commands through jruby-complete is tedious when you don’t have any help from something like Rake tasks. The JVM boot time sucks as well. For these reasons I don’t recommend using jruby-complete for everything: when running small, one-off scripts, there’s just too much overhead. Thankfully, when I do depend on jruby-complete, I’m already working on an application where I’m using Rake to automate all kinds of things. So running lengthly java commands isn’t a big deal because my Rake support is already there.

Thankfully, this companion post is chock full of tips for alleviating the pain from those nasty commands.

Back in November I got an email from Jiho Han asking a question about Presenter First:

“In Presenter First, is databinding still feasible? I’m speaking about situations where you might have a 3rd party grid control where it is almost unusable without databinding.”

Happily, we have a new sample illustrating the Adapter extension to Presenter First. The application is a simple book inventory manager with a sophisticated editable table widget (JTable and TableModel data bindings) and MVP-triplet-to-triplet coordination between the editor components.

• Read the Java source code
• Run the executable JAR file

Read the rest of this entry

Earlier this year I had the unusual opportunity to work on a project with another developer (I’ll call him Dave – not his real name) in which each of us was free to choose our own method of application development.

This is certainly not an ideal situation. At first I considered following the client’s (Dave’s company) development methods just for consistency, but I ultimately decided to follow TDD for my portions of the project for several reasons:

Read the rest of this entry

Pomegranate Studios, the masterminds behind the international ArtPrize contest, worked closely with Atomic Object to develop an application to let voters use their iPhone to participate in the event.

ArtPrize is a radically open competition where the winner is decided by public voting. Starting on September 23rd, the contest will run for two weeks with the final winner announced on October 8th.



The ArtPrize app allows users to locate artists' installations throughout downtown Grand Rapids, utilizing Google Maps on the iPhone. Once you've registered to vote, you can easily vote for your favorite artists using the app. The app also encourages users to engage with others via Facebook and Twitter, allowing audiences to express their opinions and observations in real-time. Mlive, a statewide Michigan news site, praised the ArtPrize app for its usefulness--particularly for the ability to preview artists' works and locate venues.

Atomic Object is pleased to be a part of something so creative, innovative and beneficial for the community of Grand Rapids.

The ArtPrize app is available the App Store now. Click the button below to see it in iTunes or just search for "artprize" on your iPhone.

About a year ago, we launched our first Twitter application, Uladoo. A collaboration between Dave Christiansen and Atomic Object, Uladoo is designed to "chart your life", allowing users to create a chart for anything they may want to keep track of. Users have charted cookies baked to blog-posts written.

Uladoo was developed keeping in mind the extreme simplicty of Twitter. Users need only to tweet a value to @uladoo to create a new chart. This low barrier, no sign-up setup makes Uladoo inviting, encouraging new users to try out the application without commitment or hassle. Users can create as many charts as they want, and are able to tweet values to any chart simply by referencing the name of the chart in their tweet.



Since its inception as an extremely simple interface, Uladoo has undergone some new features that allow Uladoo'ers to share their charts via Facebook and HTML embedding, while still maintaining the application's original simplicity.

When Uladoo was launched, the idea was not to dictate or direct users how they should use the service. Rather, the developers chose to let users determine how the service should be used. It's interesting to see how users have adopted and utilized Uladoo. Some of the more creative and unique charts on Uladoo are:

• Pages Written , from c_bass, Germany
• Pop Expenses , from ryanfogle, Michigan, USA
• Glasses of Water, from DugaldWilson, North Carolina, USA
• Windows XP Reboots , from catenate, Iran
• Coughs (I'm Sick) , from trentcarlyle, Colorado, USA
• Tweeple Following Me, from sarach, Washington, USA

Anything that can benefit from a simple line graph is perfect for Uladoo. We are excited to see how users continue to find creative ways to make Uladoo valuable to their lives. What will you be charting?

One of the first things visitors to the Atomic Object office may notice is a lack of walls. This has come to be known as the "Atomic Brain Trust"--an open environment that encourages ideas to flow as freely as the coffee that sparks them.

David Christiansen was one such visitor, writing of his visit to the AO office over at TechDarkside. "It's hard to think of what I saw there as an office--it had more in common with a grad school lab than an IT department. I thought it was awesome."

The open office environment has benefited Atomic Object and its clients in a variety of ways.

Problem solving. Much like our stand up meetings, the open office--wherein desks are arranged into groups with everyone facing into the center--promotes spontaneous brain storming. Employees working on radically different projects can share their collective wisdom and past experiences, to the benefit of other employees and ultimately AO's clients as well.



Productivity. The open office environment holds employees accountable to each other for their daily productivity. Everyone can see what you're working on, so it makes it much more difficult to slip in a quick game of Bejeweled or a lengthy email to your favorite aunt.



Community. Rather than sequestering individuals behind walls to limit their interaction, employees are encouraged to interact. Employees all sit facing each other in clusters, which encourages dialogue, while at the same time allowing employees to remain at their desks and continue working while doing so. In a traditional office environment, employees must interrupt their work and leave their cubicles for any interaction.

Warmth. When visitors walk into the Atomic Object office, they are often times greeted by a big friendly dog--one of several you might find around the office on any given day. If no dogs are present, visitors will at least be greeted by actual faces, instead of a wall of generically carpeted cubicles. Right away visitors see developers hard at work, actively engaged in client projects.



There it is in a nutshell. The open environment is social, spontaneous and productive. It's not just Atomic Object that is discovering this phenomenon. Agile enthusiast Elisabeth Hendrickson over at Quality Tree Software, Inc. is in the process of creating an open office environment after visiting Atomic Object and several others, where she quickly realized the benefits of our way of thinking. On Hendrickson's blog "Test Obsessed", she cites Atomic Object, among others, as a source of inspiration for her forthcoming open environment office space, hoping others with find similar inspiration and follow suit. We hope you do too.

Over the last 18 months, Atomic has made significant growth in our product development services. We now kickoff most projects with an initial discovery and design phase. In this phase we grow our understanding of the client's domain and their vision of the software they want to build. We create artifacts like financial models, personas, wireframes, visual mockups, prototypes and release plans. Eventually, we create a backlog of estimated stories that the development team can start implementing in the development phase.

A few developers at Atomic have shifted into a UX role. We've been growing the company's awareness of UX and product development practices. Last Thursday and Friday Atomic held an in-house UX workshop led by Lane Halley and Jeff Patton. The workshop exercises focused on a speculative development opportunity Atomic has been considering.

Thursday morning started by Lane and Jeff asking what we wanted to get out of the the workshop. They built a backlog of objectives for the workshop and included what we wanted to learn.

Once the schedule was set, we started by talking to the project's stakeholders about their general ideas for the project. Lane and Jeff gave a sample stakeholder interview with one of the stakeholders. We were taught some interview techniques and had the opportunity to practice interviewing with partners. We had some interview candidates lined up for the afternoon so we put together an outline of interview questions.

After Thursday's lunch we slimmed down to a smaller group. This group refined and organized the interview outlines. We conducted four interviews as pairs while the rest of the group observed. We had a retrospective after each interview where we compared notes and critiqued the interviewers.

On Friday the whole company came back together and the interviewers shared their notes. The notes were taken on cards. The cards were laid out and grouped together based on observational similarity. We constructed provisional personas (obviously real personas would require more research) from our notes. Each persona had a name, attributes, objectives and values. We broke out into teams and constructed context scenarios for each persona.

After Friday's lunch, Jeff had our product stakeholders define their high level business goals. We discussed what would constitute success. The discussion gave us insight into what kind of metrics the software may need to provide.

Then Jeff asked how we define a user story. This was a rich discussion that gave us insight into how much we have internalized user stories and how the simple definition of a story has changed over time

After our user story discussion, we extracted activities from our context scenarios. Jeff led us through an exercise where we created a story map. We organized our activities and derived stories from the activities. We looked to the project stakeholders for story validation. We then engaged the stakeholders in release planning using the story map. The exercise showed a great way to prioritize high level stories before fully defining the details required of a finer grained story to be entered into a development backlog.

The workshop ended with a retrospective where the entire company asked questions and shared thoughts.

I'm very excited to see Atomic continue to grow in our UX and product development practices. We've stayed at the forefront of agile development and management for some time. While there, we saw that our clients needed help in formalizing what their project was, who it was for and what business value it would provide. That need and our drive for excellence has pushed us forward to better help our clients. We are enjoying the ability to provide the necessary up front services that ensure we are developing successful products.

Web entrepreneurs, at least the ones we’re experienced with helping, have limited budgets. They’re also inherently optimistic people, believe deeply in their idea, and want confidence that their development team will build something that handles the heavy traffic that success will bring. The answer they want to hear is usually something like, “we design scaleability in right from the start”. Our experience tells us there’s a better way.

Read the rest of this entry

For my last Rails project, we went to a completely Ajax interface for everything. This meant that nearly every action on a controller would result in several lines of RJS calls, along with the logic of which partial to render depending on the state of updating or creating an object.

All that logic and RJS stuff was a pain to test in a controller spec, because so much setup is needed every time you call a controller action in a test (authentication, session, etc). Any branching you have in a controller action really becomes a nuisance to test, and when the customer wants to be able to change what happens on the page when a user saves some object, rewriting those tests and the controller are even less fun.

So we came up with the idea of moving all the presentation related logic out of the controller and into helper objects we call announcers. The purpose of an announcer is to make the actual rendering calls, based on state that is passed to it by the controller.

Read the rest of this entry

A software developer by the name of Gustavo Duarte wrote something quite fascinating last month on Reality-Driven Development. Apparently, his writing drew many Slashdot readers to his humble blog.

In his post, Duarte draws from such disparate sources and ideas as physicist Richard Feynman’s thoughts on the Challenger disaster, natural selection, a linux discussion thread, the book Built to Last, and others to make his case for what he calls Reality-Driven Development.

Duarte says that “reality is invited in via experiments” and defines Reality-Driven Development thusly:

A good software development process should optimize experimentation and improve feedback from reality. This is what I mean by reality-driven development. And in software the most important realities are user experience and technical quality, while the primary experiments are working software and code.

He criticizes big up-front design:

And rigid upfront design is a sure way to a crappy code base or engineering disasters. Alistair Cockburn put it best: “With design I can think very fast, but my thinking is full of little holes.”

He also casts Agile development techniques in an interesting light:

There is no specific reality-driven methodology. The Agile principles have a lot in common with these ideas (and certainly influenced them), but the devil is in the details. I prefer to think of software engineering in terms of a toolbox, full of techniques we pick and choose for the right situation. Process tools for optimizing experimentation include iterative development, executable architecture, continuous integration, and unit testing.

It’s difficult to summarize all the juicy tidbits. Reading the entire post is well worth the time.

I recently got an email asking when and where to instantiate MVP triads (and supporting objects) that appear in response to events in the system, but are not to be built at application start time. MDI (multiple document interface) applications are a good illustration of this: when your application starts, you have zero document editors, but as the user opens documents, you will have several editors. Who builds these transient triads?

The Question:

Hi,

... I am writing and application that consists of a Navigation pane which is a TreeView and a pane to display what has been clicked on in the navigator in tab form using a TabControl. I currently have the following triads

NavigatorModel, NavigatorPresenter, NavigatorView TabViewerModel, TabViewerPresenter, TabViewerView Type1Model, Type1Presenter, Type1View Type2Model, Type2Presenter, Type2View

Type1 & Type2 are different types of content that are to be displayed in the TabViewer. I am a bit confused now on where the Type1 & Type2 triads should be instantiated.

... Thanks for your time

Gavin

The Response:

Hi Gavin,

I would probably have a Factory object of some kind composed into the TabViewerModel. It could take some symbolic indicator of which type of thing you need to instantiate and view (Type1 or Type2), and perhaps the fundamental data needed to configure the newly created triad. The Factory then instantiates the requisite model, view, presenter (and any other supporting objects you may need in that little cluster)... then return a tuple containing a reference to both the new Model and View instance.

You need the View instance, obviously, because you’ve got to plug it into the tab view pane, or whatever. You might transfer this from the TabViewerModel through the TabViewerPresenter.

We’ve often needed to retain a reference to the Model in order to communicate with this newly created arm of the application… your needs or design may work differently. In this scenario, the new Model would wither be kept directly by the TabViewerModel, or TabViewerModel might pass it off to some sort of collection manager elsewhere in your system.

We tend to use dependency injection systems like Spring and Spring.NET (DIY for Ruby) to describe our object systems. For the overall system, we have a “main context” that would, in your case, describe the composition of Navigator* and TabViewer*, and also the TypeFactory instance.

Then, we create “sub contexts” to describe Type1 and Type2 MVP triads. The TypeFactory object would use the Spring library to load up a sub context from an XML file dedicated to, say, the Type1 triad.

The Factory approach is probably a better approach than burdening your presenters with the chore of multi-object instantiation and composition. (An alternate approach might be: compose the Factory object into the Presenter…)

One parting tip: Object instantiation, though very small in code, is a serious responsibility for an object to undertake, so don’t feel bad about spending a little extra time and effort to do it right.

Hope this helps! /Dave