Yesterday night I went live with Status Analyzer, a small side project I’ve been working on this week.
The idea is simply to get an analysis of your Facebook status updates, to see if anyone actually care about what you’re writing.

I’m making use of the Facebook Graph API to collect the data.

The test only takes a few seconds to run, and you’re presented with some stats on reactions to your updates as well as a nice pie chart to visualize the ways people interact with your posts. And of course, you’ll get that final verdict on how interesting you actually are!
The analysis is based on your updates the past two weeks.

Apparently, "people like what I'm saying".

Do you have the guts to find out the truth about your status updates!?

Jadestone – and myself – released a new iPhone/iPod touch game the other day. Vuvuzela Whacker is probably the most heralded game of the summer – a whac-a-mole style game where you score points by “whacking” football fans playing vuvuzelas! How can you NOT love that?

Whack those vuvuzela players!

From the press release that went out:

Vuvuzela Whacker is an action packed game for iPhone and iPod Touch. The goal is to save the world from the vuvuzela infestation by whacking as many vuvuzela players as possible in one minute. Tap away at the fans holding vuvuzelas – but avoid hitting the regular fans. There are zombies in the stands, too.

Vuvuzela Whacker features score multipliers, beautiful graphics and the ability to release frustration for TV viewers who’ve grown tired of the drone. For soccer fans, the pleasure of silencing a vuvuzela is equal to watching Lionel Messi attacking.

Vuvuzela Whacker users can show off the number of vuvuzelas they’ve silenced to their friends on Facebook. As the instrument’s at risk of being exported to the national championships as seasons begin in August, our goal is to have 1.000.000 vuvuzelas whacked before the end of the World Cup.

So help save the world and download Vuvuzela Whacker from App Store right away for only $0.99!

A while back, I tried out Google Web Toolkit to see if it was any interesting. My main concerns after that early glance was the stability of the applications and the possibilities to mix GWT code with plain JavaScript code.

Giving it another stab

I decided to give it another go last week, when re-building the mixtape interface for my side project Spotiseek. A few things led me to creating an “Ajax” application with GWT:

• quite a few requests are required to present the view – I needed the requests to be cached in the client to reduce the server load
• I needed an application built on stable and easily maintainable code
• I figured it would be a good chance to learn more about GWT

Spotiseek Mixtape interface

Drawing some conclusions

After completing the first release of the new interface, I feel confident enough to draw a few conclusions:

Positive: It’s Java!

When looking to write stable and easily maintained code, I really can’t find any better candidate than Java. Since I’ve been working with Java for a number of years, I’m of course very comfortable with developing GWT apps.
The syntax is nice and clean and of course the magic of the fantastic IntellJ IDEA is indispensible.

Positive: It does what I want it do do

It might appear a ridiculuous header, but I have to say it’s very easy to create widgets that does exactly what you want. There’s little confusion on how to actually construct the application.

Negative: Problematic project setup in the IDE

Even though IntelliJ is a fantastic IDE, there’s appearantly some improvements that could be made to the setting up of GWT projects.

Just setting up a GWT project is not a huge matter, but trying to add a GWT project module to an existing web project was a lot of hassle. There was a lot of problems getting the built-in build/make process to put the files in the right place etc.

Negative: Surprisingly poor community support

I honestly thought that the usage of GWT would be more widely spread across the internet. But when I – from time to time – got stuck with an issue, there wasn’t really that much help from Googling.

There are of course a few good forums and such where many questions are answered, but unfortunately not the answers I was looking for. I had to dig deeper in the Google documents in  order to get enough info to draw my own conclusions.

EDIT: One nice resource I’ve found is Matt Raible’s blog.

Maybe it’s not inadequate for most issues, but I had expected more…

(Sort of) Negative : Building everything from scratch

Usually, you try to mix as much HTML and JavaScript as possible in order to write code more efficiently. Building it all up from scratch is often a quite expensive process and rarely gives you the most maintainable code.

