You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Adrián Nieto Pérez <ad...@lcc.uma.es> on 2015/08/04 12:59:15 UTC
Re: Brooklyn drag-and-drop UI
Hi All, sorry for the late reply, I have been on holidays this days. Your concern about the relationships seems legit because on SeaClouds we define the relationships between nodes but Brooklyn doesn’t define the relationships moreover than wiring the sensor values to env variables. SeaClouds designer is not enough to define brooklyn entities but my approach allows you to nest entities, so maybe this one could be the right one.
Also I think that the “designer view” should be a more than one step wizard, maybe one to define the involved entities and another one to define the necessary ConfigKey’s. This also could be assisted, for example like Robotics Studio each entity exposes his available Sensors and you can draw a line between the sensor and the config key.
What do you think?
I also agree about doesn’t making a lot of noise here, Gitter looks nice for me.
Best,
Adrian.
> El 30/7/2015, a las 23:05, Thomas Bouron <th...@cloudsoftcorp.com> escribió:
>
> Hi All.
>
> First of all, I would like to apology for the very, very, very long delay of my reply. I started this by asking some UI questions / feedbacks but I was not there to answer back. I also would like to thank you, Hadrian, Adrián and Raul for you contributions, those are really valuable.
>
> I'll try to answer in details for each and every one of you but If I forget something or someone, please do shout about it, you earned it because you were really patient :)
>
> --
> Adrián: I cloned you proof of concept's git repo and played with it. That is almost exactly what I had in mind when I made my proposal. I do like the material design, I'm actually completely sold on that point, it looks some much nicer and slicker to my opinion. I would argue about the homepage and move or regroup some elements but it's not within the scope of the Drag & drop editor.
> I also spent a lot of time looking at SeaCloud UI, especially your graphical representation of a deployed blueprint. While I find great to have a "graph" view, I have few concerns about some elements with parent - child relationship, typically a SameServerEntity. How do you represent that?
>
> --
> Raul: Thank for the wireframes, looks really good! Did you used balsamic? As you said, the YAML editor needs features like syntax highlighting and autocompletion (if possible, I think it might be tricky to get this working though). I agree on the fact that we should keep it simple at first, i.e. not doing the "graph" view but keep it in mind for a more extended version.
>
> Now, I think Alex is right and this editor should be called "Designer" where you can compose your blueprint from a "Palette" of available entities / location & policies. I'm strongly for a tree view representation, I think this is the best way to represent the application topology. I don't have a real argument for it, it's just a guts feeling.
>
> To summarise:
> The "Add application" popup would open into the "Designer" mode with the palette from where a user can pick and compose his blueprint.
> It would be possible to switch between views: Designer view, YAML view (no palette) and split view.
> A click on an entity would open (or reveal with a slide effect, whatever is best in terms of UX) the possible options to configure it. If the configuration is wrong, then entity and the problematic configkey would be flagged. A good example of that is the Ambari wizard UI [1]. This should also be available on the YAML view.
> At the bottom of the popup, it would have two buttons: "Add to catalog" and "Deploy now".
> I'm happy to discuss all these points more in details through whatever channel[2] suit you.
>
> Best.
>
> [1] http://hortonworks.com/wp-content/uploads/2013/05/Screen-Shot-2013-03-29-at-3.24.24-PM.png <http://hortonworks.com/wp-content/uploads/2013/05/Screen-Shot-2013-03-29-at-3.24.24-PM.png>
> [2] Email, skype, Gitter or IRC
>
> On Wed, 29 Jul 2015 at 11:04 Alex Heneveld <alex.heneveld@cloudsoftcorp.com <ma...@cloudsoftcorp.com>> wrote:
>
> Hi Raul, Adrian, All,
>
> Apologies for the delay. I like the progress that was made while I was on holiday! And overall I really like the direction. It seems there is more in common than not between Raul and Adrian's work.
>
> Here are my thoughts:
>
> * I really like the split screen where the YAML gets built up along with a GUI picture. Minor comment on this, rather than use tabs I'd use a draggable split for this where the RHS YAML can be minimized (and would probably start minimized).
>
> * I see this designer as a new top-level tab, "Designer" or something. This should have the ability to "add to catalog" or "deploy now".
>
> * The LHS where entities are shown should probably be called a "Palette". This might have tabs for "Entities", "Locations" and "Policies". (In time we will want to support "entity initializers" here as well -- but this will take some core work to make all adjuncts -- policies, enrichers feeds, etc -- treated in the same way as the GUI -- so for now just having policies is fine, or even leaving out policies.)
> We might also want to have a "favourites" or "recently used" section for each of those, in addition to search which is essential of course as the palette is BIG!
> We could render these items in a more attractive way (e.g. use an icon if available).
>
> * For the main window (where the design is rendered graphically) a tree makes sense logically but it might be more attractive to draw it like a graph. The best drag-and-drop I've ever seen is Curvature for OpenStack [1] -- jump to about 6m30s.
> In terms of usability I'd expect if you drop a node onto another it gives some nice hover feedback then creates a parent-child relationship. You can also create a link between two nodes that you've dropped, and this by default also sets up parent-child but soon I'd like to have support for typed relationships (and e.g. cluster's member spec would be an example of this).
> If you click on a node a properties section pops up, similar to what Raul has shown, but it will take some work to make this powerful without being overwhelming.
> You can also collapse a portion of the tree with a suitable click.
>
> In terms of objectives, BTW, I see the goals as:
>
> * for new users, they are encouraged to make a blueprint, it feels easy, and they don't have to read through documentation or write YAML
> * for experts, it is fun and powerful and they use it to get the initial YAML in the right shape before tweaking it
>
> There is also the potential I think to re-use the same visualization to show live deployments -- but let's focus on the designer/composer view first.
>
> Best
> Alex
>
>
> [1] https://www.openstack.org/summit/portland-2013/session-videos/presentation/interactive-visual-orchestration-with-curvature-and-donabe <https://www.openstack.org/summit/portland-2013/session-videos/presentation/interactive-visual-orchestration-with-curvature-and-donabe>
>
> [2] previous work in this thread (for reference)
>
> Raul:
>
> * https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v1.pdf <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v1.pdf>
> * https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v2.pdf <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v2.pdf>
>
> Adrian:
>
> * https://github.com/adriannieto/incubator-brooklyn-material-gui <https://github.com/adriannieto/incubator-brooklyn-material-gui>
>
>
>
> END
>
>
>
> On 16/07/2015 15:15, Raul Canta wrote:
>> Hello all,
>>
>> Thanks for the feedback! At the start of the post my idea was to
>> "simplify" the Create Application section and make it more easy to use.
>>
>> As Alex said earlier in the email we need to have some features for the
>> YAML editor like syntax/error highlighter, auto-completion(this feature
>> need to be also in the edit application section). As for the graph view at
>> first i think is best to keep a clean tree view (similar to how the
>> "applications" tab shows the runtime view) where you can add/edit
>> new/existing entities.
>>
>> First mockup (click here for v1
>> <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v1.pdf> <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v1.pdf>)
>> it's a more complex approach of the editor so i tried to make a cleaner
>> version that can be integrated in the existing gui (click here vor v2
>> <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v2.pdf> <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-v2.pdf>
>> )
>>
>>
>> Regardint the more complex view/editor examples, i think is best to start a
>> new thread if people are interested.
>>
>>
>> Let me know your thoughts,
>> Raul C.
>>
>>
>>
>>
>> On Thu, Jul 16, 2015 at 8:02 AM, Alexandru Zbarcea <al...@apache.org> <ma...@apache.org> wrote:
>>
>>> Great discussion. I share Andrea's vision about the YAML editor.
>>>
>>> Regarding the more complex viewer/editor, where you can see a lot about the
>>> relations, I feel like is going into areas like architecture
>>> <http://lastbackend.com/images/about/image02.png> <http://lastbackend.com/images/about/image02.png> (or here
>>> <http://lastbackend.com/images/blog/2015-03-23/rebuild_r_1.gif> <http://lastbackend.com/images/blog/2015-03-23/rebuild_r_1.gif>) or
>>> monitoring
>>> <
>>> https://d262ilb51hltx0.cloudfront.net/fit/t/1200/504/0*1jHYiN2Yt7ZfvYjC.png <https://d262ilb51hltx0.cloudfront.net/fit/t/1200/504/0*1jHYiN2Yt7ZfvYjC.png>
>>>> .
>>> Then, things get very complicate because you then need to think who is the
>>> user that actually models/views those blueprints. A lot of things can be
>>> viewed: network topology, service distribution, storage, dependency,
>>> composition etc. I think we can even start a new thread of discussion
>>> regarding this. What do you think?
>>>
>>> My 2 cents are on the YAML (text) editor, to make it more productive and
>>> somehow more appealing. I like that small icon in the yaml, an
>>> auto-completion feature, a syntax-error highlighter, drag-and-drop, 2-way
>>> mapping. Aled is also right saying that mock-ups are the best way to get
>>> some feedback.
>>>
>>> Have a nice day,
>>> Alex
>>>
>>>
>>> On Wed, Jul 15, 2015 at 11:27 AM, Hadrian Zbarcea <hz...@gmail.com> <ma...@gmail.com>
>>> wrote:
>>>
>>>> After giving it a lot of thought, I start to like this proposal a lot. If
>>>> something is *only* useful for getting started, I would argue that it is
>>>> actually not useful.
>>>>
>>>> From my previous experience with a few other projects that had a similar
>>>> problem (Apache Camel being one), it is very difficult to build
>>>> descriptions in a graphical way. A graphical visualization of what to
>>>> expect is very useful though.
>>>>
>>>> One of the problems is that the expressiveness of the gui always lags
>>>> behind that of the textual representations (sometimes by years). Tree
>>>> (containment) relationships are easy to express in an editor, and
>>> collapse
>>>> the tree if necessary, yet take a lot of precious real estate visually.
>>>> References on the other hand are much harder to express in text.
>>>>
>>>> Raul, would it be possible to explore Andrea's idea a bit more?
>>>>
>>>> Cheers,
>>>> Hadrian
>>>>
>>>>
>>>> On 07/14/2015 12:48 PM, Andrea Turli wrote:
>>>>
>>>>> Thanks Raul, Adrian, all, for the great discussion!
>>>>>
>>>>> I'd also like to see brooklyn UI refreshed and my little contribution in
>>>>> this sense is to put on the table this (nice, IMHO) project:
>>>>> https://lorry.io/ <https://lorry.io/> we could borrow some ideas and drag-and-drop snippet
>>> of
>>>>> YAML to create additional (prefilled) YAML sections to compose the final
>>>>> blueprint.
>>>>> I don't see a simple way to cover all the use cases solved by Brooklyn
>>>>> with
>>>>> a graph-based UI unless we assume that the drag and drop web UI will be
>>>>> useful for getting started examples but not for advanced users. I think
>>> a
>>>>> nice YAML editor could instead be more generic and not so scary even for
>>>>> newbies.
>>>>>
>>>>> My two cents,
>>>>> Andrea
>>>>>
>>>>> Il giorno mar 14 lug 2015 17:54 Aled Sage <al...@gmail.com> <ma...@gmail.com> ha
>>>>> scritto:
>>>>>
>>>>> Thanks Raul, a few questions/comments.
>>>>>> But first, can I check if you are thinking of this as a design-time
>>> view
>>>>>> or a runtime view? I'm thinking of it as design-time. In your diagram,
>>>>>> you've shown an exclamation mark and colouring against "CouchbaseNode
>>>>>> 2", as though that was a runtime health view?
>>>>>>
>>>>>> Initial comments:
>>>>>>
>>>>>> * Showing 3 JBoss AS7 servers under the "Cluster of JBoss7Server"
>>>>>> entity is misleading for design-time.
>>>>>> Presumably the cluster is resizable - there could be 1 or 100
>>> nodes,
>>>>>> with it resizing dynamically.
>>>>>> We'd want to capture the *configuration* - i.e. that it is
>>>>>> JBoss7Server instance(s) that will be created in the cluster.
>>>>>> * It looks like runtime health info (which I don't think we need)
>>> for
>>>>>> the red line to a JBoss7Server instance, and for the exclamation
>>>>>> mark in the "CouchbaseNode 2".
>>>>>> * Can you include a "configuration" section, where if an entity is
>>>>>> selected it shows the configuration options for that entity type
>>>>>> (e.g. [1]).
>>>>>> * I suggest we keep the example YAML in agreement with the graph
>>> view,
>>>>>> so that people looking at the mockups understand what is being
>>>>>> presented.
>>>>>> * Do we want arrows to be shown on both directions for each line? Or
>>>>>> can we convey additional info (e.g. direction of
>>>>>> dependency/relationship) by having just one direction.
>>>>>> * What do you think of containment / configuration relationships:
>>>>>> o how do we differentiate the "cluster of JBoss7Server"
>>> containing
>>>>>> (either as children, or as config of an EntitySpec) the
>>>>>> JBoss7Server, versus a dependency relationship where the URL
>>> of
>>>>>> Couchbase would be injected into each JBoss7Server instance?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> The "containment problem" is bothering me. How do we elegantly show
>>> that
>>>>>> the user is drag-and-dropping an entity to be a child of another
>>> entity?
>>>>>> I wonder about Hadrian's "layers" suggestion. If a user is creating
>>>>>> their own hierarchy of entities, then that could be collapsed to show
>>>>>> just the top-level entity. It could then be expanded to show its
>>>>>> children - perhaps all shown in a single expanded box within the graph
>>>>>> view; or maybe that opens up into another tab showing the contents of
>>>>>> that composite entity.
>>>>>>
>>>>>> Maybe for phase one, we focus on just wiring together top-level
>>>>>> entities, with no containment?
>>>>>>
>>>>>> Aled
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>>
>>> https://brooklyn.incubator.apache.org/learnmore/catalog/catalog-item.html#!entities/brooklyn.entity.webapp.jboss.JBoss7Server <https://brooklyn.incubator.apache.org/learnmore/catalog/catalog-item.html#!entities/brooklyn.entity.webapp.jboss.JBoss7Server>
>>>>>> On 14/07/2015 16:07, Raul Canta wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>>
>>>>>>> Aled, I used the Balsamiq tool and reconstructed the mockups i sent
>>>>>>>
>>>>>> earier
>>>>>>
>>>>>>> and made some changes on the "applications" view.
>>>>>>>
>>>>>>> It's just an rough mockup to know if this is what you had in mind for
>>>>>>> the
>>>>>>> "drag & drop graph"
>>>>>>>
>>> https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor.pdf <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor.pdf>
>>>>>>> Similar to what Adrian Nieto proposed.
>>>>>>>
>>>>>>>
>>>>>>> Adrián Nieto, as Aled said earier in the email, i think is better to
>>> do
>>>>>>> first some basic mockups for the editor and after everyone is happy
>>> with
>>>>>>> the result i can do a more "realistic" mockup.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Let me know your thoughts,
>>>>>>> Raul C.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 14, 2015 at 5:20 PM, Aled Sage <al...@gmail.com> <ma...@gmail.com>
>>> wrote:
>>>>>>> Hi all,
>>>>>>>> I've put together some draft use-cases for the blueprint designer.
>>>>>>>> Feedback extremely welcome:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> https://docs.google.com/document/d/1A1oaIbGPDXgJsum0QnE9gmYfLwRotEOTPnoi3zqXTD8/edit?usp=sharing <https://docs.google.com/document/d/1A1oaIbGPDXgJsum0QnE9gmYfLwRotEOTPnoi3zqXTD8/edit?usp=sharing>
>>>>>>>> Aled
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14/07/2015 14:29, Aled Sage wrote:
>>>>>>>>
>>>>>>>> Hi Adrian,
>>>>>>>>> I agree it's on the right track, with drag-and-drop of services
>>>>>>>>> (analogous to existing entities/blueprints), and settings on each of
>>>>>>>>>
>>>>>>>> those
>>>>>>> services (analogous to config options).
>>>>>>>>> An important difference from Microsoft Robotics Studio is that we
>>> are
>>>>>>>>> mostly talking about a deployment configuration, whereas the
>>> robotics
>>>>>>>>> studio is a graphical programming language. Therefore, the analogy
>>>>>>>>> will
>>>>>>>>> break down so we have to be careful about what ideas we take from
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> Labels/layers sounds sensible.
>>>>>>>>>
>>>>>>>>> We should also write up some use-cases. I volunteer to make a start
>>> on
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> In terms of mockups, I love wire frames and tools like Balsamiq [1].
>>>>>>>>> It
>>>>>>>>> allows for extremely fast iterations, fast feedback, and avoids
>>>>>>>>> (time/emotional) investment in more "realistic" mockups. I suggest
>>> we
>>>>>>>> all
>>>>>>> agree that any mockup code is throw-away. If it's not, then we're at
>>>>>>>> risk
>>>>>>> of spending too much time on a single phase of the mockup, rather than
>>>>>>>>> getting our ideas out there for fast feedback.
>>>>>>>>>
>>>>>>>>> Aled
>>>>>>>>>
>>>>>>>>> [1] https://balsamiq.com/products/mockups/ <https://balsamiq.com/products/mockups/>
>>>>>>>>>
>>>>>>>>> On 14/07/2015 14:14, Hadrian Zbarcea wrote:
>>>>>>>>>
>>>>>>>>> Hi Adrian,
>>>>>>>>>> This looks very interesting to me. Complex approach or not, I
>>> believe
>>>>>>>>>> this is what is needed and you're on the right track.
>>>>>>>>>>
>>>>>>>>>> I spent quite a bit of time thinking about this problem. My
>>> intuition
>>>>>>>>>> tells me now that we need to introduce some metadata like labels
>>> and
>>>>>>>>> layers
>>>>>>> to handle complexity. However, I don't have a concrete proposal at
>>>>>>>>> this
>>>>>>> point and I am not sure how productive it would be to just throw
>>>>>>>>> ideas.
>>>>>>>>>> Best,
>>>>>>>>>> Hadrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 07/14/2015 07:22 AM, Adrián Nieto wrote:
>>>>>>>>>>
>>>>>>>>>> What do you think about trying to mockup something based directly
>>> on
>>>>>>>>>>> material design?
>>>>>>>>>>>
>>>>>>>>>>> About how it the App designer should work I would suggest
>>> something
>>>>>>>>>> like
>>>>>>> Microsoft Robotics Studio[1] but maybe this is a very complex
>>>>>>>>>> approach.
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>> http://3.bp.blogspot.com/_w8zmcBHHhdk/TD9ewicbGdI/AAAAAAAAB6o/8nEsQNzw8eI/s1600/UltrasonicExplorer.png <http://3.bp.blogspot.com/_w8zmcBHHhdk/TD9ewicbGdI/AAAAAAAAB6o/8nEsQNzw8eI/s1600/UltrasonicExplorer.png>
>>>>>>>>>>> El 14/07/2015 a las 11:47, Raul Canta escribió:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>> I've looked over Adrian Nieto post and it looks that we had the
>>>>>>>>>>>> same
>>>>>>>>>>>> idea
>>>>>>>>>>>> using AngularJS and Material Design
>>> https://material.angularjs.org <https://material.angularjs.org/>
>>>>>>>>>>>> Yes, it's about the drag and drop which Thomas Bouron proposed. I
>>>>>>>>>>>> tried to
>>>>>>>>>>>> do a first design based on the mokcup Thomas did.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>> https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-Application.jpg <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-Application.jpg>
>>> https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-YAML.jpg <https://dl.dropboxusercontent.com/u/38051787/ApacheBrooklyn-Editor-YAML.jpg>
>>>>>>>>>>>> I would like to get some feedback on the mokcups i did.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Raul C.
>>>>>>>>>>>>
>>>>>>>>>>>> P.S. For the mockups I used the design guideline of the Apache
>>>>>>>>>>>>
>>>>>>>>>>> Brooklyn
>>>>>>> look-and-feel
>>>>>>>>>>>> On Tue, Jul 14, 2015 at 11:21 AM, Adrián Nieto Pérez <
>>>>>>>>>>>> adrian@lcc.uma.es <ma...@lcc.uma.es>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> My idea was to start the project during August, but I already
>>>>>>>>>>>> did
>>>>>>>>>>>>
>>>>>>>>>>> some
>>>>>>> work on the landing view. For the server log it would be nice to
>>>>>>>>>>>> have
>>>>>>> an
>>>>>>>>>>>>> API call to retrieve the console output, or at least the last
>>>>>>>>>>>>>
>>>>>>>>>>>> message.
>>>>>>> Currently i’m working on the applications view.
>>>>>>>>>>>>> El 14/7/2015, a las 4:32, Hadrian Zbarcea <hz...@gmail.com> <ma...@gmail.com>
>>>>>>>>>>>>> escribió:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Raul,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you please share some wireframes or screenshots of what you
>>>>>>>>>>>>> are
>>>>>>>>>>>>> working on?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The second link Aled posted is an interesting one for me (and I
>>> am
>>>>>>>>>>>>> not a
>>>>>>>>>>>>> UI expert by any measure). It looks like Adrian Nieto is working
>>>>>>>>>>>>> on
>>>>>>>>>>>>> some
>>>>>>>>>>>>> changes of the UI. The initial thread he started died off
>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I cc'ed Adrian explicitly in the hope that he could share more
>>>>>>>>>>>>>
>>>>>>>>>>>> about
>>>>>>> his
>>>>>>>>>>>>> plans.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Hadrian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/13/2015 06:09 PM, aled sage wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Raul, excellent!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you elaborate for the mailing list what area of the Brooklyn
>>>>>>>>>>>>>
>>>>>>>>>>>> GUI
>>>>>>> you
>>>>>>>>>>>>> are working on? From other comms, I presume it is the drag and
>>>>>>>>>>>>> drop
>>>>>>>>>>>>> editor
>>>>>>>>>>>>> which Thomas proposed on the list previously [1].
>>>>>>>>>>>>>
>>>>>>>>>>>>> In terms of guidelines, are you thinking of look-and-feel or
>>>>>>>>>>>>> coding
>>>>>>>>>>>>> standards?
>>>>>>>>>>>>>
>>>>>>>>>>>>> For look-and-feel, I'd go for community feedback: propose some
>>>>>>>>>>>>> wire-frame
>>>>>>>>>>>>> diagrams / mockups early to get feedback, iterate on those until
>>>>>>>>>>>>> we
>>>>>>>>>>>>> have
>>>>>>>>>>>>> sufficient consensus, and then implement!
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> Another discussion about the Brooklyn GUI is the e-mail thread
>>> "A
>>>>>>>>>>>>> proposal
>>>>>>>>>>>>> of a new Apache Brooklyn GUI" [2].
>>>>>>>>>>>>>
>>>>>>>>>>>>> Aled
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>> http://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201506.mbox/%3CCAH20XTZPdcfXBam9WcGD_%3DWbWnuzMKeTOVoK3vkiXgvEBJ5zpw%40mail.gmail.com%3E <http://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201506.mbox/%3CCAH20XTZPdcfXBam9WcGD_%3DWbWnuzMKeTOVoK3vkiXgvEBJ5zpw%40mail.gmail.com%3E>
>>>>>>> [2]
>>> http://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201507.mbox/%3CFEC0FF77-671B-455C-A29E-6ABF6E4028D3%40lcc.uma.es%3E <http://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201507.mbox/%3CFEC0FF77-671B-455C-A29E-6ABF6E4028D3%40lcc.uma.es%3E>
>>>>>>>>>>>>> On Mon, Jul 13, 2015 at 8:38 PM, Raul Canta <ra...@apifocal.com> <ma...@apifocal.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am working on some improvements to the Brooklyn gui. Where
>>> can I
>>>>>>>>>>>>> find
>>>>>>>>>>>>> some guidelines?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Raul
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
>
> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>
> This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
> --
> Thomas
>
> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>
> This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.