Dashing - A dashboard framework | Hacker News Reader

Dashing - A dashboard framework

shopify.github.com

419 pointsthehodge84 comments

Hey everyone! Dashing creator here. Thanks for the frontpage :)

I have good news for you all. Dashing will be evolving soon to support multiple backends. Already there are ports being written for python, perl, .net, and also better rails integration. Stay tuned!

P.S: Sorry for the downtime. Was not expecting frontpage. While I work on getting it stable, enjoy this screenshot: http://cl.ly/image/321Y2V361X1r

It looks really good. We're just about to start building a dashboard so this could be really useful. We're using emberjs though, is it possible to use just the views and the layout code? I'm thinking along the lines of a dashboard bootstrap.

I think you want gridster then: http://gridster.net/

Thanks, that looks perfect!

Great work - this looks amazing. Do you have a mailing list I can subscribe to to get notification of when the .net version becomes available? Thanks!

https://github.com/sbarski/dashing.net

Looks good. I have used geckoboard in the past but would like to customize my own internal dashboard to use this. Kudos for using Sinatra!

It would be nice to have a github org for dashing and all its ports. That could take some of the burden of all the ports off of you.

I know its part of shopify organization now, but there is a lot of interest I know I would love to contribute to other backends as well

They won't be maintained by Shopify. Only the frontend & ruby backend will be under Shopify.

I'm going to use this literally the moment you release rails support. Hell, let me beta test it!

We have a platform that really needs this, so I'm looking forward to using it immensely.

How do I stay tuned for the Python version?

Ah, found it: https://github.com/evolvedlight/pydashie

do you have the link to the perl port? thx

Everyone complaining about the Flat UI. Isn't the use case for something like this to be displayed on a TV or large monitor around the office anyway? Seems like one place where the flat UI would be OK.

I'm not a Win 8 fan by any means, but I think this dashboard looks good. The bright/contrasty colors are exactly what are needed to broadcast metrics across the office.

Bright colors are exactly what are needed when something needs attention. This just yells "look, your most important metric just went up by 0.007%!"

Exceptionally handsome if you like Windows 8 perhaps. I don't like the big rectangles with bright colors. A good dashboard should be almost invisible until something important happens.

Come on man! Drink the koolaid and jump on the flat design bandwagon :P

I love the idea of a dashboard framework but under no circumstances am I going to make it harder on my users by adopting that Live tiles nonsense. Will be glad when that trend quickly runs its course.

Good thing the css is completely customizable :)

What terrible trolling. Just change the CSS template! Gah.

Is it trolling, though? Why should I see the potential in this dashboarding utility when there are dozens out there understanding the benefits of good visualizations, using proper colors for different situations?

Because it takes a few minutes of time you're already going to spend implementing it for a someone to change it?

Dashing contributor here: That's great, the default style isn't supposed to be a one-size-fits-all solution, and it's definitely not trying to dictate design decisions.

The real meat of the project is the underlying messaging that passes your data from the server to multiple clients.

You write a job that calls send_data, and Dashing takes care of the rest. There's room for as much customization as you like on the front end.

Are there any plans to have native graphite input widgets? This is super cool: http://thomasvm.github.com/blog/2012/11/19/bling-dashboards-...

But I don't understand why native graphite widgets aren't in dashing. These two projects (graphite + dashing) are literally made for eachother.

Dashing was built to run the internal dashboards here at Shopify. As such it's biased towards our existing technology stack. Seeing as we don't use graphite, we had no need to include widgets that support it.

That's why we want people to submit third-party widgets and jobs. We can't cater to all environments ourselves, but others can help out and share their own.

Ironically it doesn't work on IE10 on Win8.

Well it's always good to jump on the latest trend, you know. Many apps, including Chrome, are adopting this design style.

This popped up a few months ago. Unfortunately, not much discussion:

https://news.ycombinator.com/item?id=4718311

Well, maybe you can take a look at another dashboard framework I wrote. It uses PHP, pulls data directly from MySQL and works seamlessly on mobile browsers, tablets. :)

http://razorflow.com

Adding support for Google Analytics and Excel in the next two weeks!

