Well, that was…refreshing! We just finished a very productive day yesterday, reviewing the end-to-end developer experience of the BlackBerry® WebWorks™ platform. There were some very vibrant conversations about what currently does and does not contribute to a positive experience for someone approaching BlackBerry Web development for the very first time.
We found many examples of things we’re doing right (e.g. automatic updates in Ripple). However, as we hoped to find, we also discovered examples of sub-optimal experiences where new developers could possibly be road blocked in their ability to complete their BlackBerry application. It is these latter examples that proved why we ran this exercise, and we are committed to continuing this review and will re-evaluate the platform again on a regular schedule.
Our group first started by identifying who our development community was. How did they think? What was important to them? How would their potential backgrounds influence how they flow through the “getting started with BlackBerry” experience? Our focus was on the following 5 personalities:
- “The coder” – Lives in a text editor and can modify their own path variable. Comfortable troubleshooting advanced issues without assistance. Likely have built a mobile app already.
- “The beginner” – Just getting started with mobile development or are evaluating BlackBerry Web dev. May have strong development skills in another language or none at all.
- “The desktop web developer” – Have a very strong understanding of client-server web development. Have successfully built web sites and may have used frameworks like jQuery, Sencha or Dojo.
- “The enterprise developer” – Cross platform is a primary goal. Prefers to use IDEs and typically works under an IT enforced environment.
- “The PhoneGap developer” – Someone who has come to the BlackBerry developer site to learn how to port their PhoneGap application
So what did we find? Lots! In fact, I’m still going through all the feedback. Everything from “would be nice” changes to “this is a gating bug and must be fixed” is being documented, and our intent is to file issues so the public can track them in the developer issue tracker . Here are just some of the results from the group:
- Discovery process: Search engine optimization should be improved. Keywords that each developer persona would expect to search for did not always generate correct search results.
[Michelle] Search term: “enterprise development for BlackBerry 10” on Google. First result is to register for an outdated/unrelated course; next search results are for BlackBerry® Enterprise Server development.
- Sample applications: A number of BlackBerry WebWorks sample applications are published in Github. We need to refine the flow of navigating a user between blackberry.com and github.com. Also, for new developers, Github is unfamiliar. Some preparation of what to expect and how to use it will be helpful:
[Kevin]: Sample apps… I am not super familiar with Github. Didn’t like getting dumped into git for samples. I’d prefer to get a zip to download. Managed to figure it out then.
[Brent] – Click the link for samples on Getting Started – Taken to Github – what is Github? And what are these samples for – what do they do?
- HelloWorld sample: More developers will successfully complete the “Creating HelloWorld for BlackBerry 10” tutorial if we provide a direct link to a ZIP file that contains the sample application assets.
[Brent] HelloWorld sample – copying and Pasting seems like a waste. Possible to download the helloworld package? – Creating config.xml in notepad and pasting the copied xml text puts it all on one lovely line. #NotImpressed
- Ripple: The Ripple Mobile emulator is currently designed to build and sign a BlackBerry WebWorks application. It also provides an option to deploy to a target device, but only when the app is unsigned. For simulators this is ideal; however, not for live devices where a debug token would be required. Not all developers want / know how to use a debug token.
[Ed] The build choices are confusing and missing the one option I want. I want “package and sign, or package sign and deploy” to a real device. Package and launch is confusing because I don’t want to package and launch to a simulator, but when I do want to for a real device, I want it to do so signed, not with debug tokens I don’t use. I suggest: “Package”, “Package & Sign”, “Package & Sign & deploy” (to a real device” and “Package and launch” to simulator. the last one, the least likely to use.
Here’s how you can send us feedback -
- Join the discussion in the BlackBerry Web and BlackBerry WebWorks community forum.
- Log into the developer issue tracker and file a bug report. Remember to provide as much detail as possible about how to reproduce the problem and what are the expected / actual results.
- Let’s have a chat via @BlackBerryDev on Twitter® or the BlackBerryDevCommunity on Facebook®.