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 On Monday, December 19, 2016 at 8:33:20 AM UTC-7, Nicholas Bollweg wrote: > > 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: > > 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 > <http://nbviewer.jupyter.org/gist/bollwyvl/47d06961f9d39f3fba6e76d2e7417ab3> > to the newer APIs, based on this very dated example > <https://gist.github.com/bollwyvl/ddd4bf5d7c879012fa2c>. 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 > <https://github.com/bollwyvl/exploring-data> (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 > <https://github.com/Anaconda-Platform/nbpresent>, as another way of > laying out notebook content, including widgets (sort of a > sibling/competitor to Jupyter Dashboards > <http://jupyter-dashboards-layout.readthedocs.io/en/latest/index.html>). > > Ok, to your specific stuff: > > IPython widgets >> > > ipywidgets <https://github.com/ipython/ipywidgets> is (historically) the > reference implementation of Jupyter Widgets <http://jupyter.org/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 > <https://github.com/jupyter-incubator/declarativewidgets#including-a-web-component-in-a-notebook>. > > 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 > <http://jupyter-dashboards-layout.readthedocs.io/en/latest/index.html> > 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 polyfill > <https://en.wikipedia.org/wiki/Polyfill>s 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" > <http://caniuse.com/#feat=custom-elements> 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 <https://github.com/jupyter/widget-cookiecutter> 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! > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to jupyter@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/cae3b758-f310-4a5f-be85-dbc52f6dc590%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
