Sometimes a module comes out of nowhere, and blows away everything else. I believe Navigate is one of those modules.

There are lot of factors that make it awesome:

• It doesn't get in your way... it stays nearly hidden, as a little circle in the top left corner til you click it. Think designs that didn't foresee the need for massive admin functionality.

If you do click the the top left circle (I think its a steering wheel), you see this:

Dude, its so hardcore, it has a screencast.

• You can add a single menu tree to a "block" and name it in under 8 seconds.
• It introduces the concept of "favorites". You are on a page, and type into a field, it saves the link with that name. You can even reorder them at will!
• You can insert arbitrary blocks of custom php code.
• All in all, its perfect for setting up an interface for clients who don't want to spend a 2 day retreat learning about CCK and Views.

Do check it out. You will not be disappointed.

File this little gem under damn useful.

The author pitched menu blocks better than I could:

So if you’re only using your theme’s Primary links feature, you can add and configure a “Primary links (levels 2+)” block. That block would appear once you were on one of the Primary links’ pages and would show the menu tree for the 2nd level (and deeper) of your Primary links menu and would expand as you traversed down the tree... Pretty simple, eh? (I’m actually shocked this module didn’t exist before.)

This is a comment I submitted on my localhost site, with full HTML allowed for anonymous users. The fact that "XSS" came up in an alert means I'm vulnerable to attack.

If you want your skin to crawl more, visit the XSS Cheatsheet, which offers a number of techniques for XSS attacks. If you're ever in doubt, no better test than to attempt to hack yourself.

Reviewed Version: yui_editor-6.x-2.0
Depends on: Yahoo YUI

VERDICT: Outstanding! The only lovable Drupal WYSIWYG editor . Painless Installation, Great First Impressions, Easy to configure, image Uploading/insertion works out of the box, editor behavior solid and intuitive, and offers good security features.

In our last review of WYSIWYG editors, a certain editor won because it met my low expectations. Thanks to the tip from Sanjeev, I found an editor so good its off the charts.

Painless Installation, Great First Impressions

The moment after I installed YUI Editor I found this refreshing WYSIWYG smiling at me.

If I could read only one web design blog in the world, it would be smashing magazine. At one time, (maybe 2004-2005ish), I would have picked A List Apart. But frankly, I've found the vast majority of their articles as of late to be either boring, not relevant, restatements of the obvious, or not worth even a click and scan (with gripping titles like, "The Boar, the Swan, and the Dump Truck: Test driven development project management strategies in world of reality driven Standards and Accessibility." ) Perhaps that's a gross exaggeration, but some headlines excel in capturing everything I don't want to read about.

Smashing magazine, on the other hand, has created the ultimate resource of quality articles, tools, techniques, ideas, theory, and everything that really matters to people who have jobs to do, and want to do them well, on time, and improve their skills with every iteration. And you don't have to be from San Francisco's community of serial conference speakers* to understand why they are worth reading.

If you've lived under a rock for a while, than I urge you to check out the entire site. Really. You have a lot of catching up to do.

I seem to use the word “drupalism” in a pejorative way. Usually, to to describe anything that follows one of these drupaly anti-patterns:

1. The belief that one should hide settings at least 4 clicks away from wherever those settings matter. "That's where settings go.", so the argument runs.
2. A purpose-agnostic interface element that receives “whatever” from other modules (think hook_links,, and the barf it spits out….)
3. The belief that verbose help text fixes a poorly thought out interface, or form item heading.
4. The belief that one needs to have a usability study -- as opposed to good taste, or common sense -- to backup decisions related to usability.
5. Having form help text for the sake of having form help text (see the helptext on ./user/login.... if you don't chuckle, you lose help text writing privileges.
6. A drupal hook that gets passed all of the following: a) a giant object, or array (by reference), b) an $op variable that has more than 5 possible values, c) usually several other arbitrary variables that change depending on the value of $op. hook_nodeapi, hook_user, hook_comment are the most obvious examples.

I've never seen the word “drupalism” used to describe a good thing. But, as I've argued time and again, I'm an idiot, and a fool -- perhaps even stoopid.

Indeed, this is a great usability report.

I scribbled these notes as I read it:

• Statuses (such as "publish", "unpublish", "promote to frontpage") should not use checkboxes -- they should use BUTTONS. Clicking a button helps ensure that a user understands the gravity of their actions -- which is extremely important. These buttons should show a certain amount of intelligence. "Unpublish" or "Save Changes" for live content. "Publish" or "Save as Draft" for new content, and "Publish", "Save Changes" for unpublished content... etc...
• "Promote to frontpage" is a checkbox that wants to read "Show on frontpage". It's a checkbox, because its an attribute that piece of content can have -- not necessarily an action the user makes on a piece of content. Above all it is of lesser importance than the buttons listed in the previous note -- forgetting to promote a piece of content to the front page will probably be a lot less embarrassing than what could appen if someone accidently publishes a less-than-ready draft. Especially when our interface merely reads "save" -- which is deceptively safe looking.
• The "story" content type needs to either die, or be renamed "article".
• "Book pages" should become simply "pages" with pages as we previously understood them thrown away. The behavior that I think users expect from "pages" is what the book module does best. The book metaphor isn't extended that much -- "child", and "parent" are the main terms used in the interface -- not "chapter" and "page" like you'd expect in a book.

