Dojo templates & Google Maps InfoWindow

I have been building mashups using Google Maps since 2007 and one problem I had is passing in the content for these bubbles that show up when you click on a marker i.e. the InfoWindow. One big annoyance with it, is that you have to pass in the HTML content as a string when opening the marker. I don’t like it because I have to intertwine HTML inside of JavaScript. So how can we make this better?

Dojo Templates

Dojo Templates is the number one reason I love this library, I like the PubSub mechanism I posted about last time but not as much as the templates.

Dojo Templates allow you to associate HTML template files with your widgets, that get instantiated when Dojo parses your page and constructs the widget, basically replacing the references to your widgets with the widget’s markup in the HTML template file.

First: my infowindow.html template file

<div class="infoWindowContainer" dojoattachpoint="infoWindow">
       <h1>${title}</h1>
</div>

Don’t worry about that ${title} thing just yet, but I guess you already can see where I am going with this.

Second: my infowindow.js widget

dojo.declare(
 "nael.widgets.infowindow",
 [dijit._Widget, dijit._Templated],
 {
  templatePath: new dojo.moduleUrl('nael.templates', 'infowindow.html'),
  constructor: function(){

  }
 }
);

In this example, my infowindow widget’s constructor is empty.

Next we create the marker. Here we using dojo.forEach to loop over all the points that were returned with our AJAX response to fetch points. this.map is the object within this map controller that references the Google Map. (This is the same controller from the previous post on Dojo PubSub mechanism)

dojo.forEach(pois, dojo.hitch(this, function(p){
  var marker = new google.maps.Marker({
          position: new google.maps.LatLng(p.lat, p.lng),
   map: this.map
        });
  var content = "<div class='infoWindow' dojoType='nael.widgets.infowindow' title='"+p.Pois.name+"'>

" ;
  this.addInfoWindowToMarker(marker,content);
}));

The important part is the line where we add the content. Yes, we still need markup in there, but now its just a placeholder for the real markup. We can pass attributes like title into the placeholder for nael.widgets.infowindow. So anything that you want displayed in the info window becomes an attribute. This allows you to focus on content, and not worry about presentation just yet.

The last method we call addInfoWindowToMarker creates a Google maps listener on the marker and connects the info window to it. Note, that the info window here, is not the widget we created in the beginning. The one at the top is “nael’s infowindow” and only serves the purpose of templating.

addInfoWindowToMarker: function(marker,content){
 google.maps.event.addListener(marker, 'click', dojo.hitch(this, function(){
      this.infoWindow.content = content;
      this.infoWindow.maxWidth = 300;
      this.infoWindow.open(this.map, marker);
 }));
}

If you try the above, and click on the marker, the content will still be empty. Because this is a widget, it needs to be constructed. You need to tell Dojo when to parse the DOM to look for new widgets that you introduced since the last parse.

google.maps.event.addListener(this.infoWindow, "domready", dojo.hitch(this, function(){
 dojo.parser.parse(this.mapCanvasNode.id);
}));

We don’t want Dojo to go looking through the whole DOM for new widgets, we know where the widget was added. So we can just tell Dojo to look for widgets within the div referenced by the HTML id this.mapCanvasNode.id)

Finally, back to our infowindow.html template:

<div class="infoWindowContainer" dojoattachpoint="infoWindow">
       <h1>${title}</h1>
</div>

We can now adjust the template as we please without trouble, and this sure is much cleaner than doing this like I used to for years.

var content = "<div class='infoWindowContainer'>";
content += "<h1>" + title + "</h1>";
content += "</div>";

Maybe one day Google Maps will support templating the HTML for InfoWindows internally, until then, I’m sticking to the above when I can.

The benefit of templating the InfoWindow becomes obvious when you are dealing with complex InfoWindows with functionality built into it such as sharing on social networks, embedded videos, AJAX requests, pictures, etc. All that stuff can be templated, and only the dynamic stuff that comes from the backend is passed through.

