You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Justin Ross <jr...@apache.org> on 2013/03/26 15:05:44 UTC
Website update
Hi, everyone. It's clearly been too long since my last update!
http://people.apache.org/~jross/transom/2013-03-26/
Previous version: http://people.apache.org/~jross/transom/2013-02-11/
A complete list of changes follows. To summarize: The look and feel
isn't changed much since last time. There have, however, been
important changes to (1) expand content at the leaf nodes of the
existing structure, (2) enhance the navigation, and (3) automate the
generation of new release content.
I've received some very helpful feedback. Thanks indeed! (Send
more.) For my next iteration, I plan to try something new: I'm going
to promote "source modules" (Qpid Java, Qpid C++, Qpid Proton) more on
the front page. I'm sure this will spark a healthy debate about how
things work at Qpid, and that's really the point. I think it helps to
see it presented as a newcomer would see it.
Also, for fun, an alternate logo. This one's probably better for a t-shirt:
http://people.apache.org/~jross/transom/2013-03-26/images/logo-2-300-300.png
Changes:
- Content
- Expanded the java broker feature list and added more links to docs
- Added more links to qpid jms docs
- Expanded the messaging api example matrix
- Added links to readmes and source locations to per-language
example index files
- Added messaging api reference for dotnet
- Improved configuration of doxygen output
- Added news feed and list info links to the mailing lists page
- Added links to review board to the more resources page
- Added a note about release cadence to the releases page
- Added CI section in more resources
- Navigation
- Top page navigation is more compact (moving the content higher
on the page) and fully hierarchical
- Navigation is no longer manual; it's generated from the site
layout and plugged into the template
- The jira search link now focuses the search box when you link to it
- Added a proton-specific jira goto
- Internals
- Automated the process of adding new release content to the site
- The site code now does site-internal link checking
- Style
- Switched to the Roboto Condensed typeface for body text
- Rounded the corners of the Qpid intro box
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Website update
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Tue, Mar 26, 2013 at 10:05 AM, Justin Ross <jr...@apache.org> wrote:
> Also, for fun, an alternate logo. This one's probably better for a
> t-shirt:
>
>
> http://people.apache.org/~jross/transom/2013-03-26/images/logo-2-300-300.png
>
I think the T-shirt version should have horns. ;-)
--Rafael
Re: Website update
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
>
> It feels too small even on my small devices, and I think is making
> assumptions that people use 2 windows (or more specifically, 2 windows with
> our site in both) side by side
>>
>>
Hi Justin, first let me say that I'm currently without decent IT access, so I've not had a chance to take a proper look and this isn't intended in any way to be critical, from what I've read the update sounds great and I'm looking forward to it.
Following on from Robbie's comment though I'm a little troubled by the comments about the site and screen sizes. I guess that in my mind it would make sense to target the basic presentation for the middle ground, so for example a slightly nasty css2 browser (naming no names :-)) and a mid size desktop display. With that as a starting point it should be possible to target larger and smaller devices using css3 media queries.
My logic is that modern browsers support media queries but older ones do not, but older ones are more likely to be running on mid sized kit.
This may be a comment for the future, but I think it'd be good to aim for a site that gives a consistent feel across multiple devices, we're now living in a converged world so users expect to be able to look at a site on a desktop one minute, a tablet another and a smartphone the next.
Clearly a mixed media site takes some care to get right and is arguably a bit of a faff, but I guess that one advantage of targeting multiple displays is that it's a pretty good way of focussing the mind on the content "priority" as one tends to put the most useful information first, with subsequent navigation off for mobile sites.
I'm far from an expert on ergonomics so this is really just suggested as food for thought for the future, but I do think that the site will be increasingly hit by mobile traffic as that is becoming the dominant way to access the Web.
Best regards,
Fraser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Robbie Gemmell <ro...@gmail.com>.
On 28 March 2013 21:59, Justin Ross <jr...@apache.org> wrote:
> Thanks for the detailed feedback.
>
> A lot of what you've pointed out have become todos on my list, so I
> won't comment further on those.
>
> On Thu, Mar 28, 2013 at 1:13 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > Can we see the source as well as the output?
>
> Yes, certainly. I just finished tidying it up.
>
> https://github.com/ssorj/transom
>
> > What browers are we supporting, and have been tested? I gave it a load in
> > IE10, IE9, IE8 (where it presented itself as XML markup instead of
> > rendering the page...possibly something to look at given its apparently
> > still the most popular IE, accounting for about 1/4 of total traffic by
> > some measurements), FF18, FF10, and FF3 (dont ask...as expected it didnt
> > quite right but it was still very usable).
>
> Hey! That's better than I might have hoped. I've only been testing
> on recent versions of Chrome and Firefox. Looking into the IE8 issue.
> I hope we can at least coax it to render as HTML.
>
> > Related, the change from borderless front page to bordered content pages
> > everywhere else seems a little strange.
>
> There is an aesthetic issue at the root of this. The front page looks
> bad when you have the "what is Qpid" box nested inside the page box.
> One of them has to go or it looks very regimented. I can flip it, and
> take away the inner box.
>
> > Echoing previous requests for a wider width, even if needs to be a toggle
> > option. At least some of the remaining 2/3rds width of my (main) monitor
> > would like to be used at times. In terms of smaller devices, it doesnt
> even
> > use all the width on my netbook or phone (in landscape admitedly).
>
> On this one I think it's prioritizing the wrong concerns. Small
> screen devices are more and more used for browsing, and they benefit
> from a narrower and simpler layout. Big screens, on the other hand,
> are wide screens, which naturally accommodate two windows side by
> side. Windows (and Gnome) have indeed introduced mouse gestures for
> using this. Since 960 is reasonable for small devices, and half of
> 1920, it is in my opinion the most sensible target.
>
>
I see where you are coming from but still kind of disagree I guess.
It feels too small even on my small devices, and I think is making
assumptions that people use 2 windows (or more specifically, 2 windows with
our site in both) side by side so much that it deserves to be prioritized
to this extent over single-page usage; things can overlap a little in the
side-by-side case without being much of an inconvenience (if any, due to
the amount of padding in the content area). Perhaps you do, but I know I
spend plenty of my time (such as now when typing this mail or reading other
sites that free flow) without doing that on any of the screens I use (even
on the 30" monitor where it certainly becomes kind of noticable how small
the site is). Is there a show of hands for spending the majority of your
time working with side by side windows?
To see why this felt so noticable to me, I did a comparison where I opened
many of the sites I normally read in different tabs and scrolled through
them all. Ours was smaller than every single one of them to varying degree
(some being full width free flow, others fixed at anything up to 1280
width), which is probably the reason it is sticking out for me so much when
added to the 'large monitor problem'. Some then have width options to make
them wider than they default to, and at the very least I think we should do
the same if we end up targetting such a small width by default, and let
people adapt to what suits them.
As more than one of us has thought this was an issue worth noting, it seems
reasonable that a percentage of users will think so too.
> homepage is supposed to have a one sentence description defining what the
> > Apache Qpid (rather than just Qpid) product is (suggesting maybe we need
> to
> > really sub-project everything if going for this component-based
> structure)
>
> I don't understand this one yet. What distinction between Apache Qpid
> and Qpid are you using?
>
The one Apache are, whereby Apache Qpid is the primary branding for
trademark of our project rather than just Qpid, since the former should be
specific to us whereas the latter may not be (and indeed isn't, see Gordons
related question and the reply on private@ recently).
Reading the requirements again, it does actually initially talk to 'product
or project' a bit more than I thought so there seems to be more wiggle room
there than I figured...might still be best to run the page and/or blurb
past trademarks@a.o as suggested on the page.
>
> > and i wouldnt say the message in the box quite covers the requirement,
> and
> > dont know if theyd agree the required links in the footer are really part
> > of our 'main' navigation (though they are at least on every page so maybe
> > they are the main navigation :p). Etc.
>
> What goal are we serving by pursuing the letter definition of a
> correct Apache project? I see the arguable deviation here, but I
> don't see the rationale for being highly conformant.
That there was a requirement which was laid out (and emailed to us multiple
times) for Apache projects to meet so we can continue to mange such stuff
ourselves without the foundation having to do it for us, and as an Apache
project I think we should look to actually meet the requirements of being
so (particularly where the current site already does so and to not would be
a step back). Alternatively, if we disagree with them, see about getting
them clarified and/or changed.
> The more
> important questions, IMO: Is the right information prioritized? Is
> there a liability to avoid? If you think putting the Apache links in
> our main navigation is a service to our site's users, then that's
> something I support. But as of now, I'm not sure those things deserve
> more priority.
>
I think e.g the security@a.o team might argue that point at least :) Some
might say the Licence is also fairly important to the project/foundation.
>
> > The 'ways to get Qpid' page (whcih got a lot harder to find last night)
> > mentions source releases, then links to the other pages that has source
> and
> > binary artifacts on it mixed in the same table. We should perhaps split
> the
> > source and binaries into their own sections, or just make it clearer on
> the
> > tables which type of artifact something is. I found it slightly confusing
> > that we have 'ways to get Qpid', 'download', and 'releases' pages, and
> > think we possibly need to combine them a bit.
>
> It is confusing. I was in transition between two approaches. I'm
> working to clear that up.
>
> > Despite my last thought, I think we might want to have a seperate page
> for
> > the maven artifact information (which beceme a lot harder to find since
> > last night), as the broker and JCA adapter are or soon will be available
> > that way too in addition to the clients. This is an existing shortcoming
> of
> > the current website as much as anything though.
>
> Do you want it to have its own page because it's a larger volume of text?
>
In part, but mainly to group it and make it more directly referenceable
from places such as the download and individual component pages and make it
easy to find. I knew it was there but thought for a few mins today it had
been removed with the latest update as I couldnt actually find it anymore.
>
> > 'AMQP Messenger' and 'AMQP Protocol Engine' seems a bit odd to me on the
> > front page and component page. We dont use those names on any of the
> other
>
> It's only the download table that doesn't have the 'AMQP' prefix;
> everything else does. In the download table, I ran out of space, so
> I trimmed it off.
>
> > pages (such as download). Did we decide Proton needs renamed, or are we
> > saying its really the [Qpid] Proton AMQP Messenger? It feels out of place
> > with the other component names using Qpid as the qualifier, and weird
> that
> > nothing is using Proton in the name at all.
>
> That falls under the component/toolkit/subproject debate. It has a
> lot of names because we've struggled to define what it is.
>
> Our current status as I understand it:
>
> - 'Proton' is a toolkit containing multiple end-user components
> - 'AMQP Messenger' is one of those components
> - 'AMQP Protocol Engine' is another
>
> The AMQP part was preferred at one point for the way suggested anyone
> could use it to add AMQP support to their app.
>
Ok, I guess it just feels out of place to me as I don't/didnt see where it
was ever mentioned before, even the proton site doesnt call it that, and
Qpid is mentioned in many cases for the new components but Proton
apparently isnt really mentioned anywhere except the actual download link
(and the bit on the 'main menu' that dissapears when you leave the front
page). Going through the site you get told about this [AMQP] Messenger
thing then suddenly get directed to download Proton which hasn't really
been mentioned until that point, which feels weird to me and so I wonder
how it would feel to someone coming in to the site with less existing
knowledge.
Related question: what is happening with the current proton sub-site in
this case, is it going away?
>
> > It would be useful (i.e I plan to) to make offline html copies of the
> > documentation, and we would want to make the documentation match the rest
> > of the site as Rob did previously, so I wonder if there really isn't a
> nice
> > font we can use that wont require internet access to display? Or can we
> > host that locally instead of hitting the google service?
>
> We can host it, no problem.
>
> > I'd love it if we separate any further logo discussion out into a
> > differentthread . As the one who took on the world of pain to get even
> the
> > basic thing we have now, I'd rather decouple that task from this one.
> > Supposing we just use your first new effort (the TM could do with being a
> > little clearer) or even kept what we have for now, we can change it any
> > time and have any required huge mail thread worth of tweaking at that
> time
> > :)
>
> That's fine by me.
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Website update
Posted by Robbie Gemmell <ro...@gmail.com>.
On 28 March 2013 21:59, Justin Ross <jr...@apache.org> wrote:
> Thanks for the detailed feedback.
>
> A lot of what you've pointed out have become todos on my list, so I
> won't comment further on those.
>
> On Thu, Mar 28, 2013 at 1:13 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > Can we see the source as well as the output?
>
> Yes, certainly. I just finished tidying it up.
>
> https://github.com/ssorj/transom
>
> > What browers are we supporting, and have been tested? I gave it a load in
> > IE10, IE9, IE8 (where it presented itself as XML markup instead of
> > rendering the page...possibly something to look at given its apparently
> > still the most popular IE, accounting for about 1/4 of total traffic by
> > some measurements), FF18, FF10, and FF3 (dont ask...as expected it didnt
> > quite right but it was still very usable).
>
> Hey! That's better than I might have hoped. I've only been testing
> on recent versions of Chrome and Firefox. Looking into the IE8 issue.
> I hope we can at least coax it to render as HTML.
>
> > Related, the change from borderless front page to bordered content pages
> > everywhere else seems a little strange.
>
> There is an aesthetic issue at the root of this. The front page looks
> bad when you have the "what is Qpid" box nested inside the page box.
> One of them has to go or it looks very regimented. I can flip it, and
> take away the inner box.
>
> > Echoing previous requests for a wider width, even if needs to be a toggle
> > option. At least some of the remaining 2/3rds width of my (main) monitor
> > would like to be used at times. In terms of smaller devices, it doesnt
> even
> > use all the width on my netbook or phone (in landscape admitedly).
>
> On this one I think it's prioritizing the wrong concerns. Small
> screen devices are more and more used for browsing, and they benefit
> from a narrower and simpler layout. Big screens, on the other hand,
> are wide screens, which naturally accommodate two windows side by
> side. Windows (and Gnome) have indeed introduced mouse gestures for
> using this. Since 960 is reasonable for small devices, and half of
> 1920, it is in my opinion the most sensible target.
>
>
I see where you are coming from but still kind of disagree I guess.
It feels too small even on my small devices, and I think is making
assumptions that people use 2 windows (or more specifically, 2 windows with
our site in both) side by side so much that it deserves to be prioritized
to this extent over single-page usage; things can overlap a little in the
side-by-side case without being much of an inconvenience (if any, due to
the amount of padding in the content area). Perhaps you do, but I know I
spend plenty of my time (such as now when typing this mail or reading other
sites that free flow) without doing that on any of the screens I use (even
on the 30" monitor where it certainly becomes kind of noticable how small
the site is). Is there a show of hands for spending the majority of your
time working with side by side windows?
To see why this felt so noticable to me, I did a comparison where I opened
many of the sites I normally read in different tabs and scrolled through
them all. Ours was smaller than every single one of them to varying degree
(some being full width free flow, others fixed at anything up to 1280
width), which is probably the reason it is sticking out for me so much when
added to the 'large monitor problem'. Some then have width options to make
them wider than they default to, and at the very least I think we should do
the same if we end up targetting such a small width by default, and let
people adapt to what suits them.
As more than one of us has thought this was an issue worth noting, it seems
reasonable that a percentage of users will think so too.
> homepage is supposed to have a one sentence description defining what the
> > Apache Qpid (rather than just Qpid) product is (suggesting maybe we need
> to
> > really sub-project everything if going for this component-based
> structure)
>
> I don't understand this one yet. What distinction between Apache Qpid
> and Qpid are you using?
>
The one Apache are, whereby Apache Qpid is the primary branding for
trademark of our project rather than just Qpid, since the former should be
specific to us whereas the latter may not be (and indeed isn't, see Gordons
related question and the reply on private@ recently).
Reading the requirements again, it does actually initially talk to 'product
or project' a bit more than I thought so there seems to be more wiggle room
there than I figured...might still be best to run the page and/or blurb
past trademarks@a.o as suggested on the page.
>
> > and i wouldnt say the message in the box quite covers the requirement,
> and
> > dont know if theyd agree the required links in the footer are really part
> > of our 'main' navigation (though they are at least on every page so maybe
> > they are the main navigation :p). Etc.
>
> What goal are we serving by pursuing the letter definition of a
> correct Apache project? I see the arguable deviation here, but I
> don't see the rationale for being highly conformant.
That there was a requirement which was laid out (and emailed to us multiple
times) for Apache projects to meet so we can continue to mange such stuff
ourselves without the foundation having to do it for us, and as an Apache
project I think we should look to actually meet the requirements of being
so (particularly where the current site already does so and to not would be
a step back). Alternatively, if we disagree with them, see about getting
them clarified and/or changed.
> The more
> important questions, IMO: Is the right information prioritized? Is
> there a liability to avoid? If you think putting the Apache links in
> our main navigation is a service to our site's users, then that's
> something I support. But as of now, I'm not sure those things deserve
> more priority.
>
I think e.g the security@a.o team might argue that point at least :) Some
might say the Licence is also fairly important to the project/foundation.
>
> > The 'ways to get Qpid' page (whcih got a lot harder to find last night)
> > mentions source releases, then links to the other pages that has source
> and
> > binary artifacts on it mixed in the same table. We should perhaps split
> the
> > source and binaries into their own sections, or just make it clearer on
> the
> > tables which type of artifact something is. I found it slightly confusing
> > that we have 'ways to get Qpid', 'download', and 'releases' pages, and
> > think we possibly need to combine them a bit.
>
> It is confusing. I was in transition between two approaches. I'm
> working to clear that up.
>
> > Despite my last thought, I think we might want to have a seperate page
> for
> > the maven artifact information (which beceme a lot harder to find since
> > last night), as the broker and JCA adapter are or soon will be available
> > that way too in addition to the clients. This is an existing shortcoming
> of
> > the current website as much as anything though.
>
> Do you want it to have its own page because it's a larger volume of text?
>
In part, but mainly to group it and make it more directly referenceable
from places such as the download and individual component pages and make it
easy to find. I knew it was there but thought for a few mins today it had
been removed with the latest update as I couldnt actually find it anymore.
>
> > 'AMQP Messenger' and 'AMQP Protocol Engine' seems a bit odd to me on the
> > front page and component page. We dont use those names on any of the
> other
>
> It's only the download table that doesn't have the 'AMQP' prefix;
> everything else does. In the download table, I ran out of space, so
> I trimmed it off.
>
> > pages (such as download). Did we decide Proton needs renamed, or are we
> > saying its really the [Qpid] Proton AMQP Messenger? It feels out of place
> > with the other component names using Qpid as the qualifier, and weird
> that
> > nothing is using Proton in the name at all.
>
> That falls under the component/toolkit/subproject debate. It has a
> lot of names because we've struggled to define what it is.
>
> Our current status as I understand it:
>
> - 'Proton' is a toolkit containing multiple end-user components
> - 'AMQP Messenger' is one of those components
> - 'AMQP Protocol Engine' is another
>
> The AMQP part was preferred at one point for the way suggested anyone
> could use it to add AMQP support to their app.
>
Ok, I guess it just feels out of place to me as I don't/didnt see where it
was ever mentioned before, even the proton site doesnt call it that, and
Qpid is mentioned in many cases for the new components but Proton
apparently isnt really mentioned anywhere except the actual download link
(and the bit on the 'main menu' that dissapears when you leave the front
page). Going through the site you get told about this [AMQP] Messenger
thing then suddenly get directed to download Proton which hasn't really
been mentioned until that point, which feels weird to me and so I wonder
how it would feel to someone coming in to the site with less existing
knowledge.
Related question: what is happening with the current proton sub-site in
this case, is it going away?
>
> > It would be useful (i.e I plan to) to make offline html copies of the
> > documentation, and we would want to make the documentation match the rest
> > of the site as Rob did previously, so I wonder if there really isn't a
> nice
> > font we can use that wont require internet access to display? Or can we
> > host that locally instead of hitting the google service?
>
> We can host it, no problem.
>
> > I'd love it if we separate any further logo discussion out into a
> > differentthread . As the one who took on the world of pain to get even
> the
> > basic thing we have now, I'd rather decouple that task from this one.
> > Supposing we just use your first new effort (the TM could do with being a
> > little clearer) or even kept what we have for now, we can change it any
> > time and have any required huge mail thread worth of tweaking at that
> time
> > :)
>
> That's fine by me.
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Website update
Posted by Justin Ross <jr...@apache.org>.
Thanks for the detailed feedback.
A lot of what you've pointed out have become todos on my list, so I
won't comment further on those.
On Thu, Mar 28, 2013 at 1:13 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> Can we see the source as well as the output?
Yes, certainly. I just finished tidying it up.
https://github.com/ssorj/transom
> What browers are we supporting, and have been tested? I gave it a load in
> IE10, IE9, IE8 (where it presented itself as XML markup instead of
> rendering the page...possibly something to look at given its apparently
> still the most popular IE, accounting for about 1/4 of total traffic by
> some measurements), FF18, FF10, and FF3 (dont ask...as expected it didnt
> quite right but it was still very usable).
Hey! That's better than I might have hoped. I've only been testing
on recent versions of Chrome and Firefox. Looking into the IE8 issue.
I hope we can at least coax it to render as HTML.
> Related, the change from borderless front page to bordered content pages
> everywhere else seems a little strange.
There is an aesthetic issue at the root of this. The front page looks
bad when you have the "what is Qpid" box nested inside the page box.
One of them has to go or it looks very regimented. I can flip it, and
take away the inner box.
> Echoing previous requests for a wider width, even if needs to be a toggle
> option. At least some of the remaining 2/3rds width of my (main) monitor
> would like to be used at times. In terms of smaller devices, it doesnt even
> use all the width on my netbook or phone (in landscape admitedly).
On this one I think it's prioritizing the wrong concerns. Small
screen devices are more and more used for browsing, and they benefit
from a narrower and simpler layout. Big screens, on the other hand,
are wide screens, which naturally accommodate two windows side by
side. Windows (and Gnome) have indeed introduced mouse gestures for
using this. Since 960 is reasonable for small devices, and half of
1920, it is in my opinion the most sensible target.
> homepage is supposed to have a one sentence description defining what the
> Apache Qpid (rather than just Qpid) product is (suggesting maybe we need to
> really sub-project everything if going for this component-based structure)
I don't understand this one yet. What distinction between Apache Qpid
and Qpid are you using?
> and i wouldnt say the message in the box quite covers the requirement, and
> dont know if theyd agree the required links in the footer are really part
> of our 'main' navigation (though they are at least on every page so maybe
> they are the main navigation :p). Etc.
What goal are we serving by pursuing the letter definition of a
correct Apache project? I see the arguable deviation here, but I
don't see the rationale for being highly conformant. The more
important questions, IMO: Is the right information prioritized? Is
there a liability to avoid? If you think putting the Apache links in
our main navigation is a service to our site's users, then that's
something I support. But as of now, I'm not sure those things deserve
more priority.
> The 'ways to get Qpid' page (whcih got a lot harder to find last night)
> mentions source releases, then links to the other pages that has source and
> binary artifacts on it mixed in the same table. We should perhaps split the
> source and binaries into their own sections, or just make it clearer on the
> tables which type of artifact something is. I found it slightly confusing
> that we have 'ways to get Qpid', 'download', and 'releases' pages, and
> think we possibly need to combine them a bit.
It is confusing. I was in transition between two approaches. I'm
working to clear that up.
> Despite my last thought, I think we might want to have a seperate page for
> the maven artifact information (which beceme a lot harder to find since
> last night), as the broker and JCA adapter are or soon will be available
> that way too in addition to the clients. This is an existing shortcoming of
> the current website as much as anything though.
Do you want it to have its own page because it's a larger volume of text?
> 'AMQP Messenger' and 'AMQP Protocol Engine' seems a bit odd to me on the
> front page and component page. We dont use those names on any of the other
It's only the download table that doesn't have the 'AMQP' prefix;
everything else does. In the download table, I ran out of space, so
I trimmed it off.
> pages (such as download). Did we decide Proton needs renamed, or are we
> saying its really the [Qpid] Proton AMQP Messenger? It feels out of place
> with the other component names using Qpid as the qualifier, and weird that
> nothing is using Proton in the name at all.
That falls under the component/toolkit/subproject debate. It has a
lot of names because we've struggled to define what it is.
Our current status as I understand it:
- 'Proton' is a toolkit containing multiple end-user components
- 'AMQP Messenger' is one of those components
- 'AMQP Protocol Engine' is another
The AMQP part was preferred at one point for the way suggested anyone
could use it to add AMQP support to their app.
> It would be useful (i.e I plan to) to make offline html copies of the
> documentation, and we would want to make the documentation match the rest
> of the site as Rob did previously, so I wonder if there really isn't a nice
> font we can use that wont require internet access to display? Or can we
> host that locally instead of hitting the google service?
We can host it, no problem.
> I'd love it if we separate any further logo discussion out into a
> differentthread . As the one who took on the world of pain to get even the
> basic thing we have now, I'd rather decouple that task from this one.
> Supposing we just use your first new effort (the TM could do with being a
> little clearer) or even kept what we have for now, we can change it any
> time and have any required huge mail thread worth of tweaking at that time
> :)
That's fine by me.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Website update
Posted by Justin Ross <jr...@apache.org>.
Thanks for the detailed feedback.
A lot of what you've pointed out have become todos on my list, so I
won't comment further on those.
On Thu, Mar 28, 2013 at 1:13 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> Can we see the source as well as the output?
Yes, certainly. I just finished tidying it up.
https://github.com/ssorj/transom
> What browers are we supporting, and have been tested? I gave it a load in
> IE10, IE9, IE8 (where it presented itself as XML markup instead of
> rendering the page...possibly something to look at given its apparently
> still the most popular IE, accounting for about 1/4 of total traffic by
> some measurements), FF18, FF10, and FF3 (dont ask...as expected it didnt
> quite right but it was still very usable).
Hey! That's better than I might have hoped. I've only been testing
on recent versions of Chrome and Firefox. Looking into the IE8 issue.
I hope we can at least coax it to render as HTML.
> Related, the change from borderless front page to bordered content pages
> everywhere else seems a little strange.
There is an aesthetic issue at the root of this. The front page looks
bad when you have the "what is Qpid" box nested inside the page box.
One of them has to go or it looks very regimented. I can flip it, and
take away the inner box.
> Echoing previous requests for a wider width, even if needs to be a toggle
> option. At least some of the remaining 2/3rds width of my (main) monitor
> would like to be used at times. In terms of smaller devices, it doesnt even
> use all the width on my netbook or phone (in landscape admitedly).
On this one I think it's prioritizing the wrong concerns. Small
screen devices are more and more used for browsing, and they benefit
from a narrower and simpler layout. Big screens, on the other hand,
are wide screens, which naturally accommodate two windows side by
side. Windows (and Gnome) have indeed introduced mouse gestures for
using this. Since 960 is reasonable for small devices, and half of
1920, it is in my opinion the most sensible target.
> homepage is supposed to have a one sentence description defining what the
> Apache Qpid (rather than just Qpid) product is (suggesting maybe we need to
> really sub-project everything if going for this component-based structure)
I don't understand this one yet. What distinction between Apache Qpid
and Qpid are you using?
> and i wouldnt say the message in the box quite covers the requirement, and
> dont know if theyd agree the required links in the footer are really part
> of our 'main' navigation (though they are at least on every page so maybe
> they are the main navigation :p). Etc.
What goal are we serving by pursuing the letter definition of a
correct Apache project? I see the arguable deviation here, but I
don't see the rationale for being highly conformant. The more
important questions, IMO: Is the right information prioritized? Is
there a liability to avoid? If you think putting the Apache links in
our main navigation is a service to our site's users, then that's
something I support. But as of now, I'm not sure those things deserve
more priority.
> The 'ways to get Qpid' page (whcih got a lot harder to find last night)
> mentions source releases, then links to the other pages that has source and
> binary artifacts on it mixed in the same table. We should perhaps split the
> source and binaries into their own sections, or just make it clearer on the
> tables which type of artifact something is. I found it slightly confusing
> that we have 'ways to get Qpid', 'download', and 'releases' pages, and
> think we possibly need to combine them a bit.
It is confusing. I was in transition between two approaches. I'm
working to clear that up.
> Despite my last thought, I think we might want to have a seperate page for
> the maven artifact information (which beceme a lot harder to find since
> last night), as the broker and JCA adapter are or soon will be available
> that way too in addition to the clients. This is an existing shortcoming of
> the current website as much as anything though.
Do you want it to have its own page because it's a larger volume of text?
> 'AMQP Messenger' and 'AMQP Protocol Engine' seems a bit odd to me on the
> front page and component page. We dont use those names on any of the other
It's only the download table that doesn't have the 'AMQP' prefix;
everything else does. In the download table, I ran out of space, so
I trimmed it off.
> pages (such as download). Did we decide Proton needs renamed, or are we
> saying its really the [Qpid] Proton AMQP Messenger? It feels out of place
> with the other component names using Qpid as the qualifier, and weird that
> nothing is using Proton in the name at all.
That falls under the component/toolkit/subproject debate. It has a
lot of names because we've struggled to define what it is.
Our current status as I understand it:
- 'Proton' is a toolkit containing multiple end-user components
- 'AMQP Messenger' is one of those components
- 'AMQP Protocol Engine' is another
The AMQP part was preferred at one point for the way suggested anyone
could use it to add AMQP support to their app.
> It would be useful (i.e I plan to) to make offline html copies of the
> documentation, and we would want to make the documentation match the rest
> of the site as Rob did previously, so I wonder if there really isn't a nice
> font we can use that wont require internet access to display? Or can we
> host that locally instead of hitting the google service?
We can host it, no problem.
> I'd love it if we separate any further logo discussion out into a
> differentthread . As the one who took on the world of pain to get even the
> basic thing we have now, I'd rather decouple that task from this one.
> Supposing we just use your first new effort (the TM could do with being a
> little clearer) or even kept what we have for now, we can change it any
> time and have any required huge mail thread worth of tweaking at that time
> :)
That's fine by me.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Fwd: Website update
Posted by Robbie Gemmell <ro...@gmail.com>.
Re-0including users list, got dropped whenI accidentally cleared the
recipients earlier :)
---------- Forwarded message ----------
From: Robbie Gemmell <ro...@gmail.com>
Date: 28 March 2013 17:01
Subject: Re: Website update
To: "dev@qpid.apache.org" <de...@qpid.apache.org>
First up, it is a vast improvement in many ways, well done.
Next, I'm afraid many comments and/or questions than I intended when I
started this last night :P
Can we see the source as well as the output?
What browers are we supporting, and have been tested? I gave it a load in
IE10, IE9, IE8 (where it presented itself as XML markup instead of
rendering the page...possibly something to look at given its apparently
still the most popular IE, accounting for about 1/4 of total traffic by
some measurements), FF18, FF10, and FF3 (dont ask...as expected it didnt
quite right but it was still very usable).
I'm not a huge fan of the menu a) being on the right and b) disappearing
once you leave the homepage. A persistent (top?) menu might be nice.
Related, the change from borderless front page to bordered content pages
everywhere else seems a little strange.
Echoing previous requests for a wider width, even if needs to be a toggle
option. At least some of the remaining 2/3rds width of my (main) monitor
would like to be used at times. In terms of smaller devices, it doesnt even
use all the width on my netbook or phone (in landscape admitedly).
There are still issues needing fixed relating to the project branding
requirements (http://www.apache.org/foundation/marks/pmcs). Things like:
the first mention of Apache Qpid on every page needs to have a TM, the
homepage is supposed to have a one sentence description defining what the
Apache Qpid (rather than just Qpid) product is (suggesting maybe we need to
really sub-project everything if going for this component-based structure)
and i wouldnt say the message in the box quite covers the requirement, and
dont know if theyd agree the required links in the footer are really part
of our 'main' navigation (though they are at least on every page so maybe
they are the main navigation :p). Etc.
The 'ways to get Qpid' page (whcih got a lot harder to find last night)
mentions source releases, then links to the other pages that has source and
binary artifacts on it mixed in the same table. We should perhaps split the
source and binaries into their own sections, or just make it clearer on the
tables which type of artifact something is. I found it slightly confusing
that we have 'ways to get Qpid', 'download', and 'releases' pages, and
think we possibly need to combine them a bit.
Despite my last thought, I think we might want to have a seperate page for
the maven artifact information (which beceme a lot harder to find since
last night), as the broker and JCA adapter are or soon will be available
that way too in addition to the clients. This is an existing shortcoming of
the current website as much as anything though.
The Past Releases mentioned on the download page probably need to link to
the dist archive for anything past the imediately prior release, if not all
prior releases; most of the links dont work as the redirector script ttries
to point you at a mirror that no longer has the release. Infra dont want
more than the 'current release(s)' being on the mirrors and do clear them
out sometimes, and since we dont maintain multiple version streams that
probably means we should only have a single release in there.
'AMQP Messenger' and 'AMQP Protocol Engine' seems a bit odd to me on the
front page and component page. We dont use those names on any of the other
pages (such as download). Did we decide Proton needs renamed, or are we
saying its really the [Qpid] Proton AMQP Messenger? It feels out of place
with the other component names using Qpid as the qualifier, and weird that
nothing is using Proton in the name at all.
The Qpid JMS page could be clearer that there isnt actually a single JMS
client that supports all the protocol versions but rather two that do so
between them. As a user reading that, im going to be dissapointed when i
get to the download page.
It would be useful (i.e I plan to) to make offline html copies of the
documentation, and we would want to make the documentation match the rest
of the site as Rob did previously, so I wonder if there really isn't a nice
font we can use that wont require internet access to display? Or can we
host that locally instead of hitting the google service?
I'd love it if we separate any further logo discussion out into a
differentthread . As the one who took on the world of pain to get even the
basic thing we have now, I'd rather decouple that task from this one.
Supposing we just use your first new effort (the TM could do with being a
little clearer) or even kept what we have for now, we can change it any
time and have any required huge mail thread worth of tweaking at that time
:)
On 26 March 2013 14:05, Justin Ross <jr...@apache.org> wrote:
> Hi, everyone. It's clearly been too long since my last update!
>
> http://people.apache.org/~jross/transom/2013-03-26/
>
> Previous version: http://people.apache.org/~jross/transom/2013-02-11/
>
> A complete list of changes follows. To summarize: The look and feel
> isn't changed much since last time. There have, however, been
> important changes to (1) expand content at the leaf nodes of the
> existing structure, (2) enhance the navigation, and (3) automate the
> generation of new release content.
>
> I've received some very helpful feedback. Thanks indeed! (Send
> more.) For my next iteration, I plan to try something new: I'm going
> to promote "source modules" (Qpid Java, Qpid C++, Qpid Proton) more on
> the front page. I'm sure this will spark a healthy debate about how
> things work at Qpid, and that's really the point. I think it helps to
> see it presented as a newcomer would see it.
>
> Also, for fun, an alternate logo. This one's probably better for a
> t-shirt:
>
>
> http://people.apache.org/~jross/transom/2013-03-26/images/logo-2-300-300.png
>
> Changes:
>
> - Content
> - Expanded the java broker feature list and added more links to docs
> - Added more links to qpid jms docs
> - Expanded the messaging api example matrix
> - Added links to readmes and source locations to per-language
> example index files
> - Added messaging api reference for dotnet
> - Improved configuration of doxygen output
> - Added news feed and list info links to the mailing lists page
> - Added links to review board to the more resources page
> - Added a note about release cadence to the releases page
> - Added CI section in more resources
> - Navigation
> - Top page navigation is more compact (moving the content higher
> on the page) and fully hierarchical
> - Navigation is no longer manual; it's generated from the site
> layout and plugged into the template
> - The jira search link now focuses the search box when you link to it
> - Added a proton-specific jira goto
> - Internals
> - Automated the process of adding new release content to the site
> - The site code now does site-internal link checking
> - Style
> - Switched to the Roboto Condensed typeface for body text
> - Rounded the corners of the Qpid intro box
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Fwd: Website update
Posted by Robbie Gemmell <ro...@gmail.com>.
Re-0including users list, got dropped whenI accidentally cleared the
recipients earlier :)
---------- Forwarded message ----------
From: Robbie Gemmell <ro...@gmail.com>
Date: 28 March 2013 17:01
Subject: Re: Website update
To: "dev@qpid.apache.org" <de...@qpid.apache.org>
First up, it is a vast improvement in many ways, well done.
Next, I'm afraid many comments and/or questions than I intended when I
started this last night :P
Can we see the source as well as the output?
What browers are we supporting, and have been tested? I gave it a load in
IE10, IE9, IE8 (where it presented itself as XML markup instead of
rendering the page...possibly something to look at given its apparently
still the most popular IE, accounting for about 1/4 of total traffic by
some measurements), FF18, FF10, and FF3 (dont ask...as expected it didnt
quite right but it was still very usable).
I'm not a huge fan of the menu a) being on the right and b) disappearing
once you leave the homepage. A persistent (top?) menu might be nice.
Related, the change from borderless front page to bordered content pages
everywhere else seems a little strange.
Echoing previous requests for a wider width, even if needs to be a toggle
option. At least some of the remaining 2/3rds width of my (main) monitor
would like to be used at times. In terms of smaller devices, it doesnt even
use all the width on my netbook or phone (in landscape admitedly).
There are still issues needing fixed relating to the project branding
requirements (http://www.apache.org/foundation/marks/pmcs). Things like:
the first mention of Apache Qpid on every page needs to have a TM, the
homepage is supposed to have a one sentence description defining what the
Apache Qpid (rather than just Qpid) product is (suggesting maybe we need to
really sub-project everything if going for this component-based structure)
and i wouldnt say the message in the box quite covers the requirement, and
dont know if theyd agree the required links in the footer are really part
of our 'main' navigation (though they are at least on every page so maybe
they are the main navigation :p). Etc.
The 'ways to get Qpid' page (whcih got a lot harder to find last night)
mentions source releases, then links to the other pages that has source and
binary artifacts on it mixed in the same table. We should perhaps split the
source and binaries into their own sections, or just make it clearer on the
tables which type of artifact something is. I found it slightly confusing
that we have 'ways to get Qpid', 'download', and 'releases' pages, and
think we possibly need to combine them a bit.
Despite my last thought, I think we might want to have a seperate page for
the maven artifact information (which beceme a lot harder to find since
last night), as the broker and JCA adapter are or soon will be available
that way too in addition to the clients. This is an existing shortcoming of
the current website as much as anything though.
The Past Releases mentioned on the download page probably need to link to
the dist archive for anything past the imediately prior release, if not all
prior releases; most of the links dont work as the redirector script ttries
to point you at a mirror that no longer has the release. Infra dont want
more than the 'current release(s)' being on the mirrors and do clear them
out sometimes, and since we dont maintain multiple version streams that
probably means we should only have a single release in there.
'AMQP Messenger' and 'AMQP Protocol Engine' seems a bit odd to me on the
front page and component page. We dont use those names on any of the other
pages (such as download). Did we decide Proton needs renamed, or are we
saying its really the [Qpid] Proton AMQP Messenger? It feels out of place
with the other component names using Qpid as the qualifier, and weird that
nothing is using Proton in the name at all.
The Qpid JMS page could be clearer that there isnt actually a single JMS
client that supports all the protocol versions but rather two that do so
between them. As a user reading that, im going to be dissapointed when i
get to the download page.
It would be useful (i.e I plan to) to make offline html copies of the
documentation, and we would want to make the documentation match the rest
of the site as Rob did previously, so I wonder if there really isn't a nice
font we can use that wont require internet access to display? Or can we
host that locally instead of hitting the google service?
I'd love it if we separate any further logo discussion out into a
differentthread . As the one who took on the world of pain to get even the
basic thing we have now, I'd rather decouple that task from this one.
Supposing we just use your first new effort (the TM could do with being a
little clearer) or even kept what we have for now, we can change it any
time and have any required huge mail thread worth of tweaking at that time
:)
On 26 March 2013 14:05, Justin Ross <jr...@apache.org> wrote:
> Hi, everyone. It's clearly been too long since my last update!
>
> http://people.apache.org/~jross/transom/2013-03-26/
>
> Previous version: http://people.apache.org/~jross/transom/2013-02-11/
>
> A complete list of changes follows. To summarize: The look and feel
> isn't changed much since last time. There have, however, been
> important changes to (1) expand content at the leaf nodes of the
> existing structure, (2) enhance the navigation, and (3) automate the
> generation of new release content.
>
> I've received some very helpful feedback. Thanks indeed! (Send
> more.) For my next iteration, I plan to try something new: I'm going
> to promote "source modules" (Qpid Java, Qpid C++, Qpid Proton) more on
> the front page. I'm sure this will spark a healthy debate about how
> things work at Qpid, and that's really the point. I think it helps to
> see it presented as a newcomer would see it.
>
> Also, for fun, an alternate logo. This one's probably better for a
> t-shirt:
>
>
> http://people.apache.org/~jross/transom/2013-03-26/images/logo-2-300-300.png
>
> Changes:
>
> - Content
> - Expanded the java broker feature list and added more links to docs
> - Added more links to qpid jms docs
> - Expanded the messaging api example matrix
> - Added links to readmes and source locations to per-language
> example index files
> - Added messaging api reference for dotnet
> - Improved configuration of doxygen output
> - Added news feed and list info links to the mailing lists page
> - Added links to review board to the more resources page
> - Added a note about release cadence to the releases page
> - Added CI section in more resources
> - Navigation
> - Top page navigation is more compact (moving the content higher
> on the page) and fully hierarchical
> - Navigation is no longer manual; it's generated from the site
> layout and plugged into the template
> - The jira search link now focuses the search box when you link to it
> - Added a proton-specific jira goto
> - Internals
> - Automated the process of adding new release content to the site
> - The site code now does site-internal link checking
> - Style
> - Switched to the Roboto Condensed typeface for body text
> - Rounded the corners of the Qpid intro box
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Website update
Posted by Robbie Gemmell <ro...@gmail.com>.
First up, it is a vast improvement in many ways, well done.
Next, I'm afraid many comments and/or questions than I intended when I
started this last night :P
Can we see the source as well as the output?
What browers are we supporting, and have been tested? I gave it a load in
IE10, IE9, IE8 (where it presented itself as XML markup instead of
rendering the page...possibly something to look at given its apparently
still the most popular IE, accounting for about 1/4 of total traffic by
some measurements), FF18, FF10, and FF3 (dont ask...as expected it didnt
quite right but it was still very usable).
I'm not a huge fan of the menu a) being on the right and b) disappearing
once you leave the homepage. A persistent (top?) menu might be nice.
Related, the change from borderless front page to bordered content pages
everywhere else seems a little strange.
Echoing previous requests for a wider width, even if needs to be a toggle
option. At least some of the remaining 2/3rds width of my (main) monitor
would like to be used at times. In terms of smaller devices, it doesnt even
use all the width on my netbook or phone (in landscape admitedly).
There are still issues needing fixed relating to the project branding
requirements (http://www.apache.org/foundation/marks/pmcs). Things like:
the first mention of Apache Qpid on every page needs to have a TM, the
homepage is supposed to have a one sentence description defining what the
Apache Qpid (rather than just Qpid) product is (suggesting maybe we need to
really sub-project everything if going for this component-based structure)
and i wouldnt say the message in the box quite covers the requirement, and
dont know if theyd agree the required links in the footer are really part
of our 'main' navigation (though they are at least on every page so maybe
they are the main navigation :p). Etc.
The 'ways to get Qpid' page (whcih got a lot harder to find last night)
mentions source releases, then links to the other pages that has source and
binary artifacts on it mixed in the same table. We should perhaps split the
source and binaries into their own sections, or just make it clearer on the
tables which type of artifact something is. I found it slightly confusing
that we have 'ways to get Qpid', 'download', and 'releases' pages, and
think we possibly need to combine them a bit.
Despite my last thought, I think we might want to have a seperate page for
the maven artifact information (which beceme a lot harder to find since
last night), as the broker and JCA adapter are or soon will be available
that way too in addition to the clients. This is an existing shortcoming of
the current website as much as anything though.
The Past Releases mentioned on the download page probably need to link to
the dist archive for anything past the imediately prior release, if not all
prior releases; most of the links dont work as the redirector script ttries
to point you at a mirror that no longer has the release. Infra dont want
more than the 'current release(s)' being on the mirrors and do clear them
out sometimes, and since we dont maintain multiple version streams that
probably means we should only have a single release in there.
'AMQP Messenger' and 'AMQP Protocol Engine' seems a bit odd to me on the
front page and component page. We dont use those names on any of the other
pages (such as download). Did we decide Proton needs renamed, or are we
saying its really the [Qpid] Proton AMQP Messenger? It feels out of place
with the other component names using Qpid as the qualifier, and weird that
nothing is using Proton in the name at all.
The Qpid JMS page could be clearer that there isnt actually a single JMS
client that supports all the protocol versions but rather two that do so
between them. As a user reading that, im going to be dissapointed when i
get to the download page.
It would be useful (i.e I plan to) to make offline html copies of the
documentation, and we would want to make the documentation match the rest
of the site as Rob did previously, so I wonder if there really isn't a nice
font we can use that wont require internet access to display? Or can we
host that locally instead of hitting the google service?
I'd love it if we separate any further logo discussion out into a
differentthread . As the one who took on the world of pain to get even the
basic thing we have now, I'd rather decouple that task from this one.
Supposing we just use your first new effort (the TM could do with being a
little clearer) or even kept what we have for now, we can change it any
time and have any required huge mail thread worth of tweaking at that time
:)
On 26 March 2013 14:05, Justin Ross <jr...@apache.org> wrote:
> Hi, everyone. It's clearly been too long since my last update!
>
> http://people.apache.org/~jross/transom/2013-03-26/
>
> Previous version: http://people.apache.org/~jross/transom/2013-02-11/
>
> A complete list of changes follows. To summarize: The look and feel
> isn't changed much since last time. There have, however, been
> important changes to (1) expand content at the leaf nodes of the
> existing structure, (2) enhance the navigation, and (3) automate the
> generation of new release content.
>
> I've received some very helpful feedback. Thanks indeed! (Send
> more.) For my next iteration, I plan to try something new: I'm going
> to promote "source modules" (Qpid Java, Qpid C++, Qpid Proton) more on
> the front page. I'm sure this will spark a healthy debate about how
> things work at Qpid, and that's really the point. I think it helps to
> see it presented as a newcomer would see it.
>
> Also, for fun, an alternate logo. This one's probably better for a
> t-shirt:
>
>
> http://people.apache.org/~jross/transom/2013-03-26/images/logo-2-300-300.png
>
> Changes:
>
> - Content
> - Expanded the java broker feature list and added more links to docs
> - Added more links to qpid jms docs
> - Expanded the messaging api example matrix
> - Added links to readmes and source locations to per-language
> example index files
> - Added messaging api reference for dotnet
> - Improved configuration of doxygen output
> - Added news feed and list info links to the mailing lists page
> - Added links to review board to the more resources page
> - Added a note about release cadence to the releases page
> - Added CI section in more resources
> - Navigation
> - Top page navigation is more compact (moving the content higher
> on the page) and fully hierarchical
> - Navigation is no longer manual; it's generated from the site
> layout and plugged into the template
> - The jira search link now focuses the search box when you link to it
> - Added a proton-specific jira goto
> - Internals
> - Automated the process of adding new release content to the site
> - The site code now does site-internal link checking
> - Style
> - Switched to the Roboto Condensed typeface for body text
> - Rounded the corners of the Qpid intro box
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Website update
Posted by Rajith Attapattu <ra...@gmail.com>.
I really like the box as well. It's clear and concise.
I like the fact that the layout is fluid, so it should work well on
different devices.
(William Henry has every device under the Sun, I usually enlist him to
help me with that).
The links on right hand side is nice to have from the main page. I
especially like the go to Bug thing.
However we need to strike a balance btw providing enough information
from the main page and overcrowding.
I'm not too crazy on the logo and the color scheme, but then again
those are all very personal choices.
The most important things are the layout and the content, and I'm
quite happy with that.
Thanks again for working on this. I appreciate your effort.
Rajith
On Tue, Mar 26, 2013 at 12:00 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/26/2013 02:05 PM, Justin Ross wrote:
>>
>> For my next iteration, I plan to try something new: I'm going
>> to promote "source modules" (Qpid Java, Qpid C++, Qpid Proton) more on
>> the front page.
>
>
> I don't think that is the view that we should be presenting to users. While
> it does match the release artefacts of course, I don't think that is
> necessarily the clearest logical structure and I think its the logical
> structure that the website should emphasise, mapping that as appropriate to
> JIRA, svn, source releases etc.
>
> My interpretation of the current structure is as follows:
>
> Qpid Proton
> - protocol engine
> - messenger
> - available in java or c, with python, ruby and perl wrappers
>
> Other client libraries:
>
> Qpid JMS
>
> Qpid Messaging
> - c++
> - python
> - perl, ruby
>
> Brokers:
>
> - c++ broker (available on windows and linux)
> - java broker
> - broker management tools
>
> (I would pull management tools out of the 'broker' category when they can be
> used against other brokers or other things).
>
> I would have these categories on the front page in some way (with more
> detail on each and indeed on each aspect or sub-component) available via
> links.
>
> I very much like the large box explaining the purpose of the project. I also
> like the items under the 'project' category on the current page.The
> 'project' however is in my view distinct from the structure above, as it is
> overarching. I think I'd pull the blogs into this as well, also the users
> list as the project wide discussion forum.
>
> Much of the other stuff on the right hand side of the page I would move off
> the front page. While I see the value of having some easy links, I think it
> is a little noisy and I think it could be more clearly done in the context
> of the different components.
>
> So e.g. instead of having download links for Qpid 0.20, Proton 0.4 etc I
> would have have a single download link, and on the page that takes you to,
> break things out along the same lines as the structure above, with links to
> both the latest release, JIRA, any additional lists of interest etc. (We
> also need a documentation link on the front page.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Justin Ross <jr...@apache.org>.
It's interesting. You and Gordon both feel that way about
first-person pronouns in the site text. I'll change it to "everyone",
no problem.
On Thu, Mar 28, 2013 at 11:10 AM, Steve Huston <sh...@riverace.com> wrote:
> This looks really great, Justin! My only nit at this time is in the box at
> the top left of the main page, 2nd para "It makes it possible for us and
> others to build a diverse, coherent messaging ecosystem." - "us and
> others" is a little off-putting for some reason - maybe something more
> like "It makes it possible for everyone to build diverse, coherent
> messaging ecosystems." ?
>
> I'd also be in favor of going with this design in the live site.
>
> -Steve
>
> On 3/28/13 8:10 AM, "Justin Ross" <jr...@apache.org> wrote:
>
>>I've tried to incorporate some of the helpful suggestions on this
>>thread. Please take a look.
>>
>> http://people.apache.org/~jross/transom/head/index.html
>>
>>(Watch out, this is still very work-in-progress.)
>>
>>In addition to the front page changes, take a look at the reformulated
>>download page.
>>
>>Thanks!
>>Justin
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by "Weston M. Price" <wp...@redhat.com>.
On Mar 28, 2013, at 10:58 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/28/2013 02:29 PM, Rafael Schloming wrote:
>> I like this a lot. It would get my +1 as being strictly superior to the
>> current site.
>
> Likewise, great job Justin!
+1 Great work all around
>
> (I'll go through each page more closely and suggest some minor wording changes, but I would be happy to move to this regardless).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Gordon Sim <gs...@redhat.com>.
On 03/28/2013 02:29 PM, Rafael Schloming wrote:
> I like this a lot. It would get my +1 as being strictly superior to the
> current site.
Likewise, great job Justin!
(I'll go through each page more closely and suggest some minor wording
changes, but I would be happy to move to this regardless).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Rafael Schloming <rh...@alum.mit.edu>.
I like this a lot. It would get my +1 as being strictly superior to the
current site.
I think this strikes a good balance between projecting where we want to go
and reflecting the somewhat transitional structure of our current
offerings. I do think we need to maintain momentum and continue to work
both on the site itself and on reformulating our artifacts/offerings along
the lines discussed earlier in the thread, but I would be happy to update
the main site based on this.
--Rafael
On Thu, Mar 28, 2013 at 8:10 AM, Justin Ross <jr...@apache.org> wrote:
> I've tried to incorporate some of the helpful suggestions on this
> thread. Please take a look.
>
> http://people.apache.org/~jross/transom/head/index.html
>
> (Watch out, this is still very work-in-progress.)
>
> In addition to the front page changes, take a look at the reformulated
> download page.
>
> Thanks!
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Website update
Posted by Steve Huston <sh...@riverace.com>.
This looks really great, Justin! My only nit at this time is in the box at
the top left of the main page, 2nd para "It makes it possible for us and
others to build a diverse, coherent messaging ecosystem." - "us and
others" is a little off-putting for some reason - maybe something more
like "It makes it possible for everyone to build diverse, coherent
messaging ecosystems." ?
I'd also be in favor of going with this design in the live site.
-Steve
On 3/28/13 8:10 AM, "Justin Ross" <jr...@apache.org> wrote:
>I've tried to incorporate some of the helpful suggestions on this
>thread. Please take a look.
>
> http://people.apache.org/~jross/transom/head/index.html
>
>(Watch out, this is still very work-in-progress.)
>
>In addition to the front page changes, take a look at the reformulated
>download page.
>
>Thanks!
>Justin
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Justin Ross <jr...@apache.org>.
I've tried to incorporate some of the helpful suggestions on this
thread. Please take a look.
http://people.apache.org/~jross/transom/head/index.html
(Watch out, this is still very work-in-progress.)
In addition to the front page changes, take a look at the reformulated
download page.
Thanks!
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Gordon Sim <gs...@redhat.com>.
On 03/27/2013 01:34 PM, Rob Godfrey wrote:
> So one question I would have is whether two implementations of the same API
> should not actually be the same component... Should we not just have a Qpid
> JMS component that currently has two released artefacts? Similarly the
> Qpid Messaging API may have a pure python implementation and the
> C++/Swigged versions. This seems analogous to how Proton is working with
> both a Java and a C implementation.
Yes, you are probably right. I personally tend to view the c++ and
python messaging clients as two distinct components as though they aim
to be similar there are still significant differences at present.
The most important question here is what the future plans are for the
pure python implementation, particularly with regard to AMQP 1.0
support. It's probably true that however we answer that, long term there
is one component here with different artefacts within it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Rob Godfrey <ro...@gmail.com>.
On 27 March 2013 14:26, Gordon Sim <gs...@redhat.com> wrote:
> On 03/26/2013 08:06 PM, Rob Godfrey wrote:
>
>> I think in general we suffer because we haven't properly thought about
>> what
>> our "components" are and what it means to be a component. Proton is a
>> component and has a sensible location in our repo, and its own release
>> cycle and JIRA project. I tend to think long term other components (or
>> groups of components) should follow this pattern.
>>
>
> Good points. I personally am not convinced that each component needs its
> own JIRA, or its own release cycle. However I do agree that our current
> source layout and release artefacts do not align well with logical
> components.
I don't think there need to be hard and fast rules about this. Having a
separate release cycle is difficult when using the same JIRA system as the
releases are JIRA project wide. There are components that will probably
naturally synchronize their release cycles and as such that would be
fine... OTOH there's definitely a case to be made of not artificially
trying to synchronize releases... Our time based release schedule can lead
to somewhat
> I would also concede the exact set of components is not as clear as it
> needs to be.
>
> So, other than proton, what are the components? I think the key property
> of a component is that it is self-contained and independent of any other
> particular component. The components that seem most obvious to me at
> present are:
>
> * JMS client[1]
> * qpid::messaging client in c++
> * qpid.messaging client in python[2]
> * c++ broker
> * java broker
>
> There is probably a component or two among the various management tools.
> Some are very toed to one broker, which to some extent violates my rule.
> Probably the clearest component here is Fraser's new GUI management tool,
> since that can now be used against either broker. The command line tools
> for c++ broker[3] are perhaps best viewed as a sub-component of the c++
> broker for now (though some of them may now work against the java broker
> when Fraser's adapter is in place).
>
> The various swig and c# wrappers around the qpid::messaging c++ client are
> in my view sub components of the c++ client at present.
>
>
So one question I would have is whether two implementations of the same API
should not actually be the same component... Should we not just have a Qpid
JMS component that currently has two released artefacts? Similarly the
Qpid Messaging API may have a pure python implementation and the
C++/Swigged versions. This seems analogous to how Proton is working with
both a Java and a C implementation.
> I am not keen to lump changes to the svn, build and packaging in with
> changes to the website. That is exactly why we never make progress because
> the scope outgrows the available resource. We can get the website structure
> and layout right, map it to the existing 'broken' structures and then as a
> separate step(s) tackle any changes to structure. I don't oppose any
> changes there, I just don't want the website update to be dependent on
> their completion. As Rob said earlier, having a new website in place for
> the 0.22 would be really great.
>
>
I agree i don't want to hold up the website change for an svn
reorganisation, but if we are looking to do an svn reorganisation the
obvious time to do it would be immediately after a release.
-- Rob
--Gordon.
>
> [1] At present we sort of have two of these, but I think long term there
> should be only one, even if it has quite divergent codepaths for different
> versions of the protocol. Alternatively we could have one for AMQP 1.0 and
> another tucked away somewhere for legacy versions).
>
> [2] Though we need to decide what we are doing for AMQP 1.0 here. If there
> is insufficient resource available to convert the native client to 1.0, we
> could consider the python swig wrapper round the c++ as the alternative
> for transition to 1.0.
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Website update
Posted by Gordon Sim <gs...@redhat.com>.
On 03/26/2013 08:06 PM, Rob Godfrey wrote:
> I think in general we suffer because we haven't properly thought about what
> our "components" are and what it means to be a component. Proton is a
> component and has a sensible location in our repo, and its own release
> cycle and JIRA project. I tend to think long term other components (or
> groups of components) should follow this pattern.
Good points. I personally am not convinced that each component needs its
own JIRA, or its own release cycle. However I do agree that our current
source layout and release artefacts do not align well with logical
components. I would also concede the exact set of components is not as
clear as it needs to be.
So, other than proton, what are the components? I think the key property
of a component is that it is self-contained and independent of any other
particular component. The components that seem most obvious to me at
present are:
* JMS client[1]
* qpid::messaging client in c++
* qpid.messaging client in python[2]
* c++ broker
* java broker
There is probably a component or two among the various management tools.
Some are very toed to one broker, which to some extent violates my rule.
Probably the clearest component here is Fraser's new GUI management
tool, since that can now be used against either broker. The command line
tools for c++ broker[3] are perhaps best viewed as a sub-component of
the c++ broker for now (though some of them may now work against the
java broker when Fraser's adapter is in place).
The various swig and c# wrappers around the qpid::messaging c++ client
are in my view sub components of the c++ client at present.
I am not keen to lump changes to the svn, build and packaging in with
changes to the website. That is exactly why we never make progress
because the scope outgrows the available resource. We can get the
website structure and layout right, map it to the existing 'broken'
structures and then as a separate step(s) tackle any changes to
structure. I don't oppose any changes there, I just don't want the
website update to be dependent on their completion. As Rob said earlier,
having a new website in place for the 0.22 would be really great.
--Gordon.
[1] At present we sort of have two of these, but I think long term there
should be only one, even if it has quite divergent codepaths for
different versions of the protocol. Alternatively we could have one for
AMQP 1.0 and another tucked away somewhere for legacy versions).
[2] Though we need to decide what we are doing for AMQP 1.0 here. If
there is insufficient resource available to convert the native client to
1.0, we could consider the python swig wrapper round the c++ as the
alternative for transition to 1.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Rafael Schloming <rh...@alum.mit.edu>.
So I have a bunch of thoughts on this thread. They are a bit scattered, but
I'll try to consolidate here. Apologies for the clumsy organization of this
post.
Firstly, in response to Gordon's "user centric view" comments. I do agree
we need to have a user centric view, however what is suggested doesn't
strike me as a user centric view. It reads to me more like a component
centric view where the components are aspirational, i.e. what we would like
the components to be rather than what they currently are:
Qpid Proton
> - protocol engine
> - messenger
> - available in java or c, with python, ruby and perl wrappers
>
> Other client libraries:
>
> Qpid JMS
>
> Qpid Messaging
> - c++
> - python
> - perl, ruby
>
> Brokers:
>
> - c++ broker (available on windows and linux)
> - java broker
> - broker management tools
>
In my mind, a truly user centric view would be focusing on what users
actually want to do. For example I can imagine having a very simple top
level division into two categories: "Building AMQP Applications" and
"Deploying AMQP Networks".
I'm just thinking out loud here, and there may well be a
better/snapper/more succinct way to express these categories, but what I'm
driving at here is breaking things down very broadly into two different
usage scenarios, the former being "I want to write code (or I have a body
of existing code) and I want to make it speak AMQP." The latter being a set
of tools/servers/brokers/proxies/intermediaries/services/etc that already
speak AMQP and I can deploy them into my network without having to write
any code.
I think from these two categories you could then crosslink into a more
component oriented view that explains how a given component might be of
use. I think this may roughly be what the "APIs" and "Brokers" categories
on the current page are going for, but I feel like the former is a bit
esoteric as the name and hard to map to the scenario, and the latter is a
bit too specific. There are more than just Brokers involved in an AMQP
Networks.
Now for what might seem like a bit of a departure, I have to say I am
+1000000 on Rob's suggestion to break down the monolithic qpid tree into
smaller independently releasable components alongside Proton. Having worked
through a number of both qpid releases and proton releases, I can
confidently say the difference between the two (monolithic vs small) is
night and day. It is *really* difficult to understate the huge advantages
of having a simple/nimple/agile lightweight release process. I really think
we should do this along with the web site changes above.
In my view these issue are really tied together. I feel about the web site
the same way I feel about README files. If the README is more than 5 or 10
lines long, 50% of which should be marketing, then the build system/src
organization/etc is broken and we should continue to iterate until we have
achieved that level of simple/compelling README and web site. In fact I
would go so far as to say we shouldn't rev the qpid version to 1.0 until we
do this breakdown, and I'd personally like to both do both of those things
ASAP.
--Rafael
On Tue, Mar 26, 2013 at 4:06 PM, Rob Godfrey <ro...@gmail.com>wrote:
> On 26 March 2013 19:13, Gordon Sim <gs...@redhat.com> wrote:
>
> > On 03/26/2013 05:56 PM, Justin Ross wrote:
> >
> >> (A little trouble with my list subscription, so I'm using nabble to
> >> reply.)
> >>
> >> "I would have these categories on the front page in some way (with more
> >> detail on each and indeed on each aspect or sub-component) available via
> >> links."
> >>
> >> This suggests that the categories you listed are not now present on the
> >> front page.
> >>
> >
> > Sorry, I didn't mean to suggest they weren't present. I was responding to
> > the 'next iteration' plans.
> >
> >
> I agree with Gordon that the user / requirement centric view rather than
> the source-code organisation / release artefact point of view makes sense
> for the front page. It may well be that such a view may point us in a
> direction of changing our project organisation to better reflect how users
> want to use the components within the Qpid project.
>
>
> >
> > I'm confused because I think they are (APIs, Brokers, Proton).
> >> Is the trouble that some of Proton's APIs are mixed into the API group?
> >>
> >> I think a user-centric view focuses on the immediate thing people use,
> >> which
> >> is an API or a server.
> >>
> >
> > In general I agree. I think proton is a 'toolkit' and I think that is
> also
> > something that users care about.
> >
> >
> The "toolkit" thing is interesting and perhaps points to a third category.
> Personally I wouldn't have an issue in having the same component linked to
> from multiple "use cases" on the front page. Proton is providing APIs via
> Messenger, but it is also a toolkit.
>
>
> >
> > Those are the independently usable parts, and so
> >> they should be first class in the logical presentation. Proton doesn't
> >> fit
> >> in this scheme.
> >>
> >> Proton doesn't fit because it's a container of multiple end-user parts,
> >> just
> >> as our cpp (broker, messaging api) and java (broker, jms) trees are.
> >>
> >
> > The difference for me is that the combination of protocol engine and
> > messenger in to a single proton toolkit is deliberate whereas the
> > collection of clients and brokers for c++ and java respectively is
> somewhat
> > accidental and driven by the convenience of having them share certain
> > common code.
> >
> >
> >
> So I think the division into "APIs" and "Brokers" seems a little
> incomplete. A Management tool is neither an API nor a Broker... Similarly
> if we start building proxies, routers, "storage nodes" etc these will not
> be brokers. I don't want us to give the impression that Qpid is only about
> APIs and Brokers.
>
> I also wonder about categorizing QMF as an "API"... I tend to think of it
> as an application stack built on top of AMQP (or actually on top of Qpid).
> I think it is a little confusing to list it as a peer of Messenger, JMS or
> the Messaging API. I might be tempted to put it into an "Extras" or
> "Other" category. It's also pretty Qpid (C++) specific right now (though
> thanks to Fraser's great work it should soon be available for Java too)...
> it's not a generic AMQP (1.0) API as we expect the others to be. It won't
> work as a management framework for an AMQP 1.0 broker from another vendor.
>
>
> > "Much of the other stuff on the right hand side of the page I would move
> >> off the front page. While I see the value of having some easy links, I
> >> think it is a little noisy and I think it could be more clearly done in
> >> the context of the different components."
> >>
> >> I could see doing that. Note, though, that the stuff on the right does
> >> not
> >> naturally hang off the categories you described (for example, "other
> >> client
> >> libraries") because they are really operational things, and are
> therefore
> >> tied to how our source modules are organized. To map them onto
> >> proton+otherclientlibs+brokers would be very synthetic.
> >>
> >
> > Not sure what you mean by synthetic. I agree certainly that the svn
> layout
> > doesn't represent the logical structure I laid out and neither do the
> > release artefacts in some cases. However what I meant was that you could
> > provide context specific notes or links if desired. E.g. I can provide an
> > svn ref to the cpp directory for the c++ broker and for the c++ version
> of
> > qpid::messaging and perhaps explain the two are shipped together.
> >
> >
> >
> I tend to agree that the right hand side of the main page is over fussy
> (and it is somewhat surprising when clicking through to a child page that
> suddenly the breadcrumb trail is the only remaining navigational element...
> where did my sidebar go?)
>
> I think in general we suffer because we haven't properly thought about what
> our "components" are and what it means to be a component. Proton is a
> component and has a sensible location in our repo, and its own release
> cycle and JIRA project. I tend to think long term other components (or
> groups of components) should follow this pattern.
>
> At the moment Proton sticks out as "special" because it is the only
> component doing things "properly"... it might help us if we though about
> where we want to be with other components and designed to that rather than
> the mess (IMHO) that we have now. Perhaps we can even make some progress
> on moving towards that organisation?
>
> -- Rob
>
Re: Website update
Posted by Rob Godfrey <ro...@gmail.com>.
On 26 March 2013 19:13, Gordon Sim <gs...@redhat.com> wrote:
> On 03/26/2013 05:56 PM, Justin Ross wrote:
>
>> (A little trouble with my list subscription, so I'm using nabble to
>> reply.)
>>
>> "I would have these categories on the front page in some way (with more
>> detail on each and indeed on each aspect or sub-component) available via
>> links."
>>
>> This suggests that the categories you listed are not now present on the
>> front page.
>>
>
> Sorry, I didn't mean to suggest they weren't present. I was responding to
> the 'next iteration' plans.
>
>
I agree with Gordon that the user / requirement centric view rather than
the source-code organisation / release artefact point of view makes sense
for the front page. It may well be that such a view may point us in a
direction of changing our project organisation to better reflect how users
want to use the components within the Qpid project.
>
> I'm confused because I think they are (APIs, Brokers, Proton).
>> Is the trouble that some of Proton's APIs are mixed into the API group?
>>
>> I think a user-centric view focuses on the immediate thing people use,
>> which
>> is an API or a server.
>>
>
> In general I agree. I think proton is a 'toolkit' and I think that is also
> something that users care about.
>
>
The "toolkit" thing is interesting and perhaps points to a third category.
Personally I wouldn't have an issue in having the same component linked to
from multiple "use cases" on the front page. Proton is providing APIs via
Messenger, but it is also a toolkit.
>
> Those are the independently usable parts, and so
>> they should be first class in the logical presentation. Proton doesn't
>> fit
>> in this scheme.
>>
>> Proton doesn't fit because it's a container of multiple end-user parts,
>> just
>> as our cpp (broker, messaging api) and java (broker, jms) trees are.
>>
>
> The difference for me is that the combination of protocol engine and
> messenger in to a single proton toolkit is deliberate whereas the
> collection of clients and brokers for c++ and java respectively is somewhat
> accidental and driven by the convenience of having them share certain
> common code.
>
>
>
So I think the division into "APIs" and "Brokers" seems a little
incomplete. A Management tool is neither an API nor a Broker... Similarly
if we start building proxies, routers, "storage nodes" etc these will not
be brokers. I don't want us to give the impression that Qpid is only about
APIs and Brokers.
I also wonder about categorizing QMF as an "API"... I tend to think of it
as an application stack built on top of AMQP (or actually on top of Qpid).
I think it is a little confusing to list it as a peer of Messenger, JMS or
the Messaging API. I might be tempted to put it into an "Extras" or
"Other" category. It's also pretty Qpid (C++) specific right now (though
thanks to Fraser's great work it should soon be available for Java too)...
it's not a generic AMQP (1.0) API as we expect the others to be. It won't
work as a management framework for an AMQP 1.0 broker from another vendor.
> "Much of the other stuff on the right hand side of the page I would move
>> off the front page. While I see the value of having some easy links, I
>> think it is a little noisy and I think it could be more clearly done in
>> the context of the different components."
>>
>> I could see doing that. Note, though, that the stuff on the right does
>> not
>> naturally hang off the categories you described (for example, "other
>> client
>> libraries") because they are really operational things, and are therefore
>> tied to how our source modules are organized. To map them onto
>> proton+otherclientlibs+brokers would be very synthetic.
>>
>
> Not sure what you mean by synthetic. I agree certainly that the svn layout
> doesn't represent the logical structure I laid out and neither do the
> release artefacts in some cases. However what I meant was that you could
> provide context specific notes or links if desired. E.g. I can provide an
> svn ref to the cpp directory for the c++ broker and for the c++ version of
> qpid::messaging and perhaps explain the two are shipped together.
>
>
>
I tend to agree that the right hand side of the main page is over fussy
(and it is somewhat surprising when clicking through to a child page that
suddenly the breadcrumb trail is the only remaining navigational element...
where did my sidebar go?)
I think in general we suffer because we haven't properly thought about what
our "components" are and what it means to be a component. Proton is a
component and has a sensible location in our repo, and its own release
cycle and JIRA project. I tend to think long term other components (or
groups of components) should follow this pattern.
At the moment Proton sticks out as "special" because it is the only
component doing things "properly"... it might help us if we though about
where we want to be with other components and designed to that rather than
the mess (IMHO) that we have now. Perhaps we can even make some progress
on moving towards that organisation?
-- Rob
Re: Website update
Posted by Gordon Sim <gs...@redhat.com>.
On 03/26/2013 05:56 PM, Justin Ross wrote:
> (A little trouble with my list subscription, so I'm using nabble to reply.)
>
> "I would have these categories on the front page in some way (with more
> detail on each and indeed on each aspect or sub-component) available via
> links."
>
> This suggests that the categories you listed are not now present on the
> front page.
Sorry, I didn't mean to suggest they weren't present. I was responding
to the 'next iteration' plans.
> I'm confused because I think they are (APIs, Brokers, Proton).
> Is the trouble that some of Proton's APIs are mixed into the API group?
>
> I think a user-centric view focuses on the immediate thing people use, which
> is an API or a server.
In general I agree. I think proton is a 'toolkit' and I think that is
also something that users care about.
> Those are the independently usable parts, and so
> they should be first class in the logical presentation. Proton doesn't fit
> in this scheme.
>
> Proton doesn't fit because it's a container of multiple end-user parts, just
> as our cpp (broker, messaging api) and java (broker, jms) trees are.
The difference for me is that the combination of protocol engine and
messenger in to a single proton toolkit is deliberate whereas the
collection of clients and brokers for c++ and java respectively is
somewhat accidental and driven by the convenience of having them share
certain common code.
> "Much of the other stuff on the right hand side of the page I would move
> off the front page. While I see the value of having some easy links, I
> think it is a little noisy and I think it could be more clearly done in
> the context of the different components."
>
> I could see doing that. Note, though, that the stuff on the right does not
> naturally hang off the categories you described (for example, "other client
> libraries") because they are really operational things, and are therefore
> tied to how our source modules are organized. To map them onto
> proton+otherclientlibs+brokers would be very synthetic.
Not sure what you mean by synthetic. I agree certainly that the svn
layout doesn't represent the logical structure I laid out and neither do
the release artefacts in some cases. However what I meant was that you
could provide context specific notes or links if desired. E.g. I can
provide an svn ref to the cpp directory for the c++ broker and for the
c++ version of qpid::messaging and perhaps explain the two are shipped
together.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Justin Ross <jr...@apache.org>.
(A little trouble with my list subscription, so I'm using nabble to reply.)
"I would have these categories on the front page in some way (with more
detail on each and indeed on each aspect or sub-component) available via
links."
This suggests that the categories you listed are not now present on the
front page. I'm confused because I think they are (APIs, Brokers, Proton).
Is the trouble that some of Proton's APIs are mixed into the API group?
I think a user-centric view focuses on the immediate thing people use, which
is an API or a server. Those are the independently usable parts, and so
they should be first class in the logical presentation. Proton doesn't fit
in this scheme.
Proton doesn't fit because it's a container of multiple end-user parts, just
as our cpp (broker, messaging api) and java (broker, jms) trees are.
"Much of the other stuff on the right hand side of the page I would move
off the front page. While I see the value of having some easy links, I
think it is a little noisy and I think it could be more clearly done in
the context of the different components."
I could see doing that. Note, though, that the stuff on the right does not
naturally hang off the categories you described (for example, "other client
libraries") because they are really operational things, and are therefore
tied to how our source modules are organized. To map them onto
proton+otherclientlibs+brokers would be very synthetic.
Justin
--
View this message in context: http://qpid.2158936.n2.nabble.com/Website-update-tp7590445p7590469.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Website update
Posted by Gordon Sim <gs...@redhat.com>.
On 03/26/2013 02:05 PM, Justin Ross wrote:
> For my next iteration, I plan to try something new: I'm going
> to promote "source modules" (Qpid Java, Qpid C++, Qpid Proton) more on
> the front page.
I don't think that is the view that we should be presenting to users.
While it does match the release artefacts of course, I don't think that
is necessarily the clearest logical structure and I think its the
logical structure that the website should emphasise, mapping that as
appropriate to JIRA, svn, source releases etc.
My interpretation of the current structure is as follows:
Qpid Proton
- protocol engine
- messenger
- available in java or c, with python, ruby and perl wrappers
Other client libraries:
Qpid JMS
Qpid Messaging
- c++
- python
- perl, ruby
Brokers:
- c++ broker (available on windows and linux)
- java broker
- broker management tools
(I would pull management tools out of the 'broker' category when they
can be used against other brokers or other things).
I would have these categories on the front page in some way (with more
detail on each and indeed on each aspect or sub-component) available via
links.
I very much like the large box explaining the purpose of the project. I
also like the items under the 'project' category on the current page.The
'project' however is in my view distinct from the structure above, as it
is overarching. I think I'd pull the blogs into this as well, also the
users list as the project wide discussion forum.
Much of the other stuff on the right hand side of the page I would move
off the front page. While I see the value of having some easy links, I
think it is a little noisy and I think it could be more clearly done in
the context of the different components.
So e.g. instead of having download links for Qpid 0.20, Proton 0.4 etc I
would have have a single download link, and on the page that takes you
to, break things out along the same lines as the structure above, with
links to both the latest release, JIRA, any additional lists of interest
etc. (We also need a documentation link on the front page.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org