Creating Themes

If you never had the chance to check out the work, here’s a peek:

The calendar got some great feedback and even inquiries from folks who wanted to make calendars of their own, so this yea we released the source code.  It’s free to use however you wish, but please link back to us for attribution.

We wanted to share some of the cool calendars that people have created using the source that showcase art, gift ideas, and even pets up for adoption. Great calendars to spread the holiday cheer! check them out:

Battersea Dogs & Cats Home Advent Calendar:

Advent Noir – 24 Classic Black & White Winter Memories

HTML5 Snow, too!

Schlagerfiasko’s 24 days of Christmas

Der Androgon Adventskalender 2011

Great job all! We also saw a neat Mozilla Developers Network Advent this year by Chris Heilmann and team. Have you seen any other HTML5 advent calendars in the wild?  Please share – we’d love to see and share them!

Happy Holidays from ZingChart!

See a few of them in action here (photo links to live demo):

Here’s a laundry list of tokens for you to try out in your own posts:

These tokens can be placed in “text” attributes throughout various objects like series, value-box, crosshair-x value-label, and more. Here’s an example of the JSON from the above pie chart example, where we decided to call the series text, value, and node percent value for each slice:

"tooltip":{
    "text":"%t: $%v (%npv%)",
    "background-color":"#fff",
    "border-color":"#333",
    "border-width":"1px",
    "border-radius":"8px",
    "font-color":"#333"
 },

Give these a try and email us with any questions support@zingchart.com for chart help, sales@zingchart.com for licensing inquiries!

Dear ZingChart customers, tinkerers and evaluators,

Just over a year ago we released the first charting library capable of rendering Flash and HTML5 Canvas. It was a big achievement, and even earned us a nod from Zeldman. Today, we’re raising the bar again with two additional render formats.

ZingChart now renders charts in Scalable Vector Graphics (SVG) and Vector Markup Language (VML) in addition to Flash and HTML5 Canvas. Those of you who are familiar with all the benefits and limitations of each technology already know how many headaches and hours you can save by building once and rendering across HTML5, SVG, VML and/or Flash. For those that don’t, here’s a quick overview:

• Despite the fact that iPads, iPhones and some other mobile devices don’t run Flash, we’re not jumping on the anti-Flash bandwagon. Flash still reigns supreme for many charting needs – mobile is just not currently one of them.
• While SVG is a solid technology for building interactive charts (and the sole technology selected by many other libraries’ HTML5 efforts), it’s not always the best solution. We’ll refer to the IE Blog for further reading.
• Why use ancient VML, you ask? Internet Explorer 6, 7 and 8 render neither HTML5 Canvas nor SVG natively. And since many of you have been going the sans-Flash route for your data visualization, we didn’t find it helpful to force your users to take the performance hit of ExCanvas.

We’ve been working hard on making ZingChart as forward and backward compatible as possible, so you won’t need to worry about using multiple libraries or sacrificing the performance or functionality of your apps, websites and dashboards. We’ll keep fighting the format wars so you can keep building great products and projects with ZingChart.

Download ZingChart for SVG, HTML5 Canvas, Flash and VML.

Browse the Chart Gallery.

Share this post on twitter.

Happy Charting,
Andrew Begin
abegin@zingchart.com
858-490-5281

We’re almost ready to share some of the updates and findings, so subscribe to our feed or follow us to be the first to know.

Interested in getting a first look? Give us a shout at sales@zingchart.com.

Well, we recently took our guides one step further and gave them a new name in the process. These hover-guides are to be called “crosshair-x”: and “crosshair-y”: and are new objects within the “graphset”:. They’re customizable, and they are awesome. Give them a try:

NOTE: If you ever want to dig deeper into JSON that drives one of our charts, just right click on it and select View Source.

The crosshair-x and crosshair-y features are fully customizable, from the lines to the tooltips (“value-label”:) to the labels for scale-x and scale-y (“scale-label”:). Here’s some sample code to try out to get you started:

(the following goes within “graphset”:[{}])

