You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Francois Meillet <fr...@gmail.com> on 2016/11/01 10:44:27 UTC
Twitter poll result 2
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Twitter poll result 2
Posted by Francois Meillet <fr...@gmail.com>.
Bruno Borges @brunoborges made a Twitter poll by the end of October.
The question was
If you're a server-side #Java developer building web apps, please respond: have you ever tried/used Apache #Wicket?
The final results are (from 1,128 votes) :
13% Yes, and I like it !
9% Yes, but just tried
12% Yes, and didn't like
66% No. What is Wicket ?
To all Apache Wicket Users, your contributions to the analysis of these results are very important.
Remember any thoughts, any contribution are very welcome !
François
> Le 1 nov. 2016 à 18:11, Mihir Chhaya <mi...@gmail.com> a écrit :
>
> I would like to share my personal experience from developer's perspective.
> First and foremost, I personally love Apache Wicket more than any MVC
> framework I have worked with so far (Struts/JSF). This is just me.
>
> The place I am currently working adopted Wicket 1.4 around 2012. That time,
> the management in general was relying on individual developer's technical
> skills and abilities. Everybody was recommended to use Wicket 1.4. I
> personally evaluated couple of different options and then picked up Wicket
> 1.4.
>
> That time, Apache Wicket in general was lacking good documentation, good
> third party libraries and community awareness. Not any more.
>
> My other colleagues and developers eventually started working with Wicket.
> Many applications got developed using Wicket. Most of the time the code was
> 'copy and paste' from components point of view. We had working components
> developed in-house; but no solid third party components except in-method
> grid (which was great, but with some of the issues of it's own).
>
> Developers got used to writing Wicket based application.
>
> Now, agency became more serious on adopting technologies which had sound
> community and commercial technical support, and which could be considered
> as 'standard'. Also, came the need of responsive design and web
> applications for smaller devices.
>
> More than 75% of the colleagues I was working with were not interested in
> writing their Junit test cases, nor writing their own css/javascript and
> other UI related stuff - I could not find anybody other than 2-3 guys
> interested in developing rich, responsive in-house components. They were
> looking more for ready-to-use components.
>
> So, the agency started evaluation (close to two years ago) and other
> developers were assigned to find and evaluate different options.
>
> We had group of developers who had past experience of Richfaces/Icefaces
> etc.
>
> So, the evaluation started keeping following points in mind:
>
> 1. Solid technical and commercial support. Larger community support with
> detail documentation.
> 2. Following standards (Java/JEE etc). So if standards changes in future
> then it would be minimal impact.
> 3. Standards supported Out-Of-Box by application servers.
> 4. Responsive design.
> 5. Less of presentation layer coding.
> 6. For CDI/Injections, rely on Java instead of Spring.
> 7. Finding developers with prior experience in specific technology. (This
> is case-by-case and by location. Not necessarily a must - but nice to have
> kind of point to consider in evaluation.)
>
> And at the end, agency decided to move forward with using JSF (as it is
> 'standard'), EJBs and Java EE based technologies for CDI/Injection.
> Choosing JSF brought Prime-faces and it's theme to develop responsive
> applications for any devices.
>
> Considering the progress Apache Wicket has made in last couple of years, I
> do believe Apache Wicket can do all of above and much more then any other
> framework. Believe me, I still love Apache Wicket over any other framework.
> It just puts so much of control in my hand instead of relying on some
> bloated versions of html files. Additionally, I am also able to unit test
> and presentation layer - improving my confidence.
>
> But most of the developers I am working don't care to read and understand
> framework architecture in detail, nor they care exploring the power of such
> frameworks which allows them to build their components the way they want.
> They were primarily looking for something which is ready-to-use (which you
> can get with Apache Wicket + Kendo UI/ BootStrap or any other JS
> framework).
>
> We do have projects in Wicket (latest one I migrated from 1.4 to Wicket
> 7.1), but all new development is now in JSF.
>
> Apache Wicket team and the whole community has done exceptionally fantastic
> job in all aspects to improve the framework and making the project more
> appealing.
>
> Additionally, what can be done to (which Francois has already suggested in
> his post):
> 1. Maximize developers' interest in exploring and looking into the
> components.
> 2. How to show case /sample Wicket based web application developed for
> smaller devices? How to make developers look at Wicket show cases?
> 3. Commercial support and marketing it aggressively.
>
> By no mean I am trying to show/share that we have migrated to other
> framework. Above is just my sharing, by all mean to help such strong
> framework whichever way I can.
>
> Thanks,
> -Mihir.
>
> On Tue, Nov 1, 2016 at 11:49 AM, Tobias Soloschenko <
> tobiassoloschenko@googlemail.com> wrote:
>
>> I think it is also good to tell that there are a lot of new features like
>> http/2 support to show that Wicket is not a framework at which developers
>> stopped working on new features several years ago.
>>
>> I wrote an article about that on a blog of Jörn Zaefferer who is
>> responsible for jQuery UI Dev Lead | QUnit | Globalize | Infrastructure.
>>
>> Maybe the page about models can be integrated into the user guide to
>> improve it.
>>
>> kind regards
>>
>> Tobias
>>
>>> Am 01.11.2016 um 16:31 schrieb Andrea Del Bene <an...@gmail.com>:
>>>
>>> Hi Francois,
>>>
>>> I'm glad to read such a clear and smart analysis. I agree with you at
>> 100%. Buzz is something we definitely lack of. We should improve our
>> examples and write more articles on Wicket. I've also noted that Vaadin
>> people have increased the amount of the "buzz" lately. For Vaadin it's
>> easier since they have a commercial company behind it, and it seems to m
>> they have joined the forces with other commercial entities (like JRebel and
>> people behind jOOQ), but this is just my impression. After the ApacheCon I
>> hope to find the time to write more on DZone about Wicket.
>>>
>>> I also think that it's important to work against some misconceptions
>> that Wicket might have in dev community (for example, the idea that it is a
>> stateful-only framework). At least this is what i will try to do at
>> ApacheCon.
>>>
>>> Andrea.
>>>
>>>
>>>
>>>> On 01/11/2016 11:44, Francois Meillet wrote:
>>>> 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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Twitter poll result 2
Posted by Mihir Chhaya <mi...@gmail.com>.
I would like to share my personal experience from developer's perspective.
First and foremost, I personally love Apache Wicket more than any MVC
framework I have worked with so far (Struts/JSF). This is just me.
The place I am currently working adopted Wicket 1.4 around 2012. That time,
the management in general was relying on individual developer's technical
skills and abilities. Everybody was recommended to use Wicket 1.4. I
personally evaluated couple of different options and then picked up Wicket
1.4.
That time, Apache Wicket in general was lacking good documentation, good
third party libraries and community awareness. Not any more.
My other colleagues and developers eventually started working with Wicket.
Many applications got developed using Wicket. Most of the time the code was
'copy and paste' from components point of view. We had working components
developed in-house; but no solid third party components except in-method
grid (which was great, but with some of the issues of it's own).
Developers got used to writing Wicket based application.
Now, agency became more serious on adopting technologies which had sound
community and commercial technical support, and which could be considered
as 'standard'. Also, came the need of responsive design and web
applications for smaller devices.
More than 75% of the colleagues I was working with were not interested in
writing their Junit test cases, nor writing their own css/javascript and
other UI related stuff - I could not find anybody other than 2-3 guys
interested in developing rich, responsive in-house components. They were
looking more for ready-to-use components.
So, the agency started evaluation (close to two years ago) and other
developers were assigned to find and evaluate different options.
We had group of developers who had past experience of Richfaces/Icefaces
etc.
So, the evaluation started keeping following points in mind:
1. Solid technical and commercial support. Larger community support with
detail documentation.
2. Following standards (Java/JEE etc). So if standards changes in future
then it would be minimal impact.
3. Standards supported Out-Of-Box by application servers.
4. Responsive design.
5. Less of presentation layer coding.
6. For CDI/Injections, rely on Java instead of Spring.
7. Finding developers with prior experience in specific technology. (This
is case-by-case and by location. Not necessarily a must - but nice to have
kind of point to consider in evaluation.)
And at the end, agency decided to move forward with using JSF (as it is
'standard'), EJBs and Java EE based technologies for CDI/Injection.
Choosing JSF brought Prime-faces and it's theme to develop responsive
applications for any devices.
Considering the progress Apache Wicket has made in last couple of years, I
do believe Apache Wicket can do all of above and much more then any other
framework. Believe me, I still love Apache Wicket over any other framework.
It just puts so much of control in my hand instead of relying on some
bloated versions of html files. Additionally, I am also able to unit test
and presentation layer - improving my confidence.
But most of the developers I am working don't care to read and understand
framework architecture in detail, nor they care exploring the power of such
frameworks which allows them to build their components the way they want.
They were primarily looking for something which is ready-to-use (which you
can get with Apache Wicket + Kendo UI/ BootStrap or any other JS
framework).
We do have projects in Wicket (latest one I migrated from 1.4 to Wicket
7.1), but all new development is now in JSF.
Apache Wicket team and the whole community has done exceptionally fantastic
job in all aspects to improve the framework and making the project more
appealing.
Additionally, what can be done to (which Francois has already suggested in
his post):
1. Maximize developers' interest in exploring and looking into the
components.
2. How to show case /sample Wicket based web application developed for
smaller devices? How to make developers look at Wicket show cases?
3. Commercial support and marketing it aggressively.
By no mean I am trying to show/share that we have migrated to other
framework. Above is just my sharing, by all mean to help such strong
framework whichever way I can.
Thanks,
-Mihir.
On Tue, Nov 1, 2016 at 11:49 AM, Tobias Soloschenko <
tobiassoloschenko@googlemail.com> wrote:
> I think it is also good to tell that there are a lot of new features like
> http/2 support to show that Wicket is not a framework at which developers
> stopped working on new features several years ago.
>
> I wrote an article about that on a blog of Jörn Zaefferer who is
> responsible for jQuery UI Dev Lead | QUnit | Globalize | Infrastructure.
>
> Maybe the page about models can be integrated into the user guide to
> improve it.
>
> kind regards
>
> Tobias
>
> > Am 01.11.2016 um 16:31 schrieb Andrea Del Bene <an...@gmail.com>:
> >
> > Hi Francois,
> >
> > I'm glad to read such a clear and smart analysis. I agree with you at
> 100%. Buzz is something we definitely lack of. We should improve our
> examples and write more articles on Wicket. I've also noted that Vaadin
> people have increased the amount of the "buzz" lately. For Vaadin it's
> easier since they have a commercial company behind it, and it seems to m
> they have joined the forces with other commercial entities (like JRebel and
> people behind jOOQ), but this is just my impression. After the ApacheCon I
> hope to find the time to write more on DZone about Wicket.
> >
> > I also think that it's important to work against some misconceptions
> that Wicket might have in dev community (for example, the idea that it is a
> stateful-only framework). At least this is what i will try to do at
> ApacheCon.
> >
> > Andrea.
> >
> >
> >
> >> On 01/11/2016 11:44, Francois Meillet wrote:
> >> 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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Twitter poll result 2
Posted by Tobias Soloschenko <to...@googlemail.com>.
I think it is also good to tell that there are a lot of new features like http/2 support to show that Wicket is not a framework at which developers stopped working on new features several years ago.
I wrote an article about that on a blog of Jörn Zaefferer who is responsible for jQuery UI Dev Lead | QUnit | Globalize | Infrastructure.
Maybe the page about models can be integrated into the user guide to improve it.
kind regards
Tobias
> Am 01.11.2016 um 16:31 schrieb Andrea Del Bene <an...@gmail.com>:
>
> Hi Francois,
>
> I'm glad to read such a clear and smart analysis. I agree with you at 100%. Buzz is something we definitely lack of. We should improve our examples and write more articles on Wicket. I've also noted that Vaadin people have increased the amount of the "buzz" lately. For Vaadin it's easier since they have a commercial company behind it, and it seems to m they have joined the forces with other commercial entities (like JRebel and people behind jOOQ), but this is just my impression. After the ApacheCon I hope to find the time to write more on DZone about Wicket.
>
> I also think that it's important to work against some misconceptions that Wicket might have in dev community (for example, the idea that it is a stateful-only framework). At least this is what i will try to do at ApacheCon.
>
> Andrea.
>
>
>
>> On 01/11/2016 11:44, Francois Meillet wrote:
>> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Twitter poll result 2
Posted by Andrea Del Bene <an...@gmail.com>.
Hi Francois,
I'm glad to read such a clear and smart analysis. I agree with you at
100%. Buzz is something we definitely lack of. We should improve our
examples and write more articles on Wicket. I've also noted that Vaadin
people have increased the amount of the "buzz" lately. For Vaadin it's
easier since they have a commercial company behind it, and it seems to m
they have joined the forces with other commercial entities (like JRebel
and people behind jOOQ), but this is just my impression. After the
ApacheCon I hope to find the time to write more on DZone about Wicket.
I also think that it's important to work against some misconceptions
that Wicket might have in dev community (for example, the idea that it
is a stateful-only framework). At least this is what i will try to do at
ApacheCon.
Andrea.
On 01/11/2016 11:44, Francois Meillet wrote:
> 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
> \u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014
> 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:
> \u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014
> 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 \u2026 !
> 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\u2019 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\u2019s 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\u2019s 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\u2019s more a Java skill than a Wicket\u2019s 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Twitter poll result 2
Posted by Zala Pierre GOUPIL <go...@gmail.com>.
Hello,
Regarding models, and for French community, this article is a must-read:
http://djo-mos.developpez.com/tutoriels/java/wicket/explore-models/
Maybe we should start rewriting it for it to be more up-to-date and / or
translating it.
My 2 cents,
Pierre Goupil
On Tue, Nov 1, 2016 at 11:44 AM, Francois Meillet <
francois.meillet@gmail.com> wrote:
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Je n'aime pas seulement ma vie, mais aussi celle des autres.
(Blade Runner)