As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We have seen that office has the ribbon UI since 2007. Now is 2010 and we all feel the great productivity the ribbon has brought to us.
My question is why Visual Studio, now 2010, still not use the ribbon? What do you think? Please share.
Ribbon its a great user interface to organize tools like buttons and some kind of small items.
But it doesn't work well, (or at least it's very difficult to achive) when the user interface has to be very personalizable as Visual Studio has to be. And there's also the problem of many windows that are not toolbars, like the solution explorer or the many different designer, they can't be placed very easily.
Whili I'm not saying it's impossible. There is a lot of features that would have to be rebuilt to accomodate a ribbon.
From MSDN Ribbon User Experience Guidelines
Command scale
Is there a large number of commands? Would using a ribbon require more than seven core tabs? Would users constantly have to change tabs to perform common tasks? If so, using toolbars (which don't require changing tabs) and palette windows (which may require changing tabs, but there can be several open at a time) might be a more efficient choice.
For efficiency and flexibility, do users need to make significant changes to the command presentation contents, location, or size? If so, customizable and extensible toolbars and palette windows are a better choice. Note that some types of toolbars can be undocked to become palette windows, and palette windows can be moved, resized, and customized.
Because of some of this reasons I believe Visual Studio works better in a toolbar-based interface
PS: While I don't believe Visual Studio will implement the ribbon, Autodesk products like AutoCAD are very good examples of very complex ribbon-based application.
I kind of think Ribbon would be as bad for Visual Studio as those silly button bars. Working quickly in visual studio is all about good navigational keyboard shortcuts, not mouse clicking.
I have been using Office 2007 for over a year now.
The answer is simple, the ribbon interface is an almost purely cosmetic addition that in fact still slows me down dramatically.
It looks cool, and I like the fact it has more "text" and larger icons from a "Learning" perspective. But after you have "Learned" an interface the ribbon gets in the way. I find the excessively "verbose" text is distracting and causes me to spend more time looking for the desireable command.
Effectively it is just a menu turned inside out and sideways that causes you to have to click far too many times to perform actions. additionally the layout is very unnatural, it begins at the top then switches to the bottom "chunks" then goes into random left to right and top to bottom sections with possible sub menus.
This statement in the original post to me is completely inaccurate.
... Now is 2010 and we all feel the
great productivity the ribbon has
brought to us ...
I end up putting ALL the commands I normally use on the quick access toolbar and "hide" the ribbon to make up for the screen real estate it steals.
If it was put in VS I would do the same thing, add all the common commands to the quick access toolbar and "Hide" the ribbon.
Not really an SO thread, but I think the rationale behind not moving the VS interface to the ribbon was that it is meant for end users, who are typically non-technical. Users of Visual Studio do not fall in that camp (typically ;)) and there would definitely need to be a lot of usability testing and allowing developers to customize the interface to get it to where they're comfortable.
From this MSDN thread, a Microsoft employee marked this as the answer:
I once asked that question too, and the answer was then that the audience for the ribbon are the end-users. Since it uses much space and since the developer is an experienced user, there is no need for ribbon support in Visual Studio.
I agree that they should bring the ribbon to VS because the stacked command bar UI is dated and ugly. I have to look at that garbage for 8-12 hours per day. Let's not even get me started on how frustrating it is when a contextual toolbar grows the height of the toolbar and shoves the top of the text editor down.
But you're unlikely to get anything more than opinion here which is not really the right forum. I'd post it to http://connect.microsoft.com.
Related
Visual Studio 2015 is nice and all, but it's very hard to use when having multiple instance open. I have my Taskbar on the right, and this is what it looks like:
Any ideas on how to clear this up and make it easy to select the project I want, without hunting around?! Extensions welcome.
What do you guys do? Or should I utilize my memory powers more and remember which is which heh.
In VS 2013, there was VS Commands which helped, but they are yet to update it for VS2015...
One suggestion was to have my taskbar at the bottom of the screen. To me this is not feasible on a wide screen because you're losing even more height, where as you generally have more width that you can afford to lose...
I then tried it at the bottom, and it's even worse, since you fit less items in, and they group sooner, so you'd have to hover over VS before you can pick which one to switch to.
Update
As Sergey Vlasov mentioned, here is the window title change in action. Very nice solution, thanks!
You can create short abbreviations for your solutions using the Visual Studio Window Title Changer extension.
Does anyone know of a Visual Studio plugin for viewing PowerPoint slide shows in a pane in Visual Studio? I've been working through a tutorial and I'm annoyed with alt-tabbing between the two applications (I prefer giving Visual Studio the full screen).
Clarification:
I do have dual screens at work, and a 30" display at home, but in my doubtless fussy opinion, opening and arranging multiple windows is much less convenient then having the info in a pane in the IDE for this particular task. There is also the matter being able to cut and paste code from the tutorial into the edit window without having to alt-tab. I'd like something like the internal web browser pane, or in-place help panes in Eclipse.
I very much doubt there would be a VS plug-in for displaying PowerPoint slide shows. I can't imagine very many cases where this would be useful. I never use PowerPoint when doing development work.
Perhaps the only situation where it might be useful is in training, as you've described. But honestly, my recommendation would be to add a second monitor to your computer. Then you can keep Visual Studio maximized on your primary screen, while displaying the PowerPoint slides on the secondary monitor.
I suspect that you'll find a dual-screen setup will not only be useful while you're learning Visual Studio, but continue to pay dividends as you begin working in Visual Studio, as well. The productivity boost of multiple screens is well documented around the web, and my own experience is that I can hardly work without a minimum of 2 screens anymore.
This is really a no-brainer for any developer who values his or her time. Now more than ever, since:
Most mainstream, inexpensive video cards tend to come with two VGA ports (aka "dual head") standard.
The price of less bulky 17" and 19" LCDs are quite reasonable.
Windows XP has mature multiple monitor support; it's been a standard out of box win32 feature since Windows 98.
The multiple monitor support is very good in both Windows XP and Windows 7 (I experienced some minor irritations under Windows Vista, but not nearly enough to be discouraging). And you don't have to buy a giant secondary screen (or even primary screen). Two 17" or 19" monitors will generally be more productive than one large 22" or 24" screen.
I've noticed recently that it seems to be a trend in Windows applications to no longer include the menu bar in an application (the "File Edit ..." menu), instead having the functionality linked to icons seemingly randomly spread around the application window.
for example: IE8, Windows 7 media player.
Is there any usability evidence driving this change? (I, personally, find these apps really hard to use)
If so, can someone suggest where I might find this research and perhaps some guidelines for writing new applications using this style?
Some answers have suggested that it's the "Ribbon" style, which appears to be what I'm looking at. I'm still having trouble finding guidelines or evidence of what works/doesn't work.
The MS Office Ribbon perhaps inspired the latest slew of apps that use multiple icons without text labels in lieu of a menu bar. However, the implementation of these apps apparently failed to understand or realize the advantages of the Ribbon or even what makes a Ribbon a Ribbon.
Controls labeled with icons alone are more difficult to learn than those labeled with text alone [See Wiedenbeck S (1999). The use of icons and labels in an end user application program: an empirical study of learning and retention. Behaviour & Information Technology, 18(2)]. The lack of text labels for groups of controls in these apps can’t help.
Note that the Office Ribbon generally avoids both of these pitfalls by providing text labels for groups of controls (the Office Logo being a notable exception) and text labels for most individual controls (many controls on the Home tab being another notable exception).
After being subject to much research, the Office Ribbon largely preserved the traditional File-Edit-View arrangement of commands found the traditional menu bar. There’s no evidence that there’s anything wrong with this organization.
IMO, icon-scattered UI designs represent a fashion or branding statement, a rather clumsy attempt to appear “state-of-the-art” like Office, and an excuse to decorate the UI with graphics. They are not a usability improvement.
For everything about the Ribbon, see Jensen Harris’s blog.
My critique of the Ribbon. Not that I'm particularly satisfied with the traditional menu bar and tool bar.
It is ribbon. Presumably it is easier to use than the standard menu because it is context dependent. The whole purpose of developing it was that despite the fact Word can do almost anything now, people were complaining it is missing some features just because they couldn't find them. So MS people were thinking hard and ribbon is what they created. Being context dependent it shows you the features you might use right now, not all the features and it saves screen estate so more features actually visible to the user.
Well, after a quick search I found a reasonable explanation of this UI trend. It is based on the Ribbon concept. It traces back from Office 2007 and even Firefox is using it.
References:
http://www.pcpro.co.uk/news/351808/firefox-tidies-up-with-office-2007s-ribbon
http://slashdot.org/story/09/09/23/1846248/Firefox-To-Replace-Menus-Wi
https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Direction_and_Feedback
http://en.wikipedia.org/wiki/Ribbon_(computing)
The ribbon still serves as a navigation area - a combination of a menubar and toolbar that tends to be organized by area (Print, Design, Layout, External Data) rather than traditional style (File, Edit, Tools). While it does take a bit of getting used to things being organized by area, it certainly adds to the usability.
I think the reason IE 8 integrates the menu bar into the same line as the tab is to allow for more viewing real estate (or junky toolbar add-ons). A ribbon would be overkill for something as simple as a browser where 99% of the time you do one of 3 things: Enter a URL, Go to Bookmarks/Favorites, or Print.
If you are writing a Windows-based database system or other complex application, definitely checkout how Microsoft utilizes the ribbons throughout its Office products.
The "ribbon" is nothing more than a FAT toolbar. Such things are getting invented, not because of user request or need, but because of the arrogance of large corporations and bored, rich managers and "developers" sitting around with nothing to do. "Inventing" things is one thing, but FORCING it on everyone w/o preserving the previous, non-cluttered, classic, working, familiar interface is absolute arrogance. People need to be informed. You don't have to put up with it. Say something.
In other words, if I want to write a winforms db application with an appearince like VS that has docked panels and also the ability to show/hide forms within some of those panels, how would I structure the interface? How would I have the ability to open several disparate forms at different times (with big data grids on them) while avoiding floating forms and also using memory efficiently? I want to avoid floating windows.
Check out this article to build a VS like interface:
Visual Studio IDE like Dock Container
I haven't tried the component myself but it looks interesting.
Visual Studio is definetly MDI
In the technical sense, Visual Studio is an MDI application whose document windows are anchored by tab navigation.
MDI refers to "multiple document interface," and refers to the fact that there are multiple documents open and visible inside a larger parent window.
In the modern application development realm, typically MDI has been frowned upon -- but that was the "old school" MDI, with the free-floating windows. Those are widely considered to be a usability nightmare.
On the other hand, MDI implemented as tabs inside a parent window is so successful from a UI consideration that even environment which didn't traditionally have MDI (EG, Mac OS) are implementing them.
In order to implement something like this, you can "roll your own," or you can use any of a variety of custom control/API packages which will allow you to easily develop tabbed-interface MDI apps. One of the last things I did with Infragistics NetAdvantage (before moving away from it) was a Visual Studio-inspired app, with docking sidebars, search results as a pane at the bottom, and all the primary data forms as tabbed MDI documents. (Indeed, WinForms is one of the few places Infragistics really shines.)
In terms of memory management, that will be on you. :)
I think technically Visual Studio would be classed as an MDI.
The main form holds disparate controls. Each of these controls can then be docked as required etc. Visual Studio for example has a single control (with multiple tabs) to display the documents you edit. A single control with multiple tabs that holds (eg) Solution Explorer, Properties etc etc.
As a starting point to creating your own IDE style interface I would create a form with 5 panels, one docked to top, one to left, one to right, one bottom and one 'fill'
Thats your starting point. Add splitter bars to allow the panels to be resized. Each panel can then hold a Tab control, and each tab holds a 'MdiBaseControl'
An MdiBaseControl can be whatever you want. So in VS terms you have things like SolutionExplorer, Properties, Breakpoints, FindResults etc etc.
Each MdiBaseControl can be dragged from its current tab and dropped into any of the docked panels (which then adds it to the Tab control as a new tab)
I just noticed that Developer Express have some controls for building IDE-style interfaces.
In both interfaces, multiple forms can be seen at the same time but in MDI, things float freely. In this sense, Visual Studio is a SDI.
I've never found an "ideal" layout for coding in Visual Studio. I have a three-monitor setup, but it seems that the solution explorer/properties/output/errors/whatever panes are always getting in the way or hogging screen space. It's a bit open-ended, sure, but do you have an "ideal" layout with the myriad of floating/dockable/anchored setups for specific windows? For instance, I like to split vertical code panes between two screens, and typically the solution explorer is anchored to the right of the right-most code pane, but that chews up screen real estate that I'd rather have for the code. I was thinking of floating those sorts of things off to another screen.
Apparently VS 2010 will do a LOT more for multi monitor setups. ScottGu went over this at DevConnections 2008, and a few more times, usually wherever he goes.
I got the impression that the MDI or tabbed codefiles might be able to be detached from the IDE, and float/draggable onto another monitor.
As it stands today in VS 2008, Solution Explorer, Immediate Window, etc are detachable and be able to float onto another monitor, separate from the main IDE.