Roadmap for dashboard 2.0

[wshager]

It has been some time since anyone suggested a new version of the dashboard. I would like to make a serious attempt this time.

I've gotten a lot of positive feedback on my proposal to use Dojo 1.10 as the basis for the dashboard, which is miles ahead of the version currently used. For those who don't know, however, Dojo does have some downsides, as there is some very ancient code to support browser that we've all forgotten about, like IE8 and even older. As my plan now stands, only the bare essentials from Dojo will be used. As I know the code base very well [1], I know what is only used by those unknown, prehistoric browsers, and can be, as they say, ditched [2]. Of course I want to keep the footprint as small as possible, and would gladly opt for any other widget system that work as well as Dojo's does.

Instead of a plugin system, the idea is to add expath packages to the dashboard that can be told to become available as a dashboard popup (as proposed by @adamretter). The XAR will register as a very basic widget, provided as a single AMD module. The widget must be AMD-compatible and will have to render its own DOM after loading.

A tiny roadmap:

• create empty dashboard with XAR dropzone or package manager (chicken/egg problem?)
• sketch out minimal widget requirements and compatibility guidelines, based on new collection browser
• have package register as open-in-dashboard
• open said package in popup on click (use alt-click to open in new tab/window?), where popup pulls in required sources (AMD "widget" module, CSS)
• provide guidelines for creating a self-rendering widget

Notes: [1]: As a Dojo contributor I'm also closely following the developments of its upcoming version 2.0 release. [2]: For example, the collection browser uses a form framework I created, dforma, where only the AMD loader, dstore, dgrid, and some very basic widgets are used. The rest of the code is mine.

[wshager]

Another option would be to simply use an iframe.

[wshager]

If (self-rendering-widget) then require(self-rendering-widget) else open-in-iframe

My idea is to merge the dashboard with the package manager plugin, since they use the same xquery. To manage packages and see details, the dashboard could be "flipped". Agreed?

[adamretter]

Sounds interesting @wshager. At the moment @JoernT is responsible for the Dashboard in eXist and I think he will reply to you soon...

[JoernT]

Wouter,

in the old dashboard the main UX problem is the mixture of 'plugins' and 'real' xar applications. This has been identified as the main thing to improve in a new version.

As the amount of plugins is limited we decided some time ago that the plugins should go into a menu and leave the main content area for the xar icons. So, first of all the plugin concept as it was is dead. Same applies to the use of popups. The former plugins (we need a new name here e.g. admin modules) would simply also use the main content area to display their UI. Optionally we can think of the content area as a tabbed interface (or deck) allowing you to leave some admin modules open (and in their respective state).

As the set of admin module is more or less static with just eventual changes in the longer term we can use build optimization tools and the need for something like AMD loading is of less interest. We'll have a single, optimized file anyway.

Leaves the question of the libs to use for implementing the frontend. As you probably know i'm quite critical about Dojo for 2 reasons. Our own experiences with it (which i confess are outdated now) were not too great. While surely being well-engineerd we always found it hard to use if you not at it from day to day and having a steep learning curve. So much for my personal feelings (not being alone here) but more critical is that we lack any Dojo knowledge in the core eXistdb team and it's not likely we'll build it up just for the dashboard and its modules.

The dashboard is a critical part of eXistdb as it is the part new users see first. So we consider it important being able to modify, extend and maintain it. We cannot risk to be dependent on external knowledge for this part (no offense here). Further we'd like to avoid to be locked into a specific framework. While it's ok to use libs it's a different thing if you're locked e.g. into using a specific set of widgets - it should always be possible to mix and match with other cool stuff coming up.

For the constructive part ;) here some requirements:

• must be mobile-ready (responsive)
• single admin modules should be implementable in separate xar files
• must be accessible (don't use iframes)
• must be easy to extend (configurable admin modules)
• should be themeable
• should be retina-ready (use vector grafix/fonts whereever possible)
• some more?

[adamretter]

This sounds great -> "tabbed interface (or deck) allowing you to leave some admin modules open (and in their respective state)".

I will also support Joern in saying that I too had quite a negative experience of Dojo in the past; That is not to say that I wasn't just daft, I am sure others work very well with it.

[wshager]

As I've already explained, Dojo has many pain points (you show me yours and I'll show you mine), but I can ease them out, by providing simplicity and guidelines. I've considered many times to break free from it, but like I said, there are few alternatives that provide the same level of control and cleanliness (I'm open to discussion here). As to the learning curve: it is just javascript. If you think Dojo is hard to learn, expect the worst when ES6 is fully unleashed. Final word: any beef you have with Dojo you can blame on me, and I'll pass it on to Dylan Schiemann et al.

I share @JoernT appetite for requirements, but as it stands there are currently none of those mentioned. I want to start with improving on what is now the dashboard, as I'm sure by the time we're ready, those requirements will have changed again.

My current idea is to simply recreate the package list and manager into a single widget (or dijit, if you will), reusing what good code is in there, and cleaning the rest up. This is basically what I did with the collection browser. If you'd just have a quick look at it you can see it's absolutely stand-alone and not a plugin. Even when throwing everything together in a menu-based or tabbed UI, I'd propose the same level of modularity, in both UI and XQ.

[joewiz]

Work on "dashboard 2.0" can be found at https://github.com/eXist-db/existdb-dashboard.