• Settings like front page path are deep enough in drupal admin hell, that a quick fix may have to be a special help box that appears in certain circumstances. Messages would read something along the lines of "Your frontpage is currently set to "/blog". [link] Where can I change this?" These boxes could serve as bandaids for some of our more complex usability problems that aren't going to be solved in a single release.
• admin/content is important enough to have its own unique section dedicated to content management, and content management only. Site settings, user management, and content management are three very different things afterall. I believe they deserve their own individual sections outside of our behemoth misadministration console.
• Yes most users really do expect a wysiwg editor of sorts. I speak of our userbase -- e.g. people who'll never visit drupal.org, or would ever need to know what kind of CMS is running a website. At bare minimum, it should let users add links, images, lists, and blockquotes. A message should instruct users that "[return] = paragraph/ [shift-return] = linebreak. TinyMCE is evil because of the number of options it provides.
• Permissions themselves should be split out perhaps. There is quite a big difference between content related, admin related, and user related permissions. Perhaps splitting these permissions out into more intuitive locations (e.g. content permissions are found in content type settings) and offerring overview pages of what various users can do with various site components would help alleviate this problem.
• There should be a region, and navagition devoted to admin tasks. I think it belongs at the very top of the page (but is not so high that it takes up too much room). Its separated from the main theme, and is design is always consistant no matter the theme currently being used.
• The top admin bar, and admin page (as well as perhaps the content creation pages) can be modified, but not quite as readily as a "theme" as we know it. This roadblock frees up theme developers (ESPECIALLY NON DRUPAL EXPERT ONES) to focus on how sites look to their visitors -- they shouldn't nomrally need to worry about how the sites look to their admins/content managers as well. That should really be the the association of drupal ninja's concern.

Overall -- drupal's flexibility and configurability seems to be a curse to our users. The out of the box drupal should aim to offer a few good approaches to common needs that people are trying to satisfy with their website. Like an object, the more that we encapsulate these distinct needs and settings the better. Perhaps we lose "flexibility" -- but if I wanted pure flexibility, I'd write things from scratch, no?

Everyday, I attempt to read 20 or 30 web development articles, usually via dzone, del.icio.us, and the drupal planet. Its a perverse and masochistic ritual. The articles I scan leave me with a dreadful sense of emptiness -- and a longing for a different career. On the otherhand, it tends to make my development work seem exciting by contrast.

I've identified 7 types of development articles that set kittens on fire. (Disclaimer: I acknowledge my own perverted abuse of blog entries that sets kittens on fire.)

1. The Ultimate List of 83 Untested Plugins, Techniques, or Tools

If I want a huge list of plugins that may or may not work, I can always go to the jquery plugin, or drupal module page and try them myself. Those pages are more useful to me since I can at least see when the last update to them was made. If you inflict such lists on the world, realize we are unimpressed that you can copy and paste interesting sounding plugins, and rewrite a description or two.

If you'd rather offer something useful to your readers, only list plugins you've actually worked with. Simply making sure they "work" isn't really helpful. Copying and pasting them and telling the world to use them is just evil.

NOTE: Smashing Magazine actually reviews the stuff they list, so don't think I'm talking about them.

2. Agile Methodology That Works

Whatever, chief. Unless you're article is titled: "how developers can get clients, senior management, and all powers greater than themselves to accommodate agile development " , I don't care.

Drupal Tough Love is a new site by The Notorious C.H.X. , and Morbus Iff. Want to become a better drupal developer? Get ready for some tough love:

"We all make mistakes; that's how we learn. Sometimes, though, we need someone to point out our mistakes...

And if you don't learn, than Curly on the left will show you some really tough love.

Drupal Tough Love: I'll be watching you like a hawk.

Jeff Whatcott ponders why Drupal isn't dominating the job postings for social app PHP developers.  He guesses the main problem is lack of awareness and understanding of drupal among the greater developer community. With this line of thinking, the obvious fix would be outreach and education. Personally, I'm skeptical that the developers who choose systems other than drupal do so because of lack knowledge, or awareness. I think its something far less rational

I. Our API is Only as Powerful as the Developer's Knowledge of It -- When I developer first starts poking around the hood of drupal, they'll probably be totally unaware of how hook_menu works, what the formapi is, how our template engine overrides, etc... If they took the time to read up on all the documentation, they'd probably become a drupal convert. Unfortunately, developers are lazy, and prone to thinking anything they don't totally understand is "crap".

II. Developers Hold a Deeply Held Believe that *their* tool is the best -- Converting a Rails developer into a drupal developer is about as easy as converting a Muslim to Judaism. Ever tried to convince a Rails developer that drupal's modularity gave it a huge advantage for building complex applications that would have to grow over time? Yeah, I stopped 3 years ago too...

Oh, btw, RoR sux. lrn2theme. Drupal FTW!

III. Developers Often Don't Form Opinions From Experience -- Most developers like to sound smart. So when in doubt, they naturally look to the opinion of someone else who they think is smart. Making matters worse, developers have a tendency to think people they agree with are the smartest.

IV. Anti-PHP snobbery. The snob factor is huge. PHP's reputation among the elite opinion leaders in the development community is about as good as most people's opinion of communism. Making matters more difficult, PHP5 took care of most of their gripes, but nevertheless, they continue to quack the same anti-php song, and that hurts drupal.

V. Drupal Doesn't Speed Up Development for Developers Who Aren't Drupal Ninjas -- Learning drupal takes a lot of time. If time is short, and developers aren't familiar with the APIs, even I'd recommend against Drupal.