First - thank you for your amazing work. I've put YUI to use in many projects.
Second - tiny bit of feedback about yuilibrary.com - I know you have your own CDN but can we have back a "Download" button? I hate it when I have to search for 5 minutes to find out how to download something. It really makes me feel like the whole project is going to be a pain in the ass when even downloading it is hard.
I've added a "Downloads" link to the "Quick Start" dropdown menu in the top nav bar, and we'll give some thought to adding a more prominent link somewhere on the front page. Thanks for the feedback!
Others also want to host their own because they don't want to introduce another point of failure. For all the supposed reliability of CDN host X, having YUI available when my own CDN goes down isn't helping me much. On the other hand, if YUI goes kaput while my CDN is doing fine, I've got some problems.
We're admittedly programmers and not designers. Our main focus for the redesign was to improve usability, remove clutter, and decrease the overhead involved in finding relevant content. The new user guides and API docs in particular got the most attention in this regard, and I'm pretty happy with the result. It's not super sexy, but it sure is usable.
When I'm learning anything visual (GUI, plotting libraries) I really like a gallery of live examples.
YUI's site seems to assume that you already know what you are looking for.
The new site puts 4 examples (todo, calendar, charts, and search) on the home page, which is 4 more than I found the last time I looked. For contrast, jQuery UI has dozens of examples (under http://jqueryui.com/demos).
You have the pages - http://yuilibrary.com/yui/docs/examples/, but it's not really promoted. I bet you don't get many clicks to that page (due to the design of your site pushing people to other sections), but I bet the people who go there find it useful. Everyone else lands here: http://yuilibrary.com/yui/docs/guides/. Unless they think to go back, everywhere they click will look like a man page, complete with big "caveat" boxes. Functional, if you are debugging YUI, but otherwise it's just ugly.
IMO, you should promote the live examples more, rather than the API docs. If I want to do some complex stuff, I'll look for a section labeled "API". If I'm just trying to assess whether a toolkit is useful, if I don't stumble onto live examples I'll wonder why you aren't even using the tookit on its own homepage.
You could also go one better, and put some screenshots (or inlined examples) on the example index docs/examples/.
People don't complain about "design" because they think it's ugly. They complain because they can't find what they are looking for (even if they don't know what they want).
* Use a fixed-width site. Most people go for something like 960px. * Establish horizontal and vertical eyelines or columns. * If you're on Github, might as well use gists. Offer example projects as open projects on Github
I feel like you have over 20 different shades of blue if you count all the backgrounds & borders on elements -- which is annoying since blue is usually the color for links. Facebook is known for their blue color, yet they only use 4 shades of blue total.
I use YUI mainly for table/grid widget - I preferred API design in YUI3 but found various table UI bugs when I 'mixed in' sortable and resize columns etc... This meant I had to go back to YUI2. I remember this experience as amorphic 'yui pain'.
Hopefully in current/3.4 the DataGrid is now fixed with official plugins working in unison?
Some thoughts :
YUI really needs one core person with an iron fist and a clear goal driving it forward. It feels like it has the guts of something incredibly useful, but is being pulled in too many directions.
In a large company its tempting to think ' we better keep that for Sandras or Simons team' .. dont do that... think like a startup and throw bad shit away :]
I can live with the verboseness if the Widgets are really nice - and thats a way to get HTML5/js/web-startup developers thinking about Yahoo again.
Some ideas -
Be ambitious upstarts, dont ask permission to kickass.
Give the team autonomy / ie. a virtual startup within Yahoo. Maybe split off a team or an Open Source startup ?
Demand all Yahoo use latest YUI by religious edict from on high [ Doug ? ]
Consider mobile?
Drop the legacy crud, get rid of any fallbacks, burn the bridges!
One Unified example, or a framework / app-designer as the canonical YUI demo
> "Give the team autonomy / ie. a virtual startup within Yahoo. Maybe split off a team or an Open Source startup ?"
Everyone involved with the project, from upper management on down, are all engineers, and by having Yahoo entirely fund the YUI project it allows each of us to focus on nothing but building things for our community. If we were spun off, then we have to worry about making money, and well... I'd rather be coding. Even as a spin-off, if Yahoo (and others?) funded us 100%, I don't think much would change compared to how we currently operate. In my opinion, Yahoo is the best customer (and parent) a JavaScript library could ask for.
> "Demand all Yahoo use latest YUI by religious edict from on high"
When you hear the execs publicly talk about replacing old infrastructure components, upgrading everyone from YUI2 to YUI3 was one of those things we've been working on heavily. Flickr, Mail, and the Homepage are all on YUI 3.3.0+. By the end of 2011, all Y! Media properties will be on a recent version as well. That means the vast majority of the 80+ billion pageviews/month will be using a current YUI3 release. Maybe not bleeding edge, but close enough. YUI2 is deprecated and will only be receiving security fixes, if any ever arise.
> "Consider mobile?"
It's very much on our minds. It currently works great in mobile because of the efficient codebase, modular architecture, and the combohandler, but we're working on filling in some of the missing pieces. Stay tuned.
> "One Unified example, or a framework / app-designer as the canonical YUI demo"
We had a long-discussion about that very topic today. Now that we're on a new, self-hosted website, it opens up many possibilities for what we can do to really show off the library.
I like the idea of a framework.. but the Todo List app just seems overweight.
I personally dont want to see a Rails style or heavy iOS/Cocoa style framework for web.
What I like about Javascript is it has enough lisp that I can write surprisingly small amounts of code, and the code reads like the way I think about the problem. Also the async events are magic in terms of decoupling components [ reducing cross dependencies ].
I content that concise frameworks are possible in Javascript [and lisp], whereas they are not possible in C/Java/C++/ObjectiveC.
You can also follow us all on Github and see everything we're doing on a daily basis. http://github.com/yui/
A goal of our team is to be as transparent as possible and open source everything we create. I guess the only things not public are our internal mailing list and weekly meeting, and those are pretty boring. :)
[1] http://dev.sencha.com/deploy/ext-4.0.2a/examples/tree/treegr...
The new website means there's now just one URL you need to remember: http://yuilibrary.com/.
