for JavaOne tickets with
Java Code Geeks
we sought out guides/tutorials about running such a promotion, unfortunately we didn’t find anything useful so we had to improvise and work by instinct. This post will also cover some of the statistical results about the Java community so if this is the reason you are reading this post skip down for some interesting takeaways.
Running a promotion tips & tricks
The idea started when one of our talks got accepted to JavaOne, suddenly we had two extra tickets (we got 3 tickets with the booth) so we could give away two tickets. From our experience we came to the conclusion that most developers don’t know about Codename One yet and that is probably the most important thing we need to improve in our outreach. So here are a few conclusions we came to in no particular order:
1. We need a partner to handle the giveaway – this removed the bias from us. We have an incentive to give the tickets to our best customers so we can’t really be fair. That’s why we picked
Java Code Geeks
2. We picked
Java Code Geeks
as a partner – we needed a partner who is focused on Java (check), who has a big enough audience (check), whose audience isn’t already familiar with our product (check). This is probably the most important step, most of our contestant came from Java Code Geeks and as you can see from the chart to the right. Most of the people who entered our contest didn’t know about Codename One in advance and were happy to find out about us.
3. We created incentives to social share – most of the people who would read
Java Code Geeks
are probably up to date with the latest technology, but their friends (and friends of friends) might not be. The true value of the promotion is social share which is why we made the contest require sharing. Initially we wanted the person with the most retweets/shares to “win” but
Byron from Java Code Geeks
objected to this approach (in hindsight I think he was right to object) claiming that it would rule out people who don’t have many friends. It would also have promoted cheating which is a huge problem.
4. We created very detailed rules for the competition – yes, most people didn’t read them (as is obvious by some of the submissions we got) but there are now rules that the raffle itself should follow. We used Google docs to collect details and signups which allowed us to collect a lot of structured data.
We included an entirely optional survey and 99% of submitters answered questions within the survey despite the optionality!
5. We promoted the giveaway in our respective newsletters which is usually the most effective way to get people to signup. However, a single retweet by @java is probably more valuable than an 18k strong mailing list.
6. We used Facebook, Twitter and adsense ads – all charged us and delivered literally nothing. Facebook charged for clicks that Google Analytics didn’t show. Normally I would chuck this as a Google analytics omission however we saw a lot of clicks on the Facebook side and no submissions to the contest form… This seems to indicate that Facebook is charging for fraudulent clicks!
The main motivation behind asking this question was potential support for other languages in Codename One especially JVM languages e.g. JRuby, Scala etc.
We probably should have phrased a few different questions to get refined answers.
1. Better limits on the goals of the question – e.g. with the languages besides Java we didn’t quite get an answer. I would probably ask, are you interested in other languages? Would you prefer another language?
2. We would not waste a cent on Advertising.
3. Partner selection is critical – Java Code Geeks delivered!
4. As pleased as we were with the work done by the guys at Java Code Geeks, it was crucial for us to come prepared. We phrased the contest terms and defined most of the conditions/questions. Your partner can be very helpful but only you can define your own expectations and results.
Notice: This post was automatically converted using a script from an older blogging system. Some elements might not have come out as intended…. If that is the case please let us know via the comments section below.
From the company where I am working, they analyzed many mobile cross platform development tools. The assessors know your product, but one of the biggest critiques on your product is they experience more inconsistency and adjusting for cross platforms, especially Windows and BB 10 where there are some growing demand from our clients. So instead, they opted for other tools which offers more consistency and fortunately is also favorable with our development team’s programming expertise. They don’t think your tool is bad, just more inconsistent and tedious to use than some of the others they have tried. Perhaps its not just that people don’t know CodenameOne, but also run into the issues we also encountered and therefore not using it and would rather invest in expertise for other tools? Anyway its just an honest opinion and suggestion from what I observed from our team and perhaps we are the only few.
Thanks for the feedback, I’d really like to know more about the evaluation and whether the person responsible had any contact with us.
One point I’d like to clarify is that we know for a fact that our reach is to blame. Since our product is cloud based we can “see” the retention statistics rather easily and they exceed industry standards. The chart above showing the number of people who haven’t heard about Codename One in a survey directed at our community as well is a pretty strong indicator of that fact.
About Windows Phone and BB10 you do have a point. We have a couple of users to whom BB10 is a target and they found the Android bridge to be sufficient. I’m not aware of any major company in our field doing native BB10 development, it doesn’t seem viable with the Android support.
The Windows Phone port is a disappointment to us as well. There are technical difficulties due to very poor architectural decisions made by the developers at MS and after 3-4 different rewrites we aren’t much better off. I’m not aware of any cross platform tool that works well with Windows Phone, Cordova (HTML5) is bearable with its obvious caveats. Hopefully we will able to take a shortcut there as well: [http://gigaom.com/2014/07/0…](http://gigaom.com/2014/07/08/android-apps-rumored-to-run-on-windows-phones-crazy-sounding-but-possible/)
I’m not sure I understand the other comment related to the option you eventually took but we’d be happy if you raise some of the issues you’ve experienced in the discussion forum. Even if we don’t have an answer or can’t improve something good feedback is how we improve the product.
The team decided develop webapps for now, but is busy assessing whether to just hire skills for specific platforms for native development in the future. Since there are many top apps developed for Windows Phone, why is CodenameOne having difficulty? Is it better to develop apps for Windows Phone from scratch reusing some of the source done by CodenameOne? Are you still planning to improve Windows support? Anyway, I’ll have a word with the assessors and see if they want to describe the issues they are having in your forum, but it seems its all about getting the product out on time for now.
I explained some of the issues we had with Windows Phone here: [http://www.codenameone.com/…](http://www.codenameone.com/blog/a-new-pipeline-for-windows-phone)
It helps to understand how Codename One works and why its so portable [http://www.codenameone.com/…](http://www.codenameone.com/3/post/2014/05/understanding-peer-native-components-why-codename-one-is-so-portable.html)
We’d love to have a better Windows Phone port, we already invested into 3 rewrites attempting to improve the situation.
One of the product our assessors looked at is called: Xamarin ([www.xamarin.com](http://www.xamarin.com)), which is similar in concept to yours except the development code is done in C# and not Java. The downside is our development team is not C# centric, but it looks promising for people that are.
Xamarin isn’t a Write Once Run Anywhere solution. It effectively allows you to write your application in C# but you invoke native device API’s. This means you have some common business logic but your UI (roughly 50% of the code) would be platform specific.