LavaBlast Software Blog

Help your franchise business get to the next level.
AddThis Feed Button

Free charting for ASP.NET

clock November 18, 2007 23:15 by author EtienneT


Last week I stumbled upon this article by accident: Charts And Graphs: Modern Solutions. This article offers a really good overview of the web-based charting solutions on the market. There are a lot more products available on the market, but what interested me the most in this article were the FREE solutions (as in beer)! My cheap entrepreneur spirit compelled me to check the free solutions. I was really surprised to find that one of them had a Free Charting ASP.NET library.


Open Flash Chart

Open Flash Chart was the first one that got my attention because it had a Google Analytics look. Open Flash Chart uses a Flash-based engine and downloads a separate file to know what to display. This file contains both the data and the appearance of the graph.

On the main page of the project, there is no mention of the existence of a .NET library to use this project. However, in the latest release (1.9.5) two guys made a library that can be used in an ASP.NET project! I downloaded the latest version and began to play with the project. I must say that the library is promising, but there are lots of problems. I fixed some of them and I intend to submit my changes to the team.

A simple example

I decided to try the solution a little bit with some data from our data warehouse. I used SubSonic to query the data since I can't live without it! As there is no data binding in the library, you have to do this work by yourself but it should be pretty easy to add this functionality to the library.

The first step is to have an *.aspx page displaying a custom control:

<graph:Chart ID="chart" Width="100%" Height="400" runat="Server" Url="daysOfWeekData.ashx" />

This control basically inserts a Flash control in the page. The Url property specifies the URL of a file containing both the data and graph's format settings. In this example, I use daysOfWeekData.ashx which contains a bar chart of the average sales a franchise store made for each day of the week during some pre-defined time period.

How does this works?

This is a pretty simple chart. You can hover over each column and the value of the bar will show in a tooltip. So basically daysOfWeekData.ashx uses the Open Flash Chart .NET library allowing us to customize our graph and insert our data. After manipulating the data, we can render the objects to the Response stream in query string format:

&title=,& &x_label_style=12,0x000000,2,1,0x000000& &x_axis_steps=1& &y_ticks=5,10,5& &bar_glass=65,#871E00,#FF7B00,Sales,12 &values=10852.69,6702.74,5327.95,5167.67,4982.08,10143.17,19958.16& &y_min=0& &y_max=19968& &tool_tip=Total Sales for #x_label#:
#val#& &x_labels=Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday&

This code is then read and interpreted by the Flash control and displayed the chart.

I have included the code for daysOfWeekData.ashx.cs (1.96 kb), in case you are interested.

kick it on

ASP.NET GridView column resizing

clock November 8, 2007 00:54 by author EtienneT

We use lots of ASP.NET GridViews in our main product, FranchiseBlast.  We think it's important to make our users' browsing experience as pleasant as possible.

Today, we included a new feature to enable our users to be able to dynamically resize the columns of a GridView.  All the credit for the original source code goes to Matt Berseth who published his code on his blog: GridView column resizing.  Unfortunately, the column resize behavior was not implemented as AjaxControlToolkit Control Extender. Therefore, this morning I took his code and adapted it to be reusable as a control extender.  I have included the code here so that others can benefit from it (see at bottom of this article).  We also included small feature to improve the sort order visualization, in the GridView. Many thanks again to Matt Berseth.

 Here is a screenshot of one of the dynamic reports in FranchiseBlast.

FranchiseBlast is architectured with re-usable base classes and we do lots of things in the codebehind instead of the typical ASPX/ASCX.  Here is some sample code to programmatically add the extender to the page:


Thanks to our architecture, these five lines enable column resizing on all of the GridViews in FranchiseBlast.

Here is the source code, should anyone be interested: (262.87 kb)

LavaBlast at IAAPA Orlando

clock November 7, 2007 00:01 by author JKealey

Next week, some of LavaBlast's software will be demoed at the International Association of Amusement Parks and Attractions (IAAPA) Orlando Expo. Because of the diverse crowd, we're focusing less on the franchise aspects of our FranchiseBlast solution and more on the individual products.

