Github user ahgittin commented on the pull request:
https://github.com/apache/brooklyn-ui/pull/17#issuecomment-197937906
> What is the issue with the autocomplete? Works ok after at least one
character for me.
maybe it's a huge time delay or my machine. for me it only popped up once
and then vanished. other times i couldn't get anything to show.
is it possible to have ctrl-space also trigger it, and put a hint that this
is supported? that at least makes it consistent with composer and obvious that
it is possible.
> > the "additional configuration" page is imposing; can we make it clear
that there is no need to set anything, but if you want to put constraints or
special login there are many config keys available (possibly with link to the
website)
> Buttons are enabled on this screen which makes it obvious that you don't
need to do anything else. But I can change the subtitle from Provisioning
information about your location to Optional provisioning information about your
location
i find button enablement a *subtle* clue not an *obvious* one.
(*disablement* is an obvious indicator that i *cannot* proceed but if i'm taken
to a screen i assume i'm supposed to do something there. the *obvious* button
in this screen is *Add configuration* which is intimidating.)
additionally i'd like us to more user-friendly less techie/jargony. the
phrase *provisioning information about your location* whether optional or not
isn't clear to me. also it's too general in many cases (because the previous
screen gave a bunch of provisioning information) and wrong in others
(specifying a `loginUser` is not provisioning information, it's information to
connect to a provisioned machine).
how about text such as: *In many target locations, additional configuration
may be supported. Enter any such options here. Autocomplete for some config
options is available using Ctrl-Space. For information on available options
consult the [LINK]Brooklyn docs. Alternatively you can skip this step.*
> > I don't think localhost should be a top-level item. it's only something
advanced users should try. extending an existing location is probably more
important. we could call that tab "Advanced" and within it a text field for
type with autocomplete allowing localhost and any named locations the user has
previously set up.
> I disagree with that. Those 3 top level location types are taken from the
Brooklyn docs to be consistent!
the docs have evolved, and 5 years ago pre-vagrant even `localhost` was
common. they should be updated, not this based on that. the menu options in
the docs are better, with "named locations" as the second choice.
localhost is useful for techies and debugging but not a casual user who
increasingly we want to target, who is trying to deploy community blueprints
for use. it is something that an advanced user who is comfortable with `ssh
localhost` might do max once. clouds, byon, and named/extending otoh are
things people do routinely.
(incidentally i think because `localhost` is available as a resolver you
can specify it as a location in a yaml even if it isn't defined as a type. so
i'm not even sure that most users would want to click that ever!)
@shartzel any input?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
