Malcolm Davis's Blog

August 2004 Archives

Information architecture

When I was at JavaOne, I met an editor from Brazil that exposed me to a term called Information Architecture. Information architecture is about defining the structure, organization, navigation, labeling and indexing of information.

For the most part, I have focused on user tasks and interaction techniques to help determine the flow of an application. However, modern web-based applications have complicated usage and data patterns. The inclusion of large amounts of data into application usage, has forced us to think in terms of not only task-oriented, but also information-oriented.

We have all experienced horrible information architecture. My most recent horror story is with VisualStudio's help system. At one time, Microsoft's Developer Network (MSDN) was a salvation for developers. Over time the great experience disappeared as the amount of data became overwhelming. With the inclusion of multiple languages into the class help, class definitions split into separate non-connected sections, and the lack of context sensitivity to the IDE, MSDN has become of little use.

JavaDoc demonstrates the use of information architecture with a language. For many years, the JavaDoc was my browser home page. The ability to see packages, the classes associated with a package, and the entire class description, is an important information tool in software development. IDE's have become information rich making it unnecessary to access JavaDoc directly via the browser. Intel-sense now provides a great deal of data at our fingertips, which not only displays a list of possible methods on a class, but the method description and usage examples. Some see the intel-sense feature as an essential feature in learning a new language.

It is difficult to create a user experience that blends both navigational and functional elements. Most literature either focuses on the software interface or the hypertext system. To make matters worse, many developers are unaware of user interface techniques.

Class variable names

In "Code Complete" section 9.4 informal naming conventions, Steve McConnell describes the use of module variable 'm_'. Since reading this in 1994, I have used the 'm_' convention in C programs, then C++. I've seen 'm_' used in MFC, and in coding standards for the commercial software companies.

Even though Sun does not explicitly define class variable declaration in the coding standards, much of Sun's code aligns parameter names to an existing field with the same name. Much of Sun's code uses 'this.' to set member variables.

public void setName(String name) {
    this.name = name;
}

I asked Steve McConnell his opinion about 'm_' versus 'this.'. The following is his response:
...
"In general, I'm not crazy about differentiating parameters from member variables solely through use of "this.". I would rather see unique names for all variables. I think you're inviting problems and making the code harder to figure out if you name everything exactly the same. I'm not wedded to the "m_" prefix specifically, but I'd like to see the member names and parameter names be unique through some technique or other."
...

Some people use the underscore '_' to determine a variable's scope, such as Docman at SourceForge. Hence, the above sample would be:

public void setName(String name) {
    _name = name;
}

I've also know people to use 'p_' for differentiating parameters, as shown to the following sample:

public void setName(String p_name) {
    m_name = p_name;
}

C# has a different twist by providing a 'property' feature: (note the implied 'value')

public string Name {
    get {  return name;  }
    set {  name = value; }
}

Even though the C# 'property' feature looks good on paper, in practice the feature is widely misused.

The software language scene will change a great deal over the next few years with the arrival of meta information, aspect oriented programming, code generation integration, and new programming features like C# properties. However, I think at this point, it is still important to differentiate the scope of variables. Even though it looks Hungarian in nature, the focus of Hungarian notation is to identify the type of a variable, not the scope. The issue with Hungarian is that the classical types did not fall into the Object-Oriented world, and types very often change.

How do you classify yourself?

As a way to distinguish themselves from the crowd, people have adorned themselves with such titles as software engineer or architect. If nothing else, someone with several years of programming experience is classified as a senior developer.

If engineering is viewed as nothing more than applied science, then the title of engineer fits someone with a degree in computer science that writes software for a living.

However in some states, a person must be licensed by the state to have the title of engineer. In my own state of Alabama, a local stereo shop called 'Sound Engineers' had to change their name, when it was discovered that store lacked a licensed engineer on the staff.

The title "engineer" is restricted to different degrees by different states. Texas is about the strictest in the US. Furthermore Texas is the only state that offers a license in software engineering.

