Seems like we are in the same kind of business ! Like you say, a "corporate theme" fits our needs. I understand that this is not very appealing for "branded" web interfaces, but from a practical point of view, it is what is needed when data is more important than the container ! Remember that our users do not use our apps because they are "attracted" but mainly because they are "interested" !!! (design is less important than functionalities)
Nicolas Granon > -----Message d'origine----- > De : gkk gb [mailto:modjkl...@comcast.net] > Envoyé : vendredi 3 novembre 2017 20:58 > À : ngra...@idylog.com; dev@royale.apache.org > Objet : RE: Working on UI Controls styling > > 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. >
