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