You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2017/11/11 11:39:16 UTC
New Component Set
Hi
to avoid mixing conversations, I create this new thread in order to focus
on component set conversation.
As you know we already talked about making some default look-and-feel and
some of you stated that better to create a new component set.
At beginning I prefer go with Express due to what I thought Express was
done, but seems that Basic and Express has it's own reason to exists.
So, if we start a new set, I want it to have a great look of course, but it
must be functional and with great quality.
To define what components should be done, I think we can start we some that
are in mostly all applications no matter what kind of device will be used:
* Button, TextField, CheckBox, RadioButton, Slider, List, Toggle, Table,
Menu
I think we have most of the work already done before and all the components
above works mostly the same in web, desktop and devices. So this first
round could be defined as our first milestone to reach.
Then we should go with other components that I are not as easy and widely
used as the ones above:
* A Date component, that could be used in desktop and mobile and will have
a great usability. maybe could be a component that has various layouts and
could work differently depending on configuration, user election and
devices.
* Tooltips, this component seems as well a bit confusing depending on where
platform will be used, maybe in Royale is as easy as to have 2 or 3 kind of
beads to decorate other components...
* Dialogs, Alerts, .... this is something that I would try to rethink: if
we use in desktop, we expect something like a popup, in mobile, popups are
a bit weird in usability terms, I have some ideas in mind here
* Form, maybe a key piece in almost every application that should work ok
in almost all kind of devices.
* Loader or ProgressBar
*...
Lastly, we have another block of components that we can see in some UI
frameworks and not in others and maybe some of them are not as needed as
the first block:
* Panel-Card, Accordion, Badges, SnackBar, Chips,...and many more.... as
Alex said, this part is mostly based on users demand
* media components : Video, sound... should we enter this path, again users
demand should guide us here.
Having like three separate blocks of components, I see the first one a
must, all are needed. The second are in the middle, some must be needed but
we can improve the current state of the art, others could be left if
there's no interest. The last one is mostly components that could be needed
or not and like Alex said, people will let us know about it, and expect as
we have many others, people could contribute those at some level of
completion.
Additionaly. Some *philosophy* that I'd like to achieve with this set:
I'd like to create a set that could allow users to focus on functionality
while we give them usability.
So people should be able to make a concrete application screen with the
components provided, have right events, etc..
Regarding devices, this should be completely solved by our set so, the same
code should run on web, desktop, mobile, tablet and TV without the need for
people to change any line of code in their Applications.
Things like user interaction (mouse vs touch), control representation
(different sizes), responsively and adaptation, should be controled at
framework level or configurable by users at top level (the case of date
controls and how to the layout and controls be right depending if we are
working on web, desktop or mobile/tablet)
So this is like a three-part approach and something I think we should
discuss in order to work.
I think this effort needs some people working on it with a similar vision
and is a lot of work to be done that should be started only if there's some
consensus on what's the goal and the process to reach that goal. If not,
I'm afraid people working on this could reach blocking paths or be
disappointed through the long way to do.
Thoughts?
--
Carlos Rovira
http://about.me/carlosrovira
Re: New Component Set
Posted by Carlos Rovira <ca...@apache.org>.
Right, DropDownList and ComboBox must be in, and in my way of thinking it
should be only one component
About tabs, I'll be putting along Accordion and other "content
organization" components, even, this could be part of Royale itself (is
more about layout and organization)
since this kind of functionality could be used in other sets. I think Peter
worked a lot in this kind of stuff and he could give us more advice on what
direction to go
2017-11-11 16:05 GMT+01:00 gkk gb <mo...@comcast.net>:
> I'd recommend toolTips in the first set. Other components of interest
> would be a drop down list or combo box, and some kind of tabbed panel (e.g.
> Spark NavigatorContainer).
>
> > On November 11, 2017 at 3:39 AM Carlos Rovira wrote:
> >
> >
> > Hi
> >
> > to avoid mixing conversations, I create this new thread in order to
> focus
> > on component set conversation.
> >
> > As you know we already talked about making some default
> look-and-feel and
> > some of you stated that better to create a new component set.
> > At beginning I prefer go with Express due to what I thought Express
> was
> > done, but seems that Basic and Express has it's own reason to exists.
> >
> > So, if we start a new set, I want it to have a great look of course,
> but it
> > must be functional and with great quality.
> >
> > To define what components should be done, I think we can start we
> some that
> > are in mostly all applications no matter what kind of device will be
> used:
> > * Button, TextField, CheckBox, RadioButton, Slider, List,
> Toggle, Table,
> >
> > Menu
> >
> > I think we have most of the work already done before and all the
> components
> > above works mostly the same in web, desktop and devices. So this
> first
> > round could be defined as our first milestone to reach.
> >
> > Then we should go with other components that I are not as easy and
> widely
> > used as the ones above:
> > * A Date component, that could be used in desktop and mobile and
> will have
> >
> > a great usability. maybe could be a component that has various
> layouts and
> > could work differently depending on configuration, user election and
> > devices.
> > * Tooltips, this component seems as well a bit confusing
> depending on where
> >
> > platform will be used, maybe in Royale is as easy as to have 2 or 3
> kind of
> > beads to decorate other components...
> > * Dialogs, Alerts, .... this is something that I would try to
> rethink: if
> >
> > we use in desktop, we expect something like a popup, in mobile,
> popups are
> > a bit weird in usability terms, I have some ideas in mind here
> > * Form, maybe a key piece in almost every application that
> should work ok
> >
> > in almost all kind of devices.
> > * Loader or ProgressBar
> >
> > *...
> >
> > Lastly, we have another block of components that we can see in some
> UI
> > frameworks and not in others and maybe some of them are not as
> needed as
> > the first block:
> > * Panel-Card, Accordion, Badges, SnackBar, Chips,...and many
> more.... as
> >
> > Alex said, this part is mostly based on users demand
> > * media components : Video, sound... should we enter this path,
> again users
> >
> > demand should guide us here.
> >
> > Having like three separate blocks of components, I see the first one
> a
> > must, all are needed. The second are in the middle, some must be
> needed but
> > we can improve the current state of the art, others could be left if
> > there's no interest. The last one is mostly components that could be
> needed
> > or not and like Alex said, people will let us know about it, and
> expect as
> > we have many others, people could contribute those at some level of
> > completion.
> >
> > Additionaly. Some *philosophy* that I'd like to achieve with this
> set:
> >
> > I'd like to create a set that could allow users to focus on
> functionality
> > while we give them usability.
> > So people should be able to make a concrete application screen with
> the
> > components provided, have right events, etc..
> > Regarding devices, this should be completely solved by our set so,
> the same
> > code should run on web, desktop, mobile, tablet and TV without the
> need for
> > people to change any line of code in their Applications.
> > Things like user interaction (mouse vs touch), control representation
> > (different sizes), responsively and adaptation, should be controled
> at
> > framework level or configurable by users at top level (the case of
> date
> > controls and how to the layout and controls be right depending if we
> are
> > working on web, desktop or mobile/tablet)
> >
> > So this is like a three-part approach and something I think we should
> > discuss in order to work.
> > I think this effort needs some people working on it with a similar
> vision
> > and is a lot of work to be done that should be started only if
> there's some
> > consensus on what's the goal and the process to reach that goal. If
> not,
> > I'm afraid people working on this could reach blocking paths or be
> > disappointed through the long way to do.
> >
> > Thoughts?
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: New Component Set
Posted by gkk gb <mo...@comcast.net>.
I'd recommend toolTips in the first set. Other components of interest would be a drop down list or combo box, and some kind of tabbed panel (e.g. Spark NavigatorContainer).
> On November 11, 2017 at 3:39 AM Carlos Rovira wrote:
>
>
> Hi
>
> to avoid mixing conversations, I create this new thread in order to focus
> on component set conversation.
>
> As you know we already talked about making some default look-and-feel and
> some of you stated that better to create a new component set.
> At beginning I prefer go with Express due to what I thought Express was
> done, but seems that Basic and Express has it's own reason to exists.
>
> So, if we start a new set, I want it to have a great look of course, but it
> must be functional and with great quality.
>
> To define what components should be done, I think we can start we some that
> are in mostly all applications no matter what kind of device will be used:
> * Button, TextField, CheckBox, RadioButton, Slider, List, Toggle, Table,
>
> Menu
>
> I think we have most of the work already done before and all the components
> above works mostly the same in web, desktop and devices. So this first
> round could be defined as our first milestone to reach.
>
> Then we should go with other components that I are not as easy and widely
> used as the ones above:
> * A Date component, that could be used in desktop and mobile and will have
>
> a great usability. maybe could be a component that has various layouts and
> could work differently depending on configuration, user election and
> devices.
> * Tooltips, this component seems as well a bit confusing depending on where
>
> platform will be used, maybe in Royale is as easy as to have 2 or 3 kind of
> beads to decorate other components...
> * Dialogs, Alerts, .... this is something that I would try to rethink: if
>
> we use in desktop, we expect something like a popup, in mobile, popups are
> a bit weird in usability terms, I have some ideas in mind here
> * Form, maybe a key piece in almost every application that should work ok
>
> in almost all kind of devices.
> * Loader or ProgressBar
>
> *...
>
> Lastly, we have another block of components that we can see in some UI
> frameworks and not in others and maybe some of them are not as needed as
> the first block:
> * Panel-Card, Accordion, Badges, SnackBar, Chips,...and many more.... as
>
> Alex said, this part is mostly based on users demand
> * media components : Video, sound... should we enter this path, again users
>
> demand should guide us here.
>
> Having like three separate blocks of components, I see the first one a
> must, all are needed. The second are in the middle, some must be needed but
> we can improve the current state of the art, others could be left if
> there's no interest. The last one is mostly components that could be needed
> or not and like Alex said, people will let us know about it, and expect as
> we have many others, people could contribute those at some level of
> completion.
>
> Additionaly. Some *philosophy* that I'd like to achieve with this set:
>
> I'd like to create a set that could allow users to focus on functionality
> while we give them usability.
> So people should be able to make a concrete application screen with the
> components provided, have right events, etc..
> Regarding devices, this should be completely solved by our set so, the same
> code should run on web, desktop, mobile, tablet and TV without the need for
> people to change any line of code in their Applications.
> Things like user interaction (mouse vs touch), control representation
> (different sizes), responsively and adaptation, should be controled at
> framework level or configurable by users at top level (the case of date
> controls and how to the layout and controls be right depending if we are
> working on web, desktop or mobile/tablet)
>
> So this is like a three-part approach and something I think we should
> discuss in order to work.
> I think this effort needs some people working on it with a similar vision
> and is a lot of work to be done that should be started only if there's some
> consensus on what's the goal and the process to reach that goal. If not,
> I'm afraid people working on this could reach blocking paths or be
> disappointed through the long way to do.
>
> Thoughts?
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>