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.
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
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.
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...
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. :)
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.
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.
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.
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).
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.
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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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').
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.
84 comments
[ 2.9 ms ] story [ 95.0 ms ] threadWe 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.
https://news.ycombinator.com/item?id=4718311
http://razorflow.com
Adding support for Google Analytics and Excel in the next two weeks!
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.
http://dash.social-biblio.ca/torontolibrary https://github.com/foobugs/foobugs-dashboard#stock-market-da...
That being said, I'm working on decoupling the frontend and backend, which will see implementations in other languages.
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
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
We have a platform that really needs this, so I'm looking forward to using it immensely.
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.
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?
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.
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.
But I don't understand why native graphite widgets aren't in dashing. These two projects (graphite + dashing) are literally made for eachother.
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.
Looking at something like http://dash.social-biblio.ca/torontolibrary on a sub 1080p monitor is less than optimal.
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.
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.
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.
At its core, Dashing is just a promise that all your data makes it to all your dashboards.
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...
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.