ToolStrip with MenuStrip or RibbonBar?
It combines both of the controls. It also have a TabPages navigation, contextual tabs, etc. However the RibbonBar is a very complex control and when you open a new document in for example Word2007 the half of the screen you see a Ribbon Bar. It is not cool. When you have toolStrips you can layout them to Top, Bottom, Left, Right and have more control of the UI look. We can also hide the toolstrips which we do not want to see and they no longer take any screen space.
Ribbon Bar
It boils down to what you're trying to navigate and how complex do you want the Navigation to work.
I prefer to use simple existing applications to base my programs.
Thus for the most part I use either the MenuStrip + X ToolStrips or just a simple ToolStrip if a menu is more involved than is required to get a task done.
But I would have to guess that many people like the Ribbon Bar since it combines the functionality of both Menu and ToolStrips into one control.
Ribbons look more modern, and will help to give you application a modern and current look.
As for usability, I've preferred the experience, as long as you are unfamiliar with the app.
For apps where you are used to a menubar, it's a difficult change, but for new apps or new users it's a good improvement.
Related
I'm trying to build an app in winforms with something similiar to masterpages in asp.net - a menu on top and when choosing an option from the menu the entire screen on the bottom will change while the menu remains (there are 10-15 screens in the future app, some are quite similar, some are not).
What is the best way of doing this? Should I use different forms for each screen or use a panel or something else?
If I use a panel or something how do I manage to use the designer with so many panels taking space on the screen?
Try with the MDIParent Form's. View the Example
http://www.codeproject.com/Articles/12514/Multi-Document-Interface-MDI-tab-page-browsing-wit
If it is just keeping the same menu and opening/closing parts of the UI you could simply add and remove instances of usercontrols to the main form.
If you need more features such as docking (like Visual Studio) look at this
Another option is to use Form inheritance
Which one to select depends on what you want to reuse and the features you need.
One option would be to make your application an MDI window and then load entire forms, maximized, into the parent window.
Then, you would be able to treat each form as its own self-contained item, since it really would be exactly that.
Is it not an option for you to use WPF? A WPF browser application fits the paradigm you are describing quite well.
So I'm porting an application from WPF to Silverlight and I have realized that there is no standard Menu control.
So I look around and find some third-party controls that emulate the menu control, like this one at codeplex:
alt text http://www.deviantsart.com/upload/1adt6b3.png
But then I decided to take advantage of this situation and think of some new metaphors besides the standard menu we have been using since Windows 3.0, e.g. I like the following enabled/disabled buttons for a small number of choices, which also work well as a vertical stack, and will try to integrate a drop-down button idea to allow it to hold the number of nested choices that a standard menu control could hold:
alt text http://www.deviantsart.com/upload/1bbtg9l.png
What is the best application navigation menu metaphor you have seen or used in a Silverlight line-of-business application?
How about the Office Ribbon?
http://timheuer.com/blog/archive/2009/01/20/ribbon-control-for-silverlight.aspx
http://www.divelements.co.uk/net/controls/sandribbonsl/
http://msdn.microsoft.com/en-us/office/aa973809.aspx
Personally, I like the style of Apple's CoverFlow.
You can load various screens in each of the CoverFlow "panels", show the Active panel in the center, and tightly pack the other panels to the left and right.
You gain the ability to allow the user to see their other panels while working on the active one...and you can add a little flair when the user switches between the panels.
I don't know what this is called in SL, but I would like to replicate this functionality. If you go to this site: http://www.mscui.com/PatientJourneyDemonstrator/PrimaryCareAdmin.htm and click on the "Show Details" button located on the top, right-hand corder of the screen. When you click on this, there should be a "Scene Details" button-like feature on the right side. When you click on this, this is what I would like to implement. Can someone direct me please? Either to an online article, etc...
I'm not precisely sure what feature of the site you'r referring to (I'm blind so the description doesn't make much sense to me). However, two useful links - some of the MSCUI source code is available on Codeplex http://mscui.codeplex.com. Also, the Silverlight developer/designer on this project created Blacklight http://blacklight.codeplex.com which includes visual assets to use with Silverlight.
Although I don't know the specifics of the implementation, as far as I can guess, this is done by having a second Grid that follows the Grid for the page. Then, simply change the visiblity on the "guide" grid when the button toggles.
I believe that is simple, although it'll require you to work to figure out the positioning of the underlying page - but it's more flexible. With Blend it'll be easy.
Alternatively you could have a ton of additional UI elements on the page next to their respective controls, and either Tag or name them in a way that you can iterate over them to control visibility and interaction.
I think you're talking about a the grey overlay with a modal window on top. I think the best way to do that in Silverlight 3 is with the ChildWindow control.
I'm trying to decide whether I should create a simple StackPanel with Buttons on it, or whether I should use the WPF ToolBar class to contain these buttons (I am creating a simple toolbar).
What are the pros and cons to using WPF's built-in ToolBar control?
So far, these are the only advantages I have seen:
The ToolBars can collapse when necessary; additional items are available from a context drop down.
If the ToolBar is contained within a ToolBarTray, multiple ToolBars can be repositioned relative to each other.
Are the any other benefits to the WPF ToolBar? Neither of these apply to my simple toolbar.
Accessibility might be better with the WPF Toolbar, because it shows itself to Windows UI Automation as a toolbar with toolbar buttons, rather than some random controls. You never know who'll use your software.
Another very small advantage is that buttons in the ToolBar will be styled correctly, whereas the buttons in the StackPanel will take on their default look. Not insurmountable by any means, but a little annoyance none-the-less.
I would say use the Toolbar, because you never know when the next project will come along and need it. You also never know when this project may need it. I don't think there is any real drawback to using it over a StackPanel and the advantage you didn't mention is you'll have more experiance with a built in control for the next project.
On the other hand, I don't see any harm in doing it with the StackPanel, only that if you need to extend functionallity in the future, you'll have to do some rework.
I have a winforms application that doesn't have a shared set of tools that I can provide on a toolbar. But I want to have a toolbar, so I was planning on using that space to provide quick links to the most popular portions of the product. I will eventually add knowledge to the product to know which screens the current user favors and provide those as quick links on the toolbar. But is this a reasonable use of a toolbar for a desktop product, from a design and usability point of view?
Do not automatically add knowledge about what a user prefers to generate a toolbar. Having a dynamically generated toolbar is confusing for users. It's fine if your configuration bar makes suggestions dynamically (i.e. suggesting buttons), but changing the layout itself is evil.
I think a toolbar makes a good aesthetic, but if you merely want to seperate parts of the app then a Tab bar makes more sense for usability.
With the advent of tabbed browsing, every user understands the tab concept.
Sure. Firefox has something similar in their 'Bookmarks Toolbar'.
Peachtree Accounting also has a toolbar like this, as do many others.
Tabbing is OK as long as there aren't too many.
Would be real good if the user could personalize the toolbar themselves. Sometimes I don't only want places I frequent, but screens that I use occasionally that are hard to find through menus or whatnot.
To me, this looks like a job for a menu with a MRU list, or support 'Add to Favorites'.