Dan,
The first experience a developer gets from playing with the framework
will very much determine if he will continue to evaluate the
technology or try something else.
So, I think we should maximize this first experience with a very easy
step-by-step quick start and some very cool ready to run apps.
Just my /2/ยข.
Regards,
Luis Bender
ProcessMind Business Process Applications
+55 11 5505-3213 Office
+55 11 8158-8820 Mobile
Skype: luis.bender
<http://www.processmind.com.br/>
website <http://www.processmind.com.br/> | blog
<http://thebpmexperience.wordpress.com/> | bpm forum
<http://br.groups.yahoo.com/group/BPM-Forum/> | twitter
<http://twitter.com/processmind> | jobone <http://www.jobone.com.br/>
2011/11/21 Dan Haywood <[email protected]
<mailto:[email protected]>>
There's been an interesting thread going on in [email protected]
<mailto:[email protected]> [1] about (a) the number of podlings in the
incubator and (b) how long some of them are taking to graduate.
One of the main points being made is that podlings that have been
in the incubator for a certain period of time (no-one is
suggesting how long exactly, but 1 year is being used as a
strawman in the thread) should be more explicit in defining their
roadmap and action steps towards graduation.
To be honest, this is all very reasonable, but from Isis' point of
view it is perhaps slightly worrying, because although we've made
some progress with getting our code etc together (and the
licenses, ICLAs, release processes etc are in good shape), we
haven't made a lot of progress in attracting new committers.
Indeed, arguably we've gone backwards in that space: right now
only Kevin, Rob and myself currently actively commit.
With that in mind, Kevin, Rob and I had a skype conf call this
weekend to discuss some ideas to move Isis forward towards
graduation. Obviously, this is it's slightly against Apache
policy ("if it didn't happen on the mailing list then it didn't
happen"), which is why I'm posting here now to post some of our
initial conclusions and to broaden out the discussion to everyone
else who might be interested. (Kevin and Rob: correct me if I
overstate on any of this).
*Marketing Message*
The main thing we discussed was the "marketing message" for Isis.
/Automatic UI/
The view we came to was that the automatic-UI generation part of
Isis (ie the naked objects pattern) is possibly more of a negative
than a positive, at least so far as attracting new users:
* That is, for those that have heard of naked objects (guestimate:
1/4 to 1/3 of developers), chances are that they have dismissed it
as being a way to build over-simplified CRUD-style applications.
(Of course, those of us who have actually used it to build apps
know that ain't so, but that's a different discussion).
* For those that have not heard of naked objects, the proposition
that "here's a framework that will automatically generate your
UIs" doesn't resonate. Why? I guess we can speculate; my view is
that there are now plenty of UI technologies that are quite
productive/easy to use/fun; probably a lot more so than when the
original naked objects framework was developed c: 2000. Another
reason might be that developers put too much emphasis over owning
the UI rather than making sure the domain model is good.
On the other hand, we did conclude that the automatic-UI is useful
as a design tool, and would-be users of Isis could probably
understand it in those terms. The fact that the automatic UI is
also suitable for use by end-users in some situations is
subsidiary and something that adopters of Isis might discover only
later on.
/REST/
Another point that I was keen to see factored into the marketing
message for Isis is its REST support (the json-viewer). As you
may have picked up from other posts, I've been developing a
standalone spec, Restful Objects [2], which defines defines a set
of RESTful resources, and corresponding JSON representations, for
accessing and manipulating a domain object model.
I'm quite excited by this Restful stuff. On the one hand, as well
as Isis' implementation, there's also another .NET implementation
underway via Naked Objects MVC (Richard Pawson has been providing
great feedback on the spec). And Johan Andries has been making
good progress on a new RESTful UI, which I'm hoping might go open
source. Also, the REST approach has met a good reaction at our
(joint) client in Ireland.
In terms of marketing, my view is that REST is an area where there
is currently a lot of interest, but developers looking into it
will likely realise that it's a complex area to do right (ful
support for HATEOAS, HTTP headers and status codes etc). As such,
developers might be interested in a framework that can help them
out, at a somewhat higher level of abstraction than JSR-311. The
proposition is: press a button and get a complete, fully restful
API to any domain model.
/DDD/
A third message is for those that are interested in domain
modelling/domain driven design, for whom the automatic UI might
(again) be a useful design tool who might want to deploy their app
on some other framework, eg Spring or JEE.
So, overall this gives us three target use cases to address. The
view we took on was that the home page should reflect these use cases:
- domain modelling (and deploy on own platform)
- REST
- automatically generated webapp (primarily to support the other
two use cases, but optionally as a deployment in its own right)
With this in mind I've sketched up a new graphic that could be
used for the home page, see [3]. The current home page (the
hexagonal architecture) would probably be demoted to a supporting
page describing the architecture of Isis.
In addition, we thought that the side bar menu should be
restructured around these use cases.
*Alpha status viewers*
Another point we discussed was the incomplete nature of some of
the viewers. Having would-be users come across code that is
broken is clearly not a good experience, at least if there
expectations are that everything works.
Specifically:
* the scimpi viewer is code complete but its supporting
documentation is incomplete
* the wicket viewer is not complete (though it's documentation is
pretty good!)
* the xhtml viewer (which is a precursor to the json viewer, but
using XHTML representations) is superceded by the json viewer and
so should be removed
* the dnd viewer (which has worked in the past), is currently
broken (doesn't repaint properly)
We discussed the dnd viewer quite a lot. Although it is, in some
sense, the "purest" expression of the naked objects pattern
(bringing in some of the original ideas of expressive systems),
the truth, probably, is that for our target audience this isn't
important to emphasise. Crudely put: would-be users are not going
to understand what the somewhat unconventionaly UI that the dnd
browser provides is trying to achieve. The fact that it is
currently broken hardly helps atters.
So one of the points we thought made sense was to change things so
that the HTML viewer is the default, rather than DnD.
In terms of the documentation and the site, we decided that the
web site pages for the scimpi, wicket and dnd viewers should
indicate that they are "alpha" status, and on the left hand menu
we should group them under "other viewers". As such, we probably
should remove them from the Maven archetype until such time that
they are back to production quality.
*Remoting*
We also discussed the remoting component. The remoting component
enables the dnd viewer to be deployed in a client/server
configuration, and is what is used in the big Irish project (on
the old .NET version of the naked objects framework). However, my
personal view is that remoting is, well, broken. In fact, I think
it should be removed: (a) the caching semantics for client-side
domain objects is not well-defined; (b) anyone wanting a
client/server solution would probably look towards an approach
that uses REST, (c) the remoting support introduces a lot of
complexity in the default runtime (notably, the separation of the
"Persistor" API and the "ObjectStore" API).
However, we didn't necessarily all agree on this viewpoint. So
for now, we decided to de-emphasise remoting, because it doesn't
fit into the 3 main use cases that we highlighted above. That
means that it won't appear in the left-hand menu, for example. My
suggestion is that we link to it from the dnd viewer page (because
that's the only viewer that would make use of it).
*Release*
Kevin has been working through the release procedures that I
documented, and made some changes and clarifications. I think
that by-and-large they are holding up ok.
I offered to push out a new release, because we are well overdue
for another release. I propose to do this once we've
restructured the site a little (assuming that we go with the ideas
I'm summarizing in this thread).
*Blogging*
In terms of building up a community, I suggested that we need to
be more organized about blogging. A little organization here
between the contributors could substantially increase Isis' reach:
* one idea is that Rob, Kevin and I take it in turns to publish a
blog post such that there is at least one new blog post every week
* blog posts should also be cross posted to blogs.apache.org
<http://blogs.apache.org> (which will hit some other aggregators)
* publicise blog posts in twitter using #apache #isis hashtags
* publicise blog posts via dzone.com <http://dzone.com> (and any
other places you might choose)
* publicise blog posts via isis-dev mailing list, and ask others
to up-vote in dzone).
In terms of content, one question raised was what, exactly, to
blog about. My thoughts are:
* choose a theme for a series of blogs:
- eg tips-n-tricks taken from applications working on (Robert's
PlanChaser, or Kevin's various apps)
- copy-n-paste some of the sidebars from the Richard/Robert's
original Naked Objects book (for Robert)
- work through some of the applib conventions, eg how to do
choices for a property.
In terms of "how to":
* keep it short, something that won't take more than 2 or 3
minutes to read
* if you have more than that, then leave it to the next part
* sit down and write 2 or 3 posts at a time (or split up a draft
blog post that's got too long) and then only publish them
according to a schedule
*Articles*
Rob, Kevin and I didn't discuss writing articles in our call;
clearly some articles would be good (eg infoq.com
<http://infoq.com> or theserverside.com
<http://theserverside.com>), but it takes that much more time to
do. I'd rather focus on just getting a steady stream of blog
posts going first.
*Thoughts?*
OK, I think that more or less summarises the points that I wanted
to raise. If anyone has any views on
this/clarifications/corrections, then post them here.
Meantime, I intend to put some additional material on blogging up
onto our wiki.
Thanks,
Dan
[1]
http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html
[2] http://restfulobjects.org/
[3]
https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas
