Design Principles

[jpsamaroo]

Here's a list of "design principles" that I think a successful meta-framework for GUIs should keep close to heart:

Widgets:

• Writing widgets should be easy and generic in the common case - We should provide some basic "widget skeletons" that can be reused and "filled in" to create basic widgets, or more complex widgets when used in combination. And of course, these "widget skeletons" could be provided by another package too.
• Widgets are not just rendering - Interaction is equally as important as rendering, and shouldn't necessarily be logically separated from rendering; there are times when the logic for interaction depends intimately on the logic for rendering, and vice-versa, and we shouldn't make that situation feel awkward.
• Leverage multiple dispatch where it makes sense - duh
• The user is always right - Users should always be able to override "type-to-widget conversions" (i.e. how a value with a certain type dispatches and is then rendered as a certain widget). This means that if the user made their own widget for rendering a certain type of value, it shouldn't be hard for them to use it.
• Backend-specific widgets should be preferred over generic fallbacks - If possible, it should be possible to indicate the kind of widget that a value renders as (itemized list, free-form text, a button, etc.), and in the absence of a user-specified widget choice, the rendering should opt for the widget which is native to the GUI toolkit.

Layouts:

• Widgets don't get to make demands about their size or placement - If a layout engine needs to give them a certain very odd size, they have to suck it up and figure out how to render properly. Even if "render properly" implies displaying some bold text indicating that the widget is too small to be useful... Of course, allowing widgets to communicate preferred sizing/locations (like docking) to the layout engine is something that should be considered.
• Parent-child relationships between structs don't necessarily imply UI relationships - Just because a.field = b, doesn't mean that b should automatically be rendered as a "child widget" of a. It's easily possible that there is a mutual relationship between a or b, or that in fact a and b should never be rendered as a pair in any manner.

Styling:

• Styling is very preference driven, and shouldn't be hard-coded. The user should be able to apply a "style template" to all or some set of widgets that overrides some or all of the defaults. (Ideas for how this would look are very welcome).

[JeffreySarnoff]

All successful G/UIs have some internal commonality of purpose/presentation/representation. We are allowed to provide flexibility (i.e. recipes, color/look schemes), however imo it is a mistake to allow cacophony by high-level specification. Anyone who knows enough to get into lower levels can do whatever they choose, but for this to be successful -- people need to get something that works well for them and others.

[JeffreySarnoff]

@shashi your thoughts?

[essenciary]

• We don't need to reinvent the wheel, the solution is out there: RShiny is the golden standard ++ There's also Plotly's Dash, but seems to have less traction (yet)

• quasy parity with RShiny API means that a) we can avoid making mistakes while learning, benefiting from their experience b) the user migration from RShiny will be very easy

• ideally everything should be done in Julia, including: ++ layout ++ widgets and interaction. From a user perspective the widgets only exist in Julia and they only think in Julia code. The rendering and data passing is done auto-magically. Users only stay in Julia land. ++ ability to install extra widgets and extra themes from within Julia (no messing with NPM or including JS and CSS files) ++ could/should leverage Pkg to allow dependency management and versioning that is familiar (so plugins should be Julia packages) ++ scaffolding features as mentioned already - we could use PkgTemplates for this

• building a community is a major advantage - look at WordPress for a successful example. There should be repos where users can publish and discover widgets and themes. If we leverage Julia's Pkg there should be a way to discover such packages (maybe by a naming convention).

• easiest to start by extending Interact.jl / WebIO - the community is already used to these. ++ in this line of thinking, WebSockets communication will do, to start with

• but keep an eye on the near future, especially the progress in WASM compilation. Again, no need to reinvent the wheel, Microsoft is doing it right via Razor and Blazor (https://www.hanselman.com/blog/WhatIsBlazorAndWhatIsRazorComponents.aspx) ++ I wouldn't bother with server side and client side diffing a-la Phoenix - WASM is the future and Valentin and Keno are already building it.

[jpsamaroo]

@essenciary can you give some links to RShiny's documented API?

[jpsamaroo]

Also, RShiny appears to be a web application platform, but doesn't address desktop or terminal UIs. Is this accurate? If so, that'd be a deal-breaker for those applications which don't need/want the overhead that a network connection brings with it (among other reasons, like requiring the bloat of a web browser just to have a UI).

[shashi]

I would urge everyone to look at Travis and my talk in this year's JuliaCon, I am happy with the way it was presented, it is a good compendium of the features and a philosophy of WebIO, most of which overlaps what is said here. https://www.youtube.com/watch?v=A3_vpuFqb-0

I am working on turning the talk into an interactive web page. Will update here once it is done.

I have some thoughts on RShiny:

Pros:

1. It's a very easy set-up: you write one file for the server one file for the client (if I am correct) and things just work.
2. They have a widget gallery https://shiny.rstudio.com/gallery/widget-gallery.html

Cons:

1. I think writing widgets itself is very different from writing a Shiny app

With WebIO, one can write a rather trivial package which includes say, Mux and WebIO, just provides a launch() function that can take a file or function that contains a UI and serve it. This would serve the purpose of Pro 1. And I believe we don't have the Con I listed :)

Finally, I see Julian (as well as Jeffrey in a phone call) has referred to a kind of "UI recipes" framework, I'm all for that and we should take inspiration from the success of PlotRecipes.

[JeffreySarnoff]

I watched that Presentation and found it useful -- to see, and to use.

[JeffreySarnoff]

Also R Shiny has a LOT of time person-hours corporate $ behind it. And to really use it fully costs. Here is its cheat sheet https://github.com/rstudio/cheatsheets/raw/master/shiny.pdf

[JeffreySarnoff]

I see nothing wrong with utilizing some good ideas from RShiny. I see much right with doing well with the best of what is available to us (e.g. WebIO, Mux, ClmGui, JSON3 ..) and filling in where we need to. I am not advocating just using the elements that exist as is -- we can, and should, combine their best aspects to have something more tangibly useful to [less expert, less experienced] others.

[JeffreySarnoff]

from @shashi If I understood Jeffrey's intentions correctly, the purpose is the following: "proliferate Web-technologies based GUI/component making in the Julia community." From our phone call we decided that the actionable items are:

1. A more beautiful library of widgets -- Interact widgets currently look like crap, Jeffrey suggested using Semantic UI with some customizations -- I'm fully in on this idea
2. UI Recipes -- so that packages can take minimal dependencies and define how packages can "specify" the UIs they need -- this is more up in the air as to what is the API and what exactly are the kinds of UIs people can "specify"
3. Layout constraint optimization -- there is a bunch of literature about automatically laying out UI components, we should use them. This + UI Recipes could work together to make it a breeze to build interfaces.

Of course this is not an exhaustive list, but 1. is the minimal, 2 and 3 would accelerate adoption, along with an easy server set up like in Rshiny

[JeffreySarnoff]

@jpsamaroo By desktop-native I understood you as recommending we adapt ClmGui to the principles, stylings we arrive at as this all gets perfected. And meanwhile filling the gaps that most need filling -- we want Makie plots to be expressible through both the "desktop" and "browser" G/UI realizations. A cheap way to get that, I suppose, would be put it in another window -- can ClmGui spin off a browser window with context or else embed a dynamically rotatable/scalable graphic?

[essenciary]

@essenciary can you give some links to RShiny's documented API?

This is the whole RShiny API: https://shiny.rstudio.com/reference/shiny/1.3.1/

[shashi]

Some references:

1. An old discussion about a UI Recipe system: https://github.com/piever/InteractBase.jl/issues/38 . Widgets.jl came out after the discussion but may not be what we're looking for here!
2. A series of blog posts about automatic layouts: https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/