One of the key issues in this space is the lack of a good IDE for developing media rich websites without Flash. That’s what makes Flash so attractive to designers, the ease of creating these multimedia based websites. Dreamweaver doesn’t come close.

Over the last few years we’ve seen major Flash studios, like Fantasy-Interactive, make the move to web standards.

Even though HTML/CSS/JS is far more semantic, more accessible and more flexible, we don’t possess the tools to build a really top-notch IDE.

The bigger question is… should we bother building such an IDE? I’m not so sure. It’s the transparency of the markup that makes HTML/CSS/JS so accessible. Abstracting that markup in an IDE would probably bring along the same issue’s that plagues Flash today.

Related posts:

1. Why Flash is Mostly Bad
2. Unobtrusive Javascript Controversy
3. Reasons to Validate
4. Beginning Web Design Workshops

An application we are developing for a client requires some graphic representation of progress along a timeline of multiple steps.  A Gantt Chart is the obvious best solution, but alas that is not a chart type available from the Google API.  However, a Gantt chart is really just a special type of bar chart, and bar charts are available in the API.  So the question was, how can we make the standard Google bar chart display as a Gantt?

The Google Charting API Developer’s Guide does an excellent job documenting the “how” side of things, so to avoid repeating a lot of stuff from there, we’ll just focus on the “what” of building a Gantt chart with Google.

Note: The sample graphs below are actual Google Chart API calls. To see how the charts were created, have a look at the images source attribute.

A simple bar chart

As a starting point, let’s start with this sample bar chart from the Google Charting API documentation:

Getting clever by stacking bars

It’s already a horizontal bar chart, exactly what we need for our Gantt chart.  However, being a traditional bar chart, all of the bars start on the left axis.  For a simple Gantt chart, each successive bar needs to begin where the previous bar ends.  Google offers a “stacked bar” chart, where the bars for the second data series do begin right where the bars for the second series end.

If we change the color of the first data series to white to match the background color, the second data series seems to “float” well above the x-axis.

Flip it to a horizontal bar chart, and we get something that starts to look somewhat like a Gantt!

Building the Gantt Chart

Now that we have a chart to work with, let’s lay out a sample project we want to chart. Our project will have sequential 5 steps as shown below, an overall timeline of 14 days.

Sample Project Steps

1. 3 days
2. 1 day
3. 6 days
4. 1 day
5. 3 days

To begin with, let’s build a simple horizontal bar chart showing the 5 steps.  We’ll include a 0-14 scale for the chart, and make it a workable size.  Our data parameter is: “3,1,6,1,3”

To align the tasks start to finish, we need to build and supply a data series that we can represent with white bars. The data for this series is quite easy to calculate – it’s simply the sum of all prior task days. So for our example project we have:

1. Step 1 – 0 days
2. 3 days
3. 4 days
4. 10 days
5. 11 days

If we add this as the first data series to our chart, and set its color to white, we now have a very simple Gantt chart of our project.  Here, we pass the following data: “0,3,4,10,11|3,1,6,1,3”

Visualizing Status

This chart only shows the sequence and relative length of each step. It doesn’t show the status of each step, and where we are along the timeline. Let’s use the following colors to indicate each task’s status:

• Complete: #000000
• In Process & On Time: #00ff00
• In Process & Late: #ff0000
• Upcoming: #0000ff
• Other: #ff6600

We’ll use the same logic we did to get the bars for each task to align start to finish, though now we’ll have 6 total data series, including the lead time drawn in white.  For our example, steps 1 and 2 are complete, and we are on time with step 3.  We will need to pass the following data series:

• Lead Time (in white) : 0,3,4,10,11
• Complete: 3,1,0,0,0
• In Process & On Time: 0,0,6,0,0
• In Process & Late: 0,0,0,0,0
• Upcoming: 0,0,0,1,3
• Other: 0,0,0,0,0

So our Gantt chart now starts to give us some more detailed information.  We’ll also add some data labels so a legend is painted.

Next we need to give the chart some axis labels. The y-axis should give our step names, the across the x-axis, let’s show the dates of the timeline. We’ll assume a start date of 12/4.

Adding Gridlines

This is looking much better – though some vertical grid lines would give us better reference between the tasks and the dates.

Not quite what we were after though – our white bars which once blended in so nicely with the white background are now blocking the grid lines! Thankfully the Google API supports a transparency value on every color, so we’ll just make our lead time bars 100% transparent.

Showing a Progress Indicator

