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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > -- 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.