But with GWT I didn’t really see any way of not building everything from scratch. Partly because it’s very easy to do so, but also because I didn’t find any good way of reusing existing HTML components.

I’m not sure it’s a true negative having to build everything from scratch, but it requires a somewhat different approach than you might be used to.

To sum it up…

Even though there was a few problems during the development, I’m glad I chose to develop the application in GWT. It’s resulted in a nice (enough) application, built on code that is stable and easy to maintain.

Also, I’ve learned a lot about GWT development and will have no problems going forward with the development.

(Apart from the conclusions I’ve drawn, there’s of course a bunch of positives that comes with developing GWT applications. )

Maybe not suitable for all products

As I’ve stated before, I still feel that you should always consider if GWT is the best approach for your particular application.
I guess a certain amount of complexity is required, as it’s probably more tedious to write GWT Java code than regular JavaScript. If you’re going to develop a small-sized application, you’re probably best of doing it the old fashion way.

SEO issues with JavaScript applications

Of course, there are some issues with building your applications in JavaScript. One of them being the drawback in Search Engine Optimization (SEO), as your content is hidden from the indexing robots.
I know Google have proposed a new standard for specifying JavaScript content, in order to make the robots understand how to activate the content. But we’ll see what happens there…

For a while, there’s been a possibility to separate your users in various segments in Google Analytics, by setting a (single) variable in the Analytics cookie, for example:

pageTracker._setVar("member-premium-true");

Earlier this year, Google introduced the neat possibility to use multiple custom variables, allowing more customization and flexibility. You are allowed to use five slots (1-5) and set a name, value and scope to your variable.
The old setVar method has been deprecated and replaced by the new setCustomVar:

pageTracker._setCustomVar(
      1,                // This custom var is set to slot #1
      "Member Type",    // The name of the custom variable
      "Premium",        // The value of the custom variable
      1                 // Sets the scope to visitor-level
 );
pageTracker._trackPageview();

This isn’t really news, but it wasn’t obvious what had happened by just looking at the Google Analytics API docs, so I thought I’d mention it here just to “spread the word”.

<script type="text/javascript">
				pageTracker._setVar('member-premium-true');
			</script>

I just read a great article, summarized over at InfoQ, about Agile development.

I think Mark W Schumann is spot-on with his formulations on what you have to understand and accept in order to be successful with agile development.

Pairing is important, but it’s more important that you’re happy to be corrected a couple dozen times a day. Test-driven development is useful, but it’s more useful to imagine a hundred ways something can go wrong. Stand-up meetings can be effective, but the trust in your colleagues that frees you to do your own thing makes them really effective.

It’s all about being humble and accepting the fact that you just don’t know everything at the start of a project, a task or whatever.

… there has to be an attitude in middle-to-senior management that they don’t know everything, that some things aren’t amenable to control, that surprise is something that should be expected. You have to trust your teams, even when they don’t deliver the results you expect. You have to imagine more than one possible outcome.

Really recommend reading the post, no matter if you’re a developer or a manager.

I’ve conducted a small study recently, trying to figure out if we could evolve in our Flash RIA development somehow. I’ve read and experimented a lot with Flex, MXML and related tools to see if we’re missing something (we’re not using it very much today).

It’s not that we’re unhappy with how things are done now, but with the new Flex 4 and everything associated to it, I’ve felt that there’s an opportunity to make some improvements to our workflow.

Summing it up

As presented below, there are a few conclusions to be drawn here, for example:

• Flex 4 seems to be a really nice upgrade and probably something you can’t ignore in the end.
• There’s little information on the web about development of large Flash/RIA applications (like those we do). Pretty much all focus is on Flex development of small-to-medium sized applications. I’m not to speculate on the reasons why no one is spreading the word, but hope that my work can shed some light on the area.
• There’s a lot of fuzz around the Adobe products in general and Flex in particular. Very few seem to have any criticism at all when it comes to Flex, which is a bit disturbing, as nothing that looks too good to be true ever is. But maybe I’ve just been looking at the wrong side of the web? Just a reflection…

