Hi, Following Tobias Soloschenko thread about the Twitter poll result
I think we should focus on who who don't know Wicket. People who don't like Wicket, the unhappy users, will not come back. Only 34% of the respondents know what is Apache Wicket. Put another way 66% don't ever know what is Wicket. A) Apache Wicket's Adoption —————————————— Adoption (software or any good) has 2 channels : buzz and word of mouth. For many authors word of mouth (WOM) influence 50% of the acquisition decision. So to increase Wicket Adoption we have 2 choices : 1) Wicket buzz) The buzz channel is done via articles, conferences (ApacheCon), meetup, social network (twitter). The superbe Wicket's website welcome everyone who wants to adopt Wicket. How the 50% of the 66% who don't know Wicket could be targeted ? By increasing the buzz. We can increase the buzz by more articles in which we could give specific examples where Wicket has strong value, write beautiful small examples to demonstrate the beauty of our beloved framework (this is what Vaadin has been doing since few months ), nice conference's coverage (ApacheCon video on youtube) .... By improving its impact using redundancy. Mentioning Wicket'skills on dev's social network profile (linkedin) ! (very few do it) is one example. By retweeting, by mentioning Wicket more often, .... 2) Word of Mouth) (WOM) Word of Mouth is the passing of information from person to person by oral communication (Wikipedia) WOM is the second channel, with an equal importance for Wicket Adoption. Word of Mouth is made of by the developers and project managers feedbacks. A lot has been done, through a nice and complete user guide to make the learning curve easier. if I think we should focus on who who don't know Wicket, I think we must hava a clear understanding why developers don't like Wicket. Understanding the difficulties and dislikes is very important. And should be done without affect. B) Difficulties and dislikes: —————————————— In many projects, developers start writing few pages, using the examples. Most of the time developers have difficulties understanding models, and while trying to implement the functionalities that have to be done for yesterday, they still do not masterise theirs models, and do not pay attention to their codes. They just do not have time for these 2 tasks. They have to deliver. Bugs will be fixed after..... They do copy and paste to implement first functionalities, and after few weeks, the code is so messy that you start thinking at the servlet / jsp … ! The style of coding we can find in the Wicket Examples is used to write ugly classes. In many places I have seen pages with more than few thousand lines. No one wants to read it before lunch time or a friday afternoon ! And as in any corporation, developers attempt to name a culprit. From outside the developer's corporation. Guess what ? This is the time Wicket starts to receive a bad reputation. And this is where this bad reputation stops the natural spreading Wicket’ usage between developers, between teams in a company, between companies. Word of mouth adoption channel is closed here. And needless to say, when new developers arrive on this kind of existing project, they are not in a "wicket's loving mood". Difficult to understand, difficult to maintain. And you know, the first meeting is important ! We can improve a lot Wicket Examples's value by having more comments or a better pedagogical naming convention. A "test yourself" page where developers can test their Wicket’s skills, with the correct answer and with the minimum level score to start using Wicket with ease, could be interresting. But it's not good enough. The difficulties I have found in many places are : Model, Page, Granularity Model, Page, Granularity : from my clients, these 3 points are the "dislike's culprit" : Models seem to be difficult to masterise, but it’s a core concept. Getting Models proficiency is the key. Writing page (java code) that are well structured, have nice code, are easy to read should be highlighted (even if it’s more a Java skill than a Wicket’s one) How granular should components be organized is a not an "exact science" and some best practices, examples could help a lot. François --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org