Looking at the UI design pattern librairy of Yahoo http://developer.yahoo.com/ypatterns/
I wonder why can not we have exactlly the same kind of ressource but for drupal.
For example we can put "Page Grid UI design pattern" in regards with "Panel 2" drupal module and some useful demonstrations and documentation.
Sometimes there could be several drupal modules that try to do the same UI design pattern and sometimes we need several drupal module in order to achieve one UI design pattern.
So I am just dreaming about a new tab on the page http://drupal.org/project/Modules called "by UI design pattern" that just do what yahoo do but for drupal.
Think about new users to drupal, it takes a very long time to know all the drupal modules, but with a UI design pattern library, many users will be able to find what they need easier.
Another example of the bebefice of this approach would be to identify some missing Ui design pattern. Take for example this one http://developer.yahoo.com/ypatterns/pattern.php?pattern=navigationtabs
As far as I know there isn't out of the box solution to do this with drupal, but it may be possible to do it with custom theming and maybe one day it will become a feature providing by another new drupal module related to menu like the "nice menu" module does.
So what do you think about a drupal UI design pattern librairy ?
How would you like to see it ?
How would you like to do it ?
There has been talk already about setting up a ui pattern library for Drupal
library :
http://groups.drupal.org/node/7294
http://groups.drupal.org/node/8086
And here is another post for great ressources about this terrific topic
http://www.insideria.com/2008/01/5-great-ui-pattern-resources.html
Comments
I think a few UI libraries
I think a few UI libraries ought to be available that developers could follow to make developing UI's easier and quicker.
I'd favor multiple UI libraries initially and let survival of the fittest (or most adaptive) library decide which library becomes the main guideline for developing Drupal module interfaces.
Anyway for starters, I have noticed images, page widths, spacing etc. seem to work best if the number of pixels are divisible by 4. Page grid patterns could follow similar guidelines.
While there have been discussions on icon sets (off topic but somewhat relevant) I am in favor of the silk set of icons because they seem to be standard (and more importantly very well constructed, no other icon set that I've used could be integrated as cleanly into back grounds of any color as well as the silk icon set does) around the web and having the silk set of icons integrated into Drupal could bring Drupal sites more and more into the mainstream.
Why browse modules?
The purpose of http://drupal.org/project/Modules is to help site builders find the appropriate modules for their goals. Would UI design pattern be a familiar enough form of categorization? Would modules builders have enough knowledge to properly categorize their own modules?
The best value in establishing design patterns in Drupal is making more tools available to developers, and increasing documentation on what to use in various situations and how to use it.
Browsing Modules is really
Browsing Modules is really not a good way to design a solution. It radically increases the time required to produce a solution, and militates against 80:20 optimization.
As people are fond of saying, there's no one way to do things in Drupal. In practice, that means you have to reinvent the wheel every time you want to design your application. Consider the following requirements for a press room:
There should be some pretty straightforward and best-practice ways to meet these criteria. But in practice, what you have to do is browse Modules and cobble it together on your own. Sure, you can look at articles about how other people did it with their sites, but such things, while useful, are not organized in a way that makes the useful as models -- i.e., as patterns.
Installation Profiles and the various configuration import/export tools that people are developing right now are partial approaches to the problem. But what seems to me would be really useful would be for someone to put together a structured way of talking about case studies that lets us use them as the basis of a pattern.
Julma, This is something
Julma,
This is something I've been contemplating for a while, as you can see from http://groups.drupal.org/node/7294 which you linked to. I think you have a great idea IRT to how such a library could be made accessible useful to developers, and partially automated. I don't think that d.o is the right place for it, however I think api.drupal.org would be.
A quick way to start this would be to write code that finds all theme_* functions, and a reference to them, and generates sample output, screenshots it, and attaches the theme_function's documentation. api.drupal.org already does part of that (with the doxygen module, I believe), however PHP wouldn't be able to do all of that and it's a non-trivial task, but would make the library scalable and largely self-documenting.
Neil Drumm wrote something to me recently that got me thinking and has put me off usability guidelines or libraries a little. I hope he doesn't mind me copying it here as you may also be interested;
SteveJB, Icons in drupal is pretty complicated. Take a look at http://groups.drupal.org/node/7809 to see the state of things there.
Bevan/
Bevan/
Spending the time to do a
Spending the time to do a proper pattern library, starting with documenting existing conventions, would be a great thing to do. However, I do not think my personal time is best spent doing that at the moment. Everyone should do what makes the biggest impact with the resources they are able to dedicate to it.
Drupal + Fluid = Running Water
I've spent some time connecting drupal folks with fluid project folks, who are in the midst of creating a (drupal-powered) user experience design pattern library for open/community source applications (it's not live yet, but will be soon). They are also releasing actual code and have pretty good funding of their own through the Mellon foundation. Check out the fluid project at:
http://fluidproject.org/
People have raised questions about fluid's dual-licensing under the ECL 2.0 and the New BSD, but one thing to consider is that fluid wants to build components for multiple open source applications, so they have to try to be as flexible as possible. You can see a discussion of fluid's licensing issues here:
http://tinyurl.com/2fowr3
The latest version of the
The latest version of the root candy theme http://drupal.org/project/rootcandy uses the oxygen iconset.
If the theme was given images to help with navigation, it would be easier to use.
Having a UI Kit/Library with pre-built images could be useful for admin themes such as root candy if they were to use images as the following wire frame illustrates:
http://www.scribd.com/doc/2169615/RootCandy-possible-icons-for-tasks
The Root Candy theme currently looks like the best candidate for a dedicated admin theme if Drupal were to have one pre-pacakged.
Design libraries
Here's a list of some other available design libraries and resources:
http://welie.com/patterns/index.php
http://ui-patterns.com/http://welie.com/patterns/index.php
http://www.designingsocialinterfaces.com/patterns.wiki/index.php?title=M...
http://designinginterfaces.com/About_the_Book
-Daniel Chvatik
Adulmec LLC
Design Patterns Presentation from Do It With Drupal
I gave a talk at "Do It With Drupal" on Interaction Design Patterns. There are a number of pattern libraries out there that developers can use for guidance in making design decisions. I do think that developing a pattern library that is specific to Drupal could be a benefit to the community. It might be a topic for a BoF session at Drupalcon in DC.
A .PDF presentation can be downloaded from the Do It With Drupal site.
I also updated the interaction design patterns page on Wikipedia as I was researching the presentation, so it has links to a good set of pattern libraries, plus some additional sources of information.
Libraries need Librarians!
It's out there... the perfect solution... the simple way to do something... but it is buried. We all dream of being able to bore down into the internet and within minutes identifying to one piece of info we need.
It is not going to happen until there is a galactic universal filing system and everyone obeys the filing laws! Until then... we need people who are experts to direct us to the right data. Which means we need experts who are experts on experts to find the right expert who can get us the right piece of info.
If Drupal wants to 'fix' the Internet, continue to build this fantastic community knowledge base, but add to it a FaceBook (forgive me) real people network. It would not surprise me a bit if it doesn't already exist and I don't know about it. This place is huge and complicated. I love it here but it takes me days to find answer.
Thanks
ux-tab in api.drupal.org
Edit: aaargh, after writing all this down I only now realize I'm posting in a really old thread, so this has probably already all been said and done and gone on. I'll leave the comment anyway.
+1
Bohjan and Yoroy, Drupal ux maintainers, gave a best practices presentation at Drupalcon Paris for ux widgets called Building Blocks for Your Module's UI. Sadly, sadly, sadly this is one of the few videos that has not been published online. They presented wonderful examples of current widget implementations in drupal that could easily be reused. Putting an extra ux-tab in for developers at api.drupal.org was suggested there as well and welcomed by everyone present. One benefit of such an api that i can see is to prevent mishaps in modules. Earl Miles' Chaos Tools module contains some good examples of what can occur when you're left to figure it out all by yourself (Its non-ux functionality is brilliant though). It would also further encourage the sharing of a singular javascript library (jquery) across contrib.
In her presentation Karen points out that a ux api may be too generic to cover a modules' specific needs. However, a basic widget set that can be built upon may save developers time reinventing wheels on the framework side of drupal, allowing them to focus on inventing new ones instead. Also, it would bring less surprises to themers on the product side.
I like the idea of a shoot out between ux pattern implementation but maybe it would be a good thing to level the playing field by supplying a basic skin set like that of flex (direct link to zipped example) to take appearance issues out of the equasion?
Also, I think MortenDK and others have been working on an openatrium implementation to achieve an environment where ux and theme people can actually present sketches before needing to patch. It's at http://project.designfordrupal.org/org/node/122. It has the necessary functionality to set up a serious practical effort to achieve this library.