Presentation of findings

I held an in-house presentation on my findings yesterday, and I thought I’d better share it with the world (= your favourite search engine). I’ve stripped it down a bit, as there were some company specific things in there, but most of it is free for everyone to read.

A few things to consider before jumping in, though:

• This is a PowerPoint (well, OpenOffice actually) slide with notes. There was lots said when presenting each slide, so I can’t guarantee that you’ll learn everything I said. I understand this is not perfect, but figured that it’s better to upload this than nothing.
• It’s just plain slides with notes, really. I did have some imagery in the original slides, but left it out as it’s probably only needed as “distraction” when viewed on a large screen with me talking next to it. So don’t get mad if it’s boring!
• The plan wasn’t actually to hold an in-house presentation, but I figured it was a good idea. So the format on which it is presented may or may not be optimal, as it’s pretty much been summarized as I’ve went along. It could be a good idea to shape it up and make it a bit better, but at the moment, it’s more important just getting it “out there”.

The presentation itself

With that having been said – and my back having been covered – here it is (also available as a PDF):

Download (PDF, 134.18KB)

EDIT: Also added the presentation to SlideShare.

I just came across this article in Smashing Magazine about the CSS differences in Internet Explorer 6, 7 & 8.

Nothing new really, but a good summary of what works and what doesn’t. The consensus is of course that you have to be aware of that IE6 pretty much can’t handle anything, so we’re still bound to write old code to be compatible with it. Sad but true!

Damn, it’s annoying when you get stuck at a single point in development.

When continuing development of an Facebook Iframe application, I got stuck when trying to implement the showFeedDialog feature. For some reason, I couldn’t get the feed form dialog to show, even though I had configured the initialization properly and was using the correct methods and syntax.

I read through the extensive (and inconsistent thus confusing) Facebook developers’ documentation, but couldn’t really find anything to help me. I’ve probably tried all of the various ways to initialize the app and use the API by now, and also tried to use streamPublish instead.
Also, the return values from the API insinuated that the dialog should actually be displayed (returned true when invoking the method).

Back to basics

So I figured it’s best to go back to the basic levels and read through the Getting started docs. And there it was. In a screenshot of the application settings, I noticed that they’d specified the Connect URL and set it to the same as the canvas URL. That’s the one thing I’d missed!
I guess the problem was that I didn’t see this as a Connect application, as it’s running in an Iframe.
But anyway, setting the connect url solved the problem and the feed dialogs popped up as intended!

Confusing Wiki docs

The Facebook developers’ wiki is full of (useful) information, but it seems like it’s got lots of counter-information with different ways of using their implementation. It gets confusing quickly and is quite hard to troubleshoot. I hope they manage to sort it out some day…

I stumbled upon Expression SuperPreview, a really neat tool for comparing different versions of web pages.

It basically lets you enter the URL (local or public) of  a web page, and allow you to compare images of different browser versions. Compard to other tools, like BrowserShots, it’s got the handy addition to also inspect and compare DOM elements in the views.

Slim & Free or Fat & Premium

There’s a free, slimmed version available for Internet Explorer (6+) comparisons and a “premium” version included in Expression Web, where you can compare with Firefox and other browsers you may have installed. The premium version is available as a 60-day trial, and the licence is priced at $149 USD, which could prove to be money well spent.

I usually test my apps in IETester and on a virtual machine, but I’ve downloaded the 60-day trial of SuperPreview and will give it a go.

Smashing Magazine posted another great article today about usability.

Summarized, their findings were:

• Form Labels Work Best Above The Field
• Quality Of Design Is An Indicator Of Credibility
• Most Users Do Not Scroll
• Blue Is The Best Color For Links
• The Ideal Search Box Is 27-Characters Wide
• White Space Improves Comprehension
• Effective User Testing Doesn’t Have To Be Extensive
• Informative Product Pages Help You Stand Out
• Most Users Are Blind To Advertising
• Bonus: Findings From Our Case-Studies

