And They Shall Know Me By My Speling Errors

This may seem like an obvious statement for people who do a lot of GUI work, but I will say this because it simply cannot be said enough. Don't hardcode strings! That falls into the good old "no magic constants rule" (unless that constant is the 32-bit signed int -1258207934). How do you go about it?

• Take all your strings and save them in some file that is not part of your main code. There are several options: you could put them all in a code file full of constant values, you could put them in a properties file, or (my favorite) you could put them in an internationalzied resource bundle.
• Use meaningful names. SC_EN_000854 may be just the same to a compiler as LOGIN_DIALOG_LABEL_USER_NAME, in fact it's shorter and probobly compiles just a millisecond faster. But take my advice: use the human readable form
• Use some consistent strategy to create these names. Ther are at least three things it should include: what part of the application it's in, what particualr GUI element it applies to, and some indication of what it says. The order doesn't matter and you can even use short varients or (for location and type) encoded varients. But be consistent! The previous exampel could just as easily be LB_D_LOGIN_UID if you are coding it as type/location/meaning.

So why are these importiant? You mean I can't say "that's just the way you shold do it?" Ok, ok. There is a point to this blog entry rather than random rules. Why do I consider this importaint? Any guesses? Umm... you there, yea the one waving his hand up and down and shouting out "internationalization," you can sit down and calm down because you're wrong. Yes it is a very nice side effects but I think there are better reasons. You there, on the front row. "Maintainable code?" Well, it is maintanable code, but that's not the only reason we do it. Anyone else? How about you. Yes, the cynical one sitting in the back corner. "Management!" Ok, close enough, I'll take it.

It's not just management; it's tech writers, QA, marketing folks, and even other coders with better grammer and speling skills then you. To be more precice it's everyone else who wants to put their fingers in the GUI that isn't actually writing the GUI code. If you mis-spel a word and the strings are all over the code good luck finding the string. You could just search on the mis-speling and fix all occurances of that one. But in those cases people only catch the problems they can see, so the biggest stinkers may get over looked because they don't come up that often (for error dialogs they may never come up). With a centralized set of string files you can run a spel checker over it, but don't try this with java code bacuse signal to noise goes down. You can even hand it off to someone with linguistic skills who can fix all the bad grammer as well. Oh yea, I almost forgot. It's easier to internationalize as well, but you'll probobly have the other problems sooner if you are in anything but the smallest development teams.

Even though my reasons for this are entierly prgamatic it won't end all the problems. While some people care about colons v.s. hyphens for separator cues others care about what shade of grey the background is. Should it be windows grey, swing grey, or bike shed grey?

Some discussion has been happening recently about programmers and GUI design. One particular thread had to do witht he bifurcation between what I will loosley call Graphics People and Coding People. Two overly broad generalizations I know, but when you are looking at the perspective of creating a UI for an application subtleties like database/build/swing coders and artists/layout/graphic designers. Sometimes it's good and sometimes it's bad. Jon Tirsen had a bit to say about this. What I want to blog about is specilization in the development process.

But first I'm going to start talking about some of the small details about the US Army. The Army has about a bajillion job assignments called MOSes. These range from combat roles like eliete special ops and calvary scout to support roles like MP, cook, and decontamination specialist. But despite all of these specialization all must go through the same basic training even though their advanced training is much different. One of the reasons for this is so you can expect some basic skills out of anyone wearing an army uniform, namly you can give them an M16 rifle and expect them to be able to use it with some basic proficiency. At the same time you aren't going to expect an Army Ranger to beable to act as an advocate at a court-marshal and you woudn't want an MP providing cover fire from an Apache LongBow. But when a defensive line falls and headquarters is under attack you want to be able to hand everyone in sight a rifle and have them defend the camp.

So how does this relate to GUI work? Code types and Graphic Types represent two broad specializations when it comes to making an application. Unfortionatly this can lead to what Jon wrote about where the specializations become a class segregation. Situations like that are definatly bad. However I don't think the world of total equivilence is a good realm to live in. There needs to be some form of specilization if for no other reason then some people are better at some things (through training or talent) than others. The people who know how to make a graphic design look essentialy the same across 4 different browsers probobly aren't the same people who know how to ensure the cache consistency of the data behind the page and how to prevent double posting of forms.

This generalization is a two edged sword however, you may need the graphics people and the data people to do stuff others specialize in occationally. Perhaps they are on vacation and a new icon needs to be made, or an HTML page needs to be re-done for new data. A coder type could do it if needed but given the choice a graphics type would be better. Perhaps a field on a form needs to accept a phone number with dashes in it but strip it to just numbers for the database before submission. A coder type may be perfect for that but perhaps he has some nasty synchronization bug he's dealing with so the graphics person has to do some text processing and data tricks.

More and more projects now a days are much to big for one person to possibly do everything even if time wasn't a factor. That's why we work in teams. Nearly all teams have specilized roles, but it is the effective team that knows when to live within those roles and when to step outside of them.

Found this on My Yahoo, but Get a load of this juxtaposition:

No, the photo on the left is not the Late Mayor, but Jacko! Too bad for the late Mayor Jackson he's upstaged by some wierdo. The real question I have though is who's to blame? Yahoo? Reuters? Was there no human associating those photos?

I find it kind of ironic that in the post where The FuzzyBlog complains about font bitches the post is, inadvertently, an example of font bitching. From Mozilla screenshots at 200% and 75% respectivly:

Now on issue #2 that I see with monsuier BileBlog's rant on IDEs. The most relevent poriton of that previous quote is as follows.

Serious swing developers I suspect are likely to scoff [at IDEA's GUI designer tool] and stick to using their own hand rolled magic. Still, I'm sure java needs yet more ignorant mediocre inexperienced developers dabbling in swing eh? [The BileBlog ]

I suspect that he's never done serious Swing development, I also suspect that a serious OSS developer would use an an OSS version control system as well (and by suspect I mean "I'm speaking out of my ass here"). There is no doubting that hand-rolled magic is sometimes the only difference between a sophomore CS project and a shrink-wrapped product. But if I were going to write a GUI in nothing but hand-rolled magic I would need at least two to three times the schedule to accomplish it.

Why? Well, as I blogged nearly eight months ago productivity matters. There are times that you want to spend a lot of time tweaking the little tidbits, and there are lots of times you could honestly care less. That's why I like start out in the GUI designer rather than blank java class. Yea, I could do all the GridBagLayouts by hand. I could also make the vertical FlowLayouts line up nicely inside multiple BoxLayouts by hand, and I could even write my own layout manager to deal with my personal nits if I wished (in fact that was one of the first things I did with Java GUIs more than seven years ago). But why should I visualize the insets, gridwidths, and weightxs in my mind when I can visualize them with my eyes? GUI designers also speed up the tweak/compile/run loop we all get in just to see if you got a titled border on the right component or to see if you fill propertu on a component needs to be GridBagConstraints.HORIZONTAL or GridBagConstraints.BOTH or whether that box layout looks silly with an alignmentX of .96.

GUI designers are not just about layout stuff either (something the reviews indicate the IDEA designer focuses on exclusively). It's about basic wire-work as well. Do I really want to write the boilerplate code to attach some method to a actionPerformed listener added to a JButton or would I rather jump right into the code preping the data for the SOAP call? (the latter, because it's gonna have to be written anyway). When code is truly boilerplate (like button presses and menu selections) and can be automated it should be, wether it's as a language feature, an API convienece, or as a feature of the development tool.

Believe me, there are many times where hand-rolled magic is the way to go. But that time is not when you are saying "JTree here, JButton there."