Github user tbouron commented on the pull request:

    https://github.com/apache/brooklyn-ui/pull/17#issuecomment-197946011
  
    > 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.
    
    ctrl + space to display the autocomplete? It does not work for me. The 
suggestions are displayed as soon a I type something in the field. If a type a 
`i`, it display this instantly
    ![screen shot 2016-03-17 at 15 53 
15](https://cloud.githubusercontent.com/assets/2082759/13852072/83775fba-ec58-11e5-8378-d901d07a8a7c.png)
    I think that's an issue with your build.
    
    > 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'll change for your text.
    
    > 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!)
    
    I then need to know what to do in details.


---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to