> It really depends on what your goal is: a refreshed UI or getting rid of > AngularJS
I think that's an interesting question. Do we _know_ how a refreshed UI could be better than what we have now? *) Better mobile UI was one suggestion *) Reviewing it myself, I feel that there is lack of clarity whether some information/operation is Global, Collection-level, Core-level, or node-level. E.g. "Dashboard, java properties and thread dumps" are actually node level, next to Cloud, Collections and Suggestions that are global level. Next to logging, which I am guessing is a node level. *) Query screen had a number of requests against it, especially in regards to newer features *) Pluggable UI (e.g. for DIH) was a request and other plugins (/browse?) would probably enjoy a hook too (though it did not work out with admin-extra.html so much) Because that's the first question a "UI designer from somewhere" will ask, even if we could have an access to one. Regards, Alex On 15 April 2018 at 19:04, Upayavira <[email protected]> wrote: > Jan, > > The plus of the Angular upgrade path that I saw you mention elsewhere was > that you could have both old and new Angulars running in the same app, and > migrate slowly. That would work for a change of backend, using the same > styling. > > It really depends on what your goal is: a refreshed UI or getting rid of > AngularJS. > > My aim was to keep the UI the same as this gave a very clear way to validate > success. If you change the UI at the same time, identifying success becomes > harder. > > Also, replacing the backend without changing the UI is quite possible with > limited graphic design skills. Modernising the UI would require a different > set of skills, and would probably involve us bringing in a UI designer from > somewhere to give us mocked-up components to start from. > > So really, the question as to how best to do it will likely depend on who is > doing the work. > > Upayavira > > On Sun, 15 Apr 2018, at 6:13 PM, Jan Høydahl wrote: > > Just to be clear, Angular is now also built on components, transpiled and a > rich toolset, including debugger, unit testing, end-to-end tests, CLI with > scaffolding for adding new components/services etc. > > Building using components will also help prepare the new UI for a plugin > architecture where Solr contribs/plug-ins add their own UI menu items and > screens dynamically (dynamic loading vs build-time compiling). > > The old UI grows with more screens and features week by week so the burden > of switching does not become smaller if we wait. > > Upayavira, moving from jQuery to AngularJS took the approach of building a > clean parallel code base, with the downside of years of maintaining two > UIs. Do you see any better approach this time around? > > Jan > > Sendt fra min iPhone > > 15. apr. 2018 kl. 14:20 skrev Upayavira <[email protected]>: > > > > On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote: > > Hello, > > > The relevant JIRA is SOLR-12196, but we felt this deserved a greater > discussion. > > > Basically, our Admin UI is currently using AngularJS (1.x) as its > > Javascript framework. That particular library has reached its > > evolutionary end long time ago and is about to stop being supported > > all together. The later versions of Angular carry the same name, but > > are _very_ _very_ different. So, despite the heroic efforts that got > > us here, we are facing this choice again. Also, as we were just trying > > to migrate the UI and not rethink it, the underlying design/file > > layout/plugin architecture is also quite problematic. > > > The question is what is the right thing to do next. There are > > basically four options: > > 1) Migrate to the latest Angular in an incremental fashion (as per > > JIRA's original proposal) > > 2) Jump to a different library (such as React or Vue) which got a much > > stronger momentum and ecosystem these days, but sort of keep current > > architecture (UI feel/approach) > > 3) Go blue-sky with new library and actually put some deep thought > > into modern UI leveraging Solr's current features (Management API, > > JSON, etc). Also, by picking React (for example) we get access to the > > ecosystem of modern tools, extensions and even potentially mobile > > apps. > > 4) Drop our own UI and adopt somebody else's (I don't have any good > > suggestions here though)? > > > Normally, option 1 would be the sane one. The challenge is two fold though: > > a) Even option 1 is a lot of work due the Angular team's radical > > change of direction. Enough that it will lock us out from any other > > option for at least another 3-4 years. > > b) We are all server-side developers. So, even the simple Javascript > > things are hard for us, never mind the CSS part. So, this makes the > > cost of starting with any new approach dis-proportionally hard. Once > > going, it is a bit easier, because the advanced concepts are similar > > to other languages. > > > All of these, combined with all the open JIRAs on Admin issues - to me > > - make option 3 less crazy than usual. > > > What do others think? Is there discontent with the current state of > > Admin UI (apart from the implementation choice)? Are there secret web > > designers here, willing to get us over a bump of migration? Is there a > > company out there, willing to sponsor relevant skills to let us > > leapfrog the incremental upgrade (similar to how we got the Reference > > Guide). > > > As you know, I'm responsible for the current UI. The aims in building this > version of the UI were to keep the visuals entirely the same, whilst > reducing the size and complexity of the underlying JavaScript (we reduced it > by about 50% in terms of LoC). The bulk of the work in its implementation > was in terms of understanding the intent of the existing code. Reproducing > it in new code was a smaller task by comparison. I hope this will pay off in > any future rewrite. > > At the time, the JavaScript landscape was changing fast. It was clear that > anything we produced would only be valid for a number of years. It seems we > have now reached that limit. > > I have recently taught myself basic ReactJS. It is clearly a powerful beast. > The two major distinguishing factors from the current UI are its > componentised nature (which means you don't build pages, you build re-usable > components) and that it uses a transpiled language. > > To rebuild the current UI in React, we would need to decompose the HTML > pages into components, and migrate behaviour into those components. > > Using a transpiled language (and all the tools that support that, e.g. > webpack) would give us a more compact, and modern, UI. > > However, the HTML is growing old. It isn't properly responsive, and it > doesn't use idioms that people have come to expect from a UI (e.g. no > hamburgers). > > In theory, I would support a rewrite of the visuals - it would make Solr > seem more modern. However, I do not underestimate the amount of work > involved. > > Upayavira > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
