I just wanted to get this blog started. I will now return to writing my book. Once I see some comments on this blog I’ll know I’m not talking into a vast–yet empty–space.

Related link: https://www.google.com

So, it’s like this:
CNET’s talking about Google’s porn filter, Dave Winer’s talking about some sort of dis of RSS by Google, Reuter’s and Businessweek are both agog over the impending (?) IPO, Tim O’Reilly’s talking about GMail, and I’m wondering: what’s really going on while we’re all staring so intently at what, at the end of the day, is a small software company with some pretty neat products.

Did anything interesting happen this week? Really?

Related link: https://www.aspectxml.org

First, a bit of background …. recently I started up an open source project (aspectXML). After blogging with people on this network to ensure that I wasn’t reinventing the wheel too much and that there was enough interest in the subject (a nerve wracking time to be sure when at every step you expect your idea to be unceremoniously shot down in flames) I decided to get things going so that I could explore the concept a bit further and provide a project for everyone to contribute to.

I thought I had overcome the worst when the idea survived the initial exposure and the concept was accepted and even enthused by a handful of great developers who wanted to get started straight away on the first proof of concept prototype. At least that’s what I thought until I tried to put in place the tools and support services for the project itself ….

I hunted around different open source projects and came up with a small list of capabilities that a project would find essential in it’s early days. I then went about configuring one of my own machines to run as the projects start-up server. Now, this is where things got complicated as I got snowed under with different configurations, dependencies, users, password and the overall mish-mash of applications that would provide the capabilities I was looking for.

After about a week of free-time tweaking and general anguish which had nothing to do with the actual project itself I got a reasonable suite up and running but I have to wonder how much easier this would have been if there was a single tool/service that could provide everything you needed to start up an open source project.

What I needed right up front was a product that came with a useful installer that simply configured a suite of open source project support tools. My apologies if this has already been done, and the idea does not seem that far removed from how communities such as java.net work, but I wanted to get things running at first on my own machines and this proved a difficult process of setting up different applications that would have definitely benefited from a simple installer and single suite approach.

So, my challenge goes out to everyone to share their own experiences in getting an open source project off the ground, technically speaking. Are there tools out there that make this process much easier, and perhaps ones that I could take advantage of by moving my own open source project to? Also what experiences have people had with the different community projects?

My own experience was painful at first but is now extremely rewarding as I enjoy the collaborative and open atmosphere of the aspectXML development forum. However it would be great to make the whole start-up process that bit easier if we possibly can so that it is as easy as it should be for people who have the idea for an open source project to get it running and people involved as quickly and painlessly as possible.

I’d be interested in any experiences in getting an open source project up and running, especially if you have had a better time than I had and can recommend to everyone who might be doing the same thing in the future how this can be acheived as easily as possible.

Related link: https://www.superwaba.com.br/en/default.asp

I’ve been thinking a bit about wireless devices lately and somehow ran across Superwaba. I can vaguely remember, back from the days before J2ME (or even “Personal Java”) talking to the people who founded Wabasoft a few times. Judging from their website, wabasoft is apparently defunct. But Superwaba descended from Wabasoft, via an open-source path.

The question is: if I were trying to develop a handheld application, would would I use J2ME and when would I use Superwaba? Or should I avoid them both, in favor of something else?

Please note that I’m looking for facts and experienced opinions. Please don’t flame me or your fellow commenters.

Related link: https://www.sdforum.org/SDForum/Templates/CalendarEvent.aspx?CID=1373

SDForum’s Distinguished Speaker Series presents people who have made major contributions to how software is created and understood, speaking on topics of current interest (disclaimer: I’m on the program committee). This coming Thursday (April 8), the speaker is a legendary figure in software development, Fred Brooks. Brooks led the development of the IBM System 360, wrote “The Mythical Man-Month: Essays on Software Engineering”, and founded the Computer Science department at the University of North Carolina. He’s won just about every award imaginable, including the National Medal of Technology, the Turing award of the ACM, the Bower Award and Prize of the Franklin Institute, and the John von Neumann Medal of the IEEE.

But what’s Brooks done lately? Surprisingly, he’s into virtual reality. His Effective Virtual Environments project at Chapel Hill is trying to determine which technological factors really matter when creating virtual environments. His talk is titled “Making and Measuring Effective Virtual Environments”, and he promises to present some unexpected results as to what constitutes an effective illusion.

Did you know he will also be speaking at the Computer History Museum on April 7?

I believe GUI programming is significantly harder than server-side programming. This flies in the face of common industry practice. I believe that programmers with J2EE skills are more marketable than those having GUI development skills. I also believe that server-side programming positions offer more money (and fame) than client-side programming positions.

