blog.sommestad.net

The reason to this is to get more control over the site and be able to customize however I want. Also, I thought I’d better use the sommestad.net domain for something…

So please follow the blog at the new address from now on and make sure to update any bookmarks or feeds!

Note: this blog will still remain here to preserve posts and comments, even though I’ve re-added all the old posts (and my comments to those) on the new blog.

I wanted to show the user a confirmation message when closing a pop-up (OK I know, but sometimes you just got to use them!) to make sure he doesn’t lose any data when leaving.

But we can do this! Right…?
This isn’t really any big issue, as the onBeforeUnload event can be used for these exact scenarios, with a nice message too:

window.onbeforeunload = function (event) {
    // message to display (in between the standard message provided by the browser)
    return "Leaving now will have you lose everything."
};

The special case here was that I had a SWF running in the window, which needs to be unloaded (close its connections etc) when closing the browser window. That has to be done in the onBeforeUnload event as well, since it’s too late when we’re at onUnload.
The problem is that there’s no way of knowing what the user answered to the question arisen from onBeforeUnload, other than finding out when the event’s traveled onwards to the onUnload event. By which time it is too late.

So I ended up in a situation where everything was fine if the user decided to keep the browser window open (“Cancel” in the confirmation box), but should he close the window – which is fine too – I had no way of closing the connections etc in the SWF.

But why?
The reason to this is of course a security matter. Some clever fellas have set some restrictions to what you can do with Javascript to avoid misuse, for example extreme annoyance with pop-up ads or such. There’s nothing wrong with that.
But sometimes you just want to yell to JavaScript’s mom and tell her that I’m a perfectly honest guy trying to make the world better for my users!

What would’ve helped me
So what do I want, then? Well, it would’ve been nice if I could’ve gotten an answer from the confirmation box rendered with my custom message (“OK, leaving now…”).
It’s perfectly fine that the unload event cannot be stopped once the user’s said “OK, close”. But at least I would’ve wanted the chance to act upon the user’s choice before the document was unloaded.

So my final solution was just to warn the user that everything was hitting the fan, and at the same point notify my SWF that it was to be unloaded etc. It’s an OK solution, but not perfect from a usability perspective…

End of rant.

These are the release notes from the CM-Online team:

• Achievements – A new way to compete in CM-Online.
• New graphical style – for faster playing and easier to use.
• Tournaments – They are now free to play.
• Premium and regular managers – Now it is available to play the game for free, with certain restrictions.
• Cup – We have changed the international cups to the correct format.
• Economy – An overhaul have been made to the economy in order to balance the game.
• Stadium – Balanced the effects when improving your stadium to make it more worthwhile.
• Fans interest – Improved the logic to better reflect the fans interest for successful teams.

As a veteran CM-Online Manager, I’m of course pleased to see the new design and maybe most of all; the new achievement system! Now I’ll get a whole bunch of new challenges to take on…

Another highlight is that it’s now possible to play as a Regular or Premium member. Premium members get more and better features, but playing as a Regular is free of charge.

I’m of course biased, but a nice release nevertheless!

The search results have really met my demands so far, and much of the contents of the books are available to read on-line. As many of the books are protected by copyright, the publishers (from what I’ve understood, anyway) decide which pages to publish on-line. From what I’ve seen so far, they’ve more or less randomly removed a few pages here and there, to encourage the reader to buy the book to get the full contents. And that’s fine by me!

I think it’s a great tool to use when searching for development material (“I know I read it in this and that book, but I don’t have the book now…”) and when you want to get a good preview of a book before going all-in on Amazon.

Try it out yourself!

(Every time Google does something like this, I get more and more scared they’ll begin charging us big-time soon… )

Anywho. My opinion is that you should rarely bother to do this kind of micro optimizations of your code. Maintainability and readability of the code is way more important, especially in larger products as those we’re working on. People should put more effort in that area, than saving a nano second here and there. (Also, there’s often far better places to optimize the code than in variable declarations and arrays…)

I hate it when I come across code like this (JavaScript in this example):

var i = 0, j = 1, k = 2;

… as opposed to the more human readable:

var i = 0;
var j = 1;
var k = 2;

There’s no real reason what so ever to write code like that! It just makes it harder to read and maintain.
I guess maybe that’s why I’m not a preacher of the chaining madness in jQuery…

(The headline is a quote from Donald Knuth, which I think applies to any programming language, at least all of those I’ve been working with).

But MXML is said to improve productivity as be “easier to write” and that is a matterI’ve been delving into quite a lot over the past months. (Unfortunately “easier to write” usually comes with a bunch of unneccesary, over-the-top functionality…).

What do others say?

Recently I’ve been trying to figure out how to use MXML together with AS code. I’ve scanned the web for articles, and have found a few interesting. This one, by Dan Orlando, seemed to be on the same track as myself. Also, I’ve previously come across this one, discussing a few pros and cons of MXML.

I don’t know the answer… yet.

I haven’t really come to any conclusion yet, but I’m hoping to do so shortly. I’m sure there’s benefits from using MXML – i.e. to lay out your views – but it’ll be interesting to see how to best combine it with “regular” AS code…

This was a post in the midst of something, but more is to come on the topic, for sure!

What this means to us as professional web developers, is that all products (sites) must be 100% functional in Internet Explorer. There’s no room for excuses like “but it works in Firefox”. There can be no important features/styles/etc that only works in non-IE browsers.

I read about a lot of web developers saying “ignore IE and develop according to the standards”. Maybe that works for your own personal web site, viewed by 10 users a month. But if you’re running a professional site, supported by a large business, you can’t make it a crappy experience for all the regular users out there who aren’t using the latest Firefox or Safari build. That’s just dumb.
When the non-IE browsers have 95% of the market, we can start talking about ignoring IE and its quirks.

