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

I love our morning stand-up meetings: short, low-stress, and effective. Besides agenda and news, we often share technical topics with the group.

Here’s a quick list of some recent projects we’ve noticed or discussed:

• Rango – a new web application framework in Ruby, influenced by the success of the Python project Django. There’s a nice overview in PDF form.
• Atomic Object’s github account was started, hosting a few of our open-source projects.
• jesus is a web interface to God.
• jaml is an HTML template library for JavaScript, influenced by Haml.
• Lawnchair is a JavaScript client-side document store.

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?

This past year, Atomic Object stepped forward and sponsored the Creston High School robotics team. Comprised of mentors from local industry, parent volunteers, and corporate sponsors, the diverse team works together building not only a robot, but community as well.

The scope of the Creston High robotics team expands far beyond just the construction of the robot. The team consists of four separate sub-teams:

• CAD team, designers & engineers of the robot
  
• Build team, primarily responsible for the construction of the robot
  
• Programming team, who bring the robot to life, so-to-speak
  
• Web design team, maintaining and updating Team 904's web site
  
  

There are even opportunities for writers as the team tracks and publishes their progress and results via their website. This allows students an opportunity to participate where their interests and talents are best suited. Many components of the team do not even necessarily require an interest in robotics: all students need is a passion for their respective discipline.

Team members participate to some degree in all aspects of the design and construction process. This cross-team integration allows students a chance to try something outside of their interests--and sometimes they wind up finding they have a new interest as a result, opening students to possibilities and avenues they might have not otherwise explored.





Grant Gumina, a student who has been involved with the team for the past three years especially enjoys working with the the older, more experienced industry professionals. These professionals serve as mentors to the students, not directing the students, but rather guiding the students. The professionals also provide the students with valuable connections to the industry, and advice garnered from years of real-world experience. In addition to providing their expertise, the professionals assisting with the program can also help to guide career and college decisions based on their own personal experiences.

The team also participates in regional and national competitions, with an admirable 11th place finish in this year's state competition. The 11th place finish secured Team 904 a trip to the national competition in Atlanta, GA. The competitions serve as motivation for the students, as the students compete against other schools. Creston High's final project, adorned with a large Atomic Object sticker, will go on to compete starting with district matches against other local schools, and if successful will go on to statewide and finally nationwide matches. These matches are as intense as any sporting event. Students wear team shirts, and even go so far as to paint their faces and cheer like any zealous sports fan would.



Much of what the Creston High's Robotics Team does fits in with what Atomic Object does. We write custom software for automated machinery, much like the programmers from the robotics team. We also do web development, much like the web design component of the robotics team. Gumina made it a point to say that "Atomic Object's sponsorship is not buying parts for the robot, the money is actually going towards the education of the students." By sponsoring the team, AO is investing in the education and growth of Creston's bright students, and the Grand Rapids community at large.

Rapid Growth TV created a video about Carl Erickson and Atomic Object. Check it out on the Rapid Growth Media site.

http://www.rapidgrowthmedia.com/features/rgtvatomicobject.aspx

Bill Higgins draws an interesting parallel between the ideas of The Uncanny Valley in human-like robot design and user interface design. He makes an argument for why web apps should look and act like web apps and desktop apps should look and act like desktop apps. He even offers interesting thoughts on why Java never took off on the desktop.

“The Uncanny Valley of User Interface Design“

”... we must ensure that we design our applications to remain consistent with the environment in which our software runs. In more concrete terms: a Windows application should look and feel like a Windows application, a Mac application should look and feel like a Mac application, and a web application should look and feel like a web application.”

“So I’d recommend that if you’re considering or actively building Ajax/RIA applications, you should consider the Uncanny Valley of user interface design and recognize that when you build a “desktop in the web browser”-style application, you’re violating users’ unwritten expectations of how a web application should look and behave.”

A short article in Scientific American entitled “Tough Choices: How Making Decisions Tires Your Brain” looks at “executive function.” A growing body of psychological and neurological studies demonstrates that the human mind has a limited amount of decision making juice available each day.

When said juice is used up decision making declines markedly in measurable ways. Given that software development is an all-day exercise in decision making, trade-off resolution, and implementation (all topics discussed in the article), the evidence cited in the article supports the idea of Sustainable Pace (the idea, nay fact, that programmer productivity goes down past about 40-50 hours of work per week).

