L.S.,
I think a consistent look and feel is important indeed, so if we want to keep using that template, we probably have to run it by [email protected]. Another option could be that we start with a simple HTML/CSS and build the new look and feel the same way as we do with the rest of our software, incrementally and by adding features/eye candy/... while we go. My own little mockup would be one candidate obviously, but if someone (with better web design skills) wants to take a stab at creating a better proposal in the next few days, go for it ;) I think the main point would be to get something nice and simple to implement in the site/docs/webconsole done that can serve as the foundation for building the new look and feel. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Fri, Jul 1, 2011 at 9:59 AM, Guillaume Nodet <[email protected]> wrote: > The template Chris has been using is available at > http://themeforest.net/item/creativeclean-simple-creative-template/122438 > I'm not completely sure about the legal stuff though, as if we plan to > include it in the web console or manual, it seems to imply some > restrictions on downstream users, so we'd have to be very careful > about that. It should be ok for just the web site, but I think having > a consistent theme would be better. > > On Wed, Jun 29, 2011 at 10:21, Lars Heinemann <[email protected]> wrote: >> 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 >>>> >> >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
