Since we're deciding on whether or not the site is production ready we should take into consideration function over form. I think I'd like to point out a few objective points here.
1) The site functions as intended. There are no major functionality issues that I've found so far. Things like styling and typography are fairly subjective (for the most part). While I agree there is much room for improvement in that department I also happen to disagree that it is an impediment for pushing to production. This is mainly because I already feel the existing php site leaves much room for improvement as it is (so this is a no-contest comparison). 2) Navigation-wise the prototype makes more sense to me. The mega drop down does make navigation less cumbersome. The front page actually looks way more organized and easier to spot different sections of the site like downloads, news, conferences, documentation, etc... It's just way more obvious to me where I can go from the home page to those sections (if even purely from a visual perspective). The Quick TOC menu reduces the amount of scrolling I have to do to navigate to the different sections of each manual page (notes, examples, changelogs, etc...). These are all definite pros over the existing site. 3) The search functionality in the prototype actually looks more helpful to me. I can more easily spot which function I might want to view the manual page on when I search for "sort" since I get a brief description from the function prototype while I search (and I actually see the rsort, ksort, usort, uasort, etc... functions) in that list. This is a huge UX improvement over the existing search since I find the Google API rather annoying actually. I much prefer the auto-complete search present in the prototype. Anytime you can get me from point A to point B quicker I'm a happy camper. 4) I also see a lot of positive feedback about the prototype. People I've asked to give their opinion of which looks better php.net over prototype.php.net, most people agree that the latter is an improvement over the former. Albeit the sample size is fairly slim. People generally tend to ignore small nuisances like styling and typography when functional improvements (function over form) can be spotted easily. Now for the bad news: 1) Prototype actually requires a lot more requests per page view than the existing site. (Upon preliminary testing this about double the number of requests on average). The main reason for this seems to be that the prototype is using one data URI per image in the footer where we display the PHP elephant plushies. This is actually very bad, because data URIs generally gon't get cached by the User Agent. This could mean a lot of extra HTTP requests per page view increasing load with minimal benefit. I highly suggest we refactor this to use a single PNG file as a sprite image that can be cached by the UA and with a little CSS it can work any necessary effect magic needed. 2) The CSS style sheets are also not being cached, currently, due to the fact that their request URIs are dynamic. I'm not sure if this is intended behavior since it's still in prototype mode or that was a fluke. Hitting the cache for javascript, css, and image files, should be more often than not. Right now the existing site hits the cache for about ~92% of all requests, which roughly 21-22 out of every 24 requests. The prototype, however, is only hitting the cache for about ~20% or 8 out of every 41 requests (that's horrible). 3) There are strange quirks with the existing styling that leaves way too much white space for no reason at all that makes things look awkward and can confuse the end user. For instance let's take a look at what happens when a page has user contributed notes where the description, examples, changelogs, etc... sections of the page are under the fold of the left-hand navigation menu. http://i.imgur.com/g6Qaj.jpg Notice that where the red arrow is pointing is exactly the space left between the base-line of the left-hand menu. This is because the "layout-menu" class has a computed height of 2237 pixels and the notes.text div has a clear: both selector inside of the note class. This causes the huge gap on pages where the "layout-menu" extends in height, past the user notes text div. This can be spotted in /styles/theme.css on line 427. (You can probably blame me for that one so I'll be fixing that issue myself). However, these few issues can be fixed quite easily before a mid-January launch, I believe. Nothing seems critical to me and I see the pros outweighing the cons here. Sherif, I flip bits and drink coffee (occasionally that results in success).
