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 »

A campaign with a good point

Miscellaneous March 23rd, 2009 @ 11:03

Got a link sent to me regarding a campaign aimed to “Bring down IE6“. Let’s hope they accomplish something, because that would make the web development life a lot easier… :-)

Make the first comment

Calculating CSS selectors’ specificity

CSS March 23rd, 2009 @ 11:03

(This is actually old news, but maybe some people out there has missed it.)

Sometimes, developers get confused when it comes to understanding why a certain selector overrides another. I guess the standard ways of solving it is reordering the selectors in the CSS or using ID selectors instead (as they’re well known to override most other selectors). But there’s of course plenty of logic to why certain selectors override others, and the reasons can be found in the official W3C documentation.

It’ll help you a lot in creating a sold and good structure in you CSS documents. Probably a good idea to keep the list bookmarked until you remember the rules, though… :-)

Make the first comment

Jadestone wins Innovation of the Year Award!

Jadestone March 19th, 2009 @ 11:03

A proud moment for us at Jadestone; winners of Gambling Online Magazine’s “Innovation of the Year” Award, with DiceArena – the poker killer! :-D

Make the first comment

Flash Catalyst gives me the creeps

Flash & Flex March 16th, 2009 @ 11:03

Recently we’ve been having general discussions on the workflow in agile development projects. How can we make our development pipelines as effective as possible for our developers and designers? One product trying to address this is Adobe’s Flash Catalyst.

Flash Catalyst aims towards allowing for importing a ready-made Photoshop file with a site design to a workbench, where various functionality can be added easily: new pages, visual effects (transitions) etc. It all sounds really nice, as it makes it easy to convert a design into a real application with functionality.

It’s giving me the creeps

It’s pretty much at this moment I really start getting the creeps. To me, WYSIWYG (“What You See Is What You Get”) editors have never been anything but bad. They’re of course easy-to-use, but generally produce crappy code that infects your application like a virus. The code debt increases exponentially by the minute (OK, maybe I’m exaggerating again…)  and in the end, you’ll lose control of your application.

This might be OK in one-time-development applications such as ads, campaign sites etc, but in our world, we can’t really afford creating our applications from scratch all the time. It’s really important to create good, reusable code in order to stay on top. And from what I’ve seen this far, that is nothing that’s done by using tools like Flash Catalyst (or even Flex?).

It’s important to stay in control

We mostly build large applications with quite advanced features and we need to be able to maintain in control of the code, as the risk of producing nasty bugs increases with the size of your application. If you’re using a UI based tool like Flash Catalyst, it’s very likely that you will have a lot more trouble finding where the issue really is than if you’ve got yourself a well-written code base.

In my opinion – when working with applications like ours’ – the development velocity is not more important than having a well-developed application.

I’m not saying it’s worthless…

As with everything, I can’t really say that it’s crap before we’ve tried it out for real. I just don’t think we’ll be able to rely on it for our bigger games, given what I’ve read and the demos I’ve watched this far. But maybe we can use Flash Catalyst for marketing campaigns (i.e. ads) and smaller prototypes of our applications? That would probably be a more logical way to use it.

Please prove me wrong; it’d be awesome if designers could implement their changes while not ruining my code… ;-)

Some references

Chris Griffith’s thoughts on FC (and some comments on his thoughts)

FC Video Tutorial

Official FC site

4 Comments »

A first glance at GWT

JavaScript March 9th, 2009 @ 15:03

Web applications of today are often required to be quite complex – AJAX offers lots of nifty ways of giving the user a great experience. But developing stable applications using lots of JavaScript code can be quite challenging. Even though there’s help from great libraries such as Prototype, YUI and jQuery, it’s tricky to keep the code bullet-proof and fully tested.
Also, it can be difficult maintaining a decent architecture as the application grows, i.e. how to implement an MVC solution.

There’s of course a few people out there trying to address these issue, one of which being Google Web Toolkit (GWT).
We’ve discussed GWT from time to time, but haven’t really made a true effort of delving into it. I decided to try to find out how it really works and if it’s something for us to use in our applications.

Do we really need it?

I guess the first question you need to ask yourself is if you really need anything like GWT. Is our goal to build a full-feathered AJAX site without any browser reloading of pages? Do we want something with features like Gmail (from dialogues to rich-text editors)?

After researching GWT for a while, my feeling is that you either fully implement it (with effects on server-side and all) or you stick to using “old, self-developed” Javascript code. If you’re to have any kind of client-server communication (which you are), you’ll probably have to make some adjustments on the server-side as well.

