Once upon a time

Long time ago I started analysing Jin/Tonic gui. My good will to do it lasted only for a week and was enough to provide simple analysis for first time dialog and login panel. Not too much, but here and now is more. This time I will ponder one of the two most used ui elements in any graphical client for chess server - console.

Console is the place to start a chat or a game. You can issue several commands to server from it and get info about server, channels, players and games. You can read news and messages in it, watch shout and tourney annoucments; all in one place. It is what user sees second most to game window.

So as you can see the ui has two states... I used JSplitPane to create a hiddable JPanel with controls that let specify the exact type of new console. The ability of creating and using multiple consoles is one of the strongest features of Tonic, yet I managed to make in a way that it might a source for confusion and frustration.

Straight to the action.

Pros

1. Ui is simple - 7 controls is not that many.
2. One font for ui elements (text pane doesn't count, because this control's font type is controlled by user)
3. There are no unnecessary borders.
4. Scroll bar is there all the time and safe user from seeing any layout modification when scroll bar would have to be shown.
   

Cons

1. There is something I haven't told you - I decided that gui persists between Tonic runs. This is the first source of confusion - if you don't remember in what state did you left console you will be puzzled why new console panel is not showing.
2. The way I made it ui of top panel is not always showing all of its contents - when you resize some of the controls might be out of sight.
   
3. I used combobox where I should have used a list. There are only about 10 choices for the type of console. User can easily grasp that kind of number and there is simple way to show it all in a list. No need for forcing on user one extra click.
4. Clear console button is in bad place - because of its placement user has to be extra precise and cautious when resizing the console window and there is now safety net for this operation.

And on the ui analysis front I've found a blog entry about AccuRev ui worth reading.

One thing I want to do before next release is changing console's ui so it is less confusing and click hungry. I hope I will do better this time. Cheers!

Are bugs interesting?

When I checked this weblog traffic day before yesterday I saw a big spike of visit. It is because of a comment I left on recent weblog entry about using Java Help asking whether hideous ui bug in Java Help had been resolved. So it apears that bugs are interesting. One more proof for that is a bug about wording in the dialog taken from IntelliJ IDEA's Jira.

I think I'll hunt for some more useful bugs... To be exact - it is not a bug that is useful of course ;)!

Just couldn't resist, mate.

From time to time I read a tutorial trying to educate myself on programming, which is just my hobby so I'd like it to be nice and easy. I've read some java tutorials, skimmed through some C++' ones lately, seen some Scala's, Python's and so on. I am not calling myself an expert on that, I am far from that. I am just a average human.

I am trying to push myself through one of tutorials on ActionScript 3. It's name is ActionScript 3.0 for developers and designers – Part 1: Creating a preloader. I've just wonder whether that's me or there is actually something wrong with this article. I hesitated a little, but couldn't resist to write about it so you may judge it yourself.

First thing, Jamie Kosoy is using code convention that makes my hair go gray. Below is the sample.

private function _onProgressBarComplete($evt:Event = null):void
{
_isLoadComplete = true;

progress_mc.removeEventListener(Event.ENTER_FRAME,_onProgressEnterFrame); _animateOut();
};
private function _animateOut():void
{
gotoAndPlay("OUT");
addEventListener(AnimationEvent.ANIMATE_OUT, _onPreloaderOut,false,0,true);
};

I am almost sure this is not the recommended style for ActionScript 3. What the heck is with those $ and _ ?! Are those really that useful to understand code? You know what? When I read this source code I wondered whether those might some special variables, I had to check AS docs to clear it is just a convention. One thing it leads to is to ask useless question: what do those character mean? You have to be pretty sure that there will be questions about tertiary operator as well, and this _animateOut() function call on the of the line!

And the flow of article kills me of. Instead of going from start of program it goes the other way. You see on method there, another here. I know Jamie is senior developer and probably most of developers will understand this cliploader he is presenting. Including myself, but it is hard to read it this way.

Concluding I think this article should be revised to my liking! :))) That is:

• make all the special characters from variables go away (this would let me concentrate on the problem tackled in the article and not on wondering what those underscores and dollar sings might mean),
• rewrite the article so that it goes from top to bottom (this would present it the way source code is read - from application start. For this very clipLoader I would start from the code that actually loads the content and would drill down to details of passing the event to the timeline objects).

I am sure I will learn a lot from the article, but this could be even better experience for me. And how do you think?