Yii has a new face
#1
Posted 16 October 2010 - 03:50 PM

POPULAR
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.
#2
Posted 16 October 2010 - 04:55 PM
Nice job on the class reference. Very easy to navigate.
doodle
#3
Posted 16 October 2010 - 05:19 PM
I think that the fresh look and new features will attract more people to start trying out Yii and joining the community!
bye,
Giovanni.
>> My Linkedin Profile
#4
Posted 16 October 2010 - 07:39 PM
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.
See the page for srbac for instance: http://www.yiiframew...extension/srbac
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 :P
#5
Posted 16 October 2010 - 08:06 PM
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.
#6
Posted 16 October 2010 - 08:37 PM
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.
#9
Posted 17 October 2010 - 03:22 AM
the drop-down menu in the guide is made based on some ready solution or is yours idea?
#10
Posted 17 October 2010 - 03:38 AM
qiang, on 16 October 2010 - 08:37 PM, said:
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.
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
qiang, on 16 October 2010 - 08:37 PM, said:
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?
#12
Posted 17 October 2010 - 07:12 AM
Some questions:
- Why APC (not eAccelerator)?
- RBAC is DB-based or you store configuration in php file?
- Do you use memcached (or any other caching programs)?
- Do you use theming?
#13
Posted 17 October 2010 - 07:33 AM
It's our own design and implementation. Main reason of using a list instead of a dropdown is SEO.
> Why don't you use PostreSQL instead of MySQL?
It seems to us MySQL is faster, and we can tune it up by ourselves, even though we are not professional DBA.
> Why APC (not eAccelerator)?
No particular reason. Perhaps mainly because we have more real experience with APC.
> RBAC is DB-based or you store configuration in php file?
It's DB-based, mainly used for backend.
> Do you use memcached (or any other caching programs)?
Right now we only use CDbCache, because our server memory is limited (2GB).
> Do you use theming?
Nope. There's no need to quickly switch outlook as of now.
#14
Posted 17 October 2010 - 07:49 AM
in IE 6.0 site does not look good. Menu and dropdown list not work and buttons are cut.
How can I add attachement with print screen?
Solution: switch to full editor mode.
This post has been edited by qwerty: 06 November 2010 - 04:51 AM
#15
Posted 17 October 2010 - 08:00 AM
I think for Web developers, most should use newer browsers because they represent the majority of the end-user browsers.
#16
Posted 17 October 2010 - 08:07 AM
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.
#17
Posted 17 October 2010 - 08:15 AM
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.
#18
Posted 17 October 2010 - 08:19 AM
Just my personal preference though!
#19
Posted 17 October 2010 - 08:32 AM
GSTAR, on 17 October 2010 - 08:07 AM, said:
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.
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.
#20
Posted 17 October 2010 - 08:55 AM
So far, so good! Still viewing all!
The problem is communication! Excess of communication!

Help



