Anyway… I tested a sample implementation usin GWT and as a Java fan, I was of course enjoying writing nice, strict Java code with full IDE support instead of regular JavaScript. There was really nothing to complain about when it comes to writing GWT code and it was fairly easy to get started and the compilation was quick enough and provided a nice debugging tool.

Are there any limitations?

My main concern is that using GWT will come with some limitations:

  • What if I don’t what to write the code exactly like it’s done with GWT? Will I have to write all my code using GWT?
  • How painful is it really to mix “regular” Javascript with GWT code (they offer a way of doing it, but it doesn’t seem like something you’d really want to do)?
  • Is it really stable enough for an entire application/game? To be honest, the GWT site itself is actually quite buggy…

One nice feature that comes with GWT is the support for creating modules. It seems quite easy to create a smaller module (perhaps a text-editor) and plug it in to your application. I’d say that doing so would be a first good test of GWT, as it still feels a bit scary to rely on it for an entire application (i.e. creating entire pages, browser history states etc).
Maybe using it for smaller modules the best use of GWT in our case? It would be really nice if server-developers (Java guys) could implement advanced client-side features without being afraid to mess it all up… :-)

To sum it up…

I guess these questions never will be answered unless I/we actually try it out in a real implementation (or at least a real-enough prototype). There’s obviously a whole lot of things with GWT that is really nice, but I wouldn’t feel fully comfortable relying on it as of today. Trying it out in a module or two would probably be the best way to draw some real conclusions.

In the end, it’s all about what you and your product really need.

References

Google Web Toolkit Website

GWT in Practice – Ebook (lots of reading)

Ext GWT Library (great widgets)

Unofficial GWT blog

2 Comments »

Changing page without reloading browser

JavaScript March 6th, 2009 @ 13:03

I wanted to investigate if we can build web applications that doesn’t require reloading of pages in the browser, according to the principles of  Life above the Service Tier.

Evaluation

I started by reading the “Life Above the Service Tier” document, which was a description how it works today (and its flaws) and what the proposed solution is.
Also, I browsed the web for more articles, blog posts and comments on the issue.

Summary

The ideology (called SOFEA: Service-Oriented Front-End Architecture) is basically to put more rendering logic on the client side and only use the server side to transport data back and forth.

The principles of SOFEA could be implemented with help from AJAX. The controller resides on the client-side and is responsible for loading (XML) data and rendering the application using the received data, without actually reloading the page in the browser.
This means that JavaScript would be used instead of HTML/JSP to render the server data. Also, the server-side is much thinner and not really in need of any web framework (as all it does is receive messages and return XML data).

Conclusion

The principles of SOFEA seem very far away from today. There are several flaws with implementing in the suggested manor:

  • The web clients (browsers) of today are not good enough to handle could have problems handling as much logic as a large web site would require (given that old IE versions have so many users, ca 70-85%)
  • The client code (JavaScript) and architecture is not really mature/good enough to handle this much logic, given that it needs to be bullet-proof, easy to test etc (EDIT: unless using GWT or similar – it’s at least difficult to manage)
  • Developing applications would take much more time (hence be more expensive) as more manual labour is required to render content using JavaScript instead of letting the JSP engine do it with JSP/HTML/PHP/etc

Everything points to NOT implementing it in such a manor. At least not at this time, partly because the browser/client market isn’t ready for it.

Is there an other way?

Yes, there are other solutions to the main issue; changing pages without actually reloading the container (browser).

One suggested solution could be an extension to our model in Taikai, where AJAX can be used in combination with both XML, HTML/JSP and JSON, hence giving us the possibility to smoothly serve a full JSP page using AJAX.

A brief description of how it could be solved:

  • Make a JavaScript “controller” handle all URL requests to the server, in order to bind the answer to a certain action.
  • Set up “View XML files” for all views that are to be loaded with AJAX. The view could look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<xmlRoot>