"crosshair-x":{
            "text":"%t Sales: %k: $%v",
            "line-color":"red",
            "line-width":"3px",
            "font-color":"purple",
            "font-weight":"bold",
            "value-label":{
               "alpha":0.6,
               "background-color":"green"
            },
            "scale-label":{
               "alpha":1,
               "background-color":"#0000ff",
               "font-color":"#ffffff",
               "font-weight":"bold"
            },
            "marker":{
               "size":"3",
               "background-color":"#ff0000",
               "border-color":"#00ff00",
               "border-width":"2px"
            }
         }

Happy Charting!

Mention us on Twitter or Email us with any questions!

- Andrew

Default Mobile Context Menu Button

By default, the context-menu button is placed in the top left corner of the chart and is set to visible.

Default mobile "context-menu" GUI on HTML5 Gauge chart via iPhone 3G.

Customizing the Mobile Context Menu Button

By adding the “context-menu[mobile]“: object outside of “graphset”: in your JSON packet, you can hide, position and customize how this button looks to your end user. It’s even possible to use an image to add your own custom menu button.

The button can be customized and styled in the mobile context menu object.

Fonts, padding and colors of the mobile context menu can all be customized.

Here’s how we customized the above mobile context menu button:

{
 "gui" : {
     "context-menu[mobile]" : {
         "background-color" : "#ff6600",
         "item" : {
             "padding" : "5px 30px",
             "background-color" : "#ff6600",
             "border-color" : "#ff6600"
             },
         "button" : {
             "text" : "Click Here for Mobile Options",
             "margin" : "10px 200px auto 100px",
             "padding": "15px 15px 7px 15px",
             "background-color": "#ff6600 #ff9933",
             "border-color": "#000000",
             "border-width": "3px",
             "border-radius": "15px",
             "font-color": "#000",
             "font-size" : 16,
             "visible":1
             }
         }
     },
 "graphset" : [ .... normal chart JSON attributes here .... ]

Now you know what the “little black box with the question mark” is, and you know how to use it. If you took a look at the sneak-peek, you’re hopefully excited to be able to customize the context menu items in your HTML5 charts in mobile. We sure are!

{
  "graphset" : [
  {
    "type" : "line",
    "notes": [
    	{"text": "Our first note", "x": 100, "y": 40},
    	{"text": "I love oranges", "x": 280, "y": 100}

    ],
    "series" : [
     {
        "values" : [11,26,7,44,11,28,42,26,13,32,12,4,21,11,43,39]
     },
     {
        "values" : [42,13,21,15,33,10,30,46,10,7,27,40,1,32,22,45]
     },
     {
        "values" : [23,24,13,4,18,6,24,10,26,44,32,17,17,27,14,36]
     }]
  }]
}

However, now you want to hide one of the notes because it is in the way of something you are working on so you just prefix the note in question with a dash and it is gone.

{
  "graphset" : [
  {
    "type" : "line",
    "notes": [
    	{"text": "Our first note", "x": 100, "y": 40},
    	{"-text": "I love oranges", "x": 280, "y": 100}

    ],
    "series" : [
     {
        "values" : [11,26,7,44,11,28,42,26,13,32,12,4,21,11,43,39]
     },
     {
        "values" : [42,13,21,15,33,10,30,46,10,7,27,40,1,32,22,45]
     },
     {
        "values" : [23,24,13,4,18,6,24,10,26,44,32,17,17,27,14,36]
     }]
  }]
}

No parse error and it is easy to recover the property later on.  The dash is somewhat arbitrary, but the basic rule of thumb is ZingChart will ignore unknown properties as long as they are quoted properly.  You could thus use DEBUG-text or whatever you wanted to prefix the property with, we have over time just found the single – character the most natural way to mask things out when you are tinkering with a chart JSON packet.

For example, a simple line might be written as

{
  "graphset" : [
  {
    "type" : "line",
    "series" : [
     {
        "values" : [11,26,7,44,11,28,42,26,13,32,12,4,21,11,43,39]
     }]
  }]
}

However it can be simplified to:

{
    "type" : "line",
    "series" : [
     {
        "values" : [11,26,7,44,11,28,42,26,13,32,12,4,21,11,43,39]
     }]
}

This simple tip saves a few bytes, reduces nesting complexity and works with both Flash and HTML5 versions of ZingChart.

Being a team that creates data visualization tools, we’re well read on dataviz best practices, and are also in tune with the demand for exciting and intriguing visuals. We’ve stayed on the sidelines of the debate, but we decided it’s time to offer our 2 cents.

Tufte vs. Chartjunk

There’s a battle going on between data visualization professionals like Stephen Few and Edward Tufte (the Jakob Nielsen of Infographics), and design professionals. One side is calling for minimization of chartjunk and the end of the over-designed infographic, while the other is pushing the boundaries of how much design can be applied to data before the data becomes an afterthought. With the flood of publicly available datasets over the past few years, it seems that the debate is just getting started.

Our Bismarckian View

We aren’t going to try to convert our readers to follow the gospel of Tufte, because many of our customers have great uses for colorful and image-infused graphs. Having said that; Now you see it, The Visual Display of Quantitative Information and Show Me the Numbers are within our reach at all times, and get referenced often.

Our view is, a black and white line chart with no labels won’t reach a fraction of the audience that some of today’s poorest visualizations do, whereas an infographic filled to the brim with 3D pies, images, large text and loosely related graphics may reach tens of thousands of viewers without delivering any consumable, meaningful or accurate data.

We’d argue that the amount of non-data-ink or chartjunk used is irrelevant to data comprehension as long as the ink (err.. pixels) is used appropriately.

Here’s some context for “appropriate:”

1. Audience. The same discretion must be used for charts and graphs as for any other form of communication. Is your audience composed of C-suite individuals who may us your data to make decisions, or creative folk who may focus more on the visual impact and story the data tells?
2. Topic. Stock data should be represented in the most straightforward way possible, as its misinterpretation could cost your reader a lot of money. Public opinion percentages or editorial data is often less critical to decision-making and can benefit from some graphic elements to tell a story. Compare a chart in any copy of USA Today to one in the Wall Street Journal. The styles couldn’t be further apart, yet both are appropriate for the medium.
3. Chart-type. This may be the biggest thorn in the side of dataviz professionals — when a designer uses charts that don’t accurately represent data. On this front, we’ll side with Tufte, Few and the other educators. No amount of design will make up for a data visualization that poorly portrays or skews the data.
   To further complicate the chart-type issue, Stephen Few recently released a newsletter about the failure of circular chart-types.  Long story short: circles are great for design, bad for visualizing data.
4. Relevance. As explored in Robert Kosara’s “Chart Junk Considered Useful After All” post and subsequent discussion, there is definitely some validity to having graphics built into a visualization; it helps “engage the reader‘s interest” which results in higher comprehension and retention rates. Note, however, that the graphical elements used in Nigel Holmes’s study didn’t skew the data and were relevant to the story that the data was trying to tell, which is hardly the case with many infographics floating around.

Chartjunk vs. Chartbling

There is one fire we’re willing to start and pour some fuel on. With the interactive capabilities of Flash and HTML5 we can now hover, click, alter, zoom, drill-down, and manipulate data visualizations in real-time. We can use rules to set the color or style of plots based on their value. Some of these features may fall within the current definition of “chartjunk” but we’d offer that the current definition was built for the printed chart and doesn’t take into account new technology. We propose new nomenclature for visual elements in charts that are not necessary for data comprehension, but that do increase the engagement, interaction and viral reach of a visualization. We’re going with chartbling for now.

Conclusion:

We DON’T advocate stuffing a chart with graphics and images for the sole purpose of making it colorful and visually stimulating — that is and will always be chartjunk…

If you think pie charts are poor by themselves, try comparing the results of these two related pies without hurting your brain. #chartjunk.

The stock images used here are barely tied to the story, and are too much of a distraction to provide any comprehension/retention benefit. #chartjunk

This infographic by David McCandless of http://infobeautiful.net adds interesting colors and graphics to a basic bar chart to help tell the story of rising sea levels. #chartbling

Share your thoughts below or with us on twitter.