We are very pleased to announce that Yii has a new official project site! This is a complete rewrite of the old site, with brand new designs and many new features. We hope you all like it! Please report to us if you find any issues of the new website.
We started this project with the following goals in mind.
Better logo and page design
Better search engine
Easier to read documentation, including API manual, tutorials and wiki articles
Enhanced community support, including ranking, commenting, voting, reporting, and many more
Better website performance
While we will continue to develop the project site, we are proud to claim that we have achieved most of these goals.
Finally, here are some facts about this website that may interest you:
The rebranding effort was started in summer 2009
The intensive development of the new site was started in June 2010
Wei and I are the main developers; mdomba created the new API pages; jefftulsa helped with the tour page and proof-reading the static pages.
The site is powered by Linux/Apache/MySQL/PHP/Yii (trunk).
We used APC, DB-based caching, DB-based logging, RBAC
As of today, we have 24 DB tables. The size of PHP code is about 800KB.
We use git as source code repository.
In August, the site received more than one million monthly page views. We expect this number to be doubled by August the next year.
So far i’m liking all that I see, the only place where there might be slight room for improvement is when viewing an extension.
90% of the time having all the info on the same page is fine, however for some pretty active extensions it does mean that the page can be pretty large.
In this case it’s the long changelog that turns it into a big wall of text, however in other instances it could well be the documentation.
Not sure what the best approach is really apart from separating it out into different pages again - although with that if it was to be separated again it would only need to be into something like "Extension Information", "Documentation" & "Changelog" as having the download available in the sidebar removes the need for that page.
The other option is perhaps to simply make the definition between the different areas a little more obvious - at the moment the difference between an h2 (used for the top-level “Documentation”, “Changelog” titles) and h3 (used internally within those sections) isn’t very big.
Another possibility is to have the less-useful information such as the changelog display the last x lines with a link to ajax-expand to the full information.
Source available anywhere? It could be a really nice reference resource to see how the pro’s do it
Another area that might benefit from some thought is the "Wiki" for user-generated tips & tricks.
At the moment, you essentially have to know what you are searching for in order to find it.
Currently all of the entries are contained within the "Tutorial" category, and when writing a new one you can select from "Tips", "How-tos", "Tutorials", "FAQs" & "Others".
For navigation purposes, these categories aren’t very useful - they are all just slight variations on the same thing.
I think a better approach would be trying to come up with categories that reflect what the tutorial is about - similar to the extensions page.
Some brainstorming is definitely required to come up with a good category list however as it wouldn’t match up with what is currently used for the extensions page.
With a very quick browse through, "AJAX" & "Database manipulation" categories look like they would be fairly inclusive of a lot of the content in there.
We are trying to simplify the interface of extension pages. That’s why we merge all old tabs into a single page. I think those changelog can go into a file.
Wiki articles can be tagged, which allows arbitrary categorization. And everyone can edit an existing wiki article to improve its categorization.
Yeah, I agree with that - it’s definitely a lot cleaner than the old multi-page system.
I suspect the extension builders will work it out themselves now that the new system is up
Good point, I wasn’t sure how the tag system would work.
With that said however, i’m still not sure that the current categories are really that useful - after all, what is the difference between a tutorial and a how-to?
I agree with Orteko with regards to the extensions page layout. I preferred the tab based layout, as everything was organised in “sections”. The current layout defines the sections through the use of headings on the page but it doesn’t really look organised.
Perhaps you could use jQuery slideToggle() to show/hide the sections? Or have some sort of outline that separates a section from the one below it, other than a heading.
Congratulations to the dev team! The new site looks awesome!
One question:
It seems that what was the “cookbooks” before is now called wiki. I wonder wether the URL schema to these articles changed. I’m asking as there are many forum posts that link to some cookbooks. If it has changed maybe a mod_rewrite that redirects to the new URLs would be helpful.
Similarly, on the new API page the colour scheme for the page content is not very ‘lively’, so for example I think the details part of the properties need to be more predominant, i.e. instead of a light grey background it should have the blue background that worked very well on the old design.
I think the main issue is that the h2’s used to differentiate between sections are practically identical to the h3’s used within sections. If you are scrolling down the page a heading at 1.3em and 1.2em don’t look all that different
Maybe something just as simple as adding a border-bottom: 1px solid #eee to the h2’s on that page.
I do lean towards having an expandable/toggleable changelog however - it’s really only the most recent entry that is likely to be of interest, I don’t think the rest is useful enough information for it to be permanently on display.
