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> (or here <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>. 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 <[email protected]> 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/ 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 <[email protected]> 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 >>> >>> >>> 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 >>>> 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 <[email protected]> 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 >>> >>>> >>>>> 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/ >>>>>> >>>>>> 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 >>> >>>> >>>>>>>> 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 >>>>>>>>> >>>>>>>>> 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-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 < >>>>>>>>> [email protected]> >>>>>>>>> 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 <[email protected]> >>>>>>>>>> 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 >>> >>>> [2] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> 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 <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I am working on some improvements to the Brooklyn gui. Where can I >>>>>>>>>> find >>>>>>>>>> some guidelines? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Raul >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> >>> >>
