brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Zbarcea <al...@apache.org>
Subject Re: Question about the Brooklyn webui
Date Thu, 16 Jul 2015 05:02:36 GMT
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 <hzbarcea@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/ 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 <aled.sage@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
>>>
>>>
>>> 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 <aled.sage@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
>>>
>>>>
>>>>> 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
<
>>>>>>>>> adrian@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 <hzbarcea@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
>>>
>>>> [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 <raul@apifocal.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I am working on some improvements to the Brooklyn
gui. Where can I
>>>>>>>>>> find
>>>>>>>>>> some guidelines?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Raul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message