Clarification of the widget landscape
211 views
Skip to first unread message
Brad
Dec 15, 2016, 9:54:13 AM12/15/16
to Project Jupyter
Hi,
Jupyter is an amazing interactive analysis tool and the progress the team is making is truly impressive. Thank you all for your time and hard work!
My research group is looking to build a simulation and data analysis application using Jupyter as the framework.
As we are designing the app, we are imagining various widgets to help users input data and parameter values, run simulations, and examine output.
Unfortunately, my students are finding the situation with widgets in Jupyter a little confusing. I wonder if anyone would be so kind as to summarize and perhaps categorize the following:
IPython widgets
Jupyter declarative widgets
Jupyter dashboards
Polymer
WebComponents
They have read through documentation and have seen a few detailed examples and videos, but are having a hard time seeing the big picture and getting an idea of where they should focus for constructing our application.
I would also be grateful for pointers to any resources that you think would be useful in understanding this landscape.
Thank you for your help.
-Brad
Nicholas Bollweg
Dec 19, 2016, 10:33:20 AM12/19/16
to Project Jupyter
Brad:
Thanks for the interest!
We're excited to help you do really cool things with notebooks, widgets, etc. I guess it depends on what you mean by "application." Do you want something that lives "close" to the notebook, such that a scientist can use it during their work, with full access to kernels, etc. or is it a "display" that just shows information? Or a SaaS? Or a presentation? Or actually a "dashboard" on a device?!
With those questions in mind, I'll answer your last question first:
Thanks for the interest!
We're excited to help you do really cool things with notebooks, widgets, etc. I guess it depends on what you mean by "application." Do you want something that lives "close" to the notebook, such that a scientist can use it during their work, with full access to kernels, etc. or is it a "display" that just shows information? Or a SaaS? Or a presentation? Or actually a "dashboard" on a device?!
With those questions in mind, I'll answer your last question first:
I would also be grateful for pointers to any resources that you think would be useful in understanding this landscape.
I just updated this example to the newer APIs, based on this very dated example. This is more of a "replace the old broken computer next to my scientific
equipment," rather than "what is the scheduling status of this
machine?" On the API maturity side, it took about five minutes to get it working, which isn't that bad considering two years had elapsed, in which we split everything up, and have done many releases of every component! I can vouch for python-driven widgets being a sound way to build up rich, maintainable GUIs!
Here is a recent talk I did at PyData ATL (sorry, no recording) which is arguably an application, in that it is (a number of) live coding environment(s). In that talk, to make matters worse, I use nbpresent, as another way of laying out notebook content, including widgets (sort of a sibling/competitor to Jupyter Dashboards).
Ok, to your specific stuff:
ipywidgets is (historically) the reference implementation of Jupyter Widgets.
When you install the python module of ipywidgets, it also updates some JavaScript (jupyter-js-widgets), which is loaded into the notebook.
For many kinds of interactive computing activities, you might not need to write any JavaScript, CSS and HTML, and get the full complement of GUI stand-bys: buttons, sliders, layouts, etc. With a little bit of CSS knowledge (written in a pythonic way), you can have pretty attractive content. See the example at the beginning!
The Jupyter Dashboard has two components: the authoring tool and the server. The authoring tool lets you visually construct content on a single-screen scrollable dashboard, where the individual content pieces can be markdown, code, output or any widget (including, therefore, declarative widgets... though it does take some extra work), and bundle up the content. The Server can accept these bundles, and host them in a relatively secure way via Docker and clever proxies, and as such can be good for standing up "hands-off" dashboards like kiosks and NOC/EOC kind of big displays.
Polymer is the mother-of-all polyfills for browsers that don't yet support WebComponents... basically, you can use the future standard, today, at the price of a pretty big slug of JavaScript monkeypatching your environment, which is a totally normal practice, just that Polymer does a LOT, because...
WebComponents are the "not widely distributed" future standard of web development. They will presumably end much of the "tool churn" we have been seeing in React\Angular\Phosphor space, but it will take a while once they are a generally-available feature. They support things like data binding, encapsulating style, shadow DOM, and other things that I haven't wrapped my head around.
Here is a recent talk I did at PyData ATL (sorry, no recording) which is arguably an application, in that it is (a number of) live coding environment(s). In that talk, to make matters worse, I use nbpresent, as another way of laying out notebook content, including widgets (sort of a sibling/competitor to Jupyter Dashboards).
Ok, to your specific stuff:
IPython widgets
ipywidgets is (historically) the reference implementation of Jupyter Widgets.
When you install the python module of ipywidgets, it also updates some JavaScript (jupyter-js-widgets), which is loaded into the notebook.
For many kinds of interactive computing activities, you might not need to write any JavaScript, CSS and HTML, and get the full complement of GUI stand-bys: buttons, sliders, layouts, etc. With a little bit of CSS knowledge (written in a pythonic way), you can have pretty attractive content. See the example at the beginning!
Jupyter declarative widgets
Declarative widgets gives access to the underlying widget API: Instead of python, you're mainly writing HTML and JavaScript. The bits and pieces gets installed via bower, yet another javascript dependency management ecosystem, instead of a python-focused one.
Jupyter dashboards
The Jupyter Dashboard has two components: the authoring tool and the server. The authoring tool lets you visually construct content on a single-screen scrollable dashboard, where the individual content pieces can be markdown, code, output or any widget (including, therefore, declarative widgets... though it does take some extra work), and bundle up the content. The Server can accept these bundles, and host them in a relatively secure way via Docker and clever proxies, and as such can be good for standing up "hands-off" dashboards like kiosks and NOC/EOC kind of big displays.
Polymer
Polymer is the mother-of-all polyfills for browsers that don't yet support WebComponents... basically, you can use the future standard, today, at the price of a pretty big slug of JavaScript monkeypatching your environment, which is a totally normal practice, just that Polymer does a LOT, because...
WebComponents
WebComponents are the "not widely distributed" future standard of web development. They will presumably end much of the "tool churn" we have been seeing in React\Angular\Phosphor space, but it will take a while once they are a generally-available feature. They support things like data binding, encapsulating style, shadow DOM, and other things that I haven't wrapped my head around.
They have read through documentation and have seen a few detailed examples and videos, but are having a hard time seeing the big picture and getting an idea of where they should focus for constructing our application.
Hopefully some of the information above was helpful!
If you can deal with "just python", my recommendation would be to use ipywidgets, and stick as close to that baseline as possible. If the work you are doing supports people that are already working in the notebook, this will be the easiest to install/maintain. Stock widgets will work nicely in the Jupyter Dashboard server, if you need to deploy them.
Your team would write mainly Python. With a little python object-oriented programming, you can prototype your dashboard in the notebook, then make it reusable as your analysis grows.
If you start needing some special stuff, evaluate the existing offerings (i.e. bqplot, ipyleaflet, pythreejs, etc.) If they meet your need, hooray!
If you end up building truly custom widgets (as opposed to python-based confections), it may be worth evaluating the declarative widgets approach, though that does bring another level of "ops". Otherwise, there are tools to help you get going with writing and packaging your own work as modules.
Let us know how else we might help, and of course share anything cool you guys make!
Brian Granger
Dec 20, 2016, 4:22:26 PM12/20/16
to Project Jupyter
Brad,
Great question. Nick has done a great job and answering this question
and providing a lot of background. I wanted to fill in a few other
aspects that may help you decide what fits for you and where things
are headed.
In general, there are a number of factors that go into where the
project is headed:
* The planning and roadmap work from the core project contributors
about where we want to go
* Which of the various options are attracting users
* Which of the various options are attracting developers
* Which of the various options have funding to hire developers
* etc.
On all of these fronts, I think ipywidgets is the best bet:
* It has the largest number of users of the various options and has
been around the longest
* We have funding to work on it
* There are a number of core developers putting a lot of time into it
* There are a number of third parties building on top of it
* It continues to be our top priority on the roadmap in this area
The other thing to note is that much of what you describe in your
original question can be done with ipywidgets out of the box. In other
words, you can probably get a lot done by importing ipywidgets and
using it - without diving into JavaScript and building custom widgets.
I should mention though that ipywidgets is going through a phase of
massive change and development right now. Because of this, lots of
internal details will change over the next year. However, we are
working hard to make sure the Python APIs change minimally, if at
all. But even on the JavaScript side, we are working hard to minimize
the changes needed. The good news, is that all of the work being done
reflects the fact that ipywidgets is moving quickly and getting a lot
of improvements.
Hope this helps.
Cheers,
Brian
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+u...@googlegroups.com.
> To post to this group, send email to jup...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/5df08561-e25e-4a96-9de5-33faeae804bc%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgra...@calpoly.edu and elli...@gmail.com
Great question. Nick has done a great job and answering this question
and providing a lot of background. I wanted to fill in a few other
aspects that may help you decide what fits for you and where things
are headed.
In general, there are a number of factors that go into where the
project is headed:
* The planning and roadmap work from the core project contributors
about where we want to go
* Which of the various options are attracting users
* Which of the various options are attracting developers
* Which of the various options have funding to hire developers
* etc.
On all of these fronts, I think ipywidgets is the best bet:
* It has the largest number of users of the various options and has
been around the longest
* We have funding to work on it
* There are a number of core developers putting a lot of time into it
* There are a number of third parties building on top of it
* It continues to be our top priority on the roadmap in this area
The other thing to note is that much of what you describe in your
original question can be done with ipywidgets out of the box. In other
words, you can probably get a lot done by importing ipywidgets and
using it - without diving into JavaScript and building custom widgets.
I should mention though that ipywidgets is going through a phase of
massive change and development right now. Because of this, lots of
internal details will change over the next year. However, we are
working hard to make sure the Python APIs change minimally, if at
all. But even on the JavaScript side, we are working hard to minimize
the changes needed. The good news, is that all of the work being done
reflects the fact that ipywidgets is moving quickly and getting a lot
of improvements.
Hope this helps.
Cheers,
Brian
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+u...@googlegroups.com.
> To post to this group, send email to jup...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/5df08561-e25e-4a96-9de5-33faeae804bc%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgra...@calpoly.edu and elli...@gmail.com
Brad
Dec 22, 2016, 12:52:04 PM12/22/16
to Project Jupyter
Hi Nicholas,
Thank you very much for the detailed explanation. It is greatly appreciated.
FYI, our application will be something that scientists (not necessarily experienced programmers) will use to conduct simulations and data analyses. The users will interact with a browser-based UI, but most of the heavy-duty calculations will be performed using a simulation engine that will reside on the user's own machine or on a more powerful server. The Jupyter notebook by itself is a little too 'code centric' for the UI, so we need to build some tools and interface elements to allow the scientists to conduct studies with a minimal amount of coding on their part. We also anticipate that more sophisticated users may want to dive in and use elements like code cells for more specialized calculations.
Kind regards,
Brad
Brad
Dec 22, 2016, 1:02:08 PM12/22/16
to Project Jupyter, elli...@gmail.com
Hi Brian,
Thank you for the advice.
It sounds like we should first see how far we can go with ipywidgets.
Is there a way of monitoring progress on this front to see what developments and API changes take place?
Would it be appropriate to request a certain widget type if we foresee that it may have utility outside of our project?
My sincere thanks to all of you who are involved in developing and improving the Jupyter platform so that it can continue to grow as a powerful and flexible platform for scientific exploration and other applications.
Kind regards,
Brad
Sylvain Corlay
Dec 27, 2016, 7:50:14 AM12/27/16
to jup...@googlegroups.com
Hi Brad,
Regarding the progress in ipywidgets, we are currently working on the
6.0 release. You can track the 6.0 milestone on the ipywidgets
repository. The main objectives in 6.0 are
- the JupyterLab integration.
- the deployment of Jupyter Widgets in other contexts than the
notebook (sphinx docs, nbviewer, standalone apps)
- the improvement of the overall UX of the core set widgets
- the formal specification of protocols, mime types and file formats.
From a more technical standpoint, 6.0 also includes the migration to
typescript and the phosphorjs framework.
More than a set of core widgets, ipywidgets is meant to be a point of
extension for custom widget library authors. pythreejs, ipyleaflet,
bqplot, nglview, the autodesk molecular design toolkit are all custom
widget libraries built upon it.
Some additions might be made to the core set of widgets. One is a date
picker. We have also made prototypes for token-input widgets.
In terms of more complex widgets such as a grid / spreadsheet widgets,
it is unlikely that such a project would be made part of the core set
of widgets. Instead, it will probably be a custom widget library (just
like bqplot or ipyleaflet) making use of the future phosphorjs
spreadsheet.
Cheers,
Sylvain
> https://groups.google.com/d/msgid/jupyter/4d135b0f-4c1e-4d44-bfde-b4cc6960f930%40googlegroups.com.
Regarding the progress in ipywidgets, we are currently working on the
6.0 release. You can track the 6.0 milestone on the ipywidgets
repository. The main objectives in 6.0 are
- the JupyterLab integration.
- the deployment of Jupyter Widgets in other contexts than the
notebook (sphinx docs, nbviewer, standalone apps)
- the improvement of the overall UX of the core set widgets
- the formal specification of protocols, mime types and file formats.
From a more technical standpoint, 6.0 also includes the migration to
typescript and the phosphorjs framework.
More than a set of core widgets, ipywidgets is meant to be a point of
extension for custom widget library authors. pythreejs, ipyleaflet,
bqplot, nglview, the autodesk molecular design toolkit are all custom
widget libraries built upon it.
Some additions might be made to the core set of widgets. One is a date
picker. We have also made prototypes for token-input widgets.
In terms of more complex widgets such as a grid / spreadsheet widgets,
it is unlikely that such a project would be made part of the core set
of widgets. Instead, it will probably be a custom widget library (just
like bqplot or ipyleaflet) making use of the future phosphorjs
spreadsheet.
Cheers,
Sylvain
Reply all
Reply to author
Forward
0 new messages