We can use the range marker functionality to indicate visually where we are across the timeline. The width of the range marker is specified in a percent of the overall width of the graph. For our project, each day is 7.1% of the chart (100% / 14 days). Today being 12/8, we’ve used 4 days of the timeline, or 28.4% of the graph. We supply a width for the range marker of 0.29 (rounded up from .284).

As a final example, let’s change and show step 3 as in process, but running late. All we have to do is move its value from the On Time data series to the Late data series:

All of this could continue to be expanded to handle more complex projects, and to handle multiple concurrent tasks. Additional axis labels could be added to visually categorize steps or to indicate milestones within a project. For our client’s application, we included an additional x-axis label to identify the target completion date for a project, thus showing overall how far ahead or behind the project is currently running.

Related posts:

1. Google Charting Frustrations
2. Google Chart’s Resolution
3. Google Penalizes Paid Links
4. 10 Tips to Better Google Wave Conversations

Here is a quick example which demonstrates the problem:

The problem is caused by the change in Firefox’s current rending frame. Setting overflow:scroll on our #Container div causes Firefox to use that div as it’s current rending frame. Thus, the cursor is being rendered on the #Container, not on the #Dialog div, which contains the input. Effectively, the input is covering its own cursor.

The fix is a simple change in CSS inheritance. Without setting an overflow setting on the #Dialog div, we are inheriting the overflow:scroll from #Container. By setting the #Dialog div’s overflow setting back to it’s default overflow:auto we are changing Firefox’s rendering frame to the #Dialog div, thus bringing back our cursor.

Here is the fixed example:

Thankfully, Mozilla has fixed this problem in Firefox 3.

Related posts:

1. IE8 – Trying to become a real browser?
2. Web Form Fundamentals

Problem 1: Query Parameters

The first issue we had was that the data had to be passed through query parameters, or through a GET request. Both of which are insecure. The simple solution to this problem is to avoid passing sensitive data altogether. While someone could potentially snipe the URL and read the sales trends line graph, the information is meaningless without knowing who the associated account is.

Problem 2: SSL Connections

Our applications all run on secured https environments. This means I cannot securely link to the Google chart image directly, since they (rightfully) do not accept https connections.

The simple solution is to suck the data in through a server side language (PHP and Sandstone, in our case) and then output it within our own secured environment.

Conclusion

As my wife will tell you, I’m wrong about many things. This last post was one instance. As I investigated deeper into this problem it became evident that anyone with very sensitive data would not accept a hosted solution of any kind, so Google has made the right choice to err in favor of the simple interface for the people who will be using it.

Related posts:

1. How to build a Gantt Chart with the Google Charts API
2. Google Charting Frustrations
3. Google Penalizes Paid Links
4. 10 Tips to Better Google Wave Conversations

Placing this image tag in your HTML will generate the following graph.

http://chart.apis.google.com/chart?cht=p3&chd=t:60,40&chs=250x100&chl=Hello|World

Designed for Web Applications

This API is most useful in web applications. It generates attractive graphs that work well for dashboards and reports. However, it has a major drawback when it comes to security. The data itself is passed through a URL and URL’s are not a secure method of transporting data. Imagine if you logged into your online banking site and it passed your password along like this:

http://www.your-bank.com/login.php?username=Joe&password=Flounder

This URL could be sniped and your password “Flounder” would be leaked. Passing this through as an https connection does not make a difference either.

A problem worth fixing

Admittedly, we are a little more pessimistic about data security than many of our competitors, but it is still a problem which should be fixed. Google’s graph output is the prettiest of the available products that I’ve seen, both commercial and open-source, but isn’t a viable option because of it’s intrinsic security problems.

A possible solution would be to give me an API ID, which allows me to POST the encrypted data to their server and they send the binary data of the image back which I can output. It’s a little bit more technical for the few of us who care about doing it securely, but I think it is worth Google’s time to do so.

If anyone knows of a quality 3rd party OOP graphing library (preferably PHP based) I would love to hear it. I’ve tried a number of them, including JPGraph, and Jarir Maani’s SWF Charts, but haven’t found anything with the output near as pretty as Google’s. I’d prefer not to reinvent that wheel and write our own, unless absolutely necessary.

I would love to hear your suggestions.

Related posts:

1. Google Chart’s Resolution
2. How to build a Gantt Chart with the Google Charts API
3. 10 Tips to Better Google Wave Conversations
4. Google Penalizes Paid Links

Our Standards

When building enterprise level software with multi-developer teams, enforcing quality coding standards is critical. Our standards cover everything from architecture, naming conventions, interfaces and database design to version control processes.

