Dashing - A dashboard framework(shopify.github.com)
shopify.github.com
Dashing - A dashboard framework
http://shopify.github.com/dashing/
84 comments
Dashboards! For when you don't know what to put on the screen that users will click away for what they actually want! /s
Fantastic. Real time server stats with Dashing and a cheap plug computer would be great.
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.
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.
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
Looks great. Wish it used JavaScript instead of CoffeeScript to lower the barrier to entry though.
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...
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.
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.
yeah, probably. Dunno if it's a good thing, that people start with a transcompiled language...
You can still use plain old JavaScript if you want.
Couldnt load the demo on Heroku, probably too few dynos for all the HN traffic...
this looks lovely. can't wait to use it for internals
This has made me sad because we're too far down a far uglier, and less functional route at work to change.
This popped up a few months ago. Unfortunately, not much discussion:
https://news.ycombinator.com/item?id=4718311
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!
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.
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.
Points from me even if just for the name alone :) Looks great, wish I could think of a use for it!
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
We wrote our own Dashboard at my current place, but it's nothing as nice as this!
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.
That being said, I'm working on decoupling the frontend and backend, which will see implementations in other languages.
giddyup!
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
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'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.
We have a platform that really needs this, so I'm looking forward to using it immensely.
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
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.
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!
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
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.
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!
Is batman.js supposed to be an alternative to angular? If so, what advantages does it have?
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.
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?
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?
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).
nice , a few glitches here and there but definetly usefull.
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.
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.
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.
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.
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.
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.
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?
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.
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 :)
Come on man! Drink the koolaid and jump on the flat design bandwagon :P
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.
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.
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.
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%!"
For anyone interested in only the grid/rearranging js behind this: http://gridster.net/
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.
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.
At its core, Dashing is just a promise that all your data makes it to all your dashboards.
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...
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...
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.
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.
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').