click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Md. Jahid Shohel" <>
Subject Re: Should we
Date Tue, 06 Jul 2010 12:09:31 GMT
Saying from my experience, whenever I talked to people, I saw them judging a
frameworks considering, how strong their community is, how good their
support is. I agree that good tutorials, blogs helps a lot. But getting
online help (forum based, or instant) attracts people, because it keeps them
going with the development. Because on online example it is not possible to
cover all cases that all user can go through, and that is the phase when
user try to reach community for help. I used such help while i was working
with Java, Wicket, Spring, Javascript, Hibernate, Scala and lift. And for
all those, I just went to the room, and just ask about the issue, And I got
instant answer. I really enjoyed that, then searching and reading forums, or
googling about certain issue. But of course these can vary person to person.

Yes also agree with Malcom, and Bob that having a list of sites who uses the
technology helps use a lot to choose a framework. So Bob's idea about having
the list sites who uses the application is a good idea.

On Tue, Jul 6, 2010 at 12:27 PM, Malcolm Edgar <>wrote:

> Agreed with many of these comments. A couple things Architects will
> look at when evaluating a framework like Click are:
> * where is it being used (e.g. gives me confidence other people are
> using it successfully, and will help justify my recommendation)
> * is it a solid open source project. Apache helps considerable here (tick)
> * it it well documented (tick)
> * good online examples (tick)
> I think getting reference sites and testimonials will really help with
> people evaluating Click.  I think more online articles will help raise
> its profile.
> regards Malcolm Edgar
> On Tue, Jul 6, 2010 at 6:33 PM, Adrian A. <> wrote:
> >> 1) irc channel: I can create one on freenode. And we all can come there
> >> when we are online. That way users can get live help. Will also open
> >> scope for us to chat online. Most of the popular frameworks have
> >> channels under freenode. That way normal users also becomes helper for
> >> each other. And not to mention that, live helps are better then any sort
> >> of forum based (asynchronous) helps, because its live :). Of course
> >> cooperation from all will be needed for this.
> >
> > I also don't think IRC is a solution for small/medium open source
> projects,
> > but the mailing lists.
> > Even for bigger projects, IMHO a Campfire like approach is better.
> >
> > Not even many companies use IM because of the constant possibility of
> > distraction and workflow interruption.
> >
> > On the other hand, many times I hear as an argument against Click
> (compared
> > to the concurrence) the low level of mailing list traffic :).
> > This is of course quite illogical - because of the very good Click online
> > documentation: the users have no need to constantly ask trivial questions
> -
> > but this doesn't seem to count in stats :).
> >
> >> 2) Groups: There are some extremely popular groups I know, where we can
> >> post our updates and release news. These groups are Java user groups. I
> >> personally can take care of this posting new updates and releases.
> >
> > Good idea, but this must be done very sensitively because of the
> possibility
> > to be interpreted as "spam" thus having the opposite effect.
> >
> >> What you think? Also if you have other ides, please share.
> >
> > 1. More examples of applications/sites using Click + testimonials from
> the
> > users about how Click helped them.
> > 2. Blog posts, articles (IMHO the most important popularization source)
> on
> > DZone, StackOverflow, InfoQ etc. (TSS seems lost). For bigger impact they
> > need to be from unbiased 3rd parties.
> > 3. User integrations and examples of Click with other frameworks (e.g.
> other
> > ORMs too).
> > 4. More tools with and for Click.
> >
> > From what I've experienced so far, the most convincing arguments for
> those
> > who usually decide (management, PLs), are (preferably commercial)
> > *live/public* applications with that specific framework. Unfortunately
> until
> > this moment, most Click apps are intranet based, so there's not that much
> to
> > show :(.
> >
> > Adrian.
> >
> >

View raw message