Of course, on top of being able to template your InfoWindow markup, it is much easier now to replace an InfoWindow with a version 2.0 of the InfoWindow. You just have to drop in the new and improved widget and template, then abide by the Pub Sub channels you have defined between the widget and the rest of the application.

Posted in front end architecture, Google Maps, how to, web apps | 1 Comment

Dojo How To: Publish / Subscribe

I haven’t been using Dojo for a very long time, just over a year now, but its time I blog about all the little great features I have learned.

One of the features I like the most in Dojo is the Publish / Subscribe mechanism. Its flexibility allows you to cleanly implement communication between different components like modules, widgets, portlets, etc.

Lets get down to business. Say I have two controllers, a map controller, and the main app controller. The map controller owns the map object in my application, in this case a Google Map object. The app controller owns the communication with the user, browser, AJAX, etc. When my app loads, I want the map to go right to the user’s location. The map doesn’t care where I get the coordinates from, it just needs the coordinates.

startup: function(){
//some other startup code
//subscribe to the event we will get back from the app when coordinates are available dojo.subscribe("nael.controller.app.currentPosition", this, this.eventHandlers.updateMapCenter);
//when Im done starting up, yell to the app controller saying Im ready for coordinates dojo.publish("nael.controller.app.requests",["getBrowserCoordinates"]);},

So the map widget will initialize the Google Map I’m using, do some other stuff, and when it is done it will publish to the app controller’s “nael.controller.app.requests” channel. The message it sends to the channel is an array of arguments. In this case it is the request ["getBrowserCoordinates"]. Your channel names can be anything, I just use the Dojo module path to that widget and end with a good description of the channel, i.e. “requests”

On to the app controller:

The startup function of the widget just subscribes to the required channels

startup: function(){ dojo.subscribe("nael.controller.app.requests",this,this.eventListener);},

One event listener for the “nael.controller.app.requests” channel. Notice that the listener just passes it to the appropriate event handler, the one we passed in to the channel.

eventListener: function(event){
this.eventHandlers[event]();
 },

Finally, the eventHandlers object which will contain all our actual event handlers. Here we have the “getBrowserCoordinates” handler which was the argument ["getBrowserCoordinates"]the map passed into the channel.

 eventHandlers:{ getBrowserCoordinates: function(){
if(navigator.geolocation){
navigator.geolocation.getCurrentPosition(function(position){
var coords = {lng:position.coords.longitude, lat:position.coords.latitude};

dojo.publish("nael.controller.app.currentPosition",[coords]);

} ); } },

Once the app controller receives the coordinates from the browser’s geo location API, it publishes the coordinates to the “nael.controller.app.currentPosition” channel – which the map widget has subscribed to during its startup step. When the map receives that event, it tells the Google Map to re-center around the new point.

I’m doing it this way, to reduce the number of channels each module needs to listen to. I can easily bring the browser to its knees if I have a unique channel for each event I’m thinking of raising. Remember, kitchens get dirty one dish at a time. It makes sense to have one “requests” channel for the main app controller, (or every widget as a matter of fact) that all other components can just send requests to.

You may ask why I have a specific channel for the current position? I guess I could have done it similarly to the requests channel. However, I figured that all widgets will be asking the app controller for stuff, while not all widgets would need to know about the user’s current position. If we have a “responses” channel that all widgets subscribed to, it could lead to a lot of unnecessary chatter amongst the widgets and too many event listeners. The second reason, is that the current position channel, may get pretty noisy if it is a mobile browser. Couple both reasons together, and you have a recipe for disaster

So why should you care about JavaScript Publish / Subscribe?

The same reason you would care about it for other technologies. Its a better and much more powerful interface between JavaScript modules. Without these channels and event listeners, you would have just called the getBrowserCoordinates method from the map, or worse, you would have called the GeoLocation API straight from the map. You don’t have to use Dojo for this, other libraries also provide you with a pub sub mechanism, like YUI EventTarget. Other JavaScript libraries have it, or have plugins for it. Its a design pattern that makes sense.

Note: if you are still not using a JavaScript library for your web app development, you should seriously reconsider because you are wasting a lot of time re-inventing wheels and light bulbs.

Another example, say you need to add a new widget, instead of trying to figure out where you are all the right places to call a method in this widget from another, you just add the widget and subscribe to the event that is triggered. Change request done.

One final reason, Publish / Subscribe is an excellent way to build a mockup of application workflow. You can stub in some datsabase data and when the backend is ready, you just replace the stub module with the one that will listen to the right request channel, and publish to the right response channel. And as an added bonus, if you screw up the channels, nothing breaks, the messages just won’t get passed and you won’t see browser errors when functions aren’t defined. It fails gracefully – which is important.

Posted in dojo, front end architecture, how to, web apps | 1 Comment

John Underkoffler points to the future of UI

I caught this video by John Underkoffler – the science advisor for the movie Minority Report on TED the other day and it got me thinking about web interfaces, especially for online banking such as CIBC’s and online billing such as Roger’s. I’m not saying we need interfaces such as this for these kind of online applications, but we are surely due for a major overhaul of these interfaces. I sure hope we don’t need movies about these before they become more mainstream.

Is technology capable of improving the interfaces for online banking/billing sites?


Hell yes! The customers just need to demand that. We have been stuck in this e-statement model for far too long. Technology isn’t the hold up. We have had these brilliant interfaces in the wild for a while now. Consider Mint. That 15 person team was so successful they were even purchased by accounting software maker Intuit in 2009. So it is not technology that is limiting us, Mint did it and clearly they don’t have as much resources as the banks or telecoms do. So what is the hold up?

Its a monopoly on my data

Consider the analyst who goes through some sort of overview of customer spending habits to figure out new plans or services to offer to these customers. Do they get a dump of the data? Probably not, you can’t make sense of it. For these analysts to be able to see spending habits to justify new services they probably get to see some sort of visual, a chart, a graph, something. Human minds are visual, we are pretty good at spotting things if they are in a picture, not so good at spotting the one line in a contract that will
rip you a new one
cause you trouble in the future; that is why there are lawyers. Instead of dazzling me with loading icons please start focusing on delivering a little more value. I think as much right these analysts have to study my data to justify future products and services, I too have a right to my data to make sense of my spending habits. Here’s a thought, I would happily pay $6 a month for that, instead of $6 a month for call display – which by the way probably requires you to do work to DISABLE. Why do we let these people reach into our pockets without providing anything of real value to us? Would you buy a car from a dealer who asks for more money to enable the 3rd gear? or charges you per minute per kilometer driving on an out of province highway? or you pay a service charge for filling up with a different grade gas?

Who would want this kind of stuff anyway?

Gen Y grew up in the Internet age, they expect this stuff to be the norm. Its only a matter of time before it becomes the norm so why fight it? I have been using Wesabe to make sense of my banking statements up until they posted a shut down notice. I didn’t mind the hassle of exporting my statement and importing it in every month to see these beautiful spending charts. The tagging feature even allowed me to track my spending on smokes by making me more disciplined at buying my smokes from the same 2 places so that I could tag my spending at these 2 grocery stores as “smokes”.

As much as I’d love to manipulate my phone bill in 3D space, I will be extremely happy if my interaction with it becomes more 2010, instead of 1997. All I’m asking at this point is for 3 fairly simple, yet significant improvements:

  1. The ability to tag transactions, and to view my statement by tag for both billing & banking. Rogers already allows me to tag numbers, so you are halfway there!.
  2. View tags as a pie chart -or any other visual- for both billing and banking
  3. For banking, graph my “income” against “expenses”, month to month, year over year.

Simple? Can you do it for 2010? And then if you agree that these add value to your customer, then how about you replicate Wesabe for 2011?

Minority Report science adviser and inventor John Underkoffler demos g-speak — the real-life version of the film’s eye-popping, tai chi-meets-cyberspace computer interface. Is this how tomorrow’s computers will be controlled?

Posted in TED videos, thinking out loud, usability | Leave a comment

Sir Ken Robinson is a brilliant speaker, thinker and evangelist.

Posted in online marketing, TED videos, thinking out loud | Leave a comment

the intersection of business and technology

Technology is useless if it does not deliver business value. Either it saves me time and hence money, or it makes me money. It has to be one or the other. Where does front end architecture fit in this picture? As the title points out, its right in the middle.

The front end is a misunderstood piece of any application, it is usually overlooked, underestimated, and belittled. Its fairly common to perceive it as “toying” around, “no/low value”, etc. Its also very easy to believe that all the stuff that happens at the backend is the stuff that commands the big bucks. Unless you develop low level software such as compilers, web servers, drivers, etc. here is why you are wrong, and why front end architecture matters.

You can’t deliver “customer focused solutions” if you belittle the front end

Successful front end architecture means focusing on what is important for the end user, not you the developer, nor you the SQL ninja, and not even you the business SME.
I don’t know how this upside down tradition started, but I might have an idea. Application development usually starts with the back end framework, you know the Springs, and the Djangos, the Struts, and the Zends. None of these deliver any value to the user, they do add value to the delivery team and make them -in a perfect world- deliver better code, faster. So how did this tradition start? (One that focused on starting in an area that couldn’t be any farther from the end user) My reasoning is that it started with equating building end user software with constructing a building. The first step of doing that, is to lay the foundation, the stuff that will carry all the weight of the rebar, steel, concrete, pillars, roof, and all the occupants and their equipment. All this stuff is as far away from the occupants of the building as possible, but it is by far more important than whether the doors open in or out. The occupants of a building are first concerned about their safety, a “customer focused solution” in the construction industry is one that is first safe for its occupants. Everything else comes later. However, when we use this analogy to building end-user software, we start out right off the bat focusing on the wrong things. A customer focused solution starts with the end user, what will he be interacting with, and then works backwards to define the solution that is required to support that end user.

You can’t slap an interface on it

Okay, you can, but you shouldn’t. Can you slap a steering wheel in the backseat of the car? Sure you can. Should you? probably not. Why is the steering wheel in the front? because the end user needs to see the road. Start with the end user and work backwards to the solution. A more accurate statement is actually “slapping a back end on it”, or “wiring the back end to the front end”. That you can do. Why? Because at that point you know what the user wants, and you know how your front end will achieve it.

Another reason why not to do this, is if you care about your users’ experience, you would spend more time thinking through the front end, iterating and making it better. Forget the focus groups. Forget the design committees. Empower qualified, creative, and responsible people to make usability decisions. Have real users developers use your application, and keep your mouth shut. Don’t show them how to use it, or what they’re doing wrong. Observe, take notes, and make it better. Focus groups could just make you chase your own tail, as what happened with New Coke.

Phasing in features

Good back end frameworks and architecture allow you to phase in functionality as you progress in the project. A good front end architecture needs and should do the same. This means, just like a good back end does, a good front end must utilize a common framework. Today, not much focus is given to the front end. In fact it is assumed it can be completed 100% with a “big bang” approach. We don’t use a “big bang” approach with the back end, why do you do it on the front end? Because you tried to slap an interface on it…

Front end components need to be thoughtfully designed, with re-use and phase-in in mind. Don’t attempt a one-size-fits-all approach to these components. It might make for less development, but if your focus is “customer focused solutions” then you need to account for different use cases and different user types/roles. Also, just like back end components get re-factored when duplications occur, so must front end components. Why the double standard? because the front end gets belittled.

More data is better data

Yes, your gut can have a lot of say when it comes to the front end. However sometimes the change has no affect on your gut. Does it matter if your links are underlined? or are you just doing it because [insert your favorite reason here, ex. because my dog wags its tail when it sees underlined hyperlinks] Design your front end to be able to gather these usage patterns, because “customer-focused solutions” support their decisions on customers’ actions. Don’t even ask your customer whether they like A or B better, keep your mouth shut and observe. Do they use your application more? better? quicker? when A is there? or when B is there?

At the intersection of business and technology lies the role of the Front End Architect (FA). This person should be empowered and trusted to make front end architectural decisions based on supporting data that will deliver value to the end user. The FA, is not a business SME, they’re not a designer, but they could be. They are a technical person, a developer with the scars to prove it. They work with the business to figure out how to deliver this end-user value. The FA also works with designers to iron out any usability issues that may affect the end-user value and can be fixed via enhancing the look and feel. They also work with the rest of the developers to keep front end components re-usable, and phase in friendly.

Do you have an FA on your project/in your organization?

Posted in Software, thinking out loud, web apps | Leave a comment

On selling customer experiences

I was looking at how much of a dent an iPad will put in my wallet when I noticed the mandatory field reminder on Apple.com’s shopping cart. Then I came to this realization, Apple isn’t a mobile device’s company, nor a computer company, its a customer experience company. So much time is spent on just tweaking and perfecting the whole cycle. From the moment you browse their online store or their mortar-and-brick store, to the point you make your purchase, including the point when you receive your product, unwrap it – perhaps even record that joyous moment – and then finally start using it and then officially become a fan boy or girl. This happened to me in 2003/2004 when I purchased my first Mac, a PPC PowerBook G4.

Sorry, I went on a tangent there. Anyway, they are a customer experience company. The developers who built this form did not have to do it the way they did. This sick tooltip reminding you of the mandatory fields could just have been a red asterisk. However, because they are a customer experience company, they didn’t do what every average Jack and Jill developer would have. As simple a page it is – a personal info page – it most definitely went through multiple iterations before it reached its current state.
Another example, lets say you don’t look like a pirate but have a speech impediment. I’m a nice guy. If you seem like a nice person too, I’m going to do my best to understand you. However, that doesn’t apply to your website or application. Don’t make your product seem like it has a speech impediment – even if it looks great. Its just going to be awkward.
Learn from Apple guys, they don’t have to do their site the way they do, they don’t have to finnish their products the way they do, they don’t have to meticulously design the packaging inside and out. But they do. And because they do, they’re in the business of selling customer experiences. That is a very profitable business, and that is why Apple’s stock P/E is twice that of Microsoft’s.
Here’s a great TED talk on “People don’t buy what you do, they buy WHY you do it”:

Posted in Apple, TED videos | Leave a comment

Chefs, Curators, & Developers

Besides that these people all eat, sleep, and lineup for the latest iStuff, developers ought to have another thing in common with chefs and curators. I would say software development is part engineering/science and part creativity, even as high 50/50 or maybe a little more.

Curators

The term “custodian of a collection” doesn’t describe what curators really do. It almost makes it sound as if they just take care of a collection, but not necessarily care for it. A museum without a curator simply turns into a warehouse. It is the curators job to prevent that from happening. To care for the collection and keep an eye at the big picture.

Every piece, big or small, serves a purpose and delivers an essential part of the experience. The opposite of a curator is a hoarder.

Chefs

Similarly the chef does not just cook the food, they keep an eye on how the items on their menu works together, how the dishes enhance the experience, and how every ingredient in a dish works with the other ingredients. Every detail counts, and great head chefs will look after it all. They are food curators.
Musuems, food, and software is made better by what has been left out – purposely – and not what’s included.

How do they do it?

Great museums don’t happen overnight, they happen over time, time spent doing the same thing – improving the museum. The task is never done. It’s iterative, and perpetual. Curators aren’t afraid of tossing things out because they don’t work, or something better came along. Curators are careful not to hoard shit, even if it’s all good shit. They don’t go about it alone, they get feedback from other curators, from their clients, and finally their gut & others’ guts. Your unconscious brain has a lot to do with this task, sometimes it is hard to explain, but often your gut is on target.

Lessons from Chef Ramsay

The number one thing Gordon does to fix a failing restaurant is “cut the crap” – after he is done ripping through the owners of course. If you watch the show, you probably have seen him throw out half the menu – if not all of it in some cases. Take the episode of the “Curry Lounge”, tons

of curry based dishes. None of the waiters guessed what any dish was during the blind fold taste test – except for the french fries; at an authentic Indian restaurant. Chef Ramsay tweaks and iterates over the food, how it’s made and served over the course of the week. That’s his formula. That is why he is a great head chef.

Don’t be scared of “No”

There are many good reasons for saying “No”. There are also wrong times to say “No”. Say you are at a restaurant, and you ask the chef to skip the pistachio on your baked chicken because of allergies. That is a valid request you cannot say “No” to. On the other hand, don’t be surprised if the chef says “No” while at an authentic Italian pizzeria and ask for extra cheese on your Pizza Terreno – he knows better than you. A good way to say “No” is to always provide reasons and alternatives. Most clients will consider alternatives, after all they are paying you to provide the best possible service you can afford them. Sadly, you don’t always win, or you are just wrong and you lose the battle and have to provide exactly what you have been asked.

“But that is not how we do things around here”

There is always room for improvement, and there is always areas and times where you can play the role of the curator at what you do. Always start with the things you control. What if you work at a hypothetical restaurant that followed the Waterfall model? retarded right? but at every point in the process a curator could help, and a curator can make the experience better – even a little. This Waterfall restaurant basically takes orders at 5pm, by the time they are validated and cooking starts at 8pm. Then the dishes get checked, fixed and reheated. Food starts to come out at midnight. And into the wee hours of the morning the cooks have gone mad trying to

figure out what was ordered eight hours ago. Every single role in this kitchen can play the curator in what they are doing. As badly suited the experience is, it’s much worse if everybody minds their own business and blindly follow the blind.

Kitchens get dirty one dish at a time

“Too many chefs spoil the soup” True, and applies everywhere. Why else do the Marines and special commandos operate in small, tightly knit groups? Do you seriously believe that anything will need an army of develop
ers yet the army elites can perform heroic missions with a team of 15?
Don’t let your kitchen get dirty, it’s easy to say you will do it later, but know that your effort to clean it does not have a linear relationship with how long you left it dirty.

Everybody can be a curator

Whatever business you are in, you are involved in curating and improving the product/service you provide. Whether you design buildings, write software, an author, or a sales guy, a president, or an army general. We all do it. We all know that the first draft of an essay is always the worst. When you walk into a board room to make a pitch, how many times do you revise and tweak that slide deck? how many times do you do it the night before? or even 30 minutes prior? We all do it.
So here is the big question, when did we say that code should be written once and done with? What tends to happen with development teams is this task is not performed as often as it should – specially as the team size grows. It gets worse when dates start to slip, as things like continuous improvement and cleaning up the kitchen are ditched. Here is the other problem, managers, executives, planners, etc. don’t like to see tasks that don’t have end dates on the plan. They want to know things like effort spent, time elapsed and percentages for each. An iterative task only has elapsed time, but nothing to identify how much is left because it’s never complete. The affects of this curating task are phenomenal. Almost always you will be amazed by how little you changed or even better removed and how substantial the improvement was.

Making something better is never easy

…but the harder the decision, the better shape that thing is. To be successful at being a curator you really need to understand what your customer wants. Not just a little, you need to get in their head and figure shit out. You need to figure out how you can add value, or if you just can’t. Value add is highly dependent on the context. If I am in a rush, fast food will be the best value for me at that time. I’m hungry, and need a quick solution. On the other hand, you wouldn’t take your wife there on your 10th anniversary. The best way to bring yourself to a point where you can understand how you can add value, is by aiming for the simplicity on the other side of complexity. If you are looking for a good healthy relationship, you need to invest the time up front, you need to climb that complexity hill, sometimes it’s steep, sometimes it’s long, but rest assured it will flatten out after the peak. Thats where you want to be. Not many people make it to the other side, most will be hanging around at the base or on the way up. That region is highly competitive. The elite don’t hang out there. Take Apple for example. We can consider Apple to be one of the elites of the tech industry – almost like they have the Midas touch. People have tried to replicate the iPod with little success. This week, slowly but surely Apple wrestled the 2nd highest market cap from Microsoft – without even dominating the market. They know their customers, and they don’t even want everyone to be their customer.
Everything looks great on paper, it’s not until it comes to life you start spotting glitches and things to improve. Good restaurants will shutdown for a day occasionally and just cook the whole menu and their staff will critique everything and make adjustments. Iteration is key. In school you are taught to review your essays, read them out loud, tweak and adjust the paragraphs, shuffle things around, all of this to find the essence and flow of what it is you are trying to accomplish.

There are only two kinds of developers.

Those that just get shit done – literally -, and those that will get it done very well. From a time line point of view, you won’t be able to tell the difference. They both finish on time, and their stuff will work. However, the first, don’t care about what it is they are building, don’t care about who they are building it with, they put in their hours, get paid and that is it. Excellent developers don’t have to be geniuses or come with Masters & Phds. These are the ones that want to be proud of what it is they are building. They are the ones that think several steps ahead, and design for change. They will embrace change if it makes what they are building better. They will try to resist change that adds no value. They are the ones that keep an eye on the big picture. Those are the ones that will invest the extra time to re-factor the redundant classes they spotted. They are the ones that experiment and try stuff out because they are always on the look out for a better option. They are the ones that will tell you “No, you shouldn’t do that”. That is how you separate the two. An excellent developer will wave his hands and yell when something is just not right. The first kind will shrug their shoulders and pile on the dishes.

Posted in thinking out loud | Leave a comment

The Mythical Man-Month

I think it was in first year software engineering that we had to read this book, and nine years later I really, really understand the underlying purpose of this book. It may just be yet another book back then, but the lessons that are hopefully learned from it will last a life-time – not just for software projects, but any project.

The Mythical Man-Month

Unfortunately on software project plans, developers, designers, testers, business analysts, product managers, etc. etc. are considered “just another resource” that are added and removed off of tasks. The assumption is that all are equally effective and skilled in all the required domains, and all will produce the same volume and quality. So in a perfect world it makes sense to scale the team to meet deadlines, although we don’t live in a perfect and linear world, this is still the method of choice. Even though the biggest effect of this method; drastically increased non-linear communication time is widely known but mostly ignored.

Sadly this is the state of this industry, project plans that are too often disconnected from reality. I think part of the problem is driven by dividing tasks into a unit of time, after all that is how budgets are built, teams are put together, and progress is tracked. However on the other hand, this unit of time does not measure the real size of the task. Its just an illusion. Its like a building, we don’t measure building size in number of months it took to build, we measure it by number of floors or in meters i.e. something relevant and real. If a 40 meter building was estimated to take 12 months, and in 6 months we are at 10 meters, then we are 25% done, and not 50%. However if this building were a software project its assumed we are 50% complete. Then at 10 months we realize we won’t meet the deadline, forget about the Mythical Man Month and scale up. Why did this happen? Because software does not have a realistic metric, software is abstract.
Some say you get better at estimating over time, but that too assumes we live in a linear world. Ex. Project X took us 3 months, so we will estimate that project Y will take 9 months. We don’t live in a linear world, and humans aren’t good at estimating non-linear stuff. We may think that the second project is 3x as long as the first, but it could be x^2. However the hope is that over time you can make a non-linear project more linear by improving the processes for the non linear components. That effort is also non linear.
You can try to measure by team size, effort, or lines of code, etc. but all are just an illusion of measurement, none are real. Whether you measure buildings by floors or meters, you can translate between both. On the other hand, you can’t translate lines of code into time, effort or team size.
I don’t know what a better alternative is, but surely it is not this. Perhaps the problem is just trying to estimate that far into the future with too many unknown variables. Feel free to comment.
I recently read the book “ReWork” by the guys at 37Signals and one paragraph I absolutely loved has to do with project estimation.

The book is a must read.

Posted in Software, thinking out loud | Leave a comment

Crash ‘n’ Burn: The 11th hour for Flash

Adobe’s rhetoric continues after the curve ball Apple threw. The whining continues with this post: On Adobe, Flash CS5 and iPhone Applications.
Sadly, the whining doesn’t change anything, and Adobe’s argument would have been more valid if they didn’t trying to lock developers into Flash/Flex and if it -Flash- were really open. Also, I think Adobe’s Flash/Flex tools favor developing using Cold Fusion on the server side… you can use other server-side technologies however I believe the tools “play” better with Cold Fusion.
Apple’s decision makes 100% business sense to me. They’re advocating for their own platform, or open standards. Just like Adobe advocates for their own platforms, or open standards. What’s wrong with that?
Flash filled a void in the 90s, but where is that void today? Is it even still needed? Yes its far superior technology, but its a closed technology. And to think that Android will succeed because it has Flash is just absurd. Android could be the iPhone’s real challenger ONLY because it is open. The above post also seems to confuse “open” with “cross-platform”. They’re very different. Flash is cross-platform because its not open.
Flash needs something different right now, we don’t need Flash to deliver rich content online anymore. We don’t need flash to deliver sexy fonts. We don’t need Flash to scroll and fade text. Soon we won’t need Flash to play video – my Youtube embed below is still in Flash- . We don’t need navigation built in Flash. So much stuff we needed Flash for (right or wrong) , that are just not needed today.
On to Flex, Flash’s younger cousin. We – the majority – don’t need that as well. Slowly but surely applications will move to the web. They may have some Flash components that could now just be as easily done in HTML5 or even HTML and some nifty JavaScript. Where I can see Flex fitting, is for these extremely specialized software, such as CAD or medical imaging. Such software is expensive and time-consuming to write, and would be a pain to translate into different operating systems. Such software also comes with heavy visualization, so its a good fit with Flash. Maybe thats where Flash will head, who knows? But there is definitely hardly any room today for Flash on the web.
This song is dedicated to Adobe Flash, I don’t know who your savior will be, but you really need one right now…bad.

Posted in Apple, iPhone, Software, thinking out loud, web apps | Leave a comment

How to throw usability out the window – Part 1

Sometime between when I paid my Rogers bill last month, and when I tried to look it up this month, the Rogers site was “upgraded” to portal. I’m not sure what it used to be before, but I think now it sits squats on top of the BEA Weblogic portal – now owned by Oracle.

Note: This is only part I, the Rogers Portal went offline while I am writing this. To be continued when its live again…

The Loading Dial Syndrome

Who hasn’t seen one before? its a great little technique to let the user know something may take some time to come up – note the keyword is “something” not “time”. If in your site’s case “something” is replaced by “everything” then something is definitely wrong. Sometimes you just can’t make things any faster, especially today when portals by nature provide seamless integration between different internal and external applications. At some point, its just out of your control. However, if your site suffers from the Loading Dial Syndrome you are definitely doing it wrong, and its just not out of your control.

By the way, when the loading dial in the middle disappears – after a minute or so-, nothing actually loads. I end up with all this blank space in the middle of my screen. Obviously a bug of some sort, but hey I’m trying to pay my bills here, not QA your application. For the record I wouldn’t mind doing it if it was optional (i.e. I choose to jump to the Beta version) plus I receive a reduced bill.

Navigation

So after going to the “Bills & Payments” tab I see a list of my previous bills and I can dive into any of them by clicking the “Bill” link next to each. I then see the screen below:


Whats the problem? How do I go back to seeing all my bills again? I can’t even click on the same tab again. The only way I found is to click on another tab, and then click back on to “Bills & Payments” and then the view is reset to the initial state. Almost like driving a car that can’t be put into reverse.

The other thing about this screen, is that effort was spent on meaningless details, such as the red dropdowns with the white gradient background.

The thing about usability is that when you get too deep into something, you miss these obvious issues. I’m sure they looked like non-issues during develeopment, but take a step back and Don’t Make Me Think. Sure, there’s rounded corners, pretty shadows and loading dials, but none of that will make me login more often if its too darn slow. Now I have two things to dread about the end of the month, finding out how much $ I am about to spend, and trying to use this PoC. – and that doesn’t stand for Proof of Concept.

Posted in usability, web apps | Leave a comment