incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Jakobovits <arielj...@yahoo.com>
Subject Re: [RT] Awesome FlexNext User Experience (was: Starting with the Whiteboard code)
Date Fri, 10 Feb 2012 21:56:58 GMT
> offered too many Flex examples
never

> Future hiding of the examples until the user clicked a button made 'seeing' 
> the examples more involved.
is 'involved' good or bad, i can't tell from the context?

> The Help Docs were longer than necessary.
i like long help docs, means there is a good chance something is there to help

> Tour De Flex's User Experience did not reflect how people seek out information.
what if we improve our docs to communicate to Tour de Flex over local connection to "tune"
the app to examples specific to the doc being viewed?

> Adobe Community Help provided too many search options

Agree.
 
Ariel Jakobovits
Email: arieljake@yahoo.com
Phone: 650-690-2213
Fax: 650-641-0031
Cell: 650-823-8699


________________________________
 From: David Francis Buhler <davidbuhler@gmail.com>
To: flex-dev@incubator.apache.org 
Sent: Friday, February 10, 2012 8:23 AM
Subject: Re: [RT] Awesome FlexNext User Experience (was: Starting with the Whiteboard code)

I'd like to see the examples and documentation be part of an improved,
cohesive 'brand' outlined. The rest of the outline I agree with.

Someone else had suggested the idea of emulating the
examples/documentation Sencha/JQuery use, which I second.  Likewise,
Google does an excellent job with http://tour.golang.org/

I always found  Adobe to offer too many alternatives to finding information.

Examples:
-Adobe offered too many Flex examples in the help.adobe.com site made
accessing the information slow and painful. Future hiding of the
Examples until the user clicked a button made 'seeing' the examples
more involved.
-The Help Docs had poor SEO. Questions asked about technical problems
have a certain language, and the page-titles needed to reflect the
language developers use to search out solutions to problems.
-The Help Docs were longer than necessary.
-Tour De Flex's User Experience did not reflect how people seek out
information. It did not offer a linear evolution of 'challenges' or
'difficulty'. Examples often error out.
-Adobe Community Help provided too many search options, that did not
reflect an understanding of how people look for information.

-Buhler



On Fri, Feb 10, 2012 at 11:10 AM, ganaraj p r <ganarajpr@gmail.com> wrote:
> I am completely up for this. I vote for doing something along this line...
>
> On Fri, Feb 10, 2012 at 4:00 PM, Martin Heidegger <mh@leichtgewicht.at>wrote:
>
>> Dear List,
>>
>> it can be hard to find a vision for the next version of Flex. Developers
>> like us like discussions about technical details and they are boring.
>>
>> I think that is not enough! I think we need something that inspires us to
>> create something new - something that makes us believe that the things
>> created with Apache Flex are awesome.
>>
>> We can make awesome things!
>>
>> I propose following: Lets ask everyone who listens for user experience
>> concepts - full or partial. Things that they could see Flex is going to so
>> the PPMC get a better feeling how awesome they could be.
>>
>> The proposals should be split in a few categories:
>>
>>  *) _HTML/JS compatible:_ To compile mxmlc/AS3 -> html/js the concept has
>> to work within the restrictions of HTML/JS with a optional royal look and
>> feel when being built for Flash without breaking the system.
>>
>>  *) _Flash super-powered:_ Systems that leverage the power of the current
>> version of the Flash Player without thinking for a second about HTML: Stage
>> 3D / HD videos / JPEG XR / Slick custom fonts / Pixelbender effects /
>> (generated audio) / ...
>>
>>  *) _Touch centric:_ Focussing on the fingers: Swipe/Zoom/Rotate/Expand/**Swoosh/...
>> These concepts don't need to care about a mouse or keyboard.
>>
>>  *) _Fully portable:_ Interfaces flexible enough to be represented in the
>> style of various Operation systems without neglecting our need for style.
>> Awesome on Mac/iOS/Windows/Android with few adaptations.
>>
>> Some rule-of-thumbs I can think of:
>>
>>   * Responsiveness is key: The more stuff that has to run at a time the
>> less likely it will rock.
>>   * All assets should be open-source: Don't build on royal fonts or
>> imagery.
>>
>> What would you think of such a request? Is that something that the PPMC
>> think is useful? Should we rock that?
>>
>> Note: The various concepts should be presented in the Wiki.
>>
>> yours
>> Martin.
>>
>
>
>
> --
> Regards,
> Ganaraj P R
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message