Hi Dan, >Marketing message I think Isis' real strength is prototyping the domain model, the auto-UI is more important as an enabler for this than as a general UI generator.
>REST I can definitely see the attraction of this, would be good to see examples of invoking it. >VIEWERS Agree. For me a quick "quick start" that works smoothly would have got me more involved in Isis, I guess that's the case for other developers too. The "Hosted Demo" idea would work well here too, especially if users could alter the domain classes and see the outcome. This would need to be in a safe / contrived way so as not to impact other users, or maybe a cron job to reset it every ?hour... >REMOTING I think REST has overtaken this. >DDD / revamped site ideas DIAGRAM Maybe put more emphasis on the prototyping aspect of DDD. Mike On 21 Nov 2011, at 13:02, Dan Haywood wrote: > There's been an interesting thread going on in [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 (which will hit > some other aggregators) > * publicise blog posts in twitter using #apache #isis hashtags > * publicise blog posts via 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 or 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
