6:23 a.m.
hey,
for upcoming tasks like
"define and manage jdbc driver"
"define and manage data source"
and others
I wonder if we could speed up the UI development a bit by
creating some skeletons for html , and also ts-code
by running some scripts over the resource type
definitions we have.
This is not meant to be the 100% UI, but rather a start where
the UI folks can improve on, but which could give us a (working)
head start.
Does that make any sense?
Heiko
8:42 a.m.
On 23/07/15 07:23 AM, Heiko W.Rupp wrote:
hey,
for upcoming tasks like
"define and manage jdbc driver"
"define and manage data source"
and others
I wonder if we could speed up the UI development a bit by
creating some skeletons for html , and also ts-code
by running some scripts over the resource type
definitions we have.
This is not meant to be the 100% UI, but rather a start where
the UI folks can improve on, but which could give us a (working)
head start.
Does that make any sense?
Is the plan that the backend developer create a rough UI, then the UX
team comes in to properly design it and give the designs to the UI
developers to actually implement it?
The problem I have with this is that even though the rough UI made by
developers is meant to be temporary, it has a habit of becoming more
permanent. Usually due to time and priority constraints. Everyone only
has so much time to put into things, and something ugly and awkward but
functional is usually less priority than something which needs to be
done and is not up and running yet.
The other thing is that UX is can be really hard, and it might be
tempting to just make the developer created awkward UI look better
rather than solving the real UX problems.
[Note: I am not saying that a developer cannot create a really good
awesome UI/UX here, I am speaking more from my own experiences and what
I have seen in the past on projects. There is a reason we have UX people
on the team handling things :)]
But I guess all we would need to do is make sure that the rough UI is
handled somewhere other than the main branch so that it doesn't
interfere with the actual console.
Heiko
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:47 a.m.
Is this all form work? Might want to consider using hawtio's form plugins perhaps,
all you need to come up with then is a json schema, live examples at ->
http://forms.hawt.io
----- Original Message -----
hey,
for upcoming tasks like
"define and manage jdbc driver"
"define and manage data source"
and others
I wonder if we could speed up the UI development a bit by
creating some skeletons for html , and also ts-code
by running some scripts over the resource type
definitions we have.
This is not meant to be the 100% UI, but rather a start where
the UI folks can improve on, but which could give us a (working)
head start.
Does that make any sense?
Heiko
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:11 p.m.
On 23 Jul 2015, at 06:47, Stan Lewis <stlewis(a)redhat.com>
wrote:
Is this all form work? Might want to consider using hawtio's form plugins perhaps,
all you need to come up with then is a json schema, live examples at ->
http://forms.hawt.io <http://forms.hawt.io/>
Stan, thanks for the tips. Much of this is forms work, and I really like the declarative
nature of hawt.io forms (reminds me of Angular Formly (http://angular-formly.com/
<http://angular-formly.com/>) . One of the difficulties we face with form libraries
in general, is their PatternFly compliance. We work closely with our UXD counterparts and
they usually provide the html/css (using PatternFly). We take those designs (the view)
after lengthy discussions between the teams and integrate them with our front-end/backend.
So as developers we are not the only ones working with the html/view.
I see two hurdles with Hawt.io forms:
1) Hawt.io form PatternFly compliance
2) Get our UXD folks to use Hawt.io forms for their designs
I definitely like the idea.
— Mike
P.S. I know there is a current effort in PatternFly to create angular wrappers around
their components. Perhaps this is great area of overlap to participate in?
----- Original Message -----
> hey,
>
> for upcoming tasks like
>
> "define and manage jdbc driver"
> "define and manage data source"
> and others
>
> I wonder if we could speed up the UI development a bit by
> creating some skeletons for html , and also ts-code
> by running some scripts over the resource type
> definitions we have.
>
> This is not meant to be the 100% UI, but rather a start where
> the UI folks can improve on, but which could give us a (working)
> head start.
>
> Does that make any sense?
>
> Heiko
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:48 p.m.
hawtio-forms does actually import patternfly's css already, though I'm sure tweaks
could be necessary here and there. Actually all of the hawtio projects already at least
work with patternfly and bring in the CSS definitions, though I'm sure we've a few
widgets in hawtio that don't have patternfly rules as they're custom controls
etc.
----- Original Message -----
Stan, thanks for the tips. Much of this is forms work, and I really like the
declarative nature of hawt.io forms (reminds me of Angular Formly (
http://angular-formly.com/ ) . One of the difficulties we face with form
libraries in general, is their PatternFly compliance. We work closely with
our UXD counterparts and they usually provide the html/css (using
PatternFly). We take those designs (the view) after lengthy discussions
between the teams and integrate them with our front-end/backend. So as
developers we are not the only ones working with the html/view.
I see two hurdles with Hawt.io forms:
1) Hawt.io form PatternFly compliance
2) Get our UXD folks to use Hawt.io forms for their designs
I definitely like the idea.
— Mike
P.S. I know there is a current effort in PatternFly to create angular
wrappers around their components. Perhaps this is great area of overlap to
participate in?
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9 a.m.
On 23 Jul 2015, at 04:23, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
hey,
for upcoming tasks like
"define and manage jdbc driver"
"define and manage data source"
and others
I wonder if we could speed up the UI development a bit by
creating some skeletons for html , and also ts-code
by running some scripts over the resource type
definitions we have.
This is not meant to be the 100% UI, but rather a start where
the UI folks can improve on, but which could give us a (working)
head start.
Does that make any sense?
Honestly, I don’t really think this would help. The pages(html/css) are pretty easy to
find something similar and cut/paste (especially with UXD help) and the controllers are
also dead simple. Most time is spent integrating with the APIs.
— Mike
Heiko
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3197
days inactive
3197
days old
6 comments
4 participants
participants (4)
-
Heiko W.Rupp -
Matt Wringe -
mike thompson -
Stan Lewis