Archive for July, 2009

The business of wire-framing

July 17, 2009
With emergence of web 2.0 everything is going online. Websites are no longer small partly usable entities but have grown in to become full fledged applications. With this the scope and expectation of a web application have risen dramatically over past 2 years. Everybody want’s an intelligent good looking and robust application developed quickly and in budget. But how good does it go when we get real?

If you want a web-application to be developed or are a developing one it is extremely important to look at the process that you are following. Some rough requirement document, some inputs from the technical team and some rough ideas? Why do you think so many software projects fail or lose track and overshoot time and effort estimation?

This incorrect estimation comes due to lack of clarity of the requirement and the process. Isn’t there a clear disconnect between your ideas and the person who is implementing them? How do you bridge the gap? The answers is WIREFRAMES

So, what is a wire-frame:

A wire-frame is a pictorial representation of data (and not design) of your application.  Creating a wire frame is normally an iterative process which involves some Business intelligence, Product technical know how and a usability analyst to come together. It could be a PPT or there are several tools available like Omnigraffle, Axure, MockupScreens or for that matter open office draw. It is like they say, always write an algorithm before you write an implementation. Wireframes bring an application flowchart and work flow algorithms to an easily understandable level.

In the first iteration ideally you would want the person who understands the business to roughly sketch his ideas on a piece of paper. As an iteration a Usability Analyst armed with the technical know how and behavioral aspects of a web application can start mapping them onto a wireframe.

Wire frame is not how your application but what it contains and some part of how it behaves.

 The 3 major advantages which impact everything from time to cost and success of the project are:

1) Wireframes increase the clarity about the application that you are getting developed or developing. If  there are any uncertainties or challenges they can be handled right at the beginning. The picture becomes more clear on every single piece of information that the system will get in or display. You do not want to create something you cannot sell, right?

2) Better estimation of cost and time: No doubt creating a wireframe would bring in its overhead on cost and time. But if you look at the overall picture it simplifies things for a developer/technical architect to such an extent that they can virtually see what they want. Also a  designer can create the views with better understanding and focus.

3) Project management: As the application grows and comes closer to being realized that’s when you can expect some major surprises. A wire-frame coupled with an iterative release process will ensure that you get what you expect

It is again not necessary that you stick to the wire frame as is. While the application gets developed there will be challenges and constraints however the magnitude of problem and the time taken to get over them will reduce drastically

I think in a nutshell. No wireframes there is a very little chance of you getting a quality product in time.


A sample wireframe:

A Sample Wireframe build with powerpoint

BlazeDS + IE+ HTTPS issue

July 14, 2009

Problem:  While using blazeDS content is not transferred over HTTPS this may be because of a firewall or a reverse proxy like web-seal in deployment.

So if you have blocked the port 80 on server you will notice that application gets loaded but calls are throwing a ChannelFaultEvent.


The request coming in from client over https hits the firewall which should be the endpoint URL and because of this the server side(firewall) should fire the request on the non-secure/HTTP port of BlazeDS server.


The configuration of the channel should look something like

<channel-definition id=”secure-amf” class=”mx.messaging.channels.SecureAMFChannel“>
   <endpoint url=” {contextRoot}/messagebroker/amf” class=”flex.messaging.endpoints.AMFEndpoint“/>
</ properties>
</ channel-definition>

 Notice the client uses a secure channel and the server uses an insecure endpoint



%d bloggers like this: