Your sarcasm is misplaced. The new website consolidates all the YUI 3 user guides, examples, and API docs -- as well as YUI Theater and various other content that used to be spread around developer.yahoo.com -- under the yuilibrary.com website.
The new website means there's now just one URL you need to remember: http://yuilibrary.com/.
While YUI is probably one of the best JS frameworks around the sloppy design of their webpage beats me. the yuilibrary.com looks so 90ish in its design.
What parts of it strike you as sloppy? How would you improve the design? We'd love to hear specific feedback.
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.
I'll chime in here, just in terms of the design of yuilibrary.com
* 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
Great feedback, everyone. I've pushed a few quick changes to address the low-hanging fruit:
- We're now using Maven Pro for headings (no more Trebuchet).
- Replaced Lucida Grande with Helvetica in the nav bar (sorry Windows users, you get Arial).
- The site now has a max width of 1200px instead of expanding infinitely. This seems like a reasonable compromise, since any purely fixed-width design draws the ire of people who hate fixed-width designs.
It just looks ugly, hard to put into words. It feels like there's too many shades of colors & font sizes. You don't need gradients to make a site look good. Maybe you guys just need to hire a designer.
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.
Trebuchet feels dated, especially when bolded and part of blue + orange scheme. That look was very trendy a few years ago. Also, too many faces. Two faces usually work fine. Maybe replace all the Trebuchet with Maven Pro, and all the Lucida with Helvetica. And lose any weight variation you can (eg: since a link is already a different color, it doesn't really need to be bold too).
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).
It's very intentionally based on Backbone's example, to demonstrate the similarities and differences between Backbone and the YUI App Framework. It's kind of a tradition now among MVC frameworks.
Alright; I did not know that. Very neat indeed; I hadn't looked into YUI for ages but it seems pretty solid, especially if it integrates MVC concepts. Was it in previous versions of YUI or was it added recently?
In the Widgets section of the complete YUI Examples page [1], the only component that seems to support the keyboard at all is the Dial widget. The Calendar, DataTable, MenuNav, Slider and TabView don't seem to have the default keyboard-ability that their desktop equivalents do.
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.
We wanted to emphasize the CDN over downloads, but we clearly hid the download links too well.
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!
I wrote about my personal feelings on third-party SSL CDNs here: http://wonko.com/post/javascript-ssl-cdn (these are my opinions and not representative of any official YUI or Yahoo! stance on the matter).
It still fails the <C-F> test...and <C-F>download is the first thing I do when I decide that I'd like to try out some library. Nothing wrong with preferring a CDN, but some people want to get the whole thing broken into source files so they can really audit the code properly.
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.
Don't get me wrong, I 100% agree that sites should be allowed to host their own version of YUI because there are some circumstances where it may be necessary. That's why we distribute all the source code to be able to do it. But also keep in mind this is the Yahoo CDN, if it goes down, all of Yahoo goes down. I can't say the CDN won't ever go down, but to my knowledge, it has never happened.
If you are concerned about CDN reliability, for optimal performance I would still use the Yahoo CDN as you get all the benefits of combo-handling, edge-caching, and (soon) server-side dependency calculation. And as a backup, host on your own CDN in the unlikely event Yahoo's CDN goes down.
Maybe I'm just weird, but I frequently develop things offline and so I require a local copy of things for dev anyway regardless of if I use the CDN in production or not.
I know it's really not that hard to copy & paste it, or just type it in, but I'm a little surprised that this blog post didn't have "yuilibrary.com" as a simple link to itself. For usability, SEO and all.
The actual reason is that this blog post was posted before the site went live, and was not the post-launch announcement (which did have a link). I've updated it with a link.
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
re my last point as I just noticed YUI App Framework -
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.
Gord, thanks for the comments. Very much appreciated. Here are some of my thoughts...
> "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.
All of a sudden with all of rgrove's (YUI's) interaction, it makes me feel all warm and fuzzy about using YUI again. Great customer service does make a difference.
Join us for a YUI Open Hours sometime. We do them every few weeks and you can learn about all the latest stuff we're working on. Follow @yuilibrary on Twitter for updates.
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. :)
39 comments
[ 4.4 ms ] story [ 81.8 ms ] threadThe new website means there's now just one URL you need to remember: http://yuilibrary.com/.
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.
* 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
- We're now using Maven Pro for headings (no more Trebuchet).
- Replaced Lucida Grande with Helvetica in the nav bar (sorry Windows users, you get Arial).
- The site now has a max width of 1200px instead of expanding infinitely. This seems like a reasonable compromise, since any purely fixed-width design draws the ire of people who hate fixed-width designs.
Keep the feedback coming!
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.
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).
[1] http://yuilibrary.com/yui/docs/examples/
I agree that the keyboard support for Slider and Calendar could be improved.
You didn't mention AutoComplete, which also has excellent keyboard support.
[1] http://dev.sencha.com/deploy/ext-4.0.2a/examples/tree/treegr...
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!
I wrote about my personal feelings on third-party SSL CDNs here: http://wonko.com/post/javascript-ssl-cdn (these are my opinions and not representative of any official YUI or Yahoo! stance on the matter).
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.
If you are concerned about CDN reliability, for optimal performance I would still use the Yahoo CDN as you get all the benefits of combo-handling, edge-caching, and (soon) server-side dependency calculation. And as a backup, host on your own CDN in the unlikely event Yahoo's CDN goes down.
We'll look into passing the <C-F> test. :)
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
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.
> "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.
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. :)