Our standards forbid the use of public fields as properties within classes:

public $FirstName;

All class properties must be implemented through public getter and setter functions using a protected field for data storage:

protected $_firstName;

public function getFirstName()
{
    return $this->_firstName;
}

public function setFirstName($Value)
{
    $this->_firstName = $Value;
}

While we can easily call these public functions as class methods:

echo $obj->getFirstName();

In order for the above code to actually operate as a property:

echo $obj->FirstName;

We must implement the magic getter and magic setter functions:

public function __get($Name)
{
    $getter='get'.$Name;

    if(method_exists($this,$getter))
    {
        $returnValue = $this->$getter();
    }
    else
    {
        throw new InvalidPropertyException(
            "No Readable Property: $Name",
            get_class($this),
            $Name);
    }

    return $returnValue;
}

public function __set($Name, $Value)
{
    $setter='set'.$Name;

    if(method_exists($this,$setter))
    {
        $this->$setter($Value);
    }
    else if(method_exists($this,'get'.$Name))
    {
        throw new InvalidPropertyException(
            "Property $Name is read only!",
            get_class($this),
            $Name);
    }
    else
    {
        throw new InvalidPropertyException(
            "No Writeable Property: $Name",
            get_class($this),
            $Name);
    }
}

Obviously this shows that we have extended the Exception object to create an InvalidPropertyException within the Sandstone Application Framework.

This structure supports read-only properties through simply implementing just the public getter function. Also computed or combined properties are supported as well:

public function getFullName()
{
    $returnValue = $this->_firstName
            . " " . $this->_lastName;

    return $returnValue;
}

DRYing Up Our Entities

Our standards for database design have allowed us to develop some more specific standards for how our business entity classes are developed. In reviewing these classes, I was not surprised to find that the code for the class constructors and the methods for loading and saving data to the database all followed identical formats. In the case of the constructors, more often than not, the code was identical from class to class.

One of our biggest goals when refactoring code is the DRY principle. Here I was faced with a significant amount of repeated code – how could this be corrected? A standard solution to this type of scenario is to employ the superclass extraction refactoring method. What was needed was an EntityBase class, from which all business entity classes could inherit.

Our EntityBase class centralized the common constructor functionality. In order to centralize the basic plumbing of the Load and Save methods, we stepped back and took a more OO view of the fundamental parts of a class definition itself – specifically properties. We realized that just as metadata in a database describes the structure and functionality of the data, we can identify “metaproperties” which describe the structure and functionality of the actual properties. Some of the metaproperties we identified were:

• Name
• Data Type
• Related Database Field Name
• Read Only?
• Required?
• Value

Our solution implemented an architecture where individual properties of a business entity class were represented as objects themselves.

Class Properties as Objects?

Under this new architecture, properties are no longer implemented as fields and functions, but are now defined through an array of PropertyClass objects. An overridden protected method in each EntityBase child (called from the EntityBase constructor) performs the setup of this array of properties. This array is keyed by the property name for easy lookup. In order to make this functional, we had to override our magic getter and magic setter functions in the EntityBase class:

public function __get($Name)
{
    if (array_key_exists(strtolower($Name),
        $this->_properties))
    {
        $targetProperty =
            $this->_properties[strtolower($Name)];
        $returnValue = $targetProperty->PropertyValue;
    }
    else
    {
        throw new InvalidPropertyException(
            "No Readable Property: $Name",
            get_class($this),
            $Name);
    }
}

public function __set($Name, $Value)
{
if (array_key_exists(strtolower($Name),
    $this->_properties))
    {
        $targetProperty =
            $this->_properties[strtolower($Name)];

        if ($targetProperty->IsReadOnly == false)
        {
            $targetProperty->PropertyValue = $Value;
        }
        else
        {
            throw new InvalidPropertyException(
                "Property $Name is read only!",
                get_class($this),
                $Name);
        }
    }
    else
    {
        throw new InvalidPropertyException(
            "No Writeable Property: $Name",
            get_class($this),
            $Name);
    }
}

Within our PropertyClass, the setPropertyValue($Value) function enforces rules set by the values of the other metaproperties. For example, it enforces data type rules (i.e. cannot set a string value to a numeric property) and does not allow a required property to be set to null.

Support for computed or combined properties can be retained through a small addition to the magic getter:

public function __get($Name)
{
    $getter='get'.$Name;

    if(method_exists($this,$getter))
    {
        $returnValue = $this->$getter();
    }
    elseif (array_key_exists(strtolower($Name),
        $this->_properties))
    {
        $targetProperty =
            $this->_properties[strtolower($Name)];
        $returnValue = $targetProperty->PropertyValue;
    }
    else
    {
        throw new InvalidPropertyException(
            "No Readable Property: $Name",
            get_class($this),
            $Name);
    }
}

