Google Analytics setVar() deprecated and replaced by setCustomVar()

Other December 7th, 2009 @ 15:12

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>

Make the first comment

The one essential Agile ingredient

Other November 8th, 2009 @ 13:11

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.

Make the first comment

10 useful usability findings and guidelines

Other September 24th, 2009 @ 11:09

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!

Make the first comment

Premature optimization is the root of all evil

Other April 24th, 2009 @ 10:04

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

Make the first comment

Optimizing the development process

Other March 23rd, 2009 @ 15:03

I’m currently working with some research on how to create an optimized development process with between Artists <-> UI designers <-> Developers. This will be an ongoing discussion and evaluation process, but I’ve come to some conclusions this far.

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.

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

2 Comments »