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
