Thoughts on…

Java Middleware & Systems Management

86 the Syntax!

leave a comment »

For developers that know multiple programming languages, that can understand Java generics, who’ve play around with ANTLR, that have read about closures, and who generally automate a lot of their day-to-day work through various scripting languages, picking up a new syntax is a piece of cake. But this is *certainly* not the case for everyone.

If a new feature in a software product, for example, is driven through familiar controls such as drop-down menus, checkboxes, and input text fields, then chances are pretty high that they’ll figure out how to use it naturally (or eventually by way of trial and error). However, if you were to provide a text-only interface that required knowing some not-so-obvious syntax, the user has no choice than to turn to the manual, and continually reference it for details, pointers, guidelines, and grammar.

As in most things, “know your audience” comes into play here too. It is absolutely crucial to take into consideration who your user population is when deciding how to provide interfaces for new software functionality. The wrong interface, no matter how great the feature, could render it absolutely useless to some. And, as experience dictates, first impressions tend to stay with those users even in the face of improved controls in newer versions of the product.

Despite having knowledge of all of this, yours truly (due to time constraints in the development cycle) had to introduce a less then ideal interface to interact with what is otherwise a rock-solid and incredibly powerful feature. Prior to the 1.1.0 release of RHQ, the group definition / dynagroups feature could only be manipulated via a raw syntax.

Not only did this make using the feature cumbersome (even for skilled users), but it made for a rather high learning curve. I had an inclination of this as development was commencing. I sort of knew this as QA was underway. And I definitively knew this when it came time to write the end user documentation. Despite having this knowledge, there simply wasn’t enough time in the cycle to provide a better interface.

Well, as expected, we took flak for it through our customer support channels. More than once did people have trouble understanding what a group definition was, and balked at using the feature. Some of these were customers that had read all of the provided documentation, but still didn’t quite understand how to use it properly. It just goes to show you that no matter how great you think a feature is, the interface to that feature is so crucial to it penetrating your user community and becoming a tool that lessens their burden, as opposed to another “system” they have to learn.

Luckily, a solid support team coupled with a rather understanding and forgiving customer base helped to eventually smooth things over. The more and more examples we threw their way, the better they understood what group definitions were trying to accomplish. In fact, two customers eventually liked it so much that they started suggesting improvements for it, so as to make dynagroups even more useful in the future.

So, perhaps we got lucky. Maybe the utility of the feature, in this case, outweighed the annoyance of having to learn its syntax. The feature *was* introduced to automate a large portion of what was once dozens and dozens of hours of manual work. But providing a poor interface just because we can get away with it doesn’t make it right, and it doesn’t give us an excuse to sit on our hands either.

To remedy this, we made providing a newer and better interface for group definitions / dynagroups a priority in the 1.1.0 release of RHQ. As a result, it was shipped with a wizard formally titled the DynaGroup Expression Builder. Now when you create a new group definition (or edit an existing one) you’ll see a little icon at the upper right-hand portion of the input box. Click it. You’ll find it provides all of the familiar controls we should have started with in the first place: drop-down menus, checkboxes, and input text fields. Several non-developers used the interface before it was released, and commented on how much easier it was to understand.

So does this mean, assuming you’ve already gotten used to the raw syntax from pre-1.1.0 versions, that you’ll now need to learn yet another new interface? Nope. We’ve left the old interface there for two reasons: 1) backwards compatibility (for those already familiar with the syntax, as just discussed) and 2) to provide an expert interface. See, we feel that once you use the expression builder enough times, you’re going to learn the syntax naturally by example and, once you know it sufficiently well, you might want a more direct interface instead of being forced to use the wizard every time.

With the newer and better interface firmly in place, there’s no reason NOT to use dynagroups. So try ‘em out, and let us know what you think, either through the customer support portal, a user thread in the forums, a comment on a JIRA, or even (as this author would prefer) a post back to this blog.

* For more information about the Dynagroups feature, please visit the docs.
* RHQ is an extensible, open source management and monitoring infrastructure. For more information see the project site.


Written by josephmarques

October 14, 2008 at 4:39 am

Posted in rhq

Tagged with

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: