> 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 <u...@odoko.co.uk> 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 <u...@odoko.co.uk>:
>
>
>
> 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: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to