How to create a dashboard in Python with Jupyter Notebook
mljar.com
mljar.com
We've been encouraging Graphistry users to look at Streamlit for the low-code side (and getting bundled into our next release for public+private pydata GPU dashboarding!) or Databricks dashboards. Then at the expense of significantly more code / complexity without going full Flask/Django, we generally recommend switching to Dash/Voila/etc for getting way more control. Mercury seems quite close to the Streamlit/Databricks side, which in our experience is right for many pydata dashboarding teams yet most tools don't really nail. It may even be on the path to one-upping streamlit on the simplicity side. Good job & will be tracking!
Additional features for sharing:
- user can download notebook as PDF or HTML,
- you can schedule notebook execution, and send executed notebook as PDF attachment in email notification,
- adding login view to notebooks is simple, just add `share: private` to YAML
- host multiple notebooks,
- you can easily hide code,
- you can schedule notebooks,
- you can download notebooks as PDF,
- you can easily add authentication to the notebooks.
It all depends on your needs and project requirements.
We render jupyter notebooks, markown and html - we dont host running jupyter environments -> but we focus on making the experience of sharing with non-techies on your team easy. So can show/hide the code, get comments etc.
[0] https://www.unite.ai/google-has-banned-the-training-of-deepf...
For dynamic data I build my dashboards with Flask and Plotly. However that is certainly a more involved process to migrate Jupyter notebook Python plots to JS plots.
For static data one can just export html(with embedded JS) from Jupyter notebook that uses plotly.
The main difference with quick solutions is the level of customizability.
What do you mean by dynamic data? Do you need automatically fetch new data in time intervals? (Mercury has scheduling and auto-update built-in with 1 minute lowest time interval).
If you need anything or want some help, feel free to make an issue or ping me on leo [-at-] datapane.com
- Why won't the OSS version provide features like history of execution? It seems like those are pretty basic to adoption. I'm working on an open source project, and it'd be a nice tool to potentially integrate. The commercial license is of zero interest since it's, well, all open-source.
- Why don't you sell the OSS version as well (e.g. for people who want to support you, or who want support)?
- Do you provide consulting services? Are they in the $50/hour range (just extrapolating from $200/year for up to 4 hours support)
- Why Django? I like Django, but it seems like using the same tech stack as Jupyter would make for simpler integration, administration, and lower TCO (plus the universe is going async)
- For presentation, the speed is an issue. Regeneration takes a while (I'm playing with the demo on Hugging Face). It's not quite adequate for interactive presentation. I do really like the concept of making presentations in Jupyter.
- And on that topic, the biggest gap I have is with interactive front-ends. I'd like to be able to somehow connect notebooks (both for dashboards and otherwise) for data munging to data visualization frameworks like D3. Jupyter is nice. Observable would be nice if it were open-source. There's a mile-high wall between the two.
- Selling OSS might be a great idea. Didn't consider it. I thought the Personal Pro version ($199/y) will be good for persons that would like to support the project or just need a support/guidance.
- Yes, I do consulting services. I don't treat support hours in similar way as consulting. The support is for product that I love working on and I love supporting people using it.
- Django - I'm pretty good at Django. What is more, I wanted to use Celery for processing background tasks and scheduling. This gives an architecture that can handle large loads. The frontend is in React with TypeScript.
- Speed can be improved. There are many ways to better handle that (it is version 1.0). You can add Plotly charts to make presentation more interactive. The advantage of Mercury is that you can recompute all slides if needed.
On a mile-high level, Mercury seems like a perfect fit for what I'm doing. Conceptually, it's exactly what I was looking for.
Diving into the code, the fit seems less great, for reasons which are incidental (and wouldn't be worth changing for one integration). I'm trying to constrain the number of technologies in the overall project, to make it maintainable and deployable, and you seem to be on a completely orthogonal stack.
So I'll keep diving in and trying to understand it better.
The Mercury generates UI based on the YAML header (very simple, no need to mix UI with analytics code). When user tweaks widgets values, the whole notebook is executed with new parameters and converted with nbconvert (using Django + Celery). Mercury can serve multiple notebooks to multiple users on one server. It has option to export notebook to PDF or HTML. You can schedule the notebook execution with crontab string (for example `schedule: '30 8 * * 1-5'`) and add email notifications. You can easily add authentication to notebooks. It was designed to make notebook sharing fast and easy.
What is more, I'm thinking about including Voila into Mercury. So you will be able to serve Voila apps with Mercury. The end-goal is to make notebooks sharing easy.
Mercury github repository https://github.com/mljar/mercury
awesome-jupyter > Rendering/Publishing/Conversion https://github.com/markusschanta/awesome-jupyter#renderingpu... :
> ContainDS Dashboards - JupyterHub extension to host authenticated scripts or notebooks in any framework (Voilà, Streamlit, Plotly Dash etc)
IIRC, ContainDS and Voila spawn per-dashboard and/or per-user Jupyter kernels with JupyterHub Spawners and Authenticators; like Binderhub ( https://mybinder.org/ ) but with required login and without repo2docker?
Streamlit lists Bokeh, Jupyter Voila, Panel, and Plotly Dash as Alternative dashboard approaches: https://github.com/MarcSkovMadsen/awesome-streamlit#alternat...
Says here that mljar/mercury is dual-licensed AGPL: https://github.com/mljar/mercury
E.g. BentoML is built on FastAPI which is async (sanic) and built by the DRF people, but FastAPI doesn't yet have the plethora of packages with tests/ supported by the Django community and DSF Django Software Foundation.
There's a neat overview of the landscape here https://www.youtube.com/watch?v=4a-Db1zhTEw
I've had a very bad history with dashboards. All I've seen get ordered up by nontechnical leadership, not looked at, and involved endless fiddling with painful corporate applications.
The non-technical stakeholders I've had a good relationship with, I vend a SQL script/Jupyter Notebook and educate. They're happy to up-skill.
I've only had dashboards requested by users with a dysfunctional relationship with engineering, in companies where the data is irrelevant.
In environments where data matters, fast moving consumer goods, web, etc, stakeholders speak SQL/Jupyter. I've seen remarkably non-technological people learn SQL and query read replicas because they need sales aggregates.
In environments where data doesn't matter, dashboards are requested as a corporate power play.
A director who doesn't care about your project asks for a dashboard to assert their authority, and remind you your budget can be cancelled.
I treat dashboard as visualization part. What is more, visualized data is used to trigger further actions - for example, send alert email. Yes, I found them useful.
My previous team had some business metric charts/dashboards related to system we worked on that we reviewed weekly. Most weeks review was it looks normal and was pretty fast review. Occasionally we'd see an unexpected deviation in some top level metric and that could trigger follow up work. Ideally all interesting deviations an alert would catch, but alerts are never complete.
Most of dashboards I've cared for my team/department was primary user of. I have not made dashboards much for other stakeholders.
Merely an observation about the dashboard industry.
That's where dashboards come in handy.
Certainly I would never expect people to be experts. SQL Group By is nontrivial.
The endless tinkering is still requested with the static reports, but that is much easier to deal with than serving up dashboards and tinkering with that.
https://www.amazon.com/Fisher-Price-DYW53-Rollin-Strollin-Da...
It's a kids toy that lets them pretend they're driving the car.
BTW, I love spreadsheets. Spreadsheets + Python is very powerful connection :)
I've been reasonably successful at creating a data environment for my company in which all the data is exposed through REST APIs.
The existing tooling for APIs in general is top notch. Also, you get a lot of architectural flexibility.
Generalizations or problematic, since so much of this depends on industry, company, and role.
I'm in an industry (education) where at-a-glance dashboards have a proven track record of dramatically improve learning outcomes. It turns out that:
(1) Teachers, while believing they know their students, actually don't. Teachers also regularly fail to grasp what students do and don't understand.
(2) Allowing teachers to monitor their students, both individually and classroom wide, leads to much better outcomes.
In the context of a classroom, teachers are busy, non-technical (and sometimes incompetent), so an at-a-glance view is critical. For an example of real-time dashboarding done well, see Learning Catalytics. It grew out of a highly-respected physics education research project (Peer Instruction, by Eric Mazur), and allows teachers to monitor student understanding during lecture. Showing where misconceptions exist allows for deeper dives and deeper conversation. There are many systems like it, and ample evidence of improved student growth when they're used.
That's very specific, I know, but there are similar examples in other industries I've worked in.
A very good point.
I remember a piece on programming education research awhile ago. Said education outcomes improved considerably if you constantly bombard students with multiple choice questions.
Administering that through a dashboard would be essential.
I would love to read more about that, if you happen to have a link to share.
I see the relevant part seems to be the following, in the "Tip 4" section:
""" The key to making demonstrations more effective is to make learners predict the outcome of the demonstration before performing it. Crucially, their prediction should be in some way recorded or public, e.g., by a show of hands, by holding up cue cards marked with A, B, C, or D, or by talking to their neighbour. We speculate that the sting of being publicly wrong leads learners to pay more attention and to reflect on what they are learning; regardless of whether this hypothesis is true, instructors should be careful not to punish or criticise students who predicted wrongly but rather to use those incorrect predictions as a spur to further exploration and explanation. """
However, it's not the most relevant part. The most relevant part is simple use of active learning. The classic paper here is Hake (Interactive-Engagement vs. Traditional Methods: A Six-Thousand-Student Survey of Mechanics Test Data for Introductory Physics Courses). However, it's been replicated discipline-by-discipline (lots of papers in PNAS). Best summary is ICAP by Miki Chi. Miki didn't invent it, and ICAP isn't the most rigorous, but she's pretty good at these summaries.
Having students do anything beyond listening leads to huge improvements in student learning, basically no matter what it is. Some things lead to bigger improvements than others, of course. Even clicking a "next" button occasionally shows a (very modest) gain. For good interactive engagement, doubling of learning gains is a good lower-bound over passive listening.
Not only active participation, but actively being forced to remember the knowledge, in a different format to the original, is the key.
Teaching another student is definitely an approach to this. But a gentle touch multiple choice question also works.
There's a broad range of techniques which have significant learning gains beyond passive learning. Active recall is one of them. We have no clear sense of how they compare to each other or how they work in combination. There is ample evidence for active recall, but there is equally ample evidence for a dozen other techniques much like it. We don't have great studies comparing them side-by-side.
The best hypothesis for how they compare is ICAP, referenced. It's still a hypothesis. You can look at the evidence behind it.
Much of this is context-dependent too. Active recall is great for factoids. If you're trying to learn a date in history, memorize a word in a foreign language, or a formula in math, your best bet is a spaced repetition system (how you time active recall makes a big difference too; spaced repetition > simple active recall > passive recall).
If you're trying to understand a concept like force (in physics), what an integral means (in math), make sense of the tradition away from serfdom, or compare ethical systems between two cultures, active recall is almost irrelevant. At that point, the best methods are probably constructive and interactive learning.
In my mind, active recall is an excellent technique that's appropriate for the first lecture covering a topic.
Which is why I like it as a prompt in a lecture, not so much later on.
Constructive learning in my mind comes later.
Re: the balance between constructive learning and other types.
I feel that we often accelerate the students too quickly to constructive learning, whilst they can still benefit from rote learning some worked examples.
The balance between rote learning and "copying" worked examples, and constructive learning from first principles, is a very difficult one.
I truly think that, certainly for programming education, all my professional life I've gotten huge mileage out of genuinely copying in example projects and tutorials into a text editor.
I think we underestimate just how much students benefit from rote learning.
I think programming education would benefit far more from 19 year old rote learning from retired 65 year olds. I find the college education system is fairly broken, in that it deploys researchers who are excellent lecturers, but far too few 65 year olds.
And there's an ocean of extremely willing to teach 65 year olds out there.
As originally implemented, the technique was pretty simple:
- You give a traditional lecture
- Every five minutes or so, students are asked a question to see if they understand concepts
- The system peers students who answered differently to discuss. Students can change their answers at the end.
- The instructor and class see aggregated statistics (e.g. 90% of people answered 27, 5% answered 54, and 5% gave other answers)
- Based on the feedback, the instructor can do a deeper dive into places where there are common misconceptions
Today's class is very different. Mazur juggles all sorts of peer learning models, 360 reviews, etc. in ways which are superhuman. But that's the original model.
Most of the uses of formative assessment lead to classrooms feeling more personal, more personalized, and more human.
There are control-oriented systems which scare the heck out of me, like GoGuardian and Securely, but this isn't it. There is a complex ethics question of how to build systems which don't dehumanize students.
The shy kids sit there and be quiet.
"Prompt" questions, like multiple choice, are a good way of encouraging reluctant students to come out of their shell."
Today, it's cell phones and laptops, and they do a lot more than multiple choice. Students might be asked to highlight text in a passage (and the system shows a heatmap), to draw vectors, etc.
They can't be trusted to dress themselves.
Sry, but this completly ... not true! Maybe in your subjective business environment, but definitely not for the whole community of python users.
We are placed in a scientific environment, teamworking with highly dimensional data. Here there is not a single person who has time to tinker around with another ones code nor data structure.
This will be a great benefit for regular report sessions - THX to the author!
[0] - https://streamlit.io/
Edit: A good example of this is something like incoming shipments for a warehouse. Management all the way down to warehouse workers need to know what is slated for delivery, what’s already been delivered in the last few days, and what’s late.
An example of actual dashboard culture is AWS’s operational metrics meetings. The construction of the dashboards themselves is scrutinized just as much as any latency or availability metric (may God have mercy on your soul if use a pie chart or display the median of metrics without justification). And it’s actually useful for surfacing issues and knowledge sharing. The frequent cadence can be a big cause if stress though.
Managing Oracle databases? Enterprise Manager Cloud Control.
Managing your investments? Schwab has a good interface.
But to your point there's often a principal agent problem in larger organizations. A decision-maker wants to appear "data-driven" so asks for a dashboard because it costs nothing for them to ask--someone else does the work. And when the dashboard shows something different than expected they dismiss the concern or find a reason that the dashboard is "wrong."