I largely agree with your comments here.
My enterprise/corporate web app actually used the default styling -- neutral (gray) buttons/etc. with corporate blue highlights for selection etc. found in default Spark. I didn't want the components to stand out and be distracting. They're necessary, and should look nice, but should not grab attention and be distracting. So font choice is critical for readability (I use Roboto google font) and appearance should be stylish, but otherwise should remain in the background. The star of the show are the charts, text, data associated with the app. My interest wouldn't be fancy themes; I'd rather see a full component set. Just my 2 cents... > On November 3, 2017 at 10:29 AM Idylog - Nicolas Granon wrote: > > > Quote : > " Maybe a good question for our users is: How many of you used the > default Flex skins vs a whole new set of skins? If most folks completely > re-skinned to match their corporate branding, it matters less what our > default is, and more that we can allow folks to customize every pixel." > > For enterprise (business) RIAs, we have *always* sticked to the > "standard" theme (Halo, then Spark). > It was very neutral, which is good for enterprise apps. > Yet a bit more elaborate than usual (local installed) business > apps...(rounded corners, gradients). > The default font was excellent. > For business apps, a fancy theme (skins) is not very desirable... > One key point is excellent readability, and excellent differentiation > between unselected, hovered and selected items (in a list, in a form...). > All in all, something close to default adobe themes fits us perfectly ! > > OF course, our usage might not be typical... > > Nicolas Granon > > > > ---Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com mailto:aha...@adobe.com .INVALID] Envoyé : vendredi 3 novembre 2017 17:53 À : dev@royale.apache mailto:dev@royale.apache .org Objet : Re: Working on UI Controls styling Hi Carlos, I skimmed through https://material.io/guidelines/# last night. My impression is that there were two parts to it. First was the environment/principles section which talked about physical objects and light (and motion), and then there were choices of widgets. For example, I didn't see anything in the first part that said that a text input had to be a single line and couldn't be a box. That made me think that we could use our widget set and apply Material environment and principles to it. If we decide not to, I would think you would want to have some sort of similar environment/principles document which seems like a fair amount of work. I think we'd end up looking different because we have different widgets and maybe some different colors. I'm pretty sure that we don't want to be different so much that we don't create things that folks want to use. The priority to me is just to prove that you can alter every pixel in every widget we have so that others can provide custom skins as well. So starting with Material principles seems like it would save us time, we can get something released, and can innovate more later. Maybe a good question for our users is: How many of you used the default Flex skins vs a whole new set of skins? If most folks completely re-skinned to match their corporate branding, it matters less what our default is, and more that we can allow folks to customize every pixel. The wireframe can be black and white, IMO. I was thinking that "vivid" would have parameterized colors. Since Bootstrap was mentioned, I want to point out that the Flat.swc is a rough approximation of the Flat theme which is a Bootstrap theme. It is a rough approximation because I could not use the Flat CSS file directly since it contains much more advanced CSS than we currently support on the SWF side. But it presumed that the Checkbox was a Label with a Span that hides in front of or behind the in order to allow customizing every pixel. Looks like MDL uses the same Span trick but maybe without a symbol font. Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox should not have that extra Span. But it looks to me that a SkinnableCheckbox can add that extra Span and you either give it the same class name that BootStrap or MDL uses or create our own set of classnames and the CSS that goes with it. Of course, I could be wrong. This is not my area of expertise at all. -Alex On 11/3/17, 1:35 AM, "carlos.rov...@gmail.com mailto:carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: >Hi Alex, > >2017-11-03 7:39 GMT+01:00 Alex Harui : > >> Hi Carlos, >> >> Looks good to me. Thanks for doing this. >> > >Thanks :) > >> >> I'm not sure I understand all of the aspects of this effort. My >>current understanding is that Google Material is under the Apache >>License and thus we can use it if we want to. Am I correct that >>MaterialDesignLite is one implementation of Google Material and we >>could create our own implementation and it could be visually >>different? >> > >We can implement our own material in Royale, but I'm afraid that doing >that will not make us highlight our solution against the rest of >competitors. Another point is something I said various times: >When I did MDL, I notice a huge problem: MDL has its own set of >components, some are in all sets (Button) but others not (Card), and >they has it's own implementation, what make it almost impossible >generalize a theme. For this reason I always point that we need our own >set and there we can implement themes. But other >*externa* sets will never get this since they have its own >implementation and most important once you start to develop with MDL >you can't go back and change for other. So MDL is for me something we >have until our own set are robust and highly configurable in both the >things we can do and how can it could be represented, and switch >between style should be really easy to change the global look of an App >without much hassle. > > >> >> Also, IIRC, Material has different components than Flex did so we'd >> have to invent some new looks anyway. So having a TextInput with >> borders all around would just be our flavor of Material. >> > >That's what I point above. We must to *freeze* the list of components >at some time work over a concrete set We can then plan in the future >include a new component in the official set, and that will need to work >on the themes we already have to include the new one. > > >> >> Regarding colors, it looks like Material is parameterized around a >>couple of colors. So if we did our skins to work against >>parameterized colors then would it really matter what color we >>choose? >> > >That's completly right. I could make wireframe based on two or three >colors and as you change it in CSS all controls should tint >consistently. > > >> >> Regarding Basic components, right now Checkbox is a <input >>type="check"/>caption. AIUI, you cannot style the on >>many browsers, so I think we have to have a different set of elements >>in a checkbox. It looks like Bootstrap uses: >> >> Caption >> >> Where the span uses a special symbol font with checked and unchecked >>boxes. >> > >That's what we need to figure. Should we make themes available in Basic? >if >so, has basic the right implementation? >If not, and if we don't want to change the actual very basic >implementation, we need to put some "skin" implementation that at least >in JS implementation I figure that will change one face (the actual >basic) with the theme face. > >I'm thinking loud, since this is something we should explorer all >together mixing the best ideas of people involved > >Thanks > > > >> >> Thanks, >> Alex >> >> On 11/2/17, 5:15 PM, "carlos.rov...@gmail.com mailto:carlos.rov...@gmail.com >> on behalf of Carlos >>Rovira" >> wrote: >> >> >Hi, >> > >> >I want to expose my initial work (very very initial) on two styles >> >for Royale >> > >> > >> >Wireframe: >> >https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fsnag.gy%2 >> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7Cfa7b1b5a7 >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& >> sdata=%2Fk8YQxC5bDOaC >> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0 >> > >> >(Wireframe intention is for quick Royale App prototyping, people >> >will >>use >> >this to start their applications, and then moving to it's own >> >styling >>that >> >could be another royale theme provided by us, or something done by >>users. >> > >> >Vivid (to put some temporal name): >> >https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fsnag.gy%2 >> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7Cfa7b1b5a7 >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& >> sdata=kxYE7ylOsXPUEeE >> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0 >> > >> >(*Please, Notice that only the first button has some styling here*) >> >(This theme could be the default theme for royale components like >> >halo >>was >> >for mx and spark was for spark) >> > >> >I want to put in place all the main components, so I would need some >> >"component list" (Button, TextInput, CheckBox,...and what more?.), >> >and we'll be centering all the effort in only that list of components. >> >We need to "paint" all and the code all. >> > >> >The concept of theme involve a concrete set of components (and this >>bring >> >us again if we should do this to be pluggable for Basic, or go >> >directly with Express, I think even Basic should be able to use a >> >theme maybe >>using >> >beads to be PAYG) >> > >> >So, before continue tomorrow, I want some feedback on this: >> > >> >* I think Wireframe is clearly something Black&White, maybe as I >> >did, >>in >> >some grey scale colors. But for Vivid, I'm still figuring if it >> >should >>be >> >something "flat" and very simple, or go with something more >> >elaborated since the thing I did in the example with orange button. >> > >> >* I like the look and feel of Google Material, how textfields looks >> >and behaves, the animations, and visual concepts. But the problem is >> >that >>all >> >that visuals are clearly Google Material. Should we create something >>more >> >new? This has a problem that maybe we could reach something >> >great....or not, and is more work to iterate something until we reach a good point. >> >For example, the text input I created has the classic box look, for >> >me Material Design is better with only a bootom line, but the first >> >is >>more >> >generalist, while the second is clearly google, android,... I could >>try to >> >think in something new a see what happens >> > >> >* In the other hand, someone would want to join me in this effort? >> >If >>so I >> >could center in the design part, and other person could work with me >> >on the example project "RoyaleThemes". The example app is very >> >important, >>since >> >it >> >could have a playground for every component so we can tweak at >>runtime. we >> >could even generate the code to get that look...this could be like >> >FlexThemeManager App that we had in the Flex days. >> > >> >* About colors for the second again, don't have any preferences >> >right >>now, >> >I put the same colors that use on the web in the first button, but >> >as I said before things (colors and forms) could change dramatically >> >in the second set. In the first one (Wireframe) I think it's ok to >> >go the path exposed in the image example. >> > >> >Thanks for your comments on this, we'll be defining what we want as >> >we comment here ok? >> >I'm done for today, >> > >> > >> > >> > >> > >> > >> >2017-11-02 14:22 GMT+01:00 Carlos Rovira : >> > >> >> Thanks Harbs! >> >> >> >> very useful, I'll be keeping this info as I make some work >> >> >> >> Carlos >> >> >> >> 2017-11-02 12:13 GMT+01:00 Harbs : >> >> >> >>> BTW, the kind of thing we should be striving for in theme-able >> >>>components is something like this: >> >>> >> >>> >> >>>https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fvcalend >> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7Cf >> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata >> >>>= >> b3VtV >> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0 >> >>><https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fvcalen >> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7C >> >>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdat >> >>>a= >> b3Vt >> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0> >> >>> >> >>> > On Nov 2, 2017, at 12:01 PM, Harbs wrote: >> >>> > >> >>> > FYI, I worked out a theming class for my (Royale) InDesign >>extensions >> >>> which allows for setting global CSS at runtime. The approach >> >>> might >>be >> >>> useful in your theming effort: >> >>> > >> >>>https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fpaste.a >> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7Cfa >> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& >> sdata=bRWKxm >> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0 >> >>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F p >>>>>ast >>>>>e >> . >> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7Cf >> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata >> >>>= >> bRWKx >> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0> >> >>> > >> >>> > (Some of the code is specific to Adobe Extensions.) >> >>> > >> >>> > Some pointers: >> >>> > I used inject_html because I needed some overrides in a CSS file. >>I >> >>> might have been able to rework it so the CSS file was not needed. >> >>> > >> >>> > There is a function called createStyleSheet which is commented >>out. >> >>> That creates a stylesheet called “royale_theme_styles”. It’s the >>same >> >>>as >> >>> including a blank css file with the same name, but it’s loaded >> >>>dynamically rather than requiring the file to be included. If >> >>>that function is >>used >> >>> inject_html is not necessary. >> >>> > >> >>> > The order of dynamically loaded CSS has the same rules as CSS >>loaded >> >>> via declaring it in HTML and the later ones override the earlier >>ones. >> >>>We >> >>> can probably take advantage of that for different levels of >>defaults. >> >>> > >> >>> > HTH, >> >>> > Harbs >> >>> > >> >>> >> On Nov 1, 2017, at 8:05 PM, Carlos Rovira >><carlosrov...@apache.org mailto:carlosrov...@apache.org >> >>> > wrote: >> >>> >> >> >>> >> Hi, >> >>> >> >> >>> >> I think I could start to try what Harbs expose, although I >> >>> >> think >> >>>what I >> >>> >> will need in the end is to control some SVG parts with variables. >> >>>Maybe >> >>> >> with the showed SVG/CSS relation could be sufficient. I'll be >> >>>showing >> >>> how >> >>> >> limitations I find. As well as Alex said having inline SVG as >>HTML >> >>> would be >> >>> >> very useful. >> >>> >> >> >>> >> 2017-11-01 18:27 GMT+01:00 Harbs <harbs.li...@gmail.com >> >>> >> mailto:harbs.li...@gmail.com <mailto: >> >>> harbs.li...@gmail.com mailto:harbs.li...@gmail.com >>: >> >>> >> >> >>> >>> I’m not sure. I haven’t seen problems. >> >>> >>> >> >>> >>> The only issues that come to mind are: >> >>> >>> 1. There’s no load events on SVG images on Microsoft browsers. >> >>> >>> 2. Chrome has issues with SVG, transforms and fractional pixels. >> >>> >>> 3. There’s some blending issues that different browsers >> >>> >>> handle >> >>> differently >> >>> >>> depending on isolation modes. >> >>> >>> >> >>> >>> There’s likely other issues, but these are ones that I’ve had >> >>> >>> to >> >>>deal >> >>> with. >> >>> >>> >> >>> >>> The major gotcha in terms of mixing HTML and SVG is that HTML >>can >> >>>not >> >>> be >> >>> >>> nested inside SVG without ForeignObject. ForeignObject does >> >>> >>> not >> >>>have >> >>> full >> >>> >>> browser support. >> >>> >>> >> >>> >>>> On Nov 1, 2017, at 7:08 PM, Alex Harui >><aha...@adobe.com mailto:aha...@adobe.com .INVALID >> >>> > wrote: >> >>> >>>> >> >>> >>>> A couple of years ago, I thought I had learned that some >>browsers >> >>>had >> >>> >>>> issues with SVG background-images. Maybe psuedo-states were >> >>> involved, >> >>> >>> but >> >>> >>>> a Button might "blink" as it changed states and loaded an >> >>> >>>> SVG background-image. Do we know if that was just a bug in >> >>> >>>> some >> >>>browser >> >>> or >> >>> >>> is >> >>> >>>> that still a concern? >> >>> >>>> >> >>> >>>> I think I would like to see a simple set of HTML/SVG/CSS/JS >>that >> >>> shows >> >>> >>> how >> >>> >>>> any declarative SVG and JS have to work together to handle >> >>>resizable >> >>> >>>> skins/components. Then it might be more obvious what needs >> >>> >>>> to >> >>> change in >> >>> >>>> the tooling. We allow inline HTML now in MXML. I think we >> >>> can/should >> >>> >>>> allow inline SVG, but for both inline HTML and SVG, id's in >> >>> >>>> the >> >>> inline >> >>> >>>> content do not become id's to MXML and AS. >> >>> >>>> >> >>> >>>> HTH, >> >>> >>>> -Alex >> >>> >>>> >> >>> >>> >> >>> >>> >> >>> > >> >>> >> >>> >> >> >> >> >> >> -- >> >> Carlos Rovira >> >> >> >>https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me% >> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7Cfa7b1 >> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& >> sdata=C7a72gwfH2 >> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0 >> >> >> >> >> > >> > >> >-- >> >Carlos Rovira >> >https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2 >> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250 >> 0f48%7Cfa7b1b5 >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558& >> sdata=C7a72gwfH264w >> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0 >> >> > > >-- > ><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c o >deo >scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b 5 >a7b >34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQT O >Hs0 UppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0> > >Carlos Rovira > >Director General > >M: +34 607 22 60 05 > >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co d >eos >copic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b5 a >7b3 >4438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQTO H >s0U >ppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0 > > >Conocenos Avant2 en 1 minuto! ><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favan t >2.e >s%2F%23video&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b 1 >b5a >7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=b%2FFMr1Aj i >t94 TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%3D&reserved=0> > > >Este mensaje se dirige exclusivamente a su destinatario y puede >contener información privilegiada o confidencial. Si ha recibido este >mensaje por error, le rogamos que nos lo comunique inmediatamente por >esta misma vía y proceda a su destrucción. > >De la vigente Ley Orgánica de Protección de Datos (15/1999), le >comunicamos que sus datos forman parte de un fichero cuyo responsable >es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la >prestación del servicio o información solicitados, teniendo usted >derecho de acceso, rectificación, cancelación y oposición de sus datos >dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, >Madrid con la documentación necesaria.