Being a one stop shop for franchisors implies being able to produce nice promotional material for tradeshows, conferences, and expositions. We designed one for our own company; let me know what you think!


 See you there!

In 2007, can we afford to refuse potential customers who don’t have JavaScript enabled?

clock November 3, 2007 15:04 by author JKealey

Traditionally, I was very conservative when it came to making use of JavaScript (and even CSS) in my projects. Years ago, I was spending horrendous amounts of time double checking my sites on various browsers, particularly Netscape 4.7. As a developer, I found it was a necessary evil to get the site to work on all browsers, and became quite good at it. I now use Microsoft Virtual PC  to test my websites.


A decade after Netscape 4 was launched, I now find myself in a similar position with JavaScript. We need to decide if we can require our users to have JavaScript enabled.  We feel that when used properly, JavaScript can increase the site’s usability. We know that approximately 94% of web users have JavaScript enabled .  Looking at the trends, we can see that this number is rising. We also notice that an increasing amount of websites are using AJAX. However, the big players typically build two versions of their sites, allowing visitors without JavaScript to use their services.   

Maybe a better question would be Can we afford to refuse potential customers who don’t have JavaScript enabled? The answer depends on who your customers are. In the franchisor/franchisee relationship, you can impose stricter constraints on the franchisees, as you don’t have thousands of them. However, the situation is different with the retail customers, who are not technically savvy. They probably have outdated software or half-a-dozen of internet security/anti-virus/anti-spyware packages that compound the problem. (I’ll keep the discussion on the Internet’s culture of fear for another day).

Therefore, by convention, we’d err on the side of caution. This position is further reinforced by the fact that AOL’s browser has broken JavaScript support.  However, taking a deeper look into the economics of the software, we have decided to require JavaScript for one of soon to be released e-commerce sites. I am purposefully omitting many arguments for the sake of conciseness as everything is debatable.

-          Trends: We see an increasing number of sites requiring JavaScript. We’d rather design for the future than the past.  We feel JavaScript has reached its critical mass and can be used in production environments.

-          Return on investment: Given our development style and legacy code, we estimate we need to invest an additional 30% effort to properly support users without JavaScript. This is prohibitively expensive for our clients.

  • New businesses need to start making revenue immediately and hopefully can afford to implement a script-less version when (and if) the site becomes popular.  
  • Our POS (in operation in a controlled environment) uses AJAX profusely.  Re-use is very tempting.
  • The ASP.NET framework includes exceptional server-side controls that make use of JavaScript for postbacks.  We’d have to avoid a large number of useful components or re-implement them.
  • We could develop without script from the ground up (thus eliminating the problem completely), but we feel it limits our potential and usability.

-          We see search engine accessibility as an orthogonal issue. Even if we require JavaScript, we can easily create a few semi-static pages (at a negligible cost) that will be scanned by search engines.  

Still, even after the previous justifications, we are still torn. Concerning accessibility, our position is not justifiable. What “feels right” for us developers (and our customer’s pocket book) will have to be monitored in the coming months. Access logs will be reviewed and customer requests, tracked. We’ll review our decision in a few months and might end up reverting our position in the future.  Therefore, we shall remain conservative in our JavaScript usage, in case we need to review our software at a later date.

I suppose the morale of this story is to be open to change and experimentation.

kick it on

Sample C# code for BeanStream credit card processing

clock October 26, 2007 16:11 by author JKealey

The other day we started looking at various credit card payment gateways in order to be able to process transactions on one of our client’s e-commerce sites. After reading up on a few alternatives, we hoped to be able to implement an easy all-in-one solution such as PayPal’s Website Payments Pro. Unfortunately, this program is not available in Canada. Apparently it will be some time soon, but we can’t wait on them for e-commerce, obviously.

After looking round a bit more, we found a payment gateway popularity contest and since we had seen a bunch of programming samples for Authorize.NET, it interested us. However, once again, Canadians cannot use this payment gateway. We looked at PSIGate the most popular one in Canada and were interested by their offering but, in the end, our client decided to go with BeanStream, another Canadian firm. BeanStream offers Electronic Funds Transfer programs (EFT) which is very useful for collecting royalties from franchisees. I may post something concerning EFT later in the year.

