Hi Dan, Regarding the quick start, yes, you got the point. Starting from the Home<http://incubator.apache.org/isis/>page, if you want to quick start, you end up following a link to the Where to Start? <http://incubator.apache.org/isis/where-to-start.html> page, which starts with a Maven command line. If the target audience is the average developer, I think we should start with the environment setup and so on, like the "Naked Objects in About Five Minutes" from your book. Makes sense?
Regarding the cool apps, choosing the right "domain" is important, I mean dealing with a domain that makes sense for everyone and perhaps the developer could easily change for his own use, like CRM, sales pipeline, service desk, etc. Cheers, - Bender 2011/11/21 Dan Haywood <[email protected]> > Thanks for this, Luis (I'm cc'ing my reply isis-dev, if that's ok). > > We do have a quick start, but from your mail I'm guessing you found it > hidden away. I think it makes sense to highlight this up on the home page > more clearly. > > In terms of cool apps, do you have any thoughts? (eg have you written one > you'd like to donate?!) > > ~~~ > A related idea to engage people is to get our apps deployed as running > demos. If we're restricting them to just the REST viewer and HTML viewer, > then I think that would be feasible. > > In terms of how to do this, one option might be to use Amazon EC2's > Elastic Bean Stalk - which can be free for micro usage, I understand ( > http://aws.amazon.com/elasticbeanstalk/#pricing). If someone fancied > learning how to use this service...? > > Cheers > Dan > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > On 21/11/2011 17:08, Luis Bender wrote: > > 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]> > >> 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 >> > > >
