You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Martin Heidegger <mh...@leichtgewicht.at> on 2012/02/23 04:55:32 UTC
[IDEAS] Flex: New user interface design
Hello List,
I think we need new ideas for user interface designs created with Flex.
New compared to the efforts in the Android/iOS community but also just
spectacular ones.
What do you think?
yours
Martin.
Re: [IDEAS] Flex: New user interface design
Posted by Avinash Narayanan <av...@gmail.com>.
This is brilliant!!
I am not good in designing but if any running around work needs to be done,
let me know.
Thanks
Avinash Y
On Thu, Feb 23, 2012 at 11:21 AM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> I mean designs (photoshop/illustrator/gimp/**scribbles/css/etc.) and
> concepts (swfs/code/text/anything really) for user interfaces that utilize
> the
> power of flash and flex. Flex default styles look pretty rusty compared to
> Android and co. and new designs start with ideas, right?
>
> yours
> Martin.
>
>
> On 23/02/2012 14:08, Ariel Jakobovits wrote:
>
>> I'm in, but what do you mean?
>> Ariel Jakobovits
>> Email: arieljake@yahoo.com
>> Phone: 650-690-2213
>> Fax: 650-641-0031
>> Cell: 650-823-8699
>>
>>
>> ______________________________**__
>> From: Martin Heidegger<mh...@leichtgewicht.at>
>> To: flex-dev@incubator.apache.org
>> Sent: Wednesday, February 22, 2012 7:55 PM
>> Subject: [IDEAS] Flex: New user interface design
>>
>> Hello List,
>>
>> I think we need new ideas for user interface designs created with Flex.
>> New compared to the efforts in the Android/iOS community but also just
>> spectacular ones.
>>
>> What do you think?
>>
>> yours
>> Martin.
>>
>
>
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
I mean designs (photoshop/illustrator/gimp/scribbles/css/etc.) and
concepts (swfs/code/text/anything really) for user interfaces that
utilize the
power of flash and flex. Flex default styles look pretty rusty compared
to Android and co. and new designs start with ideas, right?
yours
Martin.
On 23/02/2012 14:08, Ariel Jakobovits wrote:
> I'm in, but what do you mean?
>
> Ariel Jakobovits
> Email: arieljake@yahoo.com
> Phone: 650-690-2213
> Fax: 650-641-0031
> Cell: 650-823-8699
>
>
> ________________________________
> From: Martin Heidegger<mh...@leichtgewicht.at>
> To: flex-dev@incubator.apache.org
> Sent: Wednesday, February 22, 2012 7:55 PM
> Subject: [IDEAS] Flex: New user interface design
>
> Hello List,
>
> I think we need new ideas for user interface designs created with Flex. New compared to the efforts in the Android/iOS community but also just spectacular ones.
>
> What do you think?
>
> yours
> Martin.
Re: [IDEAS] Flex: New user interface design
Posted by Ariel Jakobovits <ar...@yahoo.com>.
I'm in, but what do you mean?
Ariel Jakobovits
Email: arieljake@yahoo.com
Phone: 650-690-2213
Fax: 650-641-0031
Cell: 650-823-8699
________________________________
From: Martin Heidegger <mh...@leichtgewicht.at>
To: flex-dev@incubator.apache.org
Sent: Wednesday, February 22, 2012 7:55 PM
Subject: [IDEAS] Flex: New user interface design
Hello List,
I think we need new ideas for user interface designs created with Flex. New compared to the efforts in the Android/iOS community but also just spectacular ones.
What do you think?
yours
Martin.
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 20:08, Tomasz Maciąg | Fuse Collective wrote:
> It also depends on how you inspiration process works. Basically you're
> right, but I meant making research before anything else so I won't try
> to reinvent something that already has been done. I'm not up to date
> with new/cool ideas for UI on different platforms so it'll take some
> time for me to cache up.
Everybody can take the time he needs - no pressure! However: we will
most likely reinvent some wheels - considering that there are more than
a half a million apps in the app store ;) If the design is enough to
keep us motivated and shows us that the sky is the limit then I am all
for it :)
cheers
Martin.
Re: [IDEAS] Flex: New user interface design
Posted by Tomasz Maciąg | Fuse Collective <t....@fusecollective.com>.
W dniu 2012-02-23 11:27, Martin Heidegger pisze:
> Before researching anything you'd always have an inspiration idea
> first. Scribble down whatever idea grows in your mind to the point it
> is explainable to the list: just far enough to start a discussion.
> Inspiration for developers.
>
> yours
> Martin.
>
It also depends on how you inspiration process works. Basically you're
right, but I meant making research before anything else so I won't try
to reinvent something that already has been done. I'm not up to date
with new/cool ideas for UI on different platforms so it'll take some
time for me to cache up.
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 17:41, Tomasz Maciąg | Fuse Collective wrote:
> However I'm not entirely sure how to tackle and two basic ideas....
Before researching anything you'd always have an inspiration idea first.
Scribble down whatever idea grows in your mind to the point it is
explainable to the list: just far enough to start a discussion.
Inspiration for developers.
> Martin, do you mean new/cool user interface just for Mobile or for
> desktop/browser too?
An idea is an idea: There is no point in restricting that, is there? I
mean: If you have a cool design for Mobile (touch) but a solution for
desktop (mouse/keyboard use) is missing then i am sure the list can
provide feedback.
yours
Martin.
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Apache does not "employ" anyone. If you are a designer or know a
designer that wants to help: It is a great thing to contribute this sort
of things.
However: Please use a new thread for that topic. I started this thread
to find new ideas for the next flex user interface.
yours
Martin.
On 24/02/2012 02:22, Ben Dalton wrote:
> second the idea of putting together a bit of a styleguide for people to
> use when building applications... maybe a combination of best practices and
> examples for what you can do with the framework.
>
> I also would encourage us to employ some talented developer/designers to
> create a new default spark skin. While the default skin is much better than
> the old Halo themes, I think we can certainly improve
Re: [IDEAS] Flex: New user interface design
Posted by Ben Dalton <be...@gmail.com>.
I second the idea of putting together a bit of a styleguide for people to
use when building applications... maybe a combination of best practices and
examples for what you can do with the framework.
I also would encourage us to employ some talented developer/designers to
create a new default spark skin. While the default skin is much better than
the old Halo themes, I think we can certainly improve things.
On Thu, Feb 23, 2012 at 11:38 AM, David Francis Buhler <
davidbuhler@gmail.com> wrote:
> Android has a highly organized, hierarchical approach to their UI Design,
>
> Get Started
> -Creative Vision
> -Design Principles
> -UI Overview
>
> Style
> -Devices and Displays
> -Themes
> -Touch Feedback
> -Metrics and Grids
> -Typography
> -Color
> -Iconography
> -Writing Style
>
> Patterns
> -New
> -Gestures
> -App Structure
> -Navigation
> -Action Bar
> -Multi-pane Layouts
> -Swipe Views
> -Selection
> -Notifications
> -Compatibility
> -Pure Android
>
> Building Blocks
> -Tabs
> -Lists
> -Grid Lists
> -Scrolling
> -Spinners
> -Buttons
> -Text Fields
> -Seek Bars
> -Progress & Activity
> -Switches
> -Dialogs
> -Pickers
>
> [1] http://developer.android.com/design/index.html
>
Re: [IDEAS] Flex: New user interface design
Posted by Ariel Jakobovits <ar...@yahoo.com>.
Like this idea.
Ariel Jakobovits
ajakobov@adobe.com
650-350-0282
On Feb 24, 2012, at 2:43 PM, Daniel Reicher <da...@gmail.com> wrote:
> Another approach may be to build themes that closely follow the UI/UX
> guidelines of the native environments: Android ICS and iOS as initial
> targets and adding components to meet those specs: Scrollable Tabs, Seek
> Bars/Sliders, Progress Bar, Dialog, Toasts, Grid Lists, etc.
>
> This would *theoretically* allow an app to be compiled to varied targets
> with a native feel and offers a pretty hard-target to work toward. If the
> logo is any indication, arriving at a common denominator for a
> Flex-specific UI/UX might prove challenging as a jumping off point, but
> could be revisited down the road - or just as a continuation of the current
> mobile theme.
>
> On Thu, Feb 23, 2012 at 1:53 PM, David Francis Buhler <davidbuhler@gmail.com
>> wrote:
>
>> The Android Design site appears to have a Creative Commons license. Perhaps
>> their license provides a foundation for us to begin?
>>
>> On Thu, Feb 23, 2012 at 11:51 AM, Martin Heidegger <mh@leichtgewicht.at
>>> wrote:
>>
>>> On 24/02/2012 01:38, David Francis Buhler wrote:
>>>
>>>> Android has a highly organized, hierarchical approach to their UI
>> Design,
>>>>
>>>> [1] http://developer.android.com/**design/index.html<
>> http://developer.android.com/design/index.html>
>>>>
>>>
>>> A awesome resource for touch based design! Thanks.
>>>
>>> yours
>>> Martin.
>>>
>>
Re: [IDEAS] Flex: New user interface design
Posted by David Francis Buhler <da...@gmail.com>.
I agree with this approach.
http://scalenine.com/gallery/ had tried something similar. I think they
would have been more successful if they had a more complete and consistent
offering (such as a FaceBook theme).
On Fri, Feb 24, 2012 at 5:43 PM, Daniel Reicher <da...@gmail.com>wrote:
> Another approach may be to build themes that closely follow the UI/UX
> guidelines of the native environments: Android ICS and iOS as initial
> targets and adding components to meet those specs: Scrollable Tabs, Seek
> Bars/Sliders, Progress Bar, Dialog, Toasts, Grid Lists, etc.
>
> This would *theoretically* allow an app to be compiled to varied targets
> with a native feel and offers a pretty hard-target to work toward. If the
> logo is any indication, arriving at a common denominator for a
> Flex-specific UI/UX might prove challenging as a jumping off point, but
> could be revisited down the road - or just as a continuation of the current
> mobile theme.
>
> On Thu, Feb 23, 2012 at 1:53 PM, David Francis Buhler <
> davidbuhler@gmail.com
> > wrote:
>
> > The Android Design site appears to have a Creative Commons license.
> Perhaps
> > their license provides a foundation for us to begin?
> >
> > On Thu, Feb 23, 2012 at 11:51 AM, Martin Heidegger <mh@leichtgewicht.at
> > >wrote:
> >
> > > On 24/02/2012 01:38, David Francis Buhler wrote:
> > >
> > >> Android has a highly organized, hierarchical approach to their UI
> > Design,
> > >>
> > >> [1] http://developer.android.com/**design/index.html<
> > http://developer.android.com/design/index.html>
> > >>
> > >
> > > A awesome resource for touch based design! Thanks.
> > >
> > > yours
> > > Martin.
> > >
> >
>
Re: [IDEAS] Flex: New user interface design
Posted by Daniel Reicher <da...@gmail.com>.
Another approach may be to build themes that closely follow the UI/UX
guidelines of the native environments: Android ICS and iOS as initial
targets and adding components to meet those specs: Scrollable Tabs, Seek
Bars/Sliders, Progress Bar, Dialog, Toasts, Grid Lists, etc.
This would *theoretically* allow an app to be compiled to varied targets
with a native feel and offers a pretty hard-target to work toward. If the
logo is any indication, arriving at a common denominator for a
Flex-specific UI/UX might prove challenging as a jumping off point, but
could be revisited down the road - or just as a continuation of the current
mobile theme.
On Thu, Feb 23, 2012 at 1:53 PM, David Francis Buhler <davidbuhler@gmail.com
> wrote:
> The Android Design site appears to have a Creative Commons license. Perhaps
> their license provides a foundation for us to begin?
>
> On Thu, Feb 23, 2012 at 11:51 AM, Martin Heidegger <mh@leichtgewicht.at
> >wrote:
>
> > On 24/02/2012 01:38, David Francis Buhler wrote:
> >
> >> Android has a highly organized, hierarchical approach to their UI
> Design,
> >>
> >> [1] http://developer.android.com/**design/index.html<
> http://developer.android.com/design/index.html>
> >>
> >
> > A awesome resource for touch based design! Thanks.
> >
> > yours
> > Martin.
> >
>
Re: [IDEAS] Flex: New user interface design
Posted by David Francis Buhler <da...@gmail.com>.
The Android Design site appears to have a Creative Commons license. Perhaps
their license provides a foundation for us to begin?
On Thu, Feb 23, 2012 at 11:51 AM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> On 24/02/2012 01:38, David Francis Buhler wrote:
>
>> Android has a highly organized, hierarchical approach to their UI Design,
>>
>> [1] http://developer.android.com/**design/index.html<http://developer.android.com/design/index.html>
>>
>
> A awesome resource for touch based design! Thanks.
>
> yours
> Martin.
>
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 24/02/2012 01:38, David Francis Buhler wrote:
> Android has a highly organized, hierarchical approach to their UI Design,
>
> [1] http://developer.android.com/design/index.html
A awesome resource for touch based design! Thanks.
yours
Martin.
Re: [IDEAS] Flex: New user interface design
Posted by David Francis Buhler <da...@gmail.com>.
Android has a highly organized, hierarchical approach to their UI Design,
Get Started
-Creative Vision
-Design Principles
-UI Overview
Style
-Devices and Displays
-Themes
-Touch Feedback
-Metrics and Grids
-Typography
-Color
-Iconography
-Writing Style
Patterns
-New
-Gestures
-App Structure
-Navigation
-Action Bar
-Multi-pane Layouts
-Swipe Views
-Selection
-Notifications
-Compatibility
-Pure Android
Building Blocks
-Tabs
-Lists
-Grid Lists
-Scrolling
-Spinners
-Buttons
-Text Fields
-Seek Bars
-Progress & Activity
-Switches
-Dialogs
-Pickers
[1] http://developer.android.com/design/index.html
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 18:25, jude wrote:
> [1] http://www.judahfrangipane.com/examples/minimalscrollbars/
> [2] http://www.judahfrangipane.com/examples/throwbutton/ThrowButtonDesktop.html
Great start, thinks like that really help! Once we have a little more I
will start collecting them in the wiki.
On 23/02/2012 18:25, jude wrote:
> Do we have an examples section yet?
Yes and no: there is a example section in the wiki but its rather dry ;) [1]
No one has put the effort yet to "create" a format for providing
component examples yet.
yours
Martin.
[1] https://cwiki.apache.org/confluence/display/FLEX/App+Examples
yours
Martin.
Re: [IDEAS] Flex: New user interface design
Posted by Randy Troppmann <ra...@gmail.com>.
2012/2/23 jude <fl...@gmail.com>:
>> This would be great. I've been working on some things like this. I've
>> created skins for OSX like scrollbars [1], a throw button [2] and skins for
>> search text input (I'll have to post it).
>>
Nice work Jude.
Re: [IDEAS] Flex: New user interface design
Posted by jude <fl...@gmail.com>.
*Note: If you double click on the button in the example [2] it shows the
another screen showing another example.
2012/2/23 jude <fl...@gmail.com>
> This would be great. I've been working on some things like this. I've
> created skins for OSX like scrollbars [1], a throw button [2] and skins for
> search text input (I'll have to post it).
>
> The throw button is any button that emits events when you press on it and
> drag into a direction.
>
> In the example [2] you click and drag to the left or the right to do
> things like bring in different views. If you double click on the button it
> shows the next example. This shows a header that acts as a sort of
> navigation controller. If you drag to the right or left it will switch
> views (theoretically - I didn't add this behavior). If you pull down from
> the top it could refresh the data (or pull in a view from the top). Same
> for any other direction.
>
> Do we have an examples section yet? If not I suggest,
> - Examples
> - Buttons
> - DataGrid
> - List
>
> But if we have skins should that be another section or part of the
> examples sections?
>
> - Skins
> - Buttons
> - DataGrid
> - List
>
> etc
>
> [1] http://www.judahfrangipane.com/examples/minimalscrollbars/
> [2]
> http://www.judahfrangipane.com/examples/throwbutton/ThrowButtonDesktop.html
>
>
>
>
>
> On Thu, Feb 23, 2012 at 2:59 AM, Haykel BEN JEMIA <ha...@gmail.com>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
>>
>>
>>
>>
>> On 23 February 2012 09:41, Tomasz Maciąg | Fuse Collective <
>> t.maciag@fusecollective.com> wrote:
>>
>> > W dniu 2012-02-23 04:55, Martin Heidegger pisze:
>> >
>> >> Hello List,
>> >>
>> >> I think we need new ideas for user interface designs created with Flex.
>> >> New compared to the efforts in the Android/iOS community but also just
>> >> spectacular ones.
>> >>
>> >> What do you think?
>> >>
>> >> yours
>> >> Martin.
>> >>
>> >
>> > It's good idea and I've thought about it for some time now. I was
>> planing
>> > to this here at Fuse Collective but right now we're swamped with work
>> and I
>> > can't spare designers...
>> > But still, when I find some time, I'm planning to do some
>> comps/wireframes
>> > (may be even code something) and then wait for one of designers to have
>> > some free time.
>> > However I'm not entirely sure how to tackle and two basic ideas fights
>> in
>> > my head:
>> > 1. Create something based on the current components (I mean with pretty
>> > much the same functionality but different/nicer looks)
>> > 2. Innovate and try to create something new from scratch (It would
>> > probably took more time since it should be preceded with proper
>> research).
>> >
>> > New compared to the efforts in the Android/iOS community but also just
>> >> spectacular ones.
>> >>
>> > Martin, do you mean new/cool user interface just for Mobile or for
>> > desktop/browser too?
>> >
>>
>
>
Re: [IDEAS] Flex: New user interface design
Posted by jude <fl...@gmail.com>.
This would be great. I've been working on some things like this. I've
created skins for OSX like scrollbars [1], a throw button [2] and skins for
search text input (I'll have to post it).
The throw button is any button that emits events when you press on it and
drag into a direction.
In the example [2] you click and drag to the left or the right to do things
like bring in different views. If you double click on the button it shows
the next example. This shows a header that acts as a sort of navigation
controller. If you drag to the right or left it will switch views
(theoretically - I didn't add this behavior). If you pull down from the top
it could refresh the data (or pull in a view from the top). Same for any
other direction.
Do we have an examples section yet? If not I suggest,
- Examples
- Buttons
- DataGrid
- List
But if we have skins should that be another section or part of the examples
sections?
- Skins
- Buttons
- DataGrid
- List
etc
[1] http://www.judahfrangipane.com/examples/minimalscrollbars/
[2]
http://www.judahfrangipane.com/examples/throwbutton/ThrowButtonDesktop.html
On Thu, Feb 23, 2012 at 2:59 AM, Haykel BEN JEMIA <ha...@gmail.com>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
>
>
>
>
> On 23 February 2012 09:41, Tomasz Maciąg | Fuse Collective <
> t.maciag@fusecollective.com> wrote:
>
> > W dniu 2012-02-23 04:55, Martin Heidegger pisze:
> >
> >> Hello List,
> >>
> >> I think we need new ideas for user interface designs created with Flex.
> >> New compared to the efforts in the Android/iOS community but also just
> >> spectacular ones.
> >>
> >> What do you think?
> >>
> >> yours
> >> Martin.
> >>
> >
> > It's good idea and I've thought about it for some time now. I was planing
> > to this here at Fuse Collective but right now we're swamped with work
> and I
> > can't spare designers...
> > But still, when I find some time, I'm planning to do some
> comps/wireframes
> > (may be even code something) and then wait for one of designers to have
> > some free time.
> > However I'm not entirely sure how to tackle and two basic ideas fights in
> > my head:
> > 1. Create something based on the current components (I mean with pretty
> > much the same functionality but different/nicer looks)
> > 2. Innovate and try to create something new from scratch (It would
> > probably took more time since it should be preceded with proper
> research).
> >
> > New compared to the efforts in the Android/iOS community but also just
> >> spectacular ones.
> >>
> > Martin, do you mean new/cool user interface just for Mobile or for
> > desktop/browser too?
> >
>
Re: [IDEAS] Flex: New user interface design
Posted by David Francis Buhler <da...@gmail.com>.
colorschemedesigner uses the same approach as Johannes Itten's color
theory, suggesting the use of various percentages of complementary colors,
which is an improvement over Kuler. Pretty Cool.
On Sat, Feb 25, 2012 at 1:52 PM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> On 26/02/2012 03:11, David Francis Buhler 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.
>>
>
> Not remove: extract to a public component and theme repository. ;)
>
>
> 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.
>>
>
> Many people use a framework because it gives immediate results. I think
> its an awesome
> and important place to start from. That being said: the current things you
> get when you use Flex are
> rusty. They used to look good some years ago. Time passed and fresh
> designs are very in need.
> Also a "button" is and a "datagrid" are nice things. But it wouldn't hurt
> to have tools for more
> custom designs available too.
>
>
> 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.
>>
>
> i think I never thought so strict. But you are right: The properties are
> overwhelming indeed.
>
>
> 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.
>>
> Kuler is nice, somehow I like colorschemedesigner [1] more, but anyways: I
> like the thought
> of defining things by "scheme" rather than "concrete". Contrast levels
> etc. Sure opens some
> nice possibilities - worth investigating?
>
> yours
> Martin.
>
> [1] http://colorschemedesigner.**com/ <http://colorschemedesigner.com/>
>
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 26/02/2012 03:11, David Francis Buhler 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.
Not remove: extract to a public component and theme repository. ;)
> 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.
Many people use a framework because it gives immediate results. I think
its an awesome
and important place to start from. That being said: the current things
you get when you use Flex are
rusty. They used to look good some years ago. Time passed and fresh
designs are very in need.
Also a "button" is and a "datagrid" are nice things. But it wouldn't
hurt to have tools for more
custom designs available too.
> 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.
i think I never thought so strict. But you are right: The properties are
overwhelming indeed.
> 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.
Kuler is nice, somehow I like colorschemedesigner [1] more, but anyways:
I like the thought
of defining things by "scheme" rather than "concrete". Contrast levels
etc. Sure opens some
nice possibilities - worth investigating?
yours
Martin.
[1] http://colorschemedesigner.com/
Re: [IDEAS] Flex: New user interface design
Posted by Duane Nickull <du...@uberity.com>.
On 12-02-27 10:16 PM, "jude" <fl...@gmail.com> wrote:
>IMHO I wouldn't invest more time in themes.
+1
If I had to prioritize work, I think I would put the bugs first.
Would anyone be interested in a Vancouver, BC bug squashing/coding weekend
(maybe Whistler - ski & squash & beers)?
If so, I am happy to host.
D
Re: [IDEAS] Flex: New user interface design
Posted by jude <fl...@gmail.com>.
IMHO I wouldn't invest more time in themes. How is it that hey can change
behavior or break your app by switching between them.
Specifically because when I went from the mx theme to the Spark theme
features, styles and behavior I was expecting to be there wasn't. In took a
lot to upgrade an app to Spark. I think maybe that was a implementation
issue. I would rather they just focused on wrapping up a style sheet and
skins.
Another couple issues that relate to it. Warning...this turned out to be a
really long email...
With mx Components they had almost every property and style I ever needed.
The downside in a way was when you wanted to change the visuals you had to
find all the graphics draw commands, sometimes buried across methods in
actionscript.
With Spark you could separate the view but it wasn't well... ...I've
rewrote this paragraph 5 times now and.... I'm just going to summarize *what
I had trouble with*:
• *When creating a Spark skin how do you expose custom styles to the host
component?* On the other side of it -->
• *How do you set custom styles on a Spark component in MXML (for the
purpose of passing those values to the skin)? *
-- In my experience to get style values to the skin you have to create a
new component that declares those styles
-- Or create a style for the component type in the main application file
(which would apply to all instances unless you give it a style name) and
set the style and value there (what if the value is in another document?).
-- Or create a style rule in the document and set the styleName property of
the component to that style.
I don't really like doing the style rule method in Spark. In HTML style
rules work to some degree but then in HTML the layout rules are different.
And also you can set size and positioning properties in addition to styles.
But you can't set any property in a style rule in Spark. So then you end up
using two or more locations to define the look and feel.
This doesn't mean I'm against style rules. They work great for font and
text related purposes. But specifically having to create a style rule or a
new component to get a value into a skin just seems I don't know. In my
experience the designs have been custom enough that you end up creating a
one off skin or end up setting all the styles on the component instance.
Also, does a style rule support bindings? I just thought of this. In
summary, I would like to be able to add custom styles on the component
instance.
Having said all that - it completely changes if you have *tooling*. If you
can see the style tree and navigate to those locations it makes all the
difference. And if you have something that can create all the components
and skin files you would need when creating a skin then that also changes
the game. Which makes me wonder if this was ever a problem Adobe recognized
and wanted to solve.
*A couple more random thoughts*:
• I had struggled a lot with the above before realizing I could call
getStyle() in the skin it will get styles from the host component. I used
hostComponent.getStyle(). I didn't fully understand skin inherited the
styles from the host component. In skinnable component the styleName
property is able to accept an object and inherit the styles defined on that
object. So when the skin is created the skin styleName is to the host
component.
• Skins seem to have different component life cycle. So I expected things
to behave the same. You have to know a lot about the framework.
* Skins and components still have draw commands scatter about that
interfere with look and feel. In skins you have the updateDisplayList but I
think it should be all defined by MXML. For example, a designer should be
able to create a skin without using actionscript. I say with care that
Flash Catalyst accomplished aspects of this. It needed more time and more
components and more states exposed as well as supporting or exposing styles
in some way etc. but what took a few days took before now took a few
minutes AND (a huge and) YOU COULD SEE IT! RT Photoshop creating spark
component skins.
* Oh it drove me nuts when the compiler didn't let me set styles because it
wasn't part of the theme. Ex. Add a DataGrid to a mobile application then
try to set styles on it (styles that work). The compiler won't allow it to
be compiled.
* Excluded styles drove me nuts too. In some class some styles were
excluded possibly because it wasn't supported. The problem is you might
create a skin that does support that style and so you now need to be able
to set that style.
* Skins can't be defined inline. This would make them much more readable.
* spark skins removed styles (that I used regularly) that were in the mx
components (see Spark Datagrid)
*Solutions*
* support setting custom styles on components. possibly "styles" array or
object
<styles><myStyle>#FF00FF</myStyle><borderColor></borderColor></styles>
* allow excluded styles
* allow styles from other themes (mobile theme excludes spark styles that
actually work)
* allow skins to inherit from itemrenderer or make skins as simple as item
renderers
* allow skins inline
* add more styles on the skins or at least the same that were in the mx
counter parts
On Sat, Feb 25, 2012 at 11:54 PM, David Francis Buhler <
davidbuhler@gmail.com> wrote:
> 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
>
>
>
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 27/02/2012 08:02, Erik Lundgren wrote:
> We don't target the html/css stack yet. But we want to. So i think it is important to count it in as soon as possible.
>
> CSS rendering of "real world units" seems stable but does not work exactly the way you would expect.
>
> CSS user agents assumes a 96 ppi screen [1]. On my 113 ppi screen a 10 cm div renders as a 8.5 cm div. Exactly the behavior I don't want: 1 cm in code, 85 mm on screen.
>
> This may of course still be helpful as a fixed northern star. Given the 96 ppi and the browsers rendering we could calculate the run time screens ppi: 96 / (8.5 / 10) ).
In the HTML/CSS world dpi is "preset" and can be changed for
accessability: For example in Chrome you can set the zoom to 150%. Then
the cm size changes too! In other words the unit naming is misleading -
utterly wrong - but it is the basis browsers use. There are extensions
[1] available the set this zoom factor to the value that actually
matches the screen. Internet explorer actually allows to get a the
native dpi using screen.deviceXDPI [2]. If you are on windows the dpi
will be taken using global scaling settings that can be changed in the
control panel [3].
Here is the big problem with these settings: They can change over time.
Current documentation on mobile dpi for Flex 4.6 [4] says to use the
"initialization" [5] - That means that the layout and the sizes are not
updated when the dpi changes. The dpi can change on mobile devices for
example if you connect a HDMI monitor on the mobile device. It also
takes the FlexGlobals.topLevelApplication but if you develop in AIr the
screen size actually should be determined using the screen on which
"most of the application" is. That is not supported in windows 7 but it
could be by flex applications ....
yours
Martin.
PS.: I don't use mac what makes me slightly less interested in a
solution for Mac. Sad-Linux-Panda.
[1]
https://chrome.google.com/webstore/detail/pboiiapkapflomkknmedcjmhdfepfdje
[2] http://msdn.microsoft.com/en-us/library/ms533721(v=vs.85).aspx
<http://msdn.microsoft.com/en-us/library/ms533721%28v=vs.85%29.aspx>
[3]
http://msdn.microsoft.com/en-us/library/ie/aa770067(v=vs.85).aspx#highDPI_activating_settingDPI
<http://msdn.microsoft.com/en-us/library/ie/aa770067%28v=vs.85%29.aspx#highDPI_activating_settingDPI>
[4]
http://help.adobe.com/en_US/flex/mobileapps/WS19f279b149e7481c682e5a9412cf5976c17-8000.html
[5]
http://help.adobe.com/en_US/flex/mobileapps/WS19f279b149e7481c682e5a9412cf5976c17-8000.html#WS19f279b149e7481c-6bd5f36412cc794cd7a-8000
Re: [IDEAS] Flex: New user interface design
Posted by Erik Lundgren <er...@lndgrn.se>.
26 feb 2012 kl. 22.59 skrev Martin Heidegger:
> real world units are no problem in css/javascript allowing "cm".
We don't target the html/css stack yet. But we want to. So i think it is important to count it in as soon as possible.
CSS rendering of "real world units" seems stable but does not work exactly the way you would expect.
CSS user agents assumes a 96 ppi screen [1]. On my 113 ppi screen a 10 cm div renders as a 8.5 cm div. Exactly the behavior I don't want: 1 cm in code, 85 mm on screen.
This may of course still be helpful as a fixed northern star. Given the 96 ppi and the browsers rendering we could calculate the run time screens ppi: 96 / (8.5 / 10) ).
1. http://www.w3.org/TR/CSS21/syndata.html#length-units
Re: [RT] DPI dependent code was. Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Yeah, completely experimental code.
It does following things:
* It replaces the embed codes in the html without id and with the same
url as the swf that is running to
embed codes with a proper id
* It allows to create "JavaScript" code that receives directly a
reference to the embed code it comes from
(important if you have more than one Flash running on the same page)
* It automatically takes care of error handling
yours
Martin.
On 27/02/2012 07:28, Omar Gonzalez wrote:
> What is your script trying to do exactly? I see it handling divs and
> rewriting the Flash div for some reason? I'm not really sure what the .as
> and .js file are working to do together. I guess I might have misunderstood
> what you wanted to do with the JS bridge you originally mentioned to Erik.
> Do the browsers give a more accurate value for the dpi? I haven't tried
> querying for that value in any projects yet.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
> Apache Flex PPMC Member
>
Re: [RT] DPI dependent code was. Flex: New user interface design
Posted by Omar Gonzalez <om...@gmail.com>.
On Sun, Feb 26, 2012 at 2:18 PM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> I am all for it. I have implemented that for JavaScript before. My problem
> with the javascript implementation is to make it "easy". In other words:
> Without a "id" it is not possible to implement a generic ID. I have started
> with a implementation of JavaScript Modules but haven't had time to finish
> back then [1].
>
> yours
> Martin.
>
> [1] http://www.assembla.com/code/**nanosome/subversion/nodes/**
> trunk/as3/integrate/src/**nanosome/integrate/browser?**rev=278<http://www.assembla.com/code/nanosome/subversion/nodes/trunk/as3/integrate/src/nanosome/integrate/browser?rev=278>
>
>
What is your script trying to do exactly? I see it handling divs and
rewriting the Flash div for some reason? I'm not really sure what the .as
and .js file are working to do together. I guess I might have misunderstood
what you wanted to do with the JS bridge you originally mentioned to Erik.
Do the browsers give a more accurate value for the dpi? I haven't tried
querying for that value in any projects yet.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
[RT] DPI dependent code was. Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
I am all for it. I have implemented that for JavaScript before. My
problem with the javascript implementation is to make it "easy". In
other words: Without a "id" it is not possible to implement a generic
ID. I have started with a implementation of JavaScript Modules but
haven't had time to finish back then [1].
yours
Martin.
[1]
http://www.assembla.com/code/nanosome/subversion/nodes/trunk/as3/integrate/src/nanosome/integrate/browser?rev=278
On 27/02/2012 07:05, Omar Gonzalez wrote:
> On Sun, Feb 26, 2012 at 1:59 PM, Martin Heidegger<mh...@leichtgewicht.at>wrote:
>
>> Hello Erik,
>>
>> real world units are no problem in css/javascript allowing "cm". In Flex
>> the problem is that the Flash Player does not offer proper DPI (as you
>> mentioned). That means we need "workarounds" it can be implemented within
>> the Web using ExternalInterface - a JavaScript bridge.
>
> So this part should be easy as we can just store a JS string and execute it
> with EI and wrap that all in a class that we can use in UI components to do
> the appropriate width/height assignments. I don't think that would be a big
> deal, we should be able to just poll for that value from the browser once
> in Flex browser based apps.
>
>
>> It can be implemented in AIR using NativeExtensions. There is just no
>> standard solution for that available in Flex.....
>
> If we wrote an ANE that covered all the OSs we need to cover we could apply
> it as a behavior as we've discussed in other threads giving a component the
> capability of reading its correct width and height values in Flex based AIR
> applications. I think that would be a nice feature. Its not going to create
> UIs that are universal to all types of screen sizes from a single layout,
> but it'll make applying designs more predictable and hopefully much more
> accurate. I think its something worth investigating.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
> Apache Flex PPMC Member
>
Re: [IDEAS] Flex: New user interface design
Posted by Omar Gonzalez <om...@gmail.com>.
On Sun, Feb 26, 2012 at 1:59 PM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> Hello Erik,
>
> real world units are no problem in css/javascript allowing "cm". In Flex
> the problem is that the Flash Player does not offer proper DPI (as you
> mentioned). That means we need "workarounds" it can be implemented within
> the Web using ExternalInterface - a JavaScript bridge.
So this part should be easy as we can just store a JS string and execute it
with EI and wrap that all in a class that we can use in UI components to do
the appropriate width/height assignments. I don't think that would be a big
deal, we should be able to just poll for that value from the browser once
in Flex browser based apps.
> It can be implemented in AIR using NativeExtensions. There is just no
> standard solution for that available in Flex.....
If we wrote an ANE that covered all the OSs we need to cover we could apply
it as a behavior as we've discussed in other threads giving a component the
capability of reading its correct width and height values in Flex based AIR
applications. I think that would be a nice feature. Its not going to create
UIs that are universal to all types of screen sizes from a single layout,
but it'll make applying designs more predictable and hopefully much more
accurate. I think its something worth investigating.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Hello Erik,
real world units are no problem in css/javascript allowing "cm". In Flex
the problem is that the Flash Player does not offer proper DPI (as you
mentioned). That means we need "workarounds" it can be implemented
within the Web using ExternalInterface - a JavaScript bridge. It can be
implemented in AIR using NativeExtensions. There is just no standard
solution for that available in Flex.....
yours
Martin.
On 27/02/2012 06:43, Erik Lundgren wrote:
> Dear list,
>
> I would like to spend some time thinking about the "high level" concepts in flex – the present and the not yet present.
>
> As I scribble in my notebooks my first halt seems to be the methodology used for UI-measurement, and I need some community input:
>
>
> Should Flex measure layouts in "real world units" or "device units"?
>
>
> USE CASE PROBLEM
>
> UI layouts * should be tuned to the human motoric and sensory systems. This can be achieved through the use of "real world units" (myTouchButton always renders as 0.5 cm x 0.5 cm). If UI elements are laid out using "device units" (eg pixels) different screen densities distorts the layout experience as layouts are reused across screens (or print).
>
> * Layout = element size and position (and layering?).
>
>
> PREFERRED SOLUTION
>
> Compose layouts using some "real world unit" (I would promote points). Have Flex read the pixel density of the runtime screen and transpose the layout to "device units" (eg Pixels).
>
>
> PROBLEMS IMPLEMENTING THE SOLUTION
>
> The unit-translation-concept is present in flex today through the applicationDPI property on Application, but its implementation is not exact and based on the precondition that the FLEX can read correct screen ppi values from its runtime. Sadly, this is not always the case.
>
> Present runtime: The flash class Capabilities seems to be reading the operating systems abstractions of "real world units". On my computer (mac) flash reads the screen ppi value as 72 px/inch. In reality my screens density is 113 px/inch. This problem seems to be present on windows and mobile operating systems as well.
>
> Possible future runtimes: On the HTML/CSS stack new "resolution" media queries seems to be implemented. On the "native" stacks implementations seems to be able to read the correct screen ppi values, though the web is full of issues with broken values returned by drivers etc.
>
>
> If there is no way to implement the unit-translationsolution described above, Flex should implement some other concept for laying out UI elements.
>
> I've done research but some community input would be great: Can we find reliable bridges between flex and the ppi values of the screen that renders it? Thoughts?
>
> All the best
> /Erik
>
Re: [RT] DPI dependent code was. Flex: New user interface design
Posted by Erik Lundgren <er...@lndgrn.se>.
27 feb 2012 kl. 08.50 skrev Alex Harui:
> Current Flash Player always reports 72dpi on desktop. I think that might change in some future player. I've been wondering if there is a cheap way to get it from the HTML wrapper.
There are things in the w3c documents that sounds promising: The new css3 media queries should be able to detect "resolution" as ppi or ppcm. [1] And JS should be able to deploy media queries programatic and add eventListeners for when the queries changes. [2].
But testing this in FireFox on Mac, guess what it told me ... 96 ppi ... again the abstraction of the browser, not the real screen ppi.
I can't find a reliable way to read the users real run-time screen ppi value if we deploy to the web. That is problematic in a multi screen universe. Sigh.
1. http://www.w3.org/TR/css3-mediaqueries/#resolution
2. http://www.w3.org/TR/cssom-view/#the-mediaquerylist-interface
Yours
/Erik
Re: [IDEAS] Flex: New user interface design
Posted by Ariel Jakobovits <ar...@yahoo.com>.
Two ideas that may be worthless, but:
1. can we determine ppi from the mouse cursor/arrow - is it a standard size that we can measure?
2. can we develop a preloader/component that can query the user to define 1 inch that we can then use for the app to be sized correctly?
Ariel Jakobovits
Email: arieljake@yahoo.com
Phone: 650-690-2213
Fax: 650-641-0031
Cell: 650-823-8699
________________________________
From: Erik Lundgren <er...@lndgrn.se>
To: flex-dev@incubator.apache.org
Sent: Monday, February 27, 2012 2:58 PM
Subject: Re: [IDEAS] Flex: New user interface design
27 feb 2012 kl. 23.18 skrev Alex Harui:
> Let's assume it won't be fixed but you may be able to get a rough, but not exact idea of resolution/density via other means (JS, ANE).
I've researched this all day and I cant find any cross browser js api that allows you to break out of the 96 ppi abstract screen that the browser assumes for rendering. In extreme cases, like the iPhone 4, I belive the user agent recalculates the pixel values.
If we could do it in air using native extensions, but not on the web should we do it anyway? I don't know.
> It sounds like the problem remains unsolved in browsers as well in that the reported resolution or density isn't 100% accurate. Seems like that would
> have always been the case for any analog screen anyway, wouldn't it?
It's broken. Thats why I hoped we could fix it. :)
> What is the measure of success? Is it that a 1-inch button is roughly 1 inch or exactly 1 inch? Or is it to guarantee a workflow that allows good printing?
Perfection is good. I would like to abstract away the device scaling factor, making lives easier for designers/developers.
For me the functionality would offer a paper, to screen, to paper workflow.
I do a lot of early wireframes on paper. A unified measuring stick would be really helpful. You could simulate a device you don't own on paper. You could easily study a early layout in the users own context without the device or any code.
Designers/developers would train their eyes to one scale-set allowing them to better understand it and how to apply it to images, text, usecases etc.
And in the end it would be a great foundation for advanced printing out of Flex applications.
I can think of many more benefits, but sadly we seem to operate on one system abstraction to high for that to happen. (If someone else can't think of something smart.)
Yours
/Erik
(Sorry for my english)
Re: Native Screen ANE – was "new user interface design"
Posted by Jonathan Campos <jo...@gmail.com>.
On Tue, Feb 28, 2012 at 2:47 PM, Brent Arnold <br...@brentarnold.com> wrote:
> I don't have experience on the desktop monitor results, but from my
> understanding with mobile the dpi information is returned directly from the
> OS on the device. It's known that some devices return improper info, which
> I've heard is a result of the OS, not AIR.
Brent is correct. Capabilities goes back to the hardware and gets the value
as it reports. Whether that value is correct or not is up to the hardware.
If the value is incorrect then I don't see a simple fix of getting the
value from the hardware.
I wouldn't say there is a need for this ANE.
--
Jonathan Campos
Re: Native Screen ANE – was "new user interface design"
Posted by Brent Arnold <br...@brentarnold.com>.
I don't have experience on the desktop monitor results, but from my
understanding with mobile the dpi information is returned directly from
the OS on the device. It's known that some devices return improper info,
which I've heard is a result of the OS, not AIR.
For me the information that is returned works well enough to scale
content properly for my mobile apps. I suppose if you have a more
detailed use case, it could be a problem.
Brent
On 2/28/12 1:40 PM, Erik Lundgren wrote:
> 28 feb 2012 kl. 20.46 skrev Brent Arnold:
>
>> What information would you need that's not already included in the Capabilities class? Right now with Flash and AIR we can get access to screenDPI, screenResolutionX/Y, as well as color depth information.
> I believe the Capabilities.screenDPI doesn't query the OS for all that the os knows.
>
> On the desktop the Capabilities.screenDPI property will always return the abstract ppi, not the actual ppis of the displays connected to the pc. On mac you will always get the return value 72. On windows – I'm not sure – but I would imagine it returns 96 (or the custom dpi set by the user in the control-panel). Or maybe the player will return 72 on windows as well. The point is. You won't get the value you are looking for.
>
> There seems to be multiple issues with mobile devices returning the the wrong screen values. Maybe this can't be queried correctly by native code either, but maybe it can.
>
> There is no reliable way of getting this information in Flex at the present. There is no reliable way to draw real world measured elements in flex.
>
> Yours
> /Erik
Re: Native Screen ANE – was "new user interface design"
Posted by Erik Lundgren <er...@lndgrn.se>.
28 feb 2012 kl. 20.46 skrev Brent Arnold:
> What information would you need that's not already included in the Capabilities class? Right now with Flash and AIR we can get access to screenDPI, screenResolutionX/Y, as well as color depth information.
I believe the Capabilities.screenDPI doesn't query the OS for all that the os knows.
On the desktop the Capabilities.screenDPI property will always return the abstract ppi, not the actual ppis of the displays connected to the pc. On mac you will always get the return value 72. On windows – I'm not sure – but I would imagine it returns 96 (or the custom dpi set by the user in the control-panel). Or maybe the player will return 72 on windows as well. The point is. You won't get the value you are looking for.
There seems to be multiple issues with mobile devices returning the the wrong screen values. Maybe this can't be queried correctly by native code either, but maybe it can.
There is no reliable way of getting this information in Flex at the present. There is no reliable way to draw real world measured elements in flex.
Yours
/Erik
Re: Native Screen ANE – was "new user interface design"
Posted by Brent Arnold <br...@brentarnold.com>.
What information would you need that's not already included in the
Capabilities class? Right now with Flash and AIR we can get access to
screenDPI, screenResolutionX/Y, as well as color depth information.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/Capabilities.html
Brent
On 2/28/12 11:36 AM, Erik Lundgren wrote:
> Dear list,
>
> Talking about displays and their native ppi:s we've mentioned ANEs a couple of time. I've tried to research this, because I believe there are real use-cases if we could get it to work – layout elements based on the users context, not his/hers device.
>
> I'm a FLEX developer and feel that an ANE is a bit over my head. I may be able to figure something out in java, but everything I've been able to research about it points at C. And that is a no go for me at the moment.
>
> Are there any C gurus on the list? :)
>
>
> If anyone, more capable than me, would be willing to explore this with me I've tried to collect some material.
>
> 1. http://en.wikipedia.org/wiki/Extended_display_identification_data
> 2. http://www.insanelymac.com/forum/index.php?showtopic=208410
> 3. http://cgit.freedesktop.org/xorg/app/edid-decode/
> 4. https://github.com/claar/php-edid-decode
> 5. http://www.madrau.com/indexSRX4.html
>
> First. There seems to be a spec regulating information exchanged between pc:s and monitors called EDID. [1]
> Desktop computers stores EDID information in their registry, but in a binary format that needs to be parsed.
> I can find the EDID data on my mac, following the guidelines given at [2].
> I don't have access to a windows machine to search for it on that OS.
>
> There is an active C project for parsing the EDID data at [3]. Not sure about licensing.
> There is a php port at [4] if that would help us. Not sure about licensing.
>
> On mac you can get parsed EDID-data using an application like SwitchResX. [5]
>
> And looking at the output the program can generate from my system it seems really promising. I can read that my screens physical size is 286 mm x 179 mm, and a pixel size 1280 x 800 px. This is all I need to calculate my screens correct ppi (113 px/inch).
>
> I'm enclosing the full print out below. It could serve as the foundation for the ActionScript ANE interface. I'm thinking something like a "NativeScreen" class, collecting properties like:
>
> gamma:Number
> timing:Number
> widthCm:uint
> heightCm:uint
> widthInch:uint
> heightInch:uint
> widthPixel
> heightPixel
> ppi:uint
>
> ...
>
> I'm sure there are some pain's down this road, but maybe there is a path ahed. Does this make anyone itch? Sorry for the mac-twisted research. I don't have access to windows at the moment.
>
> Yours
> /Erik
>
>
>
> Printout from SwitchResX:
>
> DDC block report generated by SwitchResX version 4.2.7 for display
> Color LCD
>
>
> -----------------------------------------------------
> ------------------- RAW DATA ------------------------
> -----------------------------------------------------
> 0 1 2 3 4 5 6 7 8 9 A B C D E F
> -----------------------------------------------------
> 0 | 00 FF FF FF FF FF FF 00 06 10 BD 9C 00 00 00 00
> 1 | 03 13 01 03 80 1D 12 78 0A 00 00 00 00 00 00 00
> 2 | 00 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 3 | 01 01 01 01 01 01 52 1C 00 8F 50 20 2E 30 30 20
> 4 | 36 00 1E B3 10 00 00 18 00 00 00 01 00 06 10 20
> 5 | 00 00 00 00 00 00 00 00 0A 20 00 00 00 FE 00 4C
> 6 | 50 31 33 33 57 58 33 2D 54 4C 41 31 00 00 00 FE
> 7 | 00 43 6F 6C 6F 72 20 4C 43 44 0A 20 20 20 00 41
>
> -----------------------------------------------------
> < 00FFFFFF FFFFFF00 0610BD9C 00000000 03130103 801D1278 0A000000 00000000 00505400 00000101 01010101 01010101 01010101 0101521C 008F5020 2E303020 36001EB3 10000018 00000001 00061020 00000000 00000000 0A200000 00FE004C 50313333 5758332D 544C4131 000000FE 00436F6C 6F72204C 43440A20 20200041 >
>
> -----------------------------------------------------
> { 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x06, 0x10, 0xBD, 0x9C, 0x00, 0x00, 0x00, 0x00, 0x03, 0x13, 0x01, 0x03, 0x80, 0x1D, 0x12, 0x78, 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x52, 0x1C, 0x00, 0x8F, 0x50, 0x20, 0x2E, 0x30, 0x30, 0x20, 0x36, 0x00, 0x1E, 0xB3, 0x10, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x01, 0x00, 0x06, 0x10, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, 0x20, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x4C, 0x50, 0x31, 0x33, 0x33, 0x57, 0x58, 0x33, 0x2D, 0x54, 0x4C, 0x41, 0x31, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x43, 0x6F, 0x6C, 0x6F, 0x72, 0x20, 0x4C, 0x43, 0x44, 0x0A, 0x20, 0x20, 0x20, 0x00, 0x41, }
>
> -----------------------------------------------------
> Valid EDID block: checksum passed
>
> -----------------------------------------------------
> ------------------- MAIN EDID BLOCK -----------------
> -----------------------------------------------------
>
> EDID Version........1.3
> Manufacturer........APP
> Product Code........48540 (BD9C) (9CBD)
> Serial Number.......00000000
>
> Manufactured........Week 3 of year 2009
> Max H Size..........29 cm
> Max V Size..........18 cm
> Gamma...............2,20
>
> Display Supported Features:
> ---------------------------
>
>
> Display type:
> -------------
> RGB 4:4:4& YCrCb 4:4:4 Color Encoding Formats
> Display is non continuous frequency
> Default color space is not sRGB standard
> Preferred timing mode includes Native Pixel Format
>
>
> Input signal& sync:
> --------------------
> Digital Input
> Color Bit Depth is undefined
> Digital Interface is not defined
>
>
> Color info:
> -----------
> Red x = 0,000 Green x = 0,000 Blue x = 0,000 White x = 0,312
> Red y = 0,000 Green y = 0,000 Blue y = 0,000 White y = 0,328
>
> Established Timings:
> --------------------
>
> Manufacturer Reserved Timings:
> ------------------------------
>
> Standard Timing Identification:
> -------------------------------
>
> Monitor Description blocks:
> ---------------------------
> Descriptor #0 - Timing definition:
> Mode = 1280 x 800 @ 60,223Hz
> Pixel Clock............. 72,50 MHz Non-Interlaced
>
> Horizontal Vertical
> Active.................. 1280 pixels 800 lines
> Front Porch............. 48 pixels 3 lines
> Sync Width.............. 32 pixels 6 lines
> Back Porch.............. 63 pixels 37 lines
> Blanking................ 143 pixels 46 lines
> Total................... 1423 pixels 846 lines
> Scan Rate............... 50,949 kHz 60,223 Hz
>
> Image Size.............. 286 mm 179 mm
> Border.................. 0 pixels 0 lines
>
> Sync: Digital separate with
> * Negative vertical polarity
> * Negative horizontal polarity
>
> Descriptor #1 - Manufacturer specific data (not interpreted here)
>
> Descriptor #2 - ASCII data:
> LP133WX3-TLA1
>
> Descriptor #3 - ASCII data:
> Color LCD
>
>
Native Screen ANE – was "new user interface design"
Posted by Erik Lundgren <er...@lndgrn.se>.
Dear list,
Talking about displays and their native ppi:s we've mentioned ANEs a couple of time. I've tried to research this, because I believe there are real use-cases if we could get it to work – layout elements based on the users context, not his/hers device.
I'm a FLEX developer and feel that an ANE is a bit over my head. I may be able to figure something out in java, but everything I've been able to research about it points at C. And that is a no go for me at the moment.
Are there any C gurus on the list? :)
If anyone, more capable than me, would be willing to explore this with me I've tried to collect some material.
1. http://en.wikipedia.org/wiki/Extended_display_identification_data
2. http://www.insanelymac.com/forum/index.php?showtopic=208410
3. http://cgit.freedesktop.org/xorg/app/edid-decode/
4. https://github.com/claar/php-edid-decode
5. http://www.madrau.com/indexSRX4.html
First. There seems to be a spec regulating information exchanged between pc:s and monitors called EDID. [1]
Desktop computers stores EDID information in their registry, but in a binary format that needs to be parsed.
I can find the EDID data on my mac, following the guidelines given at [2].
I don't have access to a windows machine to search for it on that OS.
There is an active C project for parsing the EDID data at [3]. Not sure about licensing.
There is a php port at [4] if that would help us. Not sure about licensing.
On mac you can get parsed EDID-data using an application like SwitchResX. [5]
And looking at the output the program can generate from my system it seems really promising. I can read that my screens physical size is 286 mm x 179 mm, and a pixel size 1280 x 800 px. This is all I need to calculate my screens correct ppi (113 px/inch).
I'm enclosing the full print out below. It could serve as the foundation for the ActionScript ANE interface. I'm thinking something like a "NativeScreen" class, collecting properties like:
gamma:Number
timing:Number
widthCm:uint
heightCm:uint
widthInch:uint
heightInch:uint
widthPixel
heightPixel
ppi:uint
...
I'm sure there are some pain's down this road, but maybe there is a path ahed. Does this make anyone itch? Sorry for the mac-twisted research. I don't have access to windows at the moment.
Yours
/Erik
Printout from SwitchResX:
DDC block report generated by SwitchResX version 4.2.7 for display
Color LCD
-----------------------------------------------------
------------------- RAW DATA ------------------------
-----------------------------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F
-----------------------------------------------------
0 | 00 FF FF FF FF FF FF 00 06 10 BD 9C 00 00 00 00
1 | 03 13 01 03 80 1D 12 78 0A 00 00 00 00 00 00 00
2 | 00 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
3 | 01 01 01 01 01 01 52 1C 00 8F 50 20 2E 30 30 20
4 | 36 00 1E B3 10 00 00 18 00 00 00 01 00 06 10 20
5 | 00 00 00 00 00 00 00 00 0A 20 00 00 00 FE 00 4C
6 | 50 31 33 33 57 58 33 2D 54 4C 41 31 00 00 00 FE
7 | 00 43 6F 6C 6F 72 20 4C 43 44 0A 20 20 20 00 41
-----------------------------------------------------
< 00FFFFFF FFFFFF00 0610BD9C 00000000 03130103 801D1278 0A000000 00000000 00505400 00000101 01010101 01010101 01010101 0101521C 008F5020 2E303020 36001EB3 10000018 00000001 00061020 00000000 00000000 0A200000 00FE004C 50313333 5758332D 544C4131 000000FE 00436F6C 6F72204C 43440A20 20200041 >
-----------------------------------------------------
{ 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x06, 0x10, 0xBD, 0x9C, 0x00, 0x00, 0x00, 0x00, 0x03, 0x13, 0x01, 0x03, 0x80, 0x1D, 0x12, 0x78, 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x52, 0x1C, 0x00, 0x8F, 0x50, 0x20, 0x2E, 0x30, 0x30, 0x20, 0x36, 0x00, 0x1E, 0xB3, 0x10, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x01, 0x00, 0x06, 0x10, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, 0x20, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x4C, 0x50, 0x31, 0x33, 0x33, 0x57, 0x58, 0x33, 0x2D, 0x54, 0x4C, 0x41, 0x31, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x43, 0x6F, 0x6C, 0x6F, 0x72, 0x20, 0x4C, 0x43, 0x44, 0x0A, 0x20, 0x20, 0x20, 0x00, 0x41, }
-----------------------------------------------------
Valid EDID block: checksum passed
-----------------------------------------------------
------------------- MAIN EDID BLOCK -----------------
-----------------------------------------------------
EDID Version........1.3
Manufacturer........APP
Product Code........48540 (BD9C) (9CBD)
Serial Number.......00000000
Manufactured........Week 3 of year 2009
Max H Size..........29 cm
Max V Size..........18 cm
Gamma...............2,20
Display Supported Features:
---------------------------
Display type:
-------------
RGB 4:4:4 & YCrCb 4:4:4 Color Encoding Formats
Display is non continuous frequency
Default color space is not sRGB standard
Preferred timing mode includes Native Pixel Format
Input signal & sync:
--------------------
Digital Input
Color Bit Depth is undefined
Digital Interface is not defined
Color info:
-----------
Red x = 0,000 Green x = 0,000 Blue x = 0,000 White x = 0,312
Red y = 0,000 Green y = 0,000 Blue y = 0,000 White y = 0,328
Established Timings:
--------------------
Manufacturer Reserved Timings:
------------------------------
Standard Timing Identification:
-------------------------------
Monitor Description blocks:
---------------------------
Descriptor #0 - Timing definition:
Mode = 1280 x 800 @ 60,223Hz
Pixel Clock............. 72,50 MHz Non-Interlaced
Horizontal Vertical
Active.................. 1280 pixels 800 lines
Front Porch............. 48 pixels 3 lines
Sync Width.............. 32 pixels 6 lines
Back Porch.............. 63 pixels 37 lines
Blanking................ 143 pixels 46 lines
Total................... 1423 pixels 846 lines
Scan Rate............... 50,949 kHz 60,223 Hz
Image Size.............. 286 mm 179 mm
Border.................. 0 pixels 0 lines
Sync: Digital separate with
* Negative vertical polarity
* Negative horizontal polarity
Descriptor #1 - Manufacturer specific data (not interpreted here)
Descriptor #2 - ASCII data:
LP133WX3-TLA1
Descriptor #3 - ASCII data:
Color LCD
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 28/02/2012 09:09, Alex Harui wrote:
> If the goal is WYSIWYG printing, I would think there would be some popular
> (but maybe not perfect) strategies or groups trying to figure it out,
> especially for the HTML/JS stack.
>
I am not sure how you get "WYSIWYG" printing? The problem of the real
units comes basically from
touch screens: The average finger just doesn't fit in a > 0.2inch button
(average scrollbar).
Another aim is that text is still reasonable on a 200 dpi+ screen. Those
pop up more and more.
Also: As far as I can tell: Users have the ability to change their DPI
and its seems to be a 100% ignored
in current Flash applications. I know that cm isn't correct but its
better than nothing.
yours
Martin.
Re: [IDEAS] Flex: New user interface design
Posted by Alex Harui <ah...@adobe.com>.
On 2/27/12 3:56 PM, "Erik Lundgren" <er...@lndgrn.se> wrote:
> I really don't have a good strategy. The browser or the player doesn't expose
> the low level apis. If you can't do it programatic you would need to maintain
> some sort of device library. If you don't want to do that maybe you should
> employ some other strategy like making sure it is easy to pass configuration
> values around your app tree, making compilation for different targets as easy
> as possible.
If the goal is WYSIWYG printing, I would think there would be some popular
(but maybe not perfect) strategies or groups trying to figure it out,
especially for the HTML/JS stack.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [IDEAS] Flex: New user interface design
Posted by Erik Lundgren <er...@lndgrn.se>.
28 feb 2012 kl. 00.44 skrev Alex Harui:
> But allowing different units in CSS and trying our best to get a better sense of the density might still be worth it.
I really don't have a good strategy. The browser or the player doesn't expose the low level apis. If you can't do it programatic you would need to maintain some sort of device library. If you don't want to do that maybe you should employ some other strategy – like making sure it is easy to pass configuration values around your app tree, making compilation for different targets as easy as possible.
/Erik
Re: [IDEAS] Flex: New user interface design
Posted by Alex Harui <ah...@adobe.com>.
On 2/27/12 2:58 PM, "Erik Lundgren" <er...@lndgrn.se> wrote:
>
> 27 feb 2012 kl. 23.18 skrev Alex Harui:
>
>> Let's assume it won't be fixed but you may be able to get a rough, but not
>> exact idea of resolution/density via other means (JS, ANE).
>
> I've researched this all day and I cant find any cross browser js api that
> allows you to break out of the 96 ppi abstract screen that the browser assumes
> for rendering. In extreme cases, like the iPhone 4, I belive the user agent
> recalculates the pixel values.
>
> If we could do it in air using native extensions, but not on the web should we
> do it anyway? I don't know.
I think my desktop monitor distorts the video output of my laptop,
stretching it wider than it is on the laptop. So, I don't know of any way
to guarantee you could measure a screen and see the same size you intended.
But allowing different units in CSS and trying our best to get a better
sense of the density might still be worth it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [IDEAS] Flex: New user interface design
Posted by Erik Lundgren <er...@lndgrn.se>.
27 feb 2012 kl. 23.18 skrev Alex Harui:
> Let's assume it won't be fixed but you may be able to get a rough, but not exact idea of resolution/density via other means (JS, ANE).
I've researched this all day and I cant find any cross browser js api that allows you to break out of the 96 ppi abstract screen that the browser assumes for rendering. In extreme cases, like the iPhone 4, I belive the user agent recalculates the pixel values.
If we could do it in air using native extensions, but not on the web should we do it anyway? I don't know.
> It sounds like the problem remains unsolved in browsers as well in that the reported resolution or density isn't 100% accurate. Seems like that would
> have always been the case for any analog screen anyway, wouldn't it?
It's broken. Thats why I hoped we could fix it. :)
> What is the measure of success? Is it that a 1-inch button is roughly 1 inch or exactly 1 inch? Or is it to guarantee a workflow that allows good printing?
Perfection is good. I would like to abstract away the device scaling factor, making lives easier for designers/developers.
For me the functionality would offer a paper, to screen, to paper workflow.
I do a lot of early wireframes on paper. A unified measuring stick would be really helpful. You could simulate a device you don't own on paper. You could easily study a early layout in the users own context without the device or any code.
Designers/developers would train their eyes to one scale-set allowing them to better understand it and how to apply it to images, text, usecases etc.
And in the end it would be a great foundation for advanced printing out of Flex applications.
I can think of many more benefits, but sadly we seem to operate on one system abstraction to high for that to happen. (If someone else can't think of something smart.)
Yours
/Erik
(Sorry for my english)
Re: [IDEAS] Flex: New user interface design
Posted by Alex Harui <ah...@adobe.com>.
On 2/27/12 2:09 PM, "Erik Lundgren" <er...@lndgrn.se> wrote:
>
> Hi Alex,
>
> Still pondering the possibilities for FLEX if we could have correct ppi
> values. Do you know if the runtime team are investigating these issues?
>
> I read in Adobe Jira [1] that Flash Player bug has been marked NeverFix.
That's a very old bug, and in some ways, because we are only guaranteed to
work on SWF version 13, it isn't clear we could take advantage of a future
player fixing the problem. So let's assume it won't be fixed but you may be
able to get a rough, but not exact idea of resolution/density via other
means (JS, ANE).
It sounds like the problem remains unsolved in browsers as well in that the
reported resolution or density isn't 100% accurate. Seems like that would
have always been the case for any analog screen anyway, wouldn't it?
What is the measure of success? Is it that a 1-inch button is roughly 1
inch or exactly 1 inch? Or is it to guarantee a workflow that allows good
printing?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [IDEAS] Flex: New user interface design
Posted by Erik Lundgren <er...@lndgrn.se>.
27 feb 2012 kl. 08.50 skrev Alex Harui:
> Current Flash Player always reports 72dpi on desktop. I think that might change in some future player.
Hi Alex,
Still pondering the possibilities for FLEX if we could have correct ppi values. Do you know if the runtime team are investigating these issues?
I read in Adobe Jira [1] that Flash Player bug has been marked NeverFix.
https://bugs.adobe.com/jira/browse/SDK-13778
Yours
/Erik
Re: [IDEAS] Flex: New user interface design
Posted by Alex Harui <ah...@adobe.com>.
On 2/26/12 11:38 PM, "jude" <fl...@gmail.com> wrote:
>
> I think Adobe investigated this real world units. I don't know what
> happened with it. It might have been part of the Flex Mobile SDK. BTW Was
> that donated and if so Alex?
Mobile SDK was donated. Current Flash Player always reports 72dpi on
desktop. I think that might change in some future player. I've been
wondering if there is a cheap way to get it from the HTML wrapper.
applicationDPI is purposefully in buckets and not exact. That is supposed
to make it easier to design your UI than to have to worry about the wide
variety of densities in mobile screens, but I was in the camp to make the
actual density available for CSS media queries and let you define your own
buckets.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [IDEAS] Flex: New user interface design
Posted by jude <fl...@gmail.com>.
I like the real world units idea. I don't know what it would involve to
apply it across the framework. Would it replace the use of setting to px or
compliment it? Would you go by millimeters or inches?
I think Adobe investigated this real world units. I don't know what
happened with it. It might have been part of the Flex Mobile SDK. BTW Was
that donated and if so Alex?
I think you'd have to have an accurate DPI value from Flash Player or AIR
to accomplish this correct?
On Sun, Feb 26, 2012 at 1:43 PM, Erik Lundgren <er...@lndgrn.se> wrote:
> Dear list,
>
> I would like to spend some time thinking about the "high level" concepts
> in flex – the present and the not yet present.
>
> As I scribble in my notebooks my first halt seems to be the methodology
> used for UI-measurement, and I need some community input:
>
>
> Should Flex measure layouts in "real world units" or "device units"?
>
>
> USE CASE PROBLEM
>
> UI layouts * should be tuned to the human motoric and sensory systems.
> This can be achieved through the use of "real world units" (myTouchButton
> always renders as 0.5 cm x 0.5 cm). If UI elements are laid out using
> "device units" (eg pixels) different screen densities distorts the layout
> experience as layouts are reused across screens (or print).
>
> * Layout = element size and position (and layering?).
>
>
> PREFERRED SOLUTION
>
> Compose layouts using some "real world unit" (I would promote points).
> Have Flex read the pixel density of the runtime screen and transpose the
> layout to "device units" (eg Pixels).
>
>
> PROBLEMS IMPLEMENTING THE SOLUTION
>
> The unit-translation-concept is present in flex today through the
> applicationDPI property on Application, but its implementation is not exact
> and based on the precondition that the FLEX can read correct screen ppi
> values from its runtime. Sadly, this is not always the case.
>
> Present runtime: The flash class Capabilities seems to be reading the
> operating systems abstractions of "real world units". On my computer (mac)
> flash reads the screen ppi value as 72 px/inch. In reality my screens
> density is 113 px/inch. This problem seems to be present on windows and
> mobile operating systems as well.
>
> Possible future runtimes: On the HTML/CSS stack new "resolution" media
> queries seems to be implemented. On the "native" stacks implementations
> seems to be able to read the correct screen ppi values, though the web is
> full of issues with broken values returned by drivers etc.
>
>
> If there is no way to implement the unit-translationsolution described
> above, Flex should implement some other concept for laying out UI elements.
>
> I've done research but some community input would be great: Can we find
> reliable bridges between flex and the ppi values of the screen that renders
> it? Thoughts?
>
> All the best
> /Erik
Re: [IDEAS] Flex: New user interface design
Posted by Erik Lundgren <er...@lndgrn.se>.
Dear list,
I would like to spend some time thinking about the "high level" concepts in flex – the present and the not yet present.
As I scribble in my notebooks my first halt seems to be the methodology used for UI-measurement, and I need some community input:
Should Flex measure layouts in "real world units" or "device units"?
USE CASE PROBLEM
UI layouts * should be tuned to the human motoric and sensory systems. This can be achieved through the use of "real world units" (myTouchButton always renders as 0.5 cm x 0.5 cm). If UI elements are laid out using "device units" (eg pixels) different screen densities distorts the layout experience as layouts are reused across screens (or print).
* Layout = element size and position (and layering?).
PREFERRED SOLUTION
Compose layouts using some "real world unit" (I would promote points). Have Flex read the pixel density of the runtime screen and transpose the layout to "device units" (eg Pixels).
PROBLEMS IMPLEMENTING THE SOLUTION
The unit-translation-concept is present in flex today through the applicationDPI property on Application, but its implementation is not exact and based on the precondition that the FLEX can read correct screen ppi values from its runtime. Sadly, this is not always the case.
Present runtime: The flash class Capabilities seems to be reading the operating systems abstractions of "real world units". On my computer (mac) flash reads the screen ppi value as 72 px/inch. In reality my screens density is 113 px/inch. This problem seems to be present on windows and mobile operating systems as well.
Possible future runtimes: On the HTML/CSS stack new "resolution" media queries seems to be implemented. On the "native" stacks implementations seems to be able to read the correct screen ppi values, though the web is full of issues with broken values returned by drivers etc.
If there is no way to implement the unit-translationsolution described above, Flex should implement some other concept for laying out UI elements.
I've done research but some community input would be great: Can we find reliable bridges between flex and the ppi values of the screen that renders it? Thoughts?
All the best
/Erik
Re: [IDEAS] Flex: New user interface design
Posted by David Francis Buhler <da...@gmail.com>.
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 <co...@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 <nicholas@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 <
> > davidbuhler@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 <
> mh@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>
> > > >
> > >
> >
>
Re: [IDEAS] Flex: New user interface design
Posted by Cortlandt Winters <co...@cortwinters.net>.
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 <ni...@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 <
> davidbuhler@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 <mh@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>
> > >
> >
>
Re: [IDEAS] Flex: New user interface design
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
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 <davidbuhler@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 <mh@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>
> >
>
Re: [IDEAS] Flex: New user interface design
Posted by David Francis Buhler <da...@gmail.com>.
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 <mh...@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>
>
Re: [IDEAS] Flex: New user interface design
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
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
Re: [IDEAS] Flex: New user interface design
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
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
On 23 February 2012 09:41, Tomasz Maciąg | Fuse Collective <
t.maciag@fusecollective.com> wrote:
> W dniu 2012-02-23 04:55, Martin Heidegger pisze:
>
>> Hello List,
>>
>> I think we need new ideas for user interface designs created with Flex.
>> New compared to the efforts in the Android/iOS community but also just
>> spectacular ones.
>>
>> What do you think?
>>
>> yours
>> Martin.
>>
>
> It's good idea and I've thought about it for some time now. I was planing
> to this here at Fuse Collective but right now we're swamped with work and I
> can't spare designers...
> But still, when I find some time, I'm planning to do some comps/wireframes
> (may be even code something) and then wait for one of designers to have
> some free time.
> However I'm not entirely sure how to tackle and two basic ideas fights in
> my head:
> 1. Create something based on the current components (I mean with pretty
> much the same functionality but different/nicer looks)
> 2. Innovate and try to create something new from scratch (It would
> probably took more time since it should be preceded with proper research).
>
> New compared to the efforts in the Android/iOS community but also just
>> spectacular ones.
>>
> Martin, do you mean new/cool user interface just for Mobile or for
> desktop/browser too?
>
Re: [IDEAS] Flex: New user interface design
Posted by Tomasz Maciąg | Fuse Collective <t....@fusecollective.com>.
W dniu 2012-02-23 04:55, Martin Heidegger pisze:
> Hello List,
>
> I think we need new ideas for user interface designs created with
> Flex. New compared to the efforts in the Android/iOS community but
> also just spectacular ones.
>
> What do you think?
>
> yours
> Martin.
It's good idea and I've thought about it for some time now. I was
planing to this here at Fuse Collective but right now we're swamped with
work and I can't spare designers...
But still, when I find some time, I'm planning to do some
comps/wireframes (may be even code something) and then wait for one of
designers to have some free time.
However I'm not entirely sure how to tackle and two basic ideas fights
in my head:
1. Create something based on the current components (I mean with pretty
much the same functionality but different/nicer looks)
2. Innovate and try to create something new from scratch (It would
probably took more time since it should be preceded with proper research).
> New compared to the efforts in the Android/iOS community but also just
> spectacular ones.
Martin, do you mean new/cool user interface just for Mobile or for
desktop/browser too?