GUI builders make it easy to think GUI programming is easy. Nearly anybody can whip up a decent-looking GUI in no time at all using a GUI builder. Done.

Server-side programming is different. EBJ can seem extraordinarily complex, particularly when you are just starting. It is much harder to whip up a quick and dirty EJB system, giving the impression that server-side coding is harder to do.

A bad programmer will continue to struggle with EJB. A good programmer will find ways to automate nearly every aspect of EJB, however. That’s the secret of server-side programming: it is very well-defined and repetitive. Thus, it can be automated. Check your favorite Model-Driven-Architecture (MDA) tool. They work best when generating server-side code, things like EJBs, database access code, and web services. They might be able to generate a rudimentary GUI, but a really GREAT GUI cannot be automated.

Good GUI versus Bad GUI

Let me qualify what I said in the first paragraph. Creating a bad GUI is really, really easy. Creating a “good” GUI is really, really hard.

I enjoy GUI development for precisely this reason. I like the challenge. Here are some reasons why it is hard to create a great GUI:

• Everybody wants to contribute. The GUI is immediately visible, and every person on the team wants their particular feature. Server-side developers contend with technical challenges, but client-side developers contend with many more social and political challenges.
• The people “designing” the GUI are not GUI experts. People who are business analysts can dictate the GUI design.
• People are often attached to their legacy GUI design and cannot think in terms of more modern approaches. For instance, a designer might be obsessed with some weird “button bar” concept because their 4GL tool offered the same thing.
• People migrating text-based systems to GUI-based systems often want to cram too much data onto the screen.
• With web apps, people want to force HTML to behave just like a fat client GUI, regardless of how difficult that may be.

And the list goes on…

What Does it Take?

So what does it take to create a good GUI? Having the right people is the most important factor. You have to find a handful of people with some magic blend of technical and design know-how. How do you quantify good GUI design skills? I do not know. A great GUI is a work of art.

Assuming you find a team of really good GUI designers, you must give them power to enforce consistency. Here’s where it often breaks down. At one end of the spectrum, you have too many people designing the GUI so you end up with really complex, cluttered, difficult screens. At the other end of the spectrum, you have a handful of bad designers forcing the programmers to create a really stupid GUI.

A Few More Random Thoughts

This is a really big topic to tackle in a blog entry. I’m sure people will point out all sorts of things I forgot to say. Here are some more things on my mind…

• Skins are evil. Skins look cool, but impede usability. They offer the illusion of a good GUI. Most skinnable apps are bloated, slow, and hard to use.
• People are quick to criticise Swing, but most bad GUIs are bad because of stupid designs. You can create great GUIs in Swing.
• Good keyboard navigation is essential to good GUIs. This is also very hard to get right. IntelliJ IDEA is a perfect example of a great GUI with great keyboard navigation.
• In-place table editing is virtually impossible to get right and companies consistently underestimate how hard it is. For instance, what happens when you hit Enter while editing in a table? Should the default button on the screen be activated? Should the selection move to the next row in the table? Everybody has a different opinion.
• GUI code is notoriously hard to test in an automated fashion.

Related link: https://whatis.techtarget.com/definition/0,289893,sid9_gci214173,00.html

MENLO PARK, Calif., April 1, 2004
For Immediate Release

Fans and afficianados of the classic computer protocol “TCP/IP” watched in dismay as the Internet Engineering Task Force (IETF) announced that “Transmission Control Protocol / Internet Protocol” was no longer the full name of the protocol.

“Quite honestly, we had do do something” said Harald Alvestrand, a former chair of the IETF. “TCP/IP is a good and solid protocol, and we have been quite happy with its adoption and usage until recently. But it’s become clear that something is holding it back.”

“Look, for example, at RSS. That’s getting more and more press coverage every day. People are adopting it like crazy. While TCP once had that sort of magical buzz and growth, it’s become painfully obvious that most people view TCP as somewhat boring these days. TCP’s percentage of the market has stabilized and we need to kickstart the growth process once more.”

“So we thought hard: what does RSS have that TCP doesn’t? And the answer was clear: Nobody really knows what RSS stands for. Is it Rich Site Summary ? Really Simple Syndication ? Who can say? I heard someone the other day call it Rich Syndication and Summary.”

“We want that sort of ambiguity to be part of the TCP brand as well.”

When asked what “TCP/IP” now stood for, Alvestrand refused to reveal the new name, saying “We’ll reveal it during the halftime of the NBA Finals. All I can really tell you is that we’re not the Internet Engineering Task Force anymore either.”