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
<robbie.gemm...@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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
