Countries and devices are the most wanted, for sure. It would be cool to
- support update (FLite player or app update like with an AIR badge)
- be compatible with Nokia Services
- add Capuchin support
- include AMP in Device Central

oops…it’s my top4 not top3, sorry

I think that Adobe should establish a standard for platform service apis. The distributable player should have a consistent api for a given service regardless of platform.

Right now we have too much variation in the manufacturer apis (Nokia services, Capuchin, Qualcomm BREW extensions etc). And, the means to use the device apis are completely different on each of these platforms. This form of fragmentation is much worse than current java fragmentation.

Adobe should set out to support the most relevant mobile application apis, Location and PIM with the distributable player, and do this in a consistent way across platforms, so the ActionScript apis are all the same whether you are working with s60, windows, and the future platforms.

Adobe can then work on implementing this api capability into AIR as it comes along.

[...] Link to the original site [...]

Ciao Mark,

DRM solution
Error API
Fix input text (currently it quits the player)
Alessandro

[...] Mark posted an update on the Adobe Mobile Packager Beta and asked to get some feedback on potential features and capabilities. [...]

I like what Hayden had to say – the groundwork seems to have been laid on a few too many different foundations already when it comes to platform APIs for developers. Perhaps Open Screen will start to address this?

In terms of my own thoughts, we really need to get Distributable Player and Ovi working together.

Cheers,

It would be nice to see a general improvement to the Adobe Mobile Packager interface, like the ability to save projects, etc. It feels like a bare-bones application right now, and while it works great at what it does, there’s room for improvement. Perhaps some sort of integration with the Flash IDE (e.g. publishing a Flash Lite movie instead of just testing it builds the packages specified).

But to a certain extent, that’s just window dressing. I think Dale hit the nail on the head and reiterate how great it would be to see the Distributable Player be an acceptable packaging solution on Ovi. If the Distributable Player can’t be used on (what I hope will be) a major avenue of Flash Lite content distribution, then that’s a big strike against it.

(And fixing the input text field behaviour would be fantastic, too! Props to Alessandro for pointing that one out!)

Darren

[...] Drop in your requests here [...]

#2 Agree, and Alessandro and I had a conversation about that at MAX 2008 before we got on a bus. No standardization of APIs, a whole mess of fragmentation. No longer can claim less frag is a benefit of FL (with version 3.x).

#4 Agree with the Dale on the OVI debacle.

#5 Agree with Darren that AMP UI is “barebones”. What a nice way to put that.

Request:

OSX version of the Adobe Mobile Packager … If you haven’t noticed, “Apple is the new Microsoft”. … (or create online version of the packager if it can’t be done … but only if the workflow can be from ADC CS4 through plugin to send to package content directly from Flash and/or ADC).

… If Sony Ericsson can offer an OSX version of SWF2JAR, no excuse for Adobe not to have AMP for OSX in day and age.

Before concentrating on “developers’ experience”, I believe Adobe should concentrate on “users’ experience” of Flash content packaged with AMP. It is clear that still many people fail to realize that user experience doesn’t start only when application is running but from the instant the user “hunt” for the application and actually install it.

Not a flame war between the usual iPhone thing and the rest of the world, but anybody that tried both can possibly agreed with the following:

on iPhone:

User taps on “App Store”, search for the app name (even partially), tap on the “Install” button. App Store window closes, the view is moved to where the icon of the Application will be placed and immediate feedback is given to user on downloading and installing phases. User is free to open other apps and even trigger downloading of others while the other one is finishing. This is the most common way of installing applications on iPhone but users can also click on a link on web page opened in Mobile Safari to trigger installation using same modalities or click on a link on browser opened on a PC (both Windows and Mac) which will trigger iTunes with consequent installation at next iPhone synchronization time.

Now let’s see the same operation on a Nokia device when user tries to install a FlashLite content packaged with Adobe Mobile Packager (“xxxx” is a few FL contents packaged with AMP that I tried on my own):

User has to open the web browser, type in a rather lengthy URL, eventually agree to a dialog that asks if (s)he wants to make connection, eventually select one of the access points. If, for some strange reason, user wants to switch from 3G data connection to WiFi, (s)he has to reconfigure the Web browser settings (but that’s another story….)
User eventually lands on a installation page and click on the “Download” button. In a few instants and flashing screens, the download starts. After a few seconds, I’m greeted with a dialog that gives “very useful” information like the name of file, the size and the most important the mime type (I mean, every average user should know what a “x-epoc/x-app.sis” MIME Type is all about right?).

Now, this can possibly surpassed with the OVI store (when? How do people get the magic button on their phone?) but the following will stay the same:

Once download terminates, I get the first of many questions: “Do you want to install xxxxx”? I answer yes, especially because if I say no, my downloaded file will be lost, I cannot save it now to install it later. After having selected “Yes”, I’m presented with a “Security Warning” dialog that informs me that this application may damage my phone. Trusting my installation, I click on “Continue”.