In any case, we were a bit disappointed that the site was not full of technical information, programming samples, SDKs, etc.  We had to contact them to obtain a copy of the documentation, something we would not have expected from a technical company in the days of Web 2.0. Having to contact them increases their contact base but shows a certain lack in openness, something which is gaining stream nowadays. The integration process seemed straightforward, as expected. Send out a request and get a response back. We were a bit surprised that the requests were encoded as you would encode a query string instead of XML with a freely available XSD/DTD. The sample code provided was dirt simple VBScript (ASP) with other technologies that we don’t use.

Some would call us lazy, but we feel that re-inventing the wheel is not a mission one should waste time on. Therefore, we started googling for freely available code for C# for payment processing using BeanStream, figuring that if the company itself doesn’t make this code available, someone must have posted an article on The Code Project or at least that we could find some code on Google Code Search. We found some PHP and some Perl, but since we code in C#, this code was not useful for us. Therefore, we started our implementation from scratch for our own purposes.

The code that follows is the current state of our implementation. It has not yet been tested in production, but our unit tests are working. We discovered a SOAP API after signing up and used that instead of the query string format.  We implemented a bit of parameter verification to make it easier to integrate with our higher level structures, which don’t have strict field lengths. Hopefully you’ll find this code useful and will let us know if you find any flaws. In our code, we've subclassed this base class to insert logging and conversion from our object-oriented data structures.

We found that the documentation was not very good, especially for the SOAP API. There were tons of mistakes and inconsistencies but, worst of all, the documentation was only available in a PDF format from which we cannot copy-paste. Therefore, the 500+ error messages or 100+ country codes cannot be easily exported to an Excel spreadsheet in order to create lookup tables in our database. We're building multi-lingual systems and don't have the time to translate their 500+ error messages, so we chose a simple solution as seen in the code. All errors (and exceptions in our code) are mapped to large encompassing classes. Fortunately, we were put in contact with VERY helpful people who responded extremely rapidly to our technical questions.

The source code follows. If you're interested, download the attached zip file containing the c# source code. (5.82 kb)

kick it on

Have a unique selling proposition

clock October 1, 2007 16:37 by author EtienneT

If you are in the retail industry, chances are that you probably already know that you have to have a unique selling proposition to offer your clients.  But hey, what’s a unique selling proposition?  In the book Reality in Advertising, author Rosser Reeves defines a unique selling proposition (USP) as:

1. Each advertisement must make a proposition to the customer: "buy this product, and you will get this specific benefit."
2. The proposition itself must be unique - something that competitors do not, or will not, offer.
3. The proposition must be strong enough to pull new customers to the product. 

A franchisor needs to have something that will make its stores shine apart from the competition. As an example, let us discuss Teddy Mountain, one of our first clients here at LavaBlast. Teddy Mountain is a stuff-your-own teddy bear type of store. Stuffed animals have been around for years and are available it countless locations.  Some stores offer dirt cheap stuffed animals while others brand the bear with a particular tourist attraction such as the Eiffel Tower. Retailers in the stuff-your-own teddy bear industry sell more than just a physical teddy bear, they sell an experience and their selling proposition revolves around this custom-creation experience.

Teddy Mountain wanted to offer something more personal to the client to complement the experience.  They decided to offer birth certificates for each teddy bear they sell.  Simple idea, but this creates a strong bond between a child and their new teddy bear.  A picture of the child with their new friend would be taken and would be printed at the counter when the teddy bear was paid for.  One could think that this simple concept is insufficient to pull new customers to the product, yet in-store behavior has proven otherwise. Children are drawn towards the camera feed presented on the kiosk and often want to purchase a bear simply to get their picture taken.