The Challenge

This refactoring through superclass extraction has done an excellent job of DRYing up our business entity classes. The new architecture allows our developers to create new business entity classes in a quarter of the time. It has also allowed us to easily add functionality (such as tagging) to all business entity classes in a single step.

This new architecture did bring with it one significant challenge. How do we implement scope-based security? We still needed to manipulate the values of properties from within the class itself without having the public access rules enforced. We might need to set a required property to null, or the ability to change the value of a read-only property. Under traditional design, the compiler would handle this security validation and generate parse errors if some external source attempted to access the protected fields. Now, the question I needed to answer was, “How can I tell at run time if the call is coming from this exact instance of the class or not?” I realized the answer lies in the call stack!

I had worked with the debug_backtrace() function previously while building a custom debug and error page for the Sandstone Application Framework. According to the documentation, the “object” element of the returned array provided a reference to the calling object (if any). That’s exactly what I needed to perform this scope check at run time. I did find that in order for that object reference to be set, Zend Optimizer 3.3.0 or higher is required. Once the Zend Optimizer install on our server was updated, everything worked as advertised.

Our PropertyClass also exposes a Value property in addition to the PropertyValue. Unlike the PropertyValue property which enforces all public access rules, the Value property provides that unrestricted modification of the actual value we require.

To implement this scope level security, we first added the following protected method to the EntityBase class:

final protected function IsInternalCall()
{
$callStack = debug_backtrace();

        //The call context we are interested in
    //will be index 2 in the array.
        // 0 = this function
        // 1 = internal function call to this test
        // 2 = context in question

    $context = $callStack[2];

    if ($context['object'] === $this)
    {
        $returnValue = true;
    }
    else
    {
        $returnValue = false;
    }

    return $returnValue;
}

It’s important to note that on line 13 we are using the ===, to test if the object reference in the array is the same instance of the current object.

With this method in place, we made a few changes to the magic getter and magic setter implementations. Our standard naming conventions state that all protected field names are prefixed with an underbar:

$this->_firstName;

Therefore we can use a leading underbar in the name as the indicator that the calling function is requesting local scope level access to the property. All we have to do now when such access is requested, is validate this is an internal call:

public function __get($Name)
{
    $getter='get'.$Name;

    if(method_exists($this,$getter))
    {
        $returnValue = $this->$getter();
    }
    elseif (array_key_exists(strtolower($Name),
        $this->_properties))
    {
        $targetProperty =
            $this->_properties[strtolower($Name)];
        $returnValue = $targetProperty->PropertyValue;
    }
    elseif(substr($Name, 0, 1) == "_"
        && $this->IsInternalCall())
    {
        //Only allow this for internal calls

        //Determine the associated property name
        $propertyName =
            strtolower(
                substr($Name, 1, strlen($Name) - 1));

        //Does it exist?
        if (array_key_exists($propertyName,
            $this->_properties))
        {
            //Return it's value
            $targetProperty =
                $this->_properties[$propertyName];
            $returnValue = $targetProperty->Value;
        }
        else
        {
            throw new InvalidPropertyException(
                "No Readable Property: $Name",
                get_class($this),
                $Name);
        }
    }
    else
    {
        throw new InvalidPropertyException(
            "No Readable Property: $Name",
            get_class($this),
            $Name);
    }

    return $returnValue;
}

public function __set($Name, $Value)
{
    $setter='set'.$Name;

    if(method_exists($this,$setter))
    {
        $this->$setter($Value);
    }
    elseif (array_key_exists(strtolower($Name),
        $this->_properties))
    {
        $targetProperty =
            $this->_properties[strtolower($Name)];

        if ($targetProperty->IsReadOnly == false)
        {
            $targetProperty->PropertyValue = $Value;
        }
        else
        {
            throw new InvalidPropertyException(
                "Property $Name is read only!",
                get_class($this),
                $Name);
        }
    }
    elseif(substr($Name, 0, 1) == "_"
        && $this->IsInternalCall())
    {
        //Only allow this for internal calls

        //Determine the associated property name
        $propertyName =
            strtolower(
                substr($Name, 1, strlen($Name) - 1));

        //Does it exist?
        if (array_key_exists($propertyName,
            $this->_properties))
        {
            //Set it's value
            $targetProperty =
                $this->_properties[$propertyName];

            $targetProperty->Value = $Value;
        }
        else
        {
            throw new InvalidPropertyException(
                "No Writeable Property: $Name",
                get_class($this),
                $Name);
        }
    }
    else
    {
        throw new InvalidPropertyException(
            "No Writeable Property: $Name",
            get_class($this),
            $Name);
    }
}

