Other Software > Developer's Corner
Ribbon UI - is it really THAT good?
wraith808:
you can't get to Font or Paragraph properties without those
-tranglos (December 01, 2011, 02:15 PM)
--- End quote ---
Yes you can. I know I have, and I'd forgotten that you can click that. I think the right click menu has it.
UPDATE: I was right... it is the right-click menu.
tranglos:
The ribbon gives you a flexible toolbar. Looking at the example you gave there, that's what it looks like. You just don't get that nice, compact UI with most toolbars. -Renegade (December 01, 2011, 11:05 AM)
--- End quote ---
So this is where we disagree, I don't have a problem with that :) The way I see it, in reply to the part quoted above, the ribbon gives you a flexible toolbar but takes away the menu. I don't miss the toolbars, I miss the menus! A menu is much more compact, faster to navigate with the keyboard and - to me - more discoverable than the ribbon.
If you can't fit in an extra 80 pixels or so at the top when you have monitors at 1920 x 1200... You have a real problem. It's not the software taking up 80 pixels that's the problem. -Renegade (December 01, 2011, 11:05 AM)
--- End quote ---
Yep, and in that vein of thought, with Office 2010 MS came up with the lovely idea of taking the whole page (screen) for what used to be the "File" menu before, and later was the "Office button" in Office 2007. Why do they hate me? :)
If you can't afford a monitor with a modern resolution, then the solution to me seems to be to use older software that's designed for small resolutions. But don't blame the software author for taking advantage of newer technologies that most people have. -Renegade (December 01, 2011, 11:05 AM)
--- End quote ---
Two 23" monitors here, thanks. But IMO you have it backwards. What's the point of buying a bigger screen, if new software is going to take ever more of it and leave you with less?
But, I will concede the point on screen estate. (I just don't like hearing MS's claim that the ribbon is more compact then menu+toolbars. It isn't.) My main beef with the ribbon is that it makes commands much harder to discover (often you see the icons only, while menus give you enough horizontal space for informative descriptions), much harder to navigate than a main menu, and even when I know where a command is supposed to be, the ribbon gets shrunk when you resize the window, and what used to be a big button is now tiny and I can't find it again. After two years of working in Word and Excel nearly every day I should have learned where the things are, but I haven't. To me, that's a failure for which I'm not about to blame myself, since I don't experience similar cognitive difficulties with other software.
As for .NET. Who cares? -Renegade (December 01, 2011, 11:05 AM)
--- End quote ---
Click through for some off-topic .Net loathing...I do, when a program that used to start inside of a second now takes 10, and when it flickers all the time displaying menus or switching views. When I built my last system 4 years ago, I started from this, then upped some of the specs even more. I later swapped a video card for one that can play most of today's FPS games at max settings. I used to have a WD Raptor drive for the system partition (until it broke). I really don;t like waiting, so I built a system that didn't make me wait too much. And still, both back than and today, .Net apps flicker like heck and perform most operations with the urgency of a lazy iceberg. Granted, sometimes coders do things in ways that are inappropriate for the platform, but their suboptimal code would not cause significant slowdowns in native C++ or a Delphi apps. And still the apps crash just like they used to, except what used to be "invalid pointer operation" is now "reference not set to a valid object instance" or some such. It's the same darn error! For the user, .Net gives no gain whatsoever, but it exacts the very high price in loss of performance.
At the end of the day there is 1 and only 1 and exactly 1 consideration that matters: What will make life easier for the people that use the software? Nothing else matters beyond that. Nothing. -Renegade (December 01, 2011, 11:05 AM)
--- End quote ---
On this we totally agree. It's just that the ribbon makes it significantly harder for me, not easier. That is precisely why I am against it.
wraith808:
I do, when a program that used to start inside of a second now takes 10, and when it flickers all the time displaying menus or switching views. When I built my last system 4 years ago, I started from this, then upped some of the specs even more. I later swapped a video card for one that can play most of today's FPS games at max settings. I used to have a WD Raptor drive for the system partition (until it broke). I really don;t like waiting, so I built a system that didn't make me wait too much. And still, both back than and today, .Net apps flicker like heck and perform most operations with the urgency of a lazy iceberg. Granted, sometimes coders do things in ways that are inappropriate for the platform, but their suboptimal code would not cause significant slowdowns in native C++ or a Delphi apps. And still the apps crash just like they used to, except what used to be "invalid pointer operation" is now "reference not set to a valid object instance" or some such. It's the same darn error! For the user, .Net gives no gain whatsoever, but it exacts the very high price in loss of performance.
-tranglos (December 01, 2011, 02:48 PM)
--- End quote ---
But none of this is a function of .NET. I used to be a Delphi fanatic also. And my first forays into .NET were less than stellar, especially because I was converting Delphi apps to C#. But nothing that you said applies to *all* .NET apps; they're a function of how they're implemented. I get no flicker in places that I used to have to code around in Delphi/C++ and use less memory in most cases. It's overkill for some things, but then again, so was Delphi.
...and yes, suboptimal code will slow things down in Delphi. I've seen it. I've dealt with it and had to fix it. As far as the user getting nothing from .NET, it depends on whether the user is paying for development. When the user is paying for a product, nothing that the product is written in is going to do anything for the user. But I've found that once I figure something out in WPF/XAML, the solution is a lot easier to implement, a lot more straightforward, and easier to maintain.
Ath:
But I've found that once I figure something out in WPF/XAML, the solution is a lot easier to implement, a lot more straightforward, and easier to maintain.
-wraith808 (December 01, 2011, 02:58 PM)
--- End quote ---
Yup, that, and stick to MVVM.
wraith808:
But I've found that once I figure something out in WPF/XAML, the solution is a lot easier to implement, a lot more straightforward, and easier to maintain.
-wraith808 (December 01, 2011, 02:58 PM)
--- End quote ---
Yup, that, and stick to MVVM.
-Ath (December 01, 2011, 03:06 PM)
--- End quote ---
MVVM itself is also not a silver bullet, and can be a hindrance in some cases. All of these things (to steer back on subject), from the ribbon (and other UI elements), to .NET (and other frameworks), to MVVM (and other design patterns) are tools. And the same tool is not useful in all situations.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version