The picture here shows the in-store kiosk being used by some children.  This kiosk has two screens with two webcams and prints in the color laser printer at the cash register.  The kiosk must be simple to operate because it is used mainly by children.   This is fairly simple software and other stores also produce certificates, but the kiosk appearance (touch screen interface, webcam, three-dimensional fixtures done by Studio Y Creations) adds to the child’s in-store experience and puts Teddy Mountain in a unique position.  Because we’ve integrated the certificate with the point of sale, the employees don’t have much overhead to deal with.  Coming up in the near future are many new features on the website that link the in-store experience with the online one, refining the brand’s uniqueness.

Teddy Mountain operates in an industry which is dominated by a giant and software alone cannot be the only unique selling proposition. Teddy Mountain experience is enriched by large-scale three-dimensional fixtures that attract children from the mall inside the store. These fixtures put a little bit of magic in the shopping experience and illuminate child birthday parties. There are other refinements that define Teddy Mountain; having a clear unique selling proposition is key to increasing sales but also to attract new franchise prospects. However, since our goal is to illustrate how LavaBlast is a piece of the puzzle, as opposed to selling you a franchise, we won’t go into more detail.

Requirements Engineering at LavaBlast

clock September 11, 2007 00:32 by author JKealey

It is always interesting to try something new and I am excited to have the opportunity to write the first post on LavaBlast Software’s blog. My name is Jason Kealey and I’m a software engineering graduate of the University of Ottawa and the President of LavaBlast Software. This blog will feature various insights which we want to share with our clients and the world in general. Since our specialty is software, we thought it would be nice to create a blog focused on software for franchisors.

We’re opening the blog just a few days before I leave for Europe for a few weeks as I am presenting a paper at the 13th System Design Language Forum. Because will be presenting concepts related to my Master’s thesis, I thought the first post here could give an overview of one of my interests. Over the last two years, I have been the lead developer of an Eclipse plug-in to create, analyze, and transform models which help software engineers describe software requirements. Today, I wish to explain in layman’s terms how my expertise can be useful to franchisors or anyone who might require LavaBlast’s software. By giving insight on my expertise, I hope to communicate to my readers how we can collaborate to create software without requiring our customers to be experts in software engineering.


Traditionally, people have written free-form textual discussions to explain the behaviour of a system. This is good for initial discussions but does not scale because of the nature of unstructured text: ideas are not located easily and details are often sparse and scattered. It is better practice to list different functionality in a clear, structured pattern such as the following example:

  • FranchiseBlast SHALL record changes made to a product into an electronic journal.
  • FranchiseBlast SHALL only allow administrators to view the electronic journal.

By writing requirements in such a way, progress can be tracked, and priorities are easy to visualize. At LavaBlast Software, we like to use a collaboration wiki to elaborate our requirements for complex projects. A public example of such a wiki adapted for requirements management can be found on the website of the aforementioned tool: jUCMNav. By using a wiki, we collaboratively create the requirements document. No more emailing large documents and ending up with out of synch versions: everyone works on the central web-accessible location (protected by password if necessary)  and the requirements evolve. Later on, the requirements are not shelved as the developers who are implementing the system can go back and ask questions directly in the particular requirement’s discussion thread. Everyone works closely together to best define and scope the software system.

How to write good textual requirements is a topic that has been discussed by many authors. However, while the mileage that a team can obtain with a collection of textual requirements varies from project to project, more often than not these are insufficient. Structured textual requirements are good to describe features but not to describe scenarios or relationships between features. To better represent scenarios, a common tool of the requirement engineer’s arsenal is the textual use case. Textual use cases describe scenarios in which actors and a system under description interact. Such sequence of events increases the comprehension of the context in which the various features come into play. Use cases illustrate the system’s functionality and do not usually include technical jargon. By utilizing language that the domain expert and end users understand, a broader group of stakeholders can discuss the system’s behaviour (unlike more formal approaches). At LavaBlast, we often use textual Use Cases, but we find they lack the ease of use of a visual notation. They are great to explain detailed scenarios, but non-technical people don’t really want to read or discuss them. Here’s where the work done in my thesis comes into play.