The basic concept is as follows: "A person presented as an engineer implies to the general public that the individual has completed a rigorous course of study such as that provided by an ABET accredited engineering curriculum, mentorship under experienced engineers, and continuing education and training. The public should know that the engineer is qualified to assess the scientific and mathematic fundamentals relating to a design, problem, or situation and make a reasoned, engineering judgment as it relates to the public good." - J. Brian Dietz, P.E.

Architects have similar categories of competence, education, and license restrictions.

I have seen people with the title application architects that were nothing more than glorified web developers. The fast and loose use of the term engineer & architect, by both companies and developers alike, has diminished the meaning of the terms.

I trust I can develop software with the best of them. However, until we come together as a software society with strict rules of competence, when asked what I do, I will reply, "I just program".

NetBeans, look & feel comments

Based on comments from my blog NetBeans 3.6, I downloaded and installed the beta of NetBeans 4.0. NetBeans shows major signs of improvement in many categories (performances, memory footprint, app layout, features). Sun's effort will make NetBeans enthusiast happy. However, it also demonstrates a major issue.

Working in multiple environments, dozens of tools, the sense that there is a 'native look & feel' escapes many developers. Possibly because many programmers care more about developing object interfaces than user interfaces.

When I first started development during the O/S 2.0 & Windows 3.0 days, consistent 'look & feel' was a huge issue. It was an important detail that app keys have specific mappings (such as F1 for help), and commonly used functionality was in the same location (such as opening a document). Eventually, even toolbars had the same images, and common dialogs appeared. The mindset is similar to 'coding standards', users shouldn't have to re-tool their head each time they start a new application. Additionally, all that was required by developers was to follow the published guidelines. [Yes, the standards are published. I first read the UI guidelines for O/S 2 development in the late 80's.]

The NetBeans guidelines can be found at http://ui.netbeans.org/docs/nbui_styleguide/style_guide.html

Java Look and Feel can be found at http://java.sun.com/products/jlf/ed2/book/

The promise of native look and feel was promoted by Sun via Swing. "A Java application running on the Mac can have the Mac look and feel, the same one running on Microsoft Windows can use its look and feel, and that same program running on UNIX can use a UNIX look and feel." - James A. Gosling http://java.sun.com/products/jlf/ed2/book/HIG.Foreword.html

Wow! What a concept. However, I haven't seen the promise of "native look and feel" realized through Swing, NetBeans or Sun.

Each major IDE has pros-cons. I'm not disputing that NetBeans contains things that are missing from Eclipse, and NetBeans does several thing better than Eclipse. However, Gosling and friends slammed IBM's SWT during JavaOne fireside chat. SWT does give the 'native look & feel" that the end-user expect, the same end-users for whom I'm developing applications. Sun should provide a great alternative to SWT, and demonstrate that alternative in a product.

netbeans 3.6

I was curious to see how NetBeans IDE had improved since my last review.

I started a new application by going the newbie process of 'File->New->New Wizard'. I noticed my harddrive starting to pound, then the CPU utilization start to rise from RunIde. I continued by selecting a template for my base application, and I choose 'Next'. The target location appeared, however the drive in which I installed NetBeans did not show up. Yes, I had installed NetBeans on something other than my default C drive. I clicked "Cancel" and went back to the File menu and noticed a 'Mount Filesystem'. Ok, what was 'Mount Filesystem' doing in an IDE running on Windows?

In NetBeans feature comparison chart contains the wording: "Native MS Windows appearance (not apparent it is a Java app)". NetBeans is apparently not a Windows application either.

Outrageous CPU utilization, goofy user experience with such things as 'Mount Filesystem', no refactoring. Sun can slam Eclipse all it wants, however just like end-users, developers expect a great GUI experience, even if the experience is free.

Note:
GUI problems have plagued Sun for sometime. The original release of IPlanet gave administrators and developers premature baldness. (Fortunately I didn’t have much to lose.)

This work is licensed under a Creative Commons License.