This code implementation not only provides the scope level security we require, but does so while preserving the interface of a traditional protected field. This reduced the time required to convert all previously existing business entity classes and maintains a standard naming convention across both business entity classes and other functional classes.

Aftermath

Since making this major change to the Sandstone Application Framework architecture, we have completed a custom application project for a client. I am happy to report that this new structure, and a couple RAD tools built in-house specifically to support the new architecture, allowed us to build and deploy the application in record time.

No related posts.

Our current controversy revolves around the topic of unobtrusive javascript. We (the staff at Designing Interactive) all agree on the benefits of unobtrusive javascript:

• Automatic Graceful Degradation
• Separation of behavior from content
• Reusable code

Special Situations

Our development environment is not like most. Our server-side development framework, Sandstone, automates most of our html/css/javascript interactivity. This renders the Reusable Code benefit much less important. While our javascript code may be duplicated in the page source, it’s still only one point of change for us developmentally.

As our chief interface designer, I believe the separation of content, style and behavior is important. In fact, we do a fantastic job of this already, but there is room for improvement. We have always adopted external CSS files over inline styles, and our javascript functionality is defined in external javascript files. Our javascript triggers are still inline, however.

The cost of not changing

While our immediate code practices cause few problems, I do have concerns moving forward without change.

1. We lose some credibility in the high-end design arena by not following proven design trends.
2. While we currently support graceful degradation to browsers with javascript disabled, we currently cannot trap compatibility issues between javascript versions.
3. We limit our ability to make our page markup more lean and semantic.

Counter Arguments

My counterparts make a few valid points against change.

1. There’s no immediate functionality loss.
2. There’s little, if anything, to gain in filesize and bandwidth issues.
3. Refactoring Sandstone is a lot of work for such a small immediate gain.

My Opinion

I believe this is an important change to make in the long term. While it’s not high on our priority list, it is important if we want to continue to lead in the design industry. We know our work is not only judged by the way it’s rendered, but also in our source code. That’s the very reason our websites validate to strict guidelines.

Most importantly, if we don’t take the step forward we run the risk of falling behind in the future. Our business plan revolves around agility and the ability to change faster than our competition. The risk of not implementing at all is a risk I don’t believe we can afford to take.

I’d love to hear your comments on the issue. Both from our readers and from my colleagues.

Related posts:

1. Dear HTML, CSS, and JavaScript: Flash is more flexible
2. Goals for 2009
3. Design Last Design
4. Eliminating Waste from your Agile Process

Why does it matter?

Web browsers such as Internet Explorer and Mozilla Firefox are responsible for transforming the markup which describes your website into a graphical web page. Writing code which conforms to the w3c’s guidelines will ensure consistent rendering across browsers. Invalid code, even though it may render correctly, is relying on error detection and correction by the browser. In fact, it’s very common for web browsers to render the same page differently, sometimes dramatically.

It’s also important to remember that all web browsers are not the same. Internet Explorer and Mozilla Firefox are today’s mainstream web browsers, but are rarely used by those with visual impairments. Screen reading software, which translates computer content into audio, also reads the markup code. Invalid markup is likely to be read incorrectly, leading to inaccessible websites for many disabled persons.

Content, not Presentation

Despite it’s reputation the past years, HTML and XHTML are used to describe content. The markup language is designed for differentiating types of content (Headlines, paragraphs, lists, tables, etc…), but not for describing how the content should be displayed. You should use HTML to describe your content, and only your content. Allow for presentational markup languages (like CSS) to describe how the content is presented.

By keeping content, presentation and behavior independent from each other you also greatly simplify future maintenance tasks. You can alter existing content and write new content without being burdened with how the content will be displayed and formatted.

It’s the Law

Accessibility is the law in many countries today. You are legally obligated to ensure your websites content is accessible by all.

How To Validate

Checking your website against the w3c’s guidelines is easy. Following the guidelines is not tremendously difficult, although it can require some patience. The w3c has published a free tool for validation, and provides friendly descriptive errors when conditions are not met. You can find this tool at their website.

Related posts:

1. IE8 – Trying to become a real browser?
2. Functional Favicons
3. Unobtrusive Javascript Controversy
4. Forget about the Fold