Over the past decade, researchers around the world developed a graphical notation to describe software requirement by assembling concepts from other notations into a single easy-to-understand visual notation. This notation is called the User Requirements Notation (URN) which is composed of two sub-notations, the Use Case Map (UCM) notation and the Goal-Oriented Requirement Language (GRL).  The Use Case Map (UCM) notation represents the functional and operational aspects of a software system. The abstraction level of UCMs makes them an ideal notation to express user requirements as high-level scenarios. As for the Goal-Oriented Requirement Language (GRL), it describes the non-functional aspects of a software system and is well adapted to model high-level business goals. Now that the boring technicalities are out of the way, what does this notation mean to you?

 Goal-Oriented Requirement Language (GRL)

Above is a sample GRL diagram which represents various alternatives to create a secure system.  jUCMNav is a tool that makes it easy to create such diagrams and visualize the different alternatives using an automated evaluation propagation algorithm. Although one could draw such a diagram on paper or use the techniques commonly taught in management programs, the GRL notation combined with the powerful tool saves time.  Simply put, to achieve the high level goal of security, one needs to secure the terminal and the host. There are a number of ways one could achieve this; the sample GRL diagram shows a system where authentication is provided by swiping a cardkey and encryption is not used. In the end, security is achieved but is not very high. Although I do not wish to go into detailed explanations here, with a simple 10 minute tutorial, stakeholders can understand the notation and visualize the impact of certain solutions on their business goals.
Typically, at LavaBlast, we build the models ourselves to reveal the tradeoffs between various alternatives and present them in meetings. The goal here is to keep trace of the motivations behind a certain decision. In a meeting, the stakeholders can discuss elements that may not be taken into consideration by the model, refine it iteratively and observe the impact on the goals (automatically, thanks to the tool). In the end, a decision is made and the GRL model records the motivations.

Use Case Map (UCM) Notation

Above is a sample Use Case Map used in the context of a web store with a warehouse. Again, with a brief 10 minute tutorial about the notation, one can understand the modeled scenarios. In this case, we see a normal order where the user submits and other and waits for it to arrive.  As an exercise, without any background in the UCM notation, you are invited to see if you can understand the above diagram. Complex details can be encapsulated inside the Stubs (diamond figures) allowing for multi-layer models. After brief discussions with franchisors the LavaBlast team can, thanks to the Use Case Map notation and jUCMNav, unify all the scenarios that were discussed and rapidly break it down into various interacting scenarios. Having a visual notation such as above helps clarify any vague issues and identifies any problems very early on in the requirements elicitation phase.

The model here identifies various issues that can arrive when products are backordered; software engineers need to know about these fringe cases to build a robust system and having such a tool helps minimize costs incurred by discovering issues late in the game. Everyone can sit down around a table and discuss the scenarios which represent what LavaBlast’s understanding of a business process and clarify any issues before any code has been written. Moreover, thanks to these scenarios, the software architecture and the development team can review the modeled scenarios at a later date to ensure they are implementing the appropriate behaviour.

For decades, software engineers have understood the value of writing things down; that’s why NASA has thousand page documents for their software systems. However, we at LavaBlast take a much lightweight approach to requirements engineering. Simple visual diagrams used in meetings combined with online collaboration for requirements elaboration are a perfect balance between traceability and pragmatism.


LavaBlast knows the best practices for writing good requirements and loves to have the customer participate in the process. We understand that requirements are only useful if they evolve with the system and we use Web 2.0 collaboration tools to manage our requirements. Furthermore, we’re dedicated to help people understand the software system to be built. With our agile software development processes, we focus on clear understanding and incremental development. We want our customers to have as much fun developing a software system as we do and that starts by minimizing useless repetitive paperwork and replacing hundred page documents with clear and concise figures.

Side note

LavaBlast’s CTO was the lead software architect for jUCMNav and I was the lead developer. My main responsibilities were related to the manipulation, analysis, and transformation of Use Case Map models. This open-source tool has around 200 KLoc of Java, with about a quarter automatically generated from UML class diagrams.

Month List


The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

Sign in