[
https://issues.apache.org/jira/browse/SOLR-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14901732#comment-14901732
]
Hoss Man commented on SOLR-7858:
--------------------------------
bq. Chris Hostetter I recall you had suggestions as to how we go about
releasing the new UI, but I haven't been able to track them down. ...
http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301121010.19000@frisbee%3E
{quote}
My suggestion, along the lines of what we did with the previous UI
change...
1) ensure that the new UI is fully functional in 5x using an alt path
(believe this is already true?)
2) add an "Upgrading" note to CHANGES.txt for 5.2 directing people to
the new "experimental" UI and the URL to access it, note that it
will likely become the default in 5.3 and users are encouraged to try it
out and file bugs if they notice any problems.
3) update trunk so that it *is* the default UI, and make the old UI
available at some alternate path (eg "/solr/old_ui"). Add an Upgrading
note pointing out that the URLs may be slightly different, and how to
access the old UI if they have problems
* backport trunk changes (#3) to 5x for 5.3 (or later if problems/delays
pop up)
{quote}
And:
http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301414460.19000@frisbee%3E
{quote}
...
We might want to tweak those URLs slightly to be a little less confusing
... ie "old.html" and "new.html" (at least until after 5.3) ... i mean, i
just the paragraph you rwote above, but w/o looking at it i've already
forgoten if "index.html" is hte new one or hte old one.
So imagine if a 5.2 user has in their browser...
http://localhost:8983/solr/admin.html#/collection1
...and is trying to remember if this is the new one (that they should get
use to / help test) or the fuly qualified name of the old one that is
going away.
Likewise imagine if a 5.42 user sees the same URL, and reads a note that
the "old UI" is going to be removed in 6.0 and is trying to figure out if
that affects him.
{quote}
A few followup comments...
a) that "step 3" above (changing hte defualt on trunk first) is *really*
important ... you want that change to sit on trunk for a good while, so that
devs working on trunk and manually testing things are *using* the new UI
anytime they run stuff on trunk, and helping to find problems -- even if no
users "try" the new UI in the released versions of Solr
b) not sure why i didn't mention it before, but adding a generic header to all
of the "old" UI pages warning people that they are using the old UI and here is
a link to the new UI is something that should definitely be added once the
default is changed (it could be added even before the default is changed with
ome wording tweaks: "Please try the new UI.." vs "You are looking at the old
deprecated UI, please switch to....") to help reduce the # of bug reports /
feature requests we get about the old UI and to reduce user frustration (ie;
they see in some future release notes that there is a new collection admin
screen, but they can't find it when they load "the admin UI" bookmark they
have.)
----
bq. Having something like "admin#" or "admin/#/" (whatever makes sense for the
code) in the URL would likely eliminate that confusion for most people. Even
"index.html" in the URL (which the new UI has now) would be helpful, but using
the word "admin" in some way would be better.
In the long term, I don't know if this is will actually help things or decrease
novice user confusion (the URLs, when loaded in a browser, is already clearly a
UI, will making the UI urls longer really help people notice "oh hey, maybe
this UI based URL isn't a URL that programtic client code should talk to" ?)
but if this approach is taken it should be _very_ carefully considered in terms
of how it impacts "reserved words" for things like collection names.
It's annoying enough if we (in the short term) have reserved paths like
"/old.ui.html" but if you try to use "/admin" as a prefix to indicate that it's
for the UI, you'll probably break things like /admin/cores and
/admin/collections -- let alone the long term impacts of saying something like
"You can't have a collection named 'ui' because of the '/ui'." etc...
> Make Angular UI default
> -----------------------
>
> Key: SOLR-7858
> URL: https://issues.apache.org/jira/browse/SOLR-7858
> Project: Solr
> Issue Type: Bug
> Components: web gui
> Reporter: Upayavira
> Assignee: Upayavira
> Priority: Minor
> Attachments: SOLR-7858.patch, new ui link.png, original UI link.png
>
>
> Angular UI is very close to feature complete. Once SOLR-7856 is dealt with,
> it should function well in most cases. I propose that, as soon as 5.3 has
> been released, we make the Angular UI default, ready for the 5.4 release. We
> can then fix any more bugs as they are found, but more importantly start
> working on the features that were the reason for doing this work in the first
> place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