I like it! I think Dashing and Razorflow serve 2 different purposes though. Yours is more of a hands-on & drilldown type dashboard, whereas Dashing is much more optimized for being readonly on a large TV.

Actually, we are working on adding support for TV/Kiosk mode where the components update the data regularly, and you aren't limited to showing only one set of components. The dashboard will slowly and automatically cycle through all different components so even if you have more widgets than your screen can handle, it'll still work better than not being able to work at all.

The main difference is that Dashing is focusing more on current KPIs and Metrics. While we believe that those are crucially important, sometimes they just aren't enough for people who have data that's too much to get condensed down to a single indicator.

I have been using Razorflow myself and impressed with it so far.

Looks great. Wish it used JavaScript instead of CoffeeScript to lower the barrier to entry though.

Interestingly for me it's the reverse: using CoffeeScript lowers the barrier to entry :-)

dafuq?

I would not be surprised if spinning up on CoffeeScript was easier for beginners without real JavaScript experience.

yeah, probably. Dunno if it's a good thing, that people start with a transcompiled language...

That's just an implementation detail. CoffeeScript has syntax and semantics every bit as valid as JS's.

True story. JavaScript seems like a mix of C and Scheme CoffeeScript seems like a mix of Ruby and Python

It was much easier to get started to CoffeeScript for me, and learning it made me much more comfortable with writing JavaScript directly straight after.

You can still use plain old JavaScript if you want.

I dislike CoffeeScript as much as the next guy, but the most complicated widget is 35 lines of CoffeeScript, most of which is pretty much identical to what the JS would be. There looks to be less than 100 lines of CoffeeScript outside of the widgets. If there's a project where I can overlook the use of CoffeeScript this is it...

For anyone interested in only the grid/rearranging js behind this: http://gridster.net/

Is batman.js supposed to be an alternative to angular? If so, what advantages does it have?

It's pretty well mapped to Rails and has some of the better documentation as far as JS MVC frameworks go. However there were a few problems I found with it, like the view bindings being somewhat slow if you're doing a lot of rapid updates (though that's likely not unique to batman.js).

Disclaimer: I work on the batman.js team

It's an alternative to ember, angular, knockout, backbone, and all those other client side MVC frameworks.

Its main advantage is that it should be very familiar to a Rails developer. The APIs are very close to what you'd find in Rails, so it should be quick to get into it. Shopify, which is built in RoR, now is completely client-side powered by Batman.js. The project was extracted from that.

hey pushmatrix, thanks for replying.

does batman.js have anything like angular's custom directives? are there any other features/advantages a possible adopter should know about besides the similarity to a Rails API?

EDIT: or perhaps phrased a slightly different way: why did you guys decide to create this instead of just using angular or one of the other existing options? or was this created before those options existed or had reached a mature state?

We wrote our own Dashboard at my current place, but it's nothing as nice as this!

This is great demo. But i really don't know, do everyone have the same use case? There is so many library that work great in demo, but doesn't suit my use case. I hate to build my own library (if i am able to use existing lib, why creating new?), but i must do this because some library/framework isn't really customizable. The time cost between customizing existing lib and creating new lib is the same, so i prefer to create my own library most of my time.

I've used other dashboards before, and I found that they are really limiting. For the most part it's because you can't customize the look that much, or it's because you're limited to a list of predefined widgets.

At Dashing's core, it's just a really simple way to fetch data and send it to the client. What you do with that data, and how you display it is up to you. Hopefully the default layout and widgets act as a good starting point.

I think that you'll find Dashing very flexible. You can fetch whatever data you need, and display it however you like.

At its core, Dashing is just a promise that all your data makes it to all your dashboards.

We're using dashing to present some internal information about our company's cashflow.

We built a second application (in Rails) that collects data from various sources, stores and transforms it, and then exposes it via API for dashing to use.

So in our case, dashing is a neat presentation layer and it serves its role very well.

Both of your demos are returning errors...

I was sleeping when I got news of Dashing being at the top :S. Haha. While I work on getting it stable, enjoy this screenshot: http://cl.ly/image/321Y2V361X1r

While I'm sure it looks fantastic on a dedicated monitor/tv, it's lack of a responsive layout limits it's use in my books

Looking at something like http://dash.social-biblio.ca/torontolibrary on a sub 1080p monitor is less than optimal.

We experimented with making the default layout responsive, but ultimately decided against it.

The thinking was that displaying exactly the same data on a TV, desktop, and mobile device isn't ideal. The dashboard is designed specifically for the display. If a mobile version is needed, then the relevant widgets can easily be put into a new, mobile-optimized dashboard.

The same could be achieved with carefully designed media queries, but I feel that separate dashboards do the job better.

This has made me sad because we're too far down a far uglier, and less functional route at work to change.

Coincidentally just started using this today. I've got a couple of widgets/jobs I'm hoping to share for re-use. Some on the wiki are out of date e.g. the Twitter ones that don't support Oauth will stop working soon.

Please do! If you want to add widgets with functionality similar to existing ones, please add details of the difference s to the description (e.g. 'Uses OAuth' for Twitter').

Dashboards! For when you don't know what to put on the screen that users will click away for what they actually want! /s

It would be interesting if the browser on SmartTVs rendered this properly, then you don't need a PC just for this...

Actually it does run on SmartTVs :). All of our displays at Shopify run this way.

The browser on SmartTVs really suck, and also don't support 1080p for some reason. Since the tv SDK is html/js, I built a super simple app that can point to any Dashing instance, and even use the remote control to switch between dashboards! Super handy.

I will be releasing that functionality soon as a plugin for Dashing.

I'm not a rails guy....why does something so cool looking have to be so closely coupled to a rails backend?

Not a rails backend. It's sinatra, so there's WAY less magic going on. A beginner rubyist should be able to grok most of the (tiny) source.

That being said, I'm working on decoupling the frontend and backend, which will see implementations in other languages.

giddyup!

Points from me even if just for the name alone :) Looks great, wish I could think of a use for it!

