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
