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>) 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> ) 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 <[email protected]> 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> (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 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>> > >>> > >> >
