I suppose my biggest issue is with the Zen theme and the Wood theme. They seem so silly; perhaps more gimmicky than they should be given the typical use-cases for [Adobe] Flex.
Each client I've had used Flex for Transactional Software except 1. Most of the projects [except 1], have built internal-facing products. I can't think of many use-cases where a Flex Application will be spruced up with a "Wood" theme or where my client reaches a state of peace with a "Zen" theme. [1] http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7f85.html#WS2db454920e96a9e51e63e3d11c0bf69084-7e8c On Sat, Feb 25, 2012 at 4:41 PM, Cortlandt Winters <c...@cortwinters.net>wrote: > Nice work Jude > > I very much disagree with David here, though I totally understand the > desire. It takes much too much time to do a good skin or theme. > > Note that there isn't a single complete spark skin available for public > purchase yet and the spark architecture has been out for a couple of years > now. Removing the themes would essentially make it impossible to do small > projects. > > I like the idea of trying to do a skin that follows the android spec and to > look for other ui specs to hit with an out of the box skin. Its a shame to > lose the linux folk because I think Linux could really use flash to provide > a decent ui to all those nice command line tools and the linux graphic > designers offer a lot to us. > > One problem with the current skins is that they all are based on subtle > shade variations of a single color. Most user interfaces want to have 2 or > 3 key colors in a hierarchy of emphasis that goes with a companies brand > guidelines. > > I would very much like to design a few skins that use css to create > conceptual categories or user cases like so > > Theme A: one primary saturated color with two complementary saturated > colors for occasional highlights. > > Theme B: 2 primary colors with equal weight on a light or dark ground > > Theme C: Strictly Minimalist, no color or graphics unless strictly > necessary > > Each theme would have its css blocks defined with a level of conceptual > rules for content such as Content area, light text on dark background, or > dark text on light background, so that one doesn't run into the problem > where you end up with light text on a light background or dark text on a > dark background. Too many skins/themes don't pay attention to that. > > The goal is that a developer could fill out a half a dozen properties and > create an nice looking skin that follows a companies existing brand > guidelines or a native platforms look and feel. > > I'm not trying to put design agencies out of business or anything, just to > cover the 2 or 3 most common cases so that teams of 1 or 2 developers can > be maximally productive if they don't have a design budget. > > I know that our flex user group (in Albany ny) had a lot of users that were > individual developers working on a project by themselves with no graphics > budget and I believe that the spark architecture hit this class of > developer very hard. > > I myself was hit very hard on a project a year or so ago when a client was > disturbed that the spark scrollbar looked exactly opposite from the way > that he thought scrollbars always looked. He was a lifetime windows user > and noted that it was very disturbing that the track was dark and the thumb > was light. Used to the flexibility of the mx components I casually > mentioned that it was no problem and that I would get it to look exactly > like he thought it should look only to find myself doing about 6 hours of > free work because we didn't have any budget for it to override a half a > dozen classes. Now that I've done a lot more spark skining it wouldn't take > so long, probably half of the time was spent trying to figure out what I > was missing, but it was a non-optimal experience. > > Also sometimes it's not lazyness, many programmers are simply hopeless when > it comes to graphic design or user interface design, by offering some solid > themes for these folk we might see a bunch of "flex looking" apps, but they > would at least be good looking flex looking apps and not a hopeless shamble > of clashing colors and textures with no consistency and breaking basic user > interface rules. > > It's a lot of work to create skins, but it's kind of fun work and just the > sort of thing that we should be able to get folk to help with. I know that > I can commit to doing at least one or two, though not for a few months. > > One thing that would help the development of skins would be a simple > "kitchen sink" app, that uses each of the components in it's typical > configuration and has a bunch of canned content to test light and dark > sections. Like with the css zen garden. The as fusion folk, like scale > nine, had a contest to fill out the kitchen sink app with designs and got > some good results. Without a kitchen sink app many of the good graphic > designers would get bogged down with implementation details. > > Anyway those are my ideas, thanks for listening. > > > On Sat, Feb 25, 2012 at 2:52 PM, Nicholas Kwiatkowski <nicho...@spoon.as > >wrote: > > > My thoughts are -- it depends on the application. > > > > The existing themes are great if you are doing a lot of forms based > > 'screens'. I don't have a designer on my team, and I most likely never > > will get one. My apps are used by professions that like good usability > and > > a good clean layout -- that is one thing some of the existing themes > give. > > > > Separating them out and making them easily accessible is not a bad idea, > > but removing them -- I'd vote against hat. > > > > -Nick > > > > On Sat, Feb 25, 2012 at 1:11 PM, David Francis Buhler < > > davidbuh...@gmail.com > > > wrote: > > > > > My own personal preference would be to remove the current themes (both > MX > > > and Spark) from the SDK. This includes the Cobalt theme, Zen theme, > etc. > > I > > > would stick with the "Wireframe" theme for Spark controls. In doing so, > > we > > > remove the obvious visual impression of a "Flex Application", and > > > encourage the use of Flex/AIR apps that look like part of their native > > > environment (FaceBook, Android, iOS, Windows 8, etc.). Most developers > > take > > > short-cuts and use one of the existing themes when building a product > for > > > their client, and unintentionally give the impression of a hodgepodge > of > > > technologies that prevent the impression of product cohesion. Removing > > the > > > Cobalt theme, Zen theme, and other themes would discourage this > practice > > of > > > use-what-i-found. > > > > > > If companies have designers, they're better off with a tool like Martin > > > suggests then they are with existing Themes. Moreover, the existing > > themes > > > confuse designers (with the MX and Spark namespaces, the inability to > > > understand each and every style property, or the overwhelming number of > > > properties available). If companies don't have designers, they're > better > > > off sticking with Wireframe theme until they do. > > > > > > Incidentally, I'd love to see a tool that generates themes from a > > > user-defined base color, with the palette generation of complimentary, > > > monochromatic or triad colors, similar to Kuler. > > > > > > [1] http://kuler.adobe.com/ > > > > > > On Sat, Feb 25, 2012 at 12:20 PM, Martin Heidegger < > m...@leichtgewicht.at > > > >wrote: > > > > > > > On 23/02/2012 17:59, Haykel BEN JEMIA wrote: > > > > > > > >> I think the first step should be to create new skins for the current > > > Spark > > > >> components. Designers could make designs for them (ideally using a > > tool > > > >> that enables export to FXG like Illustrator) and then developers can > > > >> create > > > >> skins out of them. > > > >> > > > >> Haykel > > > >> > > > > > > > > Doesn't necessarily be a design for flex: Here i found some nice > > > > inspiration[1]. A *fictional* > > > > Windows 8 user interface - very nice :) > > > > > > > > yours > > > > Martin. > > > > > > > > [1] http://www.theverge.com/2012/**2/24/2822891/windows-desktop-** > > > > ui-concept< > > > http://www.theverge.com/2012/2/24/2822891/windows-desktop-ui-concept> > > > > > > > > > >