The human mind is a remarkable device. Nevertheless, it is not without limits. Recently, a growing body of research has focused on a particular mental limitation, which has to do with our ability to use a mental trait known as executive function. When you focus on a specific task for an extended period of time or choose to eat a salad instead of a piece of cake, you are flexing your executive function muscles. Both thought processes require conscious effort-you have to resist the temptation to let your mind wander or to indulge in the sweet dessert. It turns out, however, that use of executive function—a talent we all rely on throughout the day—draws upon a single resource of limited capacity in the brain. When this resource is exhausted by one activity, our mental capacity may be severely hindered in another, seemingly unrelated activity.

So, scientific study is bearing out what good programmers know implicitly and what great programmers incorporate into their lives. Working longer actually leads to poor decisions and negative productivity; working at a sustainable pace optimizes productivity.

Allan Kelly draws some interesting conclusions about Agile software development methods as related to forming business strategy. The impetus for his post was a piece in the MIT Sloan Review entitled “Should you build strategy like you build software?.”

From Allan’s “Make strategy like you make software?”:

...for companies which use a lot of technology software and strategy are increasingly converging. Ultimately your software is your strategy – so much so that I sometimes imagine software code as liquid strategy.

...many of the practices and techniques used in Agile software development can be applied to strategy formation and execution. McFarland focus on techniques such as small iterations, collective ownership, overlapping phases, direction changes (i.e. refactoring), organising around people not tools and abolishing big up front design.

It is not only software development where managers and companies have suffered from the Illusion of Control it occurs in strategy formation and planning. Strategy formation is an emergent process, in the same way that software design is emergent.

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.

The blog post "How Cognitive Science Can Improve Your PowerPoint Presentations" discusses four ways cognitive scientist Stephen M. Kosslyn offers for creating more human brain-compliant PowerPoint presentations. The basic concepts, however, are likely equally helpful in developing user interfaces.

As mentioned in a previous post, we’re talking more and more internally about user interface and user interaction design. Just came across an interesting resource: the User Interface Design Pattern Library.

We’ve been talking quite a bit these days in the office about user interfaces and interaction design. I came across an interesting post on the Architectures of Control | Design with Intent blog by Dan Lockton, a PhD researcher at Brunel University’s School of Engineering & Design.

In his post Interesting Parallels, Dan draws on unique definitions of interaction design and security (namely, that both are related to shaping human behavior) to tie the two together. He quotes a computer security specialist and interaction design expert to draw the parallel:

“Security is about preventing adverse consequences from the intentional and unwarranted actions of others. What this definition basically means is that we want people to behave in a certain way… and security is a way of ensuring that they do so.”

Bruce Schneier, Beyond Fear

“A simpler way of thinking about Interaction Designers is that they are the shapers of behavior. Interaction Designers… all attempt to understand and shape human behavior. This is the purpose of the profession: to change the way people behave.”

Jon Kolko, Thoughts on Interaction Design

It’s a rare software project that doesn’t require a developer to think about and implement user interfaces or security in some fashion. So it seems immensely useful for a software developer to view himself or herself as a shaper of human behavior, asking questions as a behaviorist to effectively create useful interfaces and secure software.

My friends at Citerus put together a great newsletter. If you don’t mind reading through a little Swedish intro (the content is mostly in English), I’d highly recommend subscribing.

From a recent interview with Jerry Weinberg in their newsletter:

Q: You seem pretty relentless about quality, why is quality so important to you?

A: Because if you don’t care about quality, everything else is trivial. (I call this The First Law of Software Engineering.) You need to ship on a certain date? If you don’t care about quality, you just ship. You need to cut costs? If you don’t care about quality, you just stop when you run out of money. You need to boost morale? If you don’t care about quality, you do whatever your people want. (Oh, wait a minute. What if they want quality, even if you don’t care? You want to destroy a professional software organization. Act as if you don’t care about quality. The professionals will leave, either physically or psychologically.)

So, that’s why quality is so important, not just to me, but to our industry. And, until we start caring, we’re not going to get better. And I know we can get better, because when I’ve worked with clients whose entire business (or people’s lives) depends on quality, they produce quality software. Curiously, it turns out that quality software is cheaper in the end, but if you’re not into long-term thinking, you won’t see that.

We are, after all, Atomic Object…

A gallery of products using radioactive materials.

Because radiation was seen to be new and powerful, at the beginning of the 20th century radioactive material was used in products such as face creams, mineral water and medicine, by equating power with rejuvenation. For similar reasons it was even used in items from spark plugs to condoms.

About a year ago Greg Pattison and I began working together on a new C++ application for a client. It was the first C++ project of any significant size for either of us since becoming enamored with interaction-based testing techniques.

Read the rest of this entry