<title>Document title</title>
<styles>
<src>/css/foo.css</src>
<src>/css/bar.css</src>
</styles>
<scripts>
<src>/js/foo.js</src>
<src>/js/bar.js</src>
</scripts>
<content id="targetContainerId">
<![CDATA[<jsp:include file="foo.jsp" />]]>
</content>
</xmlRoot>
  • When returning the response from the server, the returning page would be the pre-defined XML (as per above).
  • The controller parses the contents of the returned XML file and performs its magic:
  1. Changing the document title
  2. Loading new styles and scripts (and possibly unloading old ones to keep the page slim)
  3. Updating the content element (with id=”targetContainerId”) with the provided content, which has been rendered by the JSP engine and therefore taking advantage of its power (i.e. JSTL, HTML tags etc etc).
  4. Updating the browser history using hash (#) technique, allowing for back/forward movement while remaining in the same page container

The main advantages with such a solution would be:

  • Allowing developers to create content using known and powerful formats, such as HTML and JSP
  1. Very important in respect to time efficiency
  2. Still allows for easier debugging and development
  3. No need to put too much logic on the JavaScript side, i.e. creating elements etc (although it could still be done in some components, if needed/wanted)
  • Still providing the user with the quicker experience of a site without (or with few) full page reloads

Remaining questions:

  • Would there be any risk of memory leaks, especially in older Internet Explorer browsers? And is there an easy way of eliminating these?
  • Is the support for “hash history technique” good enough in all major browsers?

References

1 Comment »

Testing the PureMVC framework

Flash & Flex March 6th, 2009 @ 11:03

Objective

Testing the PureMVC framework.

Evaluation

I decided to test using the PureMVC framework in a small application in order to find its pros and cons.

As I had tested setting up the framework once before (in another project), it wasn’t really a big deal installing it and creating my first classes. Also, after having spent a few hours reading the PureMVC documentation and best practices, I already had knowledge on how the system worked.

Result

After completing the application, I’ve found both pros and cons with the implementation of PureMVC.
(Please note that I haven’t taken other pros/cons to consideration here, such as how often the framework is updated, community size etc.)

Pros

  • A clear structure for Models, Views and Controllers – the roles of each part is quite easy to understand and make use of.
  • Good use of Controller part of MVC, which usually is difficult to put in the AS equation. In PureMVC, the Controller is a “Command” instructing the application on what to do next (i.e. to register Proxies/Mediators).
  • Good and clear separation of “true” View and Model via Proxy and Mediator – makes it easier to let the View actually “be a View” and Model “be a Model”. The View component (i.e. an actual MovieClip) is manipulated through the Mediator and the Model (i.e. a data object, such as a Player) is manipulated through a Proxy. This ensures that no logic is misplaced in the View component.
  • Nice being able to access Proxies, Mediators etc through the ApplicationFacade from wherever. Allows for Commands to be quite complicated if needed.

Cons

  • All Mediators, Proxies and Commands are registered using a unique key. Hence, there are some difficulties keeping track of Mediators/Views (“M-V”) that are unique for the Proxy’s data object, i.e. the M-V of a certain “Player” with a certain “id”. Perhaps M-V:s should only be implemented for functionality that will only require a single instance of its type?
  • Could be troublesome to keep track of the dependencies etc in the notification system, although the references can quite easily be searched using an IDE. This is probably an issue no matter which system being used.

Other observations (not necessarily to be considered as either pros or cons)’

  • The PureMVC “pattern” needs to be implemented all the way, meaning that the view (component) cannot contain any functionality to affect the world outside of it. A mediator’s “view component” must be completely isolated.
  • Setting up a new class requires some manual labor (as some classes needs to be extended/interfaces implemented), i.e. specifying which events to listen to and how it affects the class

What do I need to know to get started?

It takes a little effort to learn the system and understand what its parts do; i.e. what a Mediator is and how it correlates to the actual View. But once you understand the system, it’s really easy to create new classes for your application.

A few vital things that need to be understood before using PureMVC (I’ll try to sum it up, but the official docs are recommended):

  • What are Notifications? All Mediators, Proxies and Commands listen to notifications specified by the user. If a certain Mediator should display a message at a certain time, it will listen for a notification of that type.
  • What the Mediator is and why it’s being used: it’s basically a layer to the actual View (MovieClip), handling all functionality related to the other parts of the application (i.e. outside of the View)
  • What the Proxy is and why it’s being used: works in the same way as a Mediator, but in a more simpler way. Manipulates the “true” model object, which could be a domain object such as a “Player” or “Table” in a card game application.
  • Where is the Controller? The controller is implemented as a Command, meaning that it’s invoked when a certain notification is sent. Once invoked, it has no function until the notification is sent again.

Conclusion

In my point of view, PureMVC is a good framework to use for MVC applications. It can get a bit complex with boilerplate code, though.

References

Make the first comment