• The flow of developing your first application by following the Adobe AIR developer site needs some improvement. We discovered there are some disconnects with how developers go from downloading the tools to getting their helloWorld application created and deploying it to a simulator or a device.
• Finding our way through the documentation was confusing. We found that when we were trying to complete certain tasks, the docs were not very straightforward or easy to find.
• The downloads page doesn’t include links to everything you need to download. For example, if you don’t have JRE 1.6, you’ll need to download and install it before you install the SDK. Also, to use FDT, you’ll need to download and install the Flex 4.6 SDK.
• There were system requirements for each tool you needed to download. It would have been nice to see one amalgamated requirements list.
• Samples need to be easier to download and should be easy to get working in supported platforms.
• There needs to more information and documentation around developing a BlackBerry 10 experience in AIR and more best practices.

We have many more pages of notes that we took throughout the day. The next step is to create bugs in the Developer Issue Tracker so that you can follow along with the progress as we make improvements for a better Adobe AIR development experience. You can expect those to come next week. We hope to address the top issues in the coming weeks.

Yesterday was a long day spent scrutinizing every aspect of developer experience, tools and application development. We have filled out the whiteboard and have summarized the main points:

1. Platform Choice is a bit confusing (we need some more explaining here)
2. Technology/Tools line of separation is unclear. Why would I choose C/C++/Qt/Cascades™? (If I’m a Qt developer, this may seem like a familiar world – yet Cascades is different. We need a better way to highlight this)
3. We have found distinct documents for accomplishing the same task (and not all paths gave the same result). This duplication needs to go.
4. For the Gaming/Native SDK developers, the End-To-End flow experience is broken. From start to finish there are too many issues before a game can be deployed.
5. There is little guidance when the IDE is launched. What should I do next? Create a Native or Cascades application. The Wizards could use some wizardry and help to get the developer a few steps closer to the app they really want.
6. We realized we need better integration of IDE, Wizards and Online Docs to focus on getting started and highlighting ‘Key’ samples. We’d all like to see a few key samples for gaming and apps and a clear path to get them running right from the IDE.
7. Our open source developers found that the path of navigating between Open Source libraries and development environment needs to be improved. It’s not made clear how a library could be integrated into the IDE.
8. Our new folks were often using search engines to query for BlackBerry® specific development tasks. We have found that this also needs to be improved. Wouldn’t it be cool if search results for “break points BlackBerry® 10” or “touch inputs BlackBerry 10” actually gave links to our documents?
9. As much as things have improved in the signing key world, we still have found a lot of pain points there. Folks kept forgetting the multiple pin/passwords that they had and having to re-register. Security, can we not just have a single pin/password?
10. The device discovery, simulator availability and generally having the IDE notified what’s connected needs to improve. (When on VPN we could use a notification that a device can’t connect)

And one more thing: We have found that a lot of us in the room were looking for pre-baked recipes that contain both documentation and samples. We could all benefit from a few recipes (ie. top 10 things you’ll most likely need when doing cascades development). What do you think?

We have also found bugs, which we’ll be tracking and following up on. A more detailed summary will follow next week. Meanwhile, we are interested to know what you think.

In the room we have folks playing the roles of new Cascades™ developers. Some are trying to approach development from the point of view of open source developers. We have gamers looking at developing games. There are those wearing iOS developer hats and looking to bring existing apps to BlackBerry. We have developers and product managers from the Czech Republic and Sweden joining us online.

We hope that these diverse perspectives will help us better understand the experiences of developers starting out with BlackBerry development.

We all started on http://developer.blackberry.com and at the outset we had a debate on whether it’s clear on what technology a developer should use. After clicking C/C++ the debate continued. What does the sponge cake represent? Why do we need to differentiate technologies right away when a single IDE has them all? As an iOS developer do I go to porting heaven or do I choose Cascades? Can I have Raw OS access, be Open Source friendly and interact with Bluetooth sensors when I choose Cascades? We were a bit confused on what choice to make and why and we’ll take that feedback to improve the site.

Tell us your thoughts on getting started with BlackBerry 10 Native development. You can follow what’s going on here by following  @BlackBerryDev, using hashtag #BBDevXP.

The day continues….

We have our team assembled here in Mississauga, Ontario ready to start experiencing what it is to be an AIR developer for BlackBerry® 10. We will be wearing the hats of a developer that uses Flash Builder, one that uses Powerflasher FDT, and one that has a game already built using Flash Professional and would like to port it over to BlackBerry 10. We’ll be installing the SDK and experiencing what it is like for everything from:

• Creating a BlackBerry App World™ storefront vendor account
• Getting signing keys
• Downloading and installing the tools
• Downloading and installing the SDK
• Downloading and installing the simulator and what the experience is like using it to test applications

We’ll be logging bugs and annoyances we find along the way all in an effort to make the AIR development experience for BlackBerry 10 better.

If you would like to participate please help us by posting bugs in the Developer Issue Tracker, or an easier way to participate is to submit your experience in the forums. You can follow what’s going on here by following @DustinMalik, or @BlackBerryDev, using hashtag #BBDevXP.

With a two to three month window between API feature complete and the gold release, we thought it was an excellent time to conduct a full end-to-end developer experience review… and we’re doing it across all our tools and in the full public eye.

That’s right – today we’re bringing together teams from all across the company to sit down with a clean PC (or Mac), start from http://developer.blackberry.com, and end with a full app that is signed, debugged, running in simulator, and running on a BlackBerry 10 Dev Alpha testing device.  We’ll walk through our own samples and tutorials, navigate our own documentation, and build a few apps all using the exact same tools and resources that you do.  And while we do it, we’re going to be blogging our progress here on the Inside BlackBerry Developers Blog. We’ll be sharing some videos of our review on the BlackBerryDev YouTube channel, logging bugs in the Developer Issue Tracker, and tweeting about what we find. All in an effort to make our tools better and show our devs just how much we love them.

Want to join in?  Submit bugs throughout the day to the Developer Issue Tracker and tweet them to @BlackBerryDev using the hashtag #BBDevXP.  We want your feedback and we want to make our tools better.  Have your say!