brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Question about the Brooklyn webui
Date Wed, 15 Jul 2015 15:27:35 GMT
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
View raw message