Awesome Charles,
thanks a bunch.
Regards
JB
On 07/13/2011 07:19 AM, Charles Moulliard wrote:
Hi,
I will prepare tomorrow a HTML/CSS + javascript template based on
Lukas proposition https://issues.apache.org/jira/browse/SMX4-731 that
we can easily integrate on Apache server.
Hi Luke,
Can you provide us the code source of your PSD document that you
provide in SMX4-731 ? Is it possible to make some small modifications
?
Regards,
Charles Moulliard
Apache Committer
Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard
On Tue, Jul 12, 2011 at 10:37 PM, Gert Vanthienen
<[email protected]> wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