The installer then shows me with another dialog where even more useful information are presented: name of the application, version and so on. I click on “continue” again, I need to select where I want to install the application. Another click bring me finally to the installation phase. After a few seconds the installer just closes, leaving me viewing the old web page.

Application installation is supposedly happened correctly, but where is the application now? It depends on the phone: some install application into a “My Own” folder, some others uses “Applications”, some other “Installation”. By the way they all are Series60 3rd Edition based phones. If you have friends at Nokia, they may share with you the trick to achieve installation of the application icon in the main screen, but for the moment is a very exclusive club.

I leave the browser, open the “Applications” folder, scroll down and finally I find my “xxxxxx” icon, I click on it and instead of seeing my app running, I’m greeted by another request: “xxxxx needs Adobe Flash Lite & Adobe version checker to run. Continue?” why I need this? I press “no” and I’m informed that there has been an error in running version checker. I guess I should have allowed it to run then.

Why giving choices if I don’t have any?

I re-launch “xxxxxx” and this time I reply “Yes” to the “choice” of running the checker. In reality, it doesn’t run anything it actually triggers the installation of another piece of software and it asks if I want to do it. I’m getting smarter by the minute now, so I presume this is another “choices are only apparent” scenario and I answer “Yes” to the request for installation.

Another dialog inform me of the version of the installer, its name and so on. This time the installation is signed, so I suspect it is not going to harm my phone like “xxxxxx” may do.

A dialog opens and asks me to select an access point. Why? The Adobe Version Checker does not agree that I need this information, so trusting again something I don’t have any info about, I select my usual data connection and the Adobe Version Checker, quits immediately displaying the dialog “Failed data connection”, every other application that uses data connection works ok, the Adobe Checker doesn’t. I re-open “xxxxx”, and repeat my steps. This times time I select the Wi-Fi access point. It seems is going better even if I’m not given any feedback, but all of sudden, the Adobe Version Checker tells me that “Sorry, Flash Lite is not available for this device”.

A quick check on Adobe web site, tells me that indeed my device is supported by both Flash Lite 3.1 and the OTA FL installation and also the SIM I’m using (an Italian one) is actually included in the list of the only 5 supported countries.

Determined to see if the problem is specific to this phone, I try on another two devices and also try a Spanish SIM (YoiGo!) another Italian one (Tim and Vodafone) and just to be sure I also check with the AT&T one I got last month in San Francisco as well as my O2 UK one. All fails, only with the Adobe Checker.

I‘d like to check this “xxxxx” application, but the “enabling” technologies behind it simply prevent me to do it.

Now, can anybody please compare these two experiences and tell me which one in the eyes of a “normal user” has more chances to achieve the widest possible reach?

I personally don’t think OVI store will add anything significant to the second experience, except for searching and downloading the apps, but installation and actually setup & running will still be a nightmare. Not for developers eventually…..

[...] Mark posted that Adobe is asking for feedback requests on the new Adobe Mobile Packager that is part of the overall >Adobe Distributable Solution. [...]

1. Agree: a SINGLE packaging tool (that distributes the player) which works on both Mac/PC and has a security model that satisfies all distribution channels would be ideal.

2. Second the request to work on text entry in Flash Lite. We need easy mechanisms to count characters, perform a search, or “word-wheel” type UX where I enter the first few letters of a persons name and the contacts list shortens in real time as I type. (Like in MSN Messenger when looking for a contact in buddy list)

3. Standard components for mobile that are EASY to skin and mold to fit your UX. There are foundational elements to a good UI that should be easy to drag and drop into your project. Examples: Lists (one, two, three lines of text with/without icon), Carousel (of lists, global level type component, not just icons), List item (that can flip or unfold)… scroll bar or progress indicator that works with both lists and text fields.

3a. Transitions Pallette – it would be cool if we could drag and drop different kinds of transitions (or behaviors, or even behaviours onto a mobile project (or keyframe) so that we could glide between lists, control the way a list scrolls, utilize standard gestures for a touch UI, or rotate the entire UI as the user moves from portrait to landscape.

Looks like what I’m advocating here is in addition to standardizing APIs and packaging tools, I’d like to see some standard UI elements available in Flash that were easy to customize. This would provide a better UX (i.e. more consistent) for customers and would cut development time considerably.

Liz

The ability to open the main swf file from a custom path. For example, If i have my app files at e:/others/ the launcher app can tell fl3.1 to open e:/others/myapp.swf not the swf inside the launcher app path.

it’s really good to see more and more flash on device. I have a question: can I use flash lite as plugin from my browser and how?

#10 Lots of OEMs and Open Screen partners are using Flash and Flash Lite within the browser context.

For example: Nokia, SE, Opera, to name just a few that are known in US and EMEA regions (APAC and esp Japan use Flash Lite heavily in the browser, for instance).

So, it depends on your device, region, and sometimes even operator (it’s not uncommon for some to disable functionality) …

It seems more and more OEMs are adopting Flash inside their respective mobile and device browsers, however …except lame duck, Apple for instance … for perfectly logical business reasons, of course).

