I am currently wireframing the functionality of a graphs widget for a social monitoring tool and need more input about how effective might this solution be...
The ribbon menu works fine, as long as there are not too many features in it. For example: I know my mother is tremendously annoyed because she can't find some things.
So clear copy and a well thought information architecture to determine what goes where, al wrapped up in the ribbon menu sounds like a rigid solution.
A ribbon by definition is a bunch of menus placed on tabs. Because the tabs “stick” after being selected, it makes most sense when you can divide your commands at the top level into discrete tasks, where you expect users to execute multiple commands on a single tab without needing a command on another tab.
In practice, this is rarely how things work in apps, and the ribbon actually has greatest use in highly complex apps with 100s of commands. That number of commands becomes difficult to physically fit in the page without using tabs, even when employing lots of pulldown menus. Anytime you have 100s of commands some are going to be hard to find, but a well-designed ribbon is better than the alternatives, such as cascade menus or multiple hide-able toolbars. Unless you have 100s of commands, you probably don’t want a ribbon.
Sometimes people use “ribbon” to mean a single toolbar. This is a line of command controls, such as command buttons, typically across the top of your page. It provides easy-to-find one-click access to commands. It's excellent when you have relatively few (less than 20) commands. If you use split buttons and menu buttons for your less commonly needed commands, then a toolbar can easily accommodate upwards of a 100 commands while still providing easy access to the top commands.
Traditionally, toolbars are label with icons. However, using icons alone is generally a bad practice. They just don’t make very good labels most of the time. Text is usually better, and modern toolbars make heavy use of text, although icons may be used in addition to text to reinforce the label’s meaning. Icons alone are only worth considering if you have very limited space, very few commands, and your commands use standard or otherwise strongly evocative icons (e.g., the fat B for bold font).
A sidebar menu is effectively a toolbar on the left side of the page. In contrast to toolbars, they are traditionally labeled with text alone, but you can add icons too if you want. Users are used to sidebars on the web, which is good for your case. If you have more than eight commands, it's helpful to subdivide your commands into labeled groups to improve findability, which is easier to do with a sidebar menu than a top-of-page toolbar. I believe sidebar menus have several additional advantages over top-of-page toolbars that make then generally more attractive. I see no reason why something like split buttons or menu buttons can’t also be used on a sidebar menu to keep rarely used commands out of the way. Knowing nothing else, I say this is your best choice.
Finally, there is the traditional GUI menu bar, composed of multiple pulldown menus across the top, and usually combined with a redundant icon-only toolbar so experts have easier access to common commands. With the advent of split buttons and menu buttons, a toolbar or sidebar can handle just as many commands as a menu bar, while menu bars are typically saddled with the disadvantage of a toolbar without text labels. These days, I would only advise menu bars in order to leverage experience from older related apps. Specifically, it’s good for a desktop-style document-centered application where commands fit well in the standard File Edit View menus and the toolbar is largely limited to standard icons (e.g., New, Save, Print, Bold, Italic, etc.). Probably not what you want for a web-based dashboard.