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 >