Hi All

Lots of very correct interesting points made here.

I think the wishlist I have is difficult in that it requires cooperation between Adobe and hardware manufacturers. But the issues below are currently the biggest issues we have with our projects. Usability and player penetration are no longer problematic.

From my perspective the top 3 would be:

1. Work on fixing discoverability issues across all target platforms. Joe the Plumber can’t necessarily be taught that he has to find his newly downloaded app in the Gallery/Memory Card/Images folder.
2. Don’t lose focus on the platforms that make up the largest market segments, ie. Series 40 and the small Walkman phones. Don’t lose sight of the fact that a very large percentage of the installed base may never be able run AIR for Mobile.
3. Create a common platform service API independent of platform. Right now – being totally inept at Java – I can’t even create a Quit button using Capuchin and some of the published code samples for Nokia Platform Services don’t work.

Mads

[...] Request Submissions Mark Doherty posted that Adobe’s feedback requests on the new Adobe Mobile Packager that is part of the overall Adobe Distributable Solution.  Please note that if you have any other [...]

Benefit Mobile Solutions :

The ability to open the main swf file from a custom path. For example, If i have my app files at e:/others/ the launcher app can tell fl3.1 to open e:/others/myapp.swf not the swf inside the launcher app path.

Unfortunately that would constitute a security breach

Darren :

It would be nice to see a general improvement to the Adobe Mobile Packager interface, like the ability to save projects, etc. It feels like a bare-bones application right now, and while it works great at what it does, there’s room for improvement. Perhaps some sort of integration with the Flash IDE (e.g. publishing a Flash Lite movie instead of just testing it builds the packages specified).

But to a certain extent, that’s just window dressing. I think Dale hit the nail on the head and reiterate how great it would be to see the Distributable Player be an acceptable packaging solution on Ovi. If the Distributable Player can’t be used on (what I hope will be) a major avenue of Flash Lite content distribution, then that’s a big strike against it.

(And fixing the input text field behaviour would be fantastic, too! Props to Alessandro for pointing that one out!)

Darren

Bare bones?? Where’s the love?!

Top 3 Issues

1. In order to ensure that the Flash platform becomes all pervasive on the mobile phone rather than a ragbag of old different incompatible versions – Improve/Repair your relationship with Nokia, Sony Ericcson, Samsung, Blackberry and Motorola + others so that they all support FlashLite 3.1 distributable player cleanly across as many phones as possible. You have different issues with each company and you can see “cracks” appearing between Adobe and Nokia by looking at the latest Nokia presentations on their developer forum. Get your CEO to listen.

2. Release Date for FlashLite 3.1 distributable player on as many mobiles as possible and make this the baseline for all suppliers shipping Flash Lite embedded on phones.

3. A proper roadmap to convince developers that Adobe actually have a platform plan which makes sense, otherwise Qt, J2ME and Nokia’s WRT look more attactive options as phone support is better standardised.

Mark Doherty :

Darren :
It would be nice to see a general improvement to the Adobe Mobile Packager interface, like the ability to save projects, etc. It feels like a bare-bones application right now, and while it works great at what it does, there’s room for improvement. Perhaps some sort of integration with the Flash IDE (e.g. publishing a Flash Lite movie instead of just testing it builds the packages specified).
But to a certain extent, that’s just window dressing. I think Dale hit the nail on the head and reiterate how great it would be to see the Distributable Player be an acceptable packaging solution on Ovi. If the Distributable Player can’t be used on (what I hope will be) a major avenue of Flash Lite content distribution, then that’s a big strike against it.
(And fixing the input text field behaviour would be fantastic, too! Props to Alessandro for pointing that one out!)
Darren

Bare bones?? Where’s the love?!

Hey, AMP is great at what it does (and mea culpa: you can save projects – it’d been a while since I used it), it’s just that it could do it better! For example, I can publish a sis, or I can publish a cab, but I can’t do both at once? Why not? I realize that in theory packaging is the final step that only should need to happen once, so it doesn’t seem like this would be a big workflow issue. But I’ve found that I’ll end up going through the package/install/test/uninstall/package loop a few times (to check the icon appearance or for other issues), so the easier this process is, the better it would be (for me personally, at least).

My #1 feature request would be to add Capuchin support

[...] Mark has opened up a blog post for comment, asking for input on the future direction of Adobe Mobile Packager and Distributable Player (and perhaps more broadly, Flash Lite). [...]