Not necessarily new findings, but as usual, very interesting reading!

I recently discovered that some of our stats in Google Analytics looked a bit suspicious. When looking into it, I remembered that there was a previous issue in the ga.js tracker, causing usage of user-defined variables, setVar(), to be tracked as pageviews. These pageviews corrupted stats like bounce rates and time on site.

Google fixed this issue in January, but the latest GA for Flash release is from December. So there’s a big chance that the bug still remains in the ActionScript version. I’ve posted a question in the GA for Flash discussion group, but as the group seems to be full of porn spam, I’m not very hopeful in getting an answer right now…

Also, some of our stats were missing data about screen resolution etc and I fear that the Flash tracker and setVar() is the root of that as well (since it’s working fine in products where setVar() isn’t used).

Anywho. I’ve not yet confirmed that this bug is still there, but an easy solution is to use Google Analytics for Flash in “Bridge mode“, instead of “AS3 mode”. This means that the ga.js file is used, which is a guarantee that the latest official Google updates are always used.

In my post a few days ago, I mentioned that that Scott Delap and his team were using the Swiz MVC framework. I decided to try it out, and I have to say it looks quite promising. The Swiz tagline is “Brutally simple micro-architecture for Rich Internet Application development with Adobe Flex”, and it was actually pretty easy to set up. The framework is similar to the way Java Spring works with autowiring, so if you’re familiar with that you’ll probably like Swiz.

I’ve only read the docs and tried the demo out so far, but it’s a very interesting candidate for future Flex projects. It’s quite easy to separate the views and controllers from the business logic and using both MXML and ActionScript views seems to work fine. Swiz really gets the job done.

Seems better than PureMVC

I’ve tested the PureMVC framework earlier and kind of liked it, but developing with PureMVC gets quite repetitive and you produce quite a lot of boilerplate code. I like it better when the MVC framework easily guides you towards a proper structure, without having to do too much work to get there.

Also, there seem to be pretty good community activity in the Swiz Google Code project.

It seems like the best MVC framework candidate so far!

I came across a really interesting presentation from Scott Delap on InfoQ:

Scott Delap shares his experience creating a lobby interface for an online game using Flex&Air. He details on related technologies used, available tooling and frameworks pros&cons, remoting options, unit, functional and load testing approach used.

To sum it up, it’s a good and elaborate presentation from a Java developer’s perspective, with reflections from a online multiplayer game development project. I enjoyed the full hour of watching it!

They’ve dealt with many of the questions we have and their conclusions are very interesting.

Presentation summary

I’ve summarized the most interesting contents of the presentation. They’re actually notes taken during the presentation, so please forgive any poor language or formatting:

• The Flex Builder WYSIWYG actually works, which isn’t common at all
• MVC in Flex is pretty much MVc, where the controller and view are sort of bundled together
• When choosing an MVC framework, Swiz turned out to be most interesting (among likes of Cairngorm, PureMVC etc). Swiz is similar to Spring with auto-wiring. Also supports Dependency Injection, Command Chains, and has MXML support even for non-views (i.e. for wiring the M:s, V:s and C:s).

Their MVC implementation:

• MXML for the views
• ActionScript for the controllers
• Remoting interfaces + specific back-end implementation
• Swiz wiring it all up
• They found no real reasons to use a “big MVC framework”, whereas Swiz did the job well enough

Remoting

Looked at several candidates, where WebORB, Hessian, XMPP, GraniteDS, Rest not weren’t considered enough for various reasons. Also evaluated BlazeDS, which doesn’t scale and has no NIO support.
Best candidate: LiveCycleDS - supports NIO, RTMP and lots of connections:

• Good for remoting Java <> Actionscript and easy to integrate
• Some Java <> ActionScript translations a bit problematic, i.e. enums and null values
• Some lack of documentation when it comes to messaging

Unit testing

• Evaluated ASUnit, FlexUnit, DpUnit/Fluint
• Chose Fluint, but could just as well have chosen FlexUnit. Unit testing Utilities, Controllers, Remoting Services with Mocks