I’m not saying I like fixing IE bugs/quirks, but it’s a part of the job, just like any other task. Firefox (my own preference), Safari, Chrome or whatever are surely awesome browsers, far better than IE. But it doesn’t matter, because it’s only us “experts” and hardcore users that know about it. Your target group doesn’t.

So make it your primary goal to have the site working 100% in IE! If you want to use the extra goodies provided by other browsers, make that the little extra functionality that makes it a 110% experience in standards browsers.

(I do my primary development using FF and Firebug (as it’s much more efficient), and do a test round in IE 6+ when I’m done with the design. )

No reason not to keep trying, though!

• Dive deep into Flash Player 10 and Pixel Bender, with Tom Krcha.

• New Flash Catalyst and Adobe Flex (Gumbo), with Enrique Duvos.

• Adobe Flex/LC DC Integration, with Tom Krcha.

• Case: Min Boling/My Home, with Peter Molgaard.

My main interest was the (more) in-depth demo of Flash Catalyst and Flex, which I’ve been investigating quite a lot lately (and also given some more or less harsh comments on).

Flash Catalyst strikes back!

After today, I’m more impressed with the capabilities of Flash Catalyst – at least if it’s used properly. It was nice to hear Enrique emphasize that it was intended for the View part of the application (in an MVC app). Previously, I’ve interpreted the fuzz about Flash Catalyst as a replacement for the entire MVC model (basically a replacement of regular coding), but that’s not (necessarily) the case.

If we were to use FC purely as a tool for the View Components in our applications, we could really improve our productivity massively. But to me, it stops there. I would keep away from using the different “states” in FC, i.e. to create the various views in the app. Single-view only, please!

But it’s all on a pretty much theoretical level, really, as FC is still on a very early stage in its development (seems like we’re at least a year away from first real release). But it looks interesting, to say the least!

My notes from the seminar

I put down some notes on my mobile phone during the seminar. Maybe some rambling, but hHere it goes:

• Good to use Flash Catalyst – only for isolated components? Avoid using “states” in FC?
• What are the capabilities of FXG? What’s the syntax like?
• Does FXG “skin classes” (and likes thereof) be in MXML? Can regular AS classes be used instead?
• Can FXG code be imported to Flash Catalyst?
• How can Flex and FXG be combined with regular AS classes?
• Try putting more use to SWC files?
• How are SWC files used with Flex? How are component files (binaries) managed in Flex in general?
• Would Gumbo (new Flex Builder) be interesting to use?
• Take a look at Blaze DS for data services. Using HTTP protocol. RTMF to be used when more instant feedback needed.
• Have a look at Adobe AFCS.

All in all…

• Flash Catalyst seemed a lot more interesting in a live demo and I look forward to seeing the public beta (without expecting too much…) .
• PixelBender was really cool (a lot more cooler than its docs )!
• The presented “case”, My Home,  was very cool, but perhaps a bit Big Brothery. Doesn’t feel too secure…
• A good seminar; better than expected!

What’s the deal, anyway?
I’ve been discussing the issue a lot with Peter, our team’s designer, and we’ve been trying to pin-point the most important parts of the process. Two of the main issues are:

1. being able to have short “design-implement-test” iterations when implementing new features, making changes etc.
2. maintaining a solid code base while still allowing non-developers to make changes to the interface.

Does the technology matter?
It’s hard to say which technology to use in order to meet the demands, as it depends very much on what the product really is. If it’s a game where instant and fluffy feedback is important, then we should probably make it a Flash app. If it on the other hand is more of a site, where larger sets of data are important to display in an easy-to-understand manor, then we should probably make it a HTML/AJAX app.

In our upcoming, and many of our current, projects we’re focusing a lot on the visual experience. We’re developing games. In Flash. So how can we optimize the processes with focus on Flash development?

Supporting short development iterations
In order to support short iterations, we need to make it easier for project members to change things without being hindered by their technical skills; a designer or artist shouldn’t need to have ActionScript expertise to change the colors of a button or the placement of a menu.

One way of solving this can be to use Flex with MXML. In MXML, the layout (View) can be changed using a special markup language, logically similar to HTML. Various components, such as buttons, can be positioned freely with some pretty easy-to-use tags. This is quite commonly used among developers all over the world.
Now I haven’t used MXML to any massive extent, but in my opinion, using MXML isn’t really all I want it to be. The code gets a bit ugly and somewhat hard to control. And from what I’ve understood, there’s really no built-in way to connect an MXML view to a pre-compiled SWF with assets (?).

We’ve got a great tool for this
A while ago, one of my co-workers developed our own framework where it’s possible to easily define views on an XML format. Some capabilities of the framework:

• a widget (component) class can be mapped to an SWF file, i.e. containing the art assets for a widget
• widgets can be positioned anywhere in its container, either with an absolute position or relative to any other widget
• widgets can listen to events from other widgets, in order to allow for them to communicate with each other
• a widget can consist of another XML definition to allow for better structure in the view document

It pretty much meets the demands one’s got on such a framework! An advantage (which could also be seen as a disadvantage) is that we can develop the framework further when needed, in order to add more nifty functionality.

Is this enough for us?
Anyway. Allowing the designer/artist to create widgets/components and using the widget framework for creating a layout is probably a very good way of meeting the demands of our desired work process. A couple of things that are vital:

• The View (Widgets and Layout) needs to be clearly distanced from the actual functionality in order to maintain a solid and independent code base, i.e. no functionality should reside in the Widgets or the View document.
• The widgets should be kept as small and isolated as possible, to make it as flexible as possible and avoid difficulties/conflicts in version systems.

We should try to identify if we have any further needs that aren’t met by our widget framework of today. As it’s a great system, we should really try to cling on to it and keep developing it (as we have up until today).