Gert, I like your mockup and it will serve well as foundation for further enhancements.
Best regards, Lars -------------------------------------- Lars Heinemann FuseSource Email: [email protected] Web: http://www.fusesource.com Blog: http://lhein.blogspot.com Twitter: lhein77 Am 29.06.2011 um 10:16 schrieb Gert Vanthienen: > L.S., > > > About the content: in my mind, most of the content we have, belongs in > the documentation project. It's only the generic information about > the mailing lists, source code locations, jira, community, ... that > has to go into the website project. That's about the distinction I > tried to make when creating the website project, so most of the > website contents should be there but it sure needs updating and a bit > of restructuring to get it organized. > > For the documentation, I would suggest we: > 1. keep the information in the wiki around as the documentation for > ServiceMix 3.x (we decided to only do one more release of that a while > ago, so there's no point in investing a lot of time porting the > information) > 2. for the time being, focus on the documentation for ServiceMix 4 - I > think the quick start and camel guide are a good start, but we need to > flesh things out to get a good documentation base for the 4.x series > which we will probably be maintaining for a while > 3. as soon as we start committing any code for ServiceMix 5, make sure > to document everything right away - I think that's just a habit we > have to grow and I don't mind being the PITA that asks people to add > the docs after every commit, but I really think it's the only way to > ensure that the documentation does not get behind so much that it > needs a lot of work to fill the gap (as we have now with ServiceMix > 4.x) > > About the website design, ideally I think we would to implement a new > design together with the new contents and make sure we have something > to show off. While I like both Chris' and Lukasz' designs, they are > pretty sophisticated and we never got around to actually translating > that into a template that's easy enough to tweak and implement by > simple developers (like non-web-designers as myself). BTW, we do have > the PSD file for Lukasz' mockup attached to > https://issues.apache.org/jira/browse/SMX4-731, but there's not HTML > version for that yet. > > That's why I created a very simple HTML page and CSS myself in > http://servicemix.apache.org/staging/mockup/index.html (which is > already in the website codebase) - I agree it does not look half as > sophisticated as the other two suggestions, but it still keeps the > overall layout of those two and at least it has the virtue of being > very simple HTML and CSS we can easily work with and include in the > documentation project as well. Perhaps we can start with something > like this and if anyone fancies adding a bit more eye candy to it, > that would be great obviously! > > > Regards, > > Gert Vanthienen > ------------------------ > FuseSource > Web: http://fusesource.com > Blog: http://gertvanthienen.blogspot.com/ > > > > On Wed, Jun 29, 2011 at 9:57 AM, Guillaume Nodet <[email protected]> wrote: >> Moving to a separate thread. >> >> I've sent an email to Lukasz asking for the sources of the web site. >> >> On nightly builds, I agree this would be a good idea to have automated >> deployment of the web site. If hudson can be leveraged for that, it >> would be awesome. >> >> On Wed, Jun 29, 2011 at 09:38, Jean-Baptiste Onofré <[email protected]> >> wrote: >>> I like the splatch website design also. >>> >>> As we discussed for Karaf, moving the SMX website to use scalate requires >>> that we have a "nightly" deployment of the website to quickly update the >>> news section, etc. >>> >>> Regards >>> JB >>> >>> On 06/29/2011 09:33 AM, Guillaume Nodet wrote: >>>> >>>> If we do the same as Karaf, the scalate based web site mostly consist >>>> in non technical docs (downloads, community, irc, forums, etc...) and >>>> all the technical docs are in versioned manuals. >>>> >>>> ServiceMix has a particularity though because we have several major >>>> versions which are really different, so that may affect a bit. >>>> >>>> Anyway, I really like the one splatch, so if he can give us the core >>>> images used in that web page, I'm sure we can make it work with the >>>> site Gert has worked on. >>>> >>>> On Wed, Jun 29, 2011 at 08:15, Lars Heinemann<[email protected]> wrote: >>>>> >>>>> Yes, I agree that we first should go for the content. But it's a bit >>>>> wired as if we don't have so many sub pages as >>>>> in the current page then we will probably do content for pages which will >>>>> not be used or in a different form. >>>>> >>>>> We should just have some basic idea how the sitemap will look like before >>>>> flooding in the content. >>>>> >>>>> Best regards, >>>>> Lars >>>>> >>>>> -------------------------------------- >>>>> >>>>> Lars Heinemann >>>>> FuseSource >>>>> Email: [email protected] >>>>> Web: http://www.fusesource.com >>>>> Blog: http://lhein.blogspot.com >>>>> Twitter: lhein77 >>>>> >>>>> >>>>> >>>>> Am 29.06.2011 um 08:03 schrieb Guillaume Nodet: >>>>> >>>>>> I don't have any problems with changing the design, but I just think >>>>>> that the content is more important than the color >>>>>> >>>>>> On Wed, Jun 29, 2011 at 07:39, Lars Heinemann<[email protected]> wrote: >>>>>>> >>>>>>> Regarding the webpage design... >>>>>>> >>>>>>> As already stated I don't like the design of the webpage. It seems to >>>>>>> be a duplicate of the Karaf homepage >>>>>>> and I can't see that the page is now more easy and clean as we once >>>>>>> intended to do. >>>>>> >>>>>> Well, if I can slightly object, it's kinda the opposite, as Karaf has >>>>>> simply reused the ServiceMix design ;-) >>>>>> >>>>>>> I'd like to point you to the following design proposals which I think >>>>>>> are really awesome looking... >>>>>>> >>>>>>> http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from >>>>>>> ccustine) >>>>>>> http://img259.imageshack.us/img259/1718/servicemix46.jpg (from >>>>>>> splatch) >>>>>>> >>>>>>> Shouldn't we go for something like this? Those designs are awesome >>>>>>> looking and have a very clear and simple navigation concept. >>>>>> >>>>>> Both looks really good to me, but before switching the css, we need to >>>>>> get the scalate stuff to work and the content up to date, so that we >>>>>> can switch to that new stuff asap. >>>>>> Then, we can propose changes on the pure css stuff (colors, images, >>>>>> icons etc...) based on the new website. Once we have the >>>>>> infrastructure in place, we can easily branch or experiment with css >>>>>> patches. >>>>>> >>>>>>> Wdyt? >>>>>>> >>>>>>> Best regards, >>>>>>> Lars >>>>>>> >>>>>>> -------------------------------------- >>>>>>> >>>>>>> Lars Heinemann >>>>>>> FuseSource >>>>>>> Email: [email protected] >>>>>>> Web: http://www.fusesource.com >>>>>>> Blog: http://lhein.blogspot.com >>>>>>> Twitter: lhein77 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Am 29.06.2011 um 01:39 schrieb Gert Vanthienen: >>>>>>> >>>>>>>> Guillaume, >>>>>>>> >>>>>>>> >>>>>>>> All this seems to make a lot of sense to me - let's drop the bits that >>>>>>>> don't bring any value (any more) and try to add value to the project >>>>>>>> by focusing on providing these container-level services to integration >>>>>>>> projects. I also like the idea for creating both a Tomcat and a Karaf >>>>>>>> based distribution. That way, people can start with the more familiar >>>>>>>> WAR deployment in a simple Tomcat container and, as they need the more >>>>>>>> advanced features, gently migrate to the full OSGi-goodness of the >>>>>>>> Karaf based distribution. >>>>>>>> >>>>>>>> For the website, I took an initial stab at migrating the relevant bits >>>>>>>> of existing website contents to a Scalate/Maven-based project at >>>>>>>> https://svn.apache.org/repos/asf/servicemix/website and pushed an >>>>>>>> initial copy of the result out to >>>>>>>> http://servicemix.apache.org/staging/ so we can start adding content >>>>>>>> again there until we're happy enough with the result to promote this >>>>>>>> to become the home page. >>>>>>>> >>>>>>>> Information about the current location/build/... of the documentation >>>>>>>> project can be found at >>>>>>>> http://servicemix.apache.org/documentation-project.html - we have a >>>>>>>> bit of content for ServiceMix 4.x in there already but it still needs >>>>>>>> quite some work. For ServiceMix 5.x, we should probably grow the >>>>>>>> habit of documenting every single feature the moment we add it to the >>>>>>>> codebase right from the start so we can build the documentation right >>>>>>>> along with the actual code. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Gert Vanthienen >>>>>>>> ------------------------ >>>>>>>> FuseSource >>>>>>>> Web: http://fusesource.com >>>>>>>> Blog: http://gertvanthienen.blogspot.com/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet<[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Last week, I've been discussing with a few committers about the >>>>>>>>> ServiceMix roadmap. >>>>>>>>> So I'd like to communicate those thoughts to a wider audience. >>>>>>>>> >>>>>>>>> We've been discussing already that the value of ServiceMix (which was >>>>>>>>> the JBI layer in ServiceMix 3 >>>>>>>>> and the container side in ServiceMix 4) has moved mostly to Camel and >>>>>>>>> Karaf respectively. The remainining >>>>>>>>> bits are mostly the NMR. However, the value of the NMR is not in the >>>>>>>>> NMR itself, but rather the NMR was >>>>>>>>> supposed to enable various container-level features. However, we >>>>>>>>> haven't really built those features so >>>>>>>>> that the *real* value of the NMR is not that high currently. >>>>>>>>> >>>>>>>>> So, what we've been discussing is to focus on that added value in a >>>>>>>>> more transparent way by tweaking >>>>>>>>> Camel a bit to support global interceptors, so that one could deploy >>>>>>>>> the real routes without having to >>>>>>>>> force the use of a specific transport such as the current NMR. This >>>>>>>>> way, a user could test / develop >>>>>>>>> the Camel routes or take existing Camel routes and deploy them in >>>>>>>>> ServiceMix, thereby transparently >>>>>>>>> enabling a bunch of useful features. We've been thinking about >>>>>>>>> adding >>>>>>>>> message tracing / timing / auditing, >>>>>>>>> sending test messages, security checks, viewing flows, persistent >>>>>>>>> modification of camel >>>>>>>>> routes, camel route versioning, etc... That need to be coupled with >>>>>>>>> a >>>>>>>>> web console similar to the >>>>>>>>> Camel / ActiveMQ web consoles, to actually display all the data to >>>>>>>>> provide useful information for monitoring >>>>>>>>> Camel routes and help diagnosing problems in production for example. >>>>>>>>> There's really nothing magically new >>>>>>>>> here and some of those features were actually part of ServiceMix 3, >>>>>>>>> but without much focus on those and >>>>>>>>> they have always kept a bit on the side. The idea is really to make >>>>>>>>> ServiceMix the best possible container >>>>>>>>> for deploying Camel based integration. >>>>>>>>> >>>>>>>>> Additional things that could be pushed inside ServiceMix 5 would be a >>>>>>>>> Tomcat based container deployment >>>>>>>>> option (for those that don't need OSGi), a new manual similar to what >>>>>>>>> we have in Karaf (maybe reusing >>>>>>>>> parts of it). We'd also need a new website (without the technical >>>>>>>>> doc, as we have for Karaf I think). >>>>>>>>> >>>>>>>>> On the maintenance of the JBI components and NMR/JBI layer, I think >>>>>>>>> we >>>>>>>>> should keep them in smx4. >>>>>>>>> People wanting to deploy those could easily add a pointer to the >>>>>>>>> servicemix 4 features descriptors and >>>>>>>>> deploy the needed features. So we could officially deprecate those >>>>>>>>> and tell users they won't be >>>>>>>>> available in smx5. This also means that there's really not much to >>>>>>>>> reuse from smx4, so smx5 would >>>>>>>>> have its own new and dedicated svn area. >>>>>>>>> >>>>>>>>> FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the >>>>>>>>> coming months, so those are not >>>>>>>>> faithful wishes, but really something I want to start implementing >>>>>>>>> asap. >>>>>>>>> >>>>>>>>> Feedback welcomed! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------ >>>>>>>>> Guillaume Nodet >>>>>>>>> ------------------------ >>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>> ------------------------ >>>>>>>>> Open Source SOA >>>>>>>>> http://fusesource.com >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> Open Source SOA >>>>>> http://fusesource.com >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >>