Functional testing

• FlexMonkey not working properly with AIR and had a bit of lag
• Wrote a stripped-down version of Selenium

Load testing
Currently no good way of performing load testing.

• Hard to simulate 1000:s of users
• No really good tool for load testing at the moment

Final thoughts on Flex

• MXML works as advertised
• Easy to do complex things

When working with web sites, you often come across compatibility issues due to the users’ variations in browser usage. The vast majority (around 70-75%) of the users still use Internet Explorer as their browser, while most of the development is done in Firefox (thanks to the excellent Firebug and similar tools).

Hence, from time to time you need to adjust your code to make it work in all – well, actually it’s mostly about making it work in IE too, as it’s not as good as the others in following standards – browsers.

A handful of issues

A few days ago, I was testing a site in IE (both 6 and 7) and figured I might as well write down the (CSS) issues I came across:

• Issue: Opacity animation of text looks jagged.
  Solution: Adding background-color to the animated element.
• Issue: Some elements get “magic” padding/spacing at the bottom, due to the whitespace in the code.
  Solution: Adding overflow: hidden to the element(s).
• Issue: Elements within links do not inherit text-decoration, especially on :hover.
  Solution: Set text-decoration on inner elements too, e.g. text-decoration: none.
• Issue: Right floated elements without a set width expands to 100%.
  Solution: Always set width of floated elements – particularily those floating to the right.
  Note: The W3C CSS2 specs used to state that floated elements require an explicitly set width, but that section has now been removed. Do note that it’s probably good practice to set width on floated elements if it’s vital to always keep them next to each other.
• Issue: Lists (ul li) treating list-style-position and margins differently in FF and IE.
  Solution: Always use list-style-position: outside and margin-left instead of list-style-position: inside.
• Issue: Lists with images gets no padding to text.
  Solution: Adding padding-left to the list element (li).
• Issue: Block elements aren’t centered in Internet Explorer.
  Solution: Make sure to set both side margins to auto and text-align: center.

Note that these are only a handful of the issues that you can come across.

Position is Everything

Apart from Googling answers to CSS issues, I’ve got a favourite site for finding and solving Internet Explorer related problems: Position Is Everything. After a while, you know these issues by hand, but until you do, it’s really a good place to get help before tearing your hair out…

I read today on InsideRIA that the first beta of Flash Catalyst is available for download on Adobe Labs!

I’ve been both sceptical and excited about Catalyst in previous posts, so it’ll be very interesting to try it out for real!
I’ll probably post my initial thoughts on it sometime soon.

EDIT: The Beta 1 of the new Flash Builder (aka Gumbo) is also out. Ryan Stewart posted another blog about the two releases.

Today, I ran into some JavaScript security issues that cost me a few hours too many of my life.

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.

From time to time, discussions pop up on how to optimize your code. “Create your arrays like this”, “define your variables like that” etc. Today I read a blog post by Sean Moore, summarizing a lot of (alleged) performance optimizations in AS3. It contains quite a few incorrect points, but probably serves quite good as a place to find out the truth behind some optimization myths. There are a few interesting comments in the “comments section”…

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).

I’m yet to fully understand the “awesomeness” of using MXML in your Flash/Flex applications. I’ve always written my code in AS (1,2,3) and set up the views by combining AS code with laying them out in the Flash authoring environment. And I have to say that’s worked out well!

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!

EDIT: I’ve posted a presentation about Flex (and MXML).

From time to time, I have a look at various browser statistics to check if there’s been any changes in the usage share of browsers. Even though non-IE browsers take more and more shares on the market, Internet Explorer still rules (with around 70% in average). In some areas, the share is even higher; I worked on a product recently where we had an “IE share” of 97% …

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. )

I came across this post on newbie Flex development for us experienced Flash developers. I think senocular is spot on here; many of the highlights are things I’ve come across myself when fooling around with Flex.

No reason not to keep trying, though!