royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject New Component Set
Date Sat, 11 Nov 2017 11:39:16 GMT

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,

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
* 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

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.


Carlos Rovira

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message