Here's some inspiration:

http://dash.social-biblio.ca/torontolibrary https://github.com/foobugs/foobugs-dashboard#stock-market-da...

Fantastic. Real time server stats with Dashing and a cheap plug computer would be great.

Doesn't seem to handle load very well, though normall I guess it wouldn't need to.

The demo is probably running on a free heroku instance which means a single thread on an itsy-bitsy EC2 instance. At the top of HN we're talking at least 500 concurrent visitors... on a single thread.

Bingo. It's on the free heroku, hence the trouble staying alive. Here's an image of what the demo looks like: http://cl.ly/image/321Y2V361X1r

Couldnt load the demo on Heroku, probably too few dynos for all the HN traffic...

Where's documentation of how to use the graph widget?

The graph widget is based on Rickshaw (http://code.shutterstock.com/rickshaw/).

The current implementation requires you to send an array of hashes with the x and y co-ordinates you want to plot.

Here's the example job where you can see it in action: https://github.com/Shopify/dashing/blob/master/templates/pro...

this looks lovely. can't wait to use it for internals

I don't get it. Why is something at the UI level coupled to a server-side framework?

Me neither and this is somehow scary. I'd prefer just an UI kit with guidelines for integration with backend.

Because it is meant to be a full stack framework.

Also, it's not really a UI kit. Although it comes with premise widgets and styles, these are just suggestions. The real meat is how the data gets to your widgets, letting you do whatever you want with it. That structure is the core of Dashing.

However, there is a decoupled version in the works with the integration guidelines you mention.

Check out Gridster.js then - http://gridsterjs.net

The server-side code needs to generate the server-sent events. You can probably switch it out easily.

nice , a few glitches here and there but definetly usefull.

that's awful. css and some javascript? do we really need anymore head-up-arse code junk floating around our heads right now? every five minutes there is a new javascript plugin/distraction that claims to change our lives. When will you people get a life and start solving real problems?

frankenstein coding, glue this sinatra dashboard to you php symfony "instance" and upload to s3. why waste our time? where are the integration points for this and who is really going to use it? Do i pitch this to my boss?

I did. And he said build it! We did, and employees have commented that they like the daily visibility in to company metrics they previously knew very little about.

Reply on news.ycombinator.com