Since most of the people having to change from Office 2003 to 2007 in their office are confused, it amuses me if there is an objective reason for abandoning the good old interface of previous Offices.
It would also be nice to have some backing facts when people ask about rationale of change. For example I would be interested in:
Was there a study telling that new users without any prior Office knowledge can adapt or use the new interface more efficiently?
What are the strong points of the new UI from a designer perspective (which function is more accessible than before; which important pieces of information are more apparent? etc.)
For more answer than you probably want, you should read this excellent series of posts by an Office UI developer about why they decided to build a new UI for Office 2007. The basic reasons boiled down to:
The old, toolbar-based UI was already overcluttered, and there was no place to put new features.
It was difficult for users to discover the features that were already there.
Jensen Harris, one of the Office 2007 team, wrote extensively about the design process, the information they used to guide the design, and how they evaluated the designs they came up with: see http://blogs.msdn.com/jensenh/archive/tags/Why+the+New+UI_3F00_/default.aspx for the main set of articles and the rest of his blog for additional info.
One thing I think worth keeping in mind is that the ribbon UI isn't designed just for existing users.
I personally think that it IS more user friendly once you get to know it (it makes sense to see something visually rather than bury it in a menu), and from the anecdotal evidence I've seen* many new users prefer it.
We just started rolling it out at work, and while there have been grumbles, there have also been many positive reactions to it.
Microsoft published a paper on this. I haven't read it.
http://download.microsoft.com/download/1/6/f/16fd06b3-7059-4e21-adf4-9fbdcb9a2853/MsftOfficeUIAnsResearch.pdf
I guess the new ribbon UI provides a more natural and better user experience than the old one. People usually complain coz they are so used to the old way of doing things.
An example of bad design in the old UI is in the "File" Menu, you have the "Exit/Close", which does not make sense, as with the windows xp taskbar "Start" button, that contains the "Shut down", notice how windows vista/7 has the windows logo instead of the "Start" word.
Just my two cents.
Related
For common elements, such as a logout button on a website, save button in an application, need to be presented to users in an standard, easily discoverable way. How do you go about deciding where in your application to place these elements? Do you research similar apps and try to follow convention? Is there any database that attempts to track the use of these common elements or is this too hard to capture?
The goal is to put UI elements where users expect to find them. You want to leverage the knowledge that they already have about how applications work.
So, looking at the the UI elements for the OS that you are targeting is helpful. Unfortunately, there are some key differences here between Windows and Mac, you will have to pick one or switch based on the OS if you target both.
Looking at applications that are similar to yours is generally not a good idea unless you believe that people using your product are already using these other products and you want them to switch.
Instead, you look at products that are complementary to yours, or products that you expect everyone is familiar with. At one point it was a good idea to look at Excel and Word to know how an Windows application should work; But I don't think that the current versions of Excel and Word are a good model, they deviate too much from the way the OS works. You could still use older versions - before the ribbon, if you are targeting Windows.
It's best to be a bit conservative, choosing applications that have been out for a while and people are likely to be comfortable with rather than chasing the latest design innovations that are coming out of Apple and Microsoft.
I research similar apps and try to follow convention...
E.g. logout goes up in the top right near the "X"/close in most applications
Save/Edit buttons towards the bottom of the thing I'm editing... since contextually they happen after I finish the editing I just did.
Then again, you have apps like Outlook... that have the send/save buttons at the top.
In general though... I have application-wide actions (e.g. login/logout/help user info at the top)
Item specific tend to be inline or just after the item they are adding/editing.
I totally agree with leveraging knowledge that the user already has. Every techie is (or probably is) familiar with http://www.dice.com. It frustrates me to no end to see that their website is designed with the logout "link" (not even a "button") at the very BOTTOM of the page. In this age of security conciousness, what a place to put a logout link ???
I have used DeLorme Street Atlas USA mapping software ever since Windows 3.1. About five or so years ago, they changed their entire user interface, moving AWAY from all of the features that make application software in the Windows environment easy to learn and navigate and SIMILAR from one application to another, and TO a totally foreign user interface, unique to their individual product offering.
Was it necessary ? probably not... What was it's impact to the current user community ? probably not thought about... What was it's impact to someone new to Street Atlas USA ?? Probably LESSENED the adoption rate of the software product, because it looked so foreign compared to a user's already-used applications developed with the common Windows-based look and feel.
Although books can be written on how "we" dislike Microsoft, the value-added benefit to Windows since it's infancy with Windows 3.1 was that you could create totally different software applications, but have a SIMILAR navigation style threaded throughout all of the applications, LESSENING the new application learning curve, and INCREASING the adoption rate amongst software applications for the Windows user.
Leveraging positive current user knowledge can only increase the adoption rate of a software product. Why re-invent the wheel, when the current wheel is known and adequate ?
We are currently an Infragistics NetAdvantage Select customer and have been for a few years. Their controls are ok but not what I would call great but the time invested in learning them to date is the main reason we stick with them. We use both ASP.NET and Winnform controls.
As we are due to renew, we are considering DevExpress as an option as they seem to offer much of the same functionality.
For anyone that has made this move fro mInfragistics to DevExpress, how have you found it? A step forward or back? Pros and Cons to doing so?
My company is using DevExpress and we are very satisfied with their suite. We have never used the Infragistics suite, so I can't talk about the process to switch from Infragistics to DevExpress.
Generally, I find the DevExpress controls very easy to use and implement in our applications. Some controls have a small learning curve like the DevExpress TreeList but it is not a huge issue.
One thing I dont like with some of their controls is the property "Properties". This property is used to set additional options to the control.
Per example to set the max length of a textedit (textbox of devexpress) :
textEdit.Properties.MaxLength instead of textEdit.MaxLength
So, their controls are great and have a great look but I think the main quality of DevExpress is their support. You can ask a question on the support page and you will receive a answer within one day, maybe two days if the question is complex.
So, if you are not statisfied with Infragistics, try DevExpress. You can download a trial version so you have nothing to lose.
I will second that you should give Telerik a look. Their support is top notch in the industry. They give you good real world examples and their documention I feel is second to none.
I took on a contract with a company entrenched in the controls you're considering and I wouldn't use them if they were free.
The reasons I make this statement is their documentation in my opinion was bad. When I spend money on a RAD type control suite, it's to make my work easier and faster to production. I found in some cases it was easier to just figure out how to make built-in controls do what you want versus trying to figure out the problems I was having with their controls.
Their samples are kind of like Microsoft samples used to be. They are fluff based for Tech sales to show at a seminar "how easy something is to setup" but in real world if you used the techniques and monitored viewstate and traffic their examples generated, you'd be less than impressed.
I didn't have an account to submit support tickets but I had 4 over the course of a month submitted through the account holder and to my knowledge didn't get an answer back on any of them. (That could have been a break down with the person I had to go through but I doubt it.)
When it comes to Telerik's, Rad controls for Ajax, very seldom I can't figure out what I need to do by either looking at the sample Visual Studio sample web solution that get's installed combined with their documentation.
Good luck in your search and even if you don't consider Telerik, I would strongly suggest you look for other options.
Slightly unrelated but you might also want to evaluate the Telerik controls. We have been using them for years. Exceptional controls and support. And their controls work with ASP.NET MVC as well.
Just a happy customer here.
Not related to controls, but with DevExpress suite you get superb VS addins for free - CodeRush and RefactorPro.
Like Francis, I haven't made the move from infragistics to devexpress, I started with devexpress. I can speak to the learning curve. Depending on the controls you're going to use, and how you intend to use them, there can be very little learning curve.
The data manipulation controls (xtragrid, xtrascheduler, xtracharts, etc.) are extremely easy to use when binding to a database. Less so when binding to persistent objects. Their XPO, oddly enough, isn't as easy/intuitive as it could or should be when databinding though also not incredibly hard.
The major benefit for me was documentation. Their documentation site as well as their tutorial videos are top notch and really get to the point without using trivial, nor overly-complex examples.
As Francis said, the response time on tickets, and the (usual) clarity and detail of the replies - they often include small projects showing what you're supposed to do, or will alter your project that you submit with a ticket - is second to none imo.
Moving from Infragistics to Devexpress is tough! I have been using Infragistics for past 2 years as a Windows and a Web developer and now I am using Devexpress at a different place.
It is slightly difficult for the developer to use the Devexpress control due to its versatile properties. If you take a example of grid in DevExpress (in case of Windows) there are 2 parts:
The main display part and
The view part so you can manage them during the binding
On the other hand there was no such thing in Infragistics, so it was plain and simple to use.
Similarly there are lot of such difference between Infragistics and Devexpress controls.
Now What I feel is if you are interested in having some complex functionality with lot of tedious logic then Devexpress is good for you! Or if you want to keep the things simple with decent functionality then Infragistics is good for you.
So as you know it is very difficult to tell which one of these is really superior - we have to choose them based on our own requirements.
Stick to Developers Express. They have much better upgrade path and almost all breaking changes are in written.
I have been using them since 2003 and still ahven't found a better match.
I migrated from Infragistics to DevExpress. Will never go back to Infragistics as their objects are much heavier and performance is not too great. Documentation is terrible and their examples are very juevenile. Infragistics data grid inline editing (Excel like) is a nice feature which is not available in DevExpress. Other than that, data grid, master, detail setup, data grid dropdown list declaration and other feature are much more streamlined in DevExpress.
I have been using Telerik RAD Controls since several years. I am very satisfied with the ASP.NET Ajax and WinForms controls. I have not used DevExpress or Infragistics controls before but I had a look at both when I took the decision to use Telerik.
This is probably too late, but as I found this post while asking the same question I thought I would add my comment with respect to Telerik. I have previously used Infragistics, which I found OK, but I thought the performance wasn't great. Recently I worked a contract with a company who were using Telerik for Winforms and what we discovered was that there were a number of bugs in their controls. There support was great and they were quick to respond to questions or comments, but unfortunately most of the time when we raised a question on why something wasn't working, the answer was that it was a bug in their control. also their documentation states explicitly that their controls are not intended to be inherited, so while building your own custom control off the top of their control seems to work in most cases, it isn't recommended.
I find that most of microsoft's new programs are very hard to use.
Microsoft Office 2007 (word especially) I find to be hard to use.
Microsoft IIS 7.0 is a PAIN, I never remember which icon to click on, things are just to cluttered and hard to find.
As a programmer, we have to design according to what people are used too, what exactly is MS telling us to do?
we have to design according to what people are used too
Well that's a slight misconception. You're not wrong that people familiar with something will appreciate the interface remaining familiar, but not all change is bad. You have to weigh the power of the change up against the harm it does to veteran users.
Lets take Office 2007 as an example.
The ribbon interface is a huge departure from the interface Office has used for as long as I can remember but there is sound logic behind it.
User functions are grouped by activity and it's very easy to change which set of functions you're looking at.
They're also contextual so some thing only show up when you're on a table or an image (etc).
These both help keep the clutter down - something really quite useful as these apps grow in feature-sets. Rather than spending hours choosing and customising a set of toolbars, you have access to everything through the tabs.
And Microsoft did this all the right way. They tested the interface on lots and lots of real people. They listened to see what worked and what they should fix or drop. They also kept some legacy keyboard shortcuts for seasoned pros.
The redesign effort was targeted at making life easier on beginner and intermediate -level users. Mission accomplished. The problem you're having is overcoming your familiarity but I can't be more helpful than say: It'll happen in time, but you'll manage it in the end.
Look, I'm just a simple caveman, scared by your post-modern architectures and vroom vroom machines go honk. I'm used to the simple life of the paleolithic era; charcoal cave paintings and bone-based technology. I can't make heads or tails of your fancy ribbon UIs and pointy-clicky icons. That's why I'm never upgrading from DOS. The old ways were always the best, and learning new ones bad like fire.
Well, Microsoft has to balance this. On one side, users scream for new features and change-for-change's sake in a lot of MS software. On the other, lack of backwards compatibility (including subjective UI compatibility) is a deal breaker. Really no way to win there.
That said, I don't think we need to design according to what people are used to; neither does Microsoft. Change will never happen if we just do what has always been done before. IIS is not developed for programmers; it's developed for IT people. And the new interface serves them well. Likewise, Office is designed for office drones, not programmers, and the new Office is very discoverable for that particular group.
I think they take a while to get used to, but I do like them. (Althought I will fully admit I am a mac person and I like the mac UI a lot better).
The biggest thing I've seen about the UI that is difficult is the fact that it is so much different from previous versions (I'm talking about the current version of Office). That seems to be where most of the rub is.
The rule I was taught about UI design is that things need to be familiar to the user (that's really is what makes it "intuitive"). MS broke that rule ......but from a business perspective they are allowed a little leeway when doing this simply because they control so much of the market share. Ultimately, they know that a radical change won't cause a loss of much market share because for most people and businesses there isn't a real viable alternative. (I know there is open office, but migrating a mid to large office to it will cost as much money or more as it will to just continue using the same product).
Do we have to design according to what people are used to, yes we kinda do. Does this mean we have to make it look like what MS is doing now, not necessarily. What we have to do is create a design the users can relate to. They have to be able to make a jump of logic from what they know already to using the products we create. If not, they most likely won't use the application unless they are absolutely forced to.
User interface and user experience are totally separate concepts. (Simon Guest; User Interface Blog.)
Microsoft did quite a bit of research in the raw usability of Office 2007, and found that while there is a learning curve for people like yourself, or me, who are experts in the tool, newer users and non-experts experienced much greater discoverability of more advanced features, and wound up using more of the application's features and power. Yes, there is a learning curve if you knew Office 2003 inside-out (which, frankly, few of us really did).
Now I'm not making apologies -- Microsoft's UIs haven't always been easy to use, and sometimes they fail miserably. (Personally I think not standardizing all of their office products on the Ribbon is a classic example -- there's a large context switch in my brain when I open Project or Visio, compared to when I open Word.)
As for what developers are "supposed" to do: Bear in mind that the ribbon isn't ideal for every scenario. If you're using it as a glorified, prettified toolbar, it's being used incorrectly. It's designed to help you organize literally hundreds (if not thousands) of commands in a way that makes them discoverable to your end user. It's supposed to reinforce the traditional experience of discovering the abilities of your application in a safe way (see any edition of About Face), when the depth of your application is too great to function within menus.
Aside from that, bear in mind that we should generally be making the most appropriate UI for our own audience, as Microsoft is attempting to do for its own audience. Again, we may find these things more difficult to use, as we are used to doing things a set way -- but it's the right thing (typically) for Microsoft to do. Remember that we programmers are not the target users of most UI. (How many of us turn off visual themes, for example? Now how many normal end users? BTW, I don't fall in that camp; I'm one of the few who actually finds Vista moderately attractive.)
Again, at the end of the day, what Microsoft does matters only to the extent that it becomes what your users expect, and then only if you can't educate them that "your way" is better. In any event, if usability is truly critical for you and your users, it's time to invest in usability testing and ensure that your application really is as usable as you think it is. And start reading usability sites. (You don't have to agree with them all, but understand them.) Here are some samples:
AskTog (Bruce Tognazzini, inactive but the archives are a treasure trove)
UseIt (Jakob Nielsen)
jnd.org (Don Norman)
Office User Interface Blog (Jensen Harris)
Microsoft Windows User Experience Interaction Guidelines (The holy word on Windows)
It's interesting because there was a lot of talk about the usability testing that went into the design of the Ribbon controls, but along with almost everyone else I know I find them very difficult to use. I keep losing controls that I need and not being able to get them back until I've cycled through another three or four document views looking for them. I instinctively move my mouse to menus that no longer exist.
I wonder if they would be easier to someone not accustomed to the earlier office products- maybe this is who they did their usability testing with. I don't think the design of the new interfaces is bad as such, but it is different enough that for those of us who don't spend our whole time staring at Office but have been using the product for a long time it makes life difficult. I guess most real power-users would be doing most tasks from keystrokes anyway which presumably haven't changed too much.
The business problem is really that they need an incentive to upgrade and so they keep adding new features ( who do you know that uses all the features of Word ) and then they need to find ways to present those without making the application impossibly cluttered, which was certainly happening in the previous version of Office.
I'm not sure what we take from this as developers- maybe it's that we should design for usability from the start or find ways to make the transition between old and new functionality as easy as possible for our existing users.
Microsoft IIS 7.0 is a PAIN
I'm relieved to hear that others have found the new IIS UI a challenge. I stumbled into it without being forewarned, and was completely discombobulated. There is so much clicking around. You have to memorize where the feature is, or click and click. I don't know of a way to see all of the IIS settings at once (not that you could before, either, but at least you could stay in the single tabbed dialog).
I think it is really hard to adapt to an entirely new UI when you are so familiar with the old one. I am similarly disoriented by the ribbon menus. More clicking around to find the features. And not everything is in the ribbon. Some is in menus accessible from other entry points, such as file properties.
For new users who never saw the old UIs, it probably isn't so much of a problem.
I guess what I really dislike is having to spend the time learning the new UI, at the least convenient time. There is an immediate loss of productivity when you have to learn the new UI. You can't just drop into IIS, configure the website, and be on your way. The first few times, it's going to take a lot longer. Maybe with growing familiarity, we will come to like the new UIs better.
I wish they had given the option to show the menus for us old fuddy duddies.
I had a meeting with one of the Microsoft Office guys last year when I brought up the same points. His point was that the number of features had grown so much that a new method of displaying them was required. I was not entirely convinced and found it amusing that Microsoft are so touchy about the problem that he had a very nice, well-prepared PowerPoint presentation to give to try and explain it.
MS is trying to give users more power by being able to click this to do this or that and try to make what others may see as very advanced functions simpler to use and more powerful than the previous ones. I remember going from IIS 3.0 to 4.0 where suddenly, there are all these new buttons to click and things are different but it is kind of better. I also remember going from Windows 3.11 to 95 having its own shock of updating things.
Did you ever try watching a movie on VHS and on DVD or go from cassette to CD? Remember how the DVD suddenly had all these new features like chapters, no need to rewind, bonus features that you could just go to and not have to fast forward to find? Similarly how a CD organized things so much better than a cassette? Another point would be to look at TVs where it used to be very few options on a TV: There were 2 dials, the power and volume where combined into one place, and a few other knobs were all we had but now you have TVs where you can store favorites, closed captioning options, sound setting, and color style that could scare some people that remember the old days where you had to physically pull a knob to turn on the machine.
I find that most of microsoft's new
programs are very hard to use.
If you feel so, do yourself a favor and change to Mac. I did it and wont go back to windows. So much time wasted to achieve little things with Windows.
And Apple has Style Guides for GUIs. You dont have to stick to them, but as far as I can tell most developers do.
To prevent a Mac-Windows-Flamewar I would like to point out that this is totally my opinion. Please dear Windows user, do not feel attacked by my opinion.
Is it worth to try to keep your GUI within the system looks ?
Every major program have their own anyways...
(visual studio, iexplorer, firefox, symantec utilities, adobe ...)
Or just the frame and dialogs should be left in the system look 'n feel range ?
update:
One easy exemple, if you want to add a close button to your tab, usually you make it against your current desktop theme. But if the user has a different theme, your close button is out of place, it doesn't fit the system look anymore.
I played with the uxtheme api, but there is nothing much you can do, and some themes i've seen are incomplete sets.
So to address this issue, the best way i see, is to do like visual studio/firefox/chrome roolup your own tab control with your theme...
I think, that unless your program becomes a very major part of the users life, you should strive to minimize "surprises" and maximimze recognizability (is that even a word?).
So, if you are making something that is used by 1.000 people for 10 minutes a day, go with system looks, and mechanisms.
If, on the other hand, you are making something that 100 people are using for 6 hours a day, I would start exploring what UI improvements and shortcuts I could cram in to make those 6 hours easier to deal with.
Notice however, that UI fixes must not come at the expense of performance. This is almost always the case in the beginning when someone thinks that simply overriding the OnPaint event in .Net will be sufficient.
Before you know it you are once again intercepting NC_PAINT and NC_BACKGROUNDERASE and all those little tricks to make it go as fast as the built-in controls.
I tend to agree with others here- especially Soraz and Smaci.
One thing I'll add, though. If you do feel that the OS L&F is too constraining, and you have good grounds for going beyond it, I'd strive to follow the priciple of "Pacing and leading" (which I'm borrowing here from an NLP context).
The idea is that you still want to capitalise as much as possible on your intended audidences familiarity with the host OS (there will be rare exceptions to this, as Smaci has already covered). So you use as much as possible of the "standard" controls and behaviours (this is the "pacing") - but extend it where necessary in ways that still "fit in" as much as possible (leading).
You've already mentioned some good examples of this principle at work - Visual Studio, even Office to some extend (Office is "special" as new UI styles that cut their teeth here often find their way back into future OS versions - or de-facto standards).
I'm bringing this up to contrast the type of apps that just "do it their way" - usually because they've been ported from another platform, or have been written to be cross-platform in GUI as well as core. Java apps often fall into this category, but they're not the only ones. It's not as bad as it used to be, but even today most pro audio apps have mongrel UIs, showing their lineage as they have been ported from one platform to another through the years. While there might be good business reasons for these examples, it remains that their UIs tend to suck and going this route should be avoided if in any way possible!
The overriding principle is still to follow the path of least surprise, and take account of your user's familiarity with the OS, and ratio of their time using your app to others on the OS.
Yes, if only because it enables the OS to use any accessability features that are built in like text-to-speech. There is nothing more annoying for someone who needs accessability features to have yet another UI that breaks all the tools they are used to.
I'd say it depends on the users, the application and the platform. The interface should be intuitive to the users, which is only the same as following system UI standards if they are appropriate for those users. For example, in the past I have been involved in developing hand held systems for dairy and bread delivery on Windows CE hand helds. The users in this case typically were not computer literate, and had a weak educational backround. The user interface focussed on ease of use through simple language and was modelled on a pre-existing paper form system. It made no attempt to follow the Windows look and feel as this would not have been appropriate.
Currently, I develop very graphical software for a user group that is typically 3rd level educated and very computer literate. The expectation here is that the software will adhere to and extend the Windows look and feel.
Software should be easy and intuitive where possible, and how to achieve this is entirely context dependent.
I'd like to reply with another question (Not really Stackoverflow protocol, but I think that, in this case, it's justified)
The question is 'Is it worth breaking the OS look and feel?'
In other words,
Do you have justification for doing so? (In order to present data in some way that's not possible within normal L&F)
What do you gain from doing so? (Improvinging usability?)
What do you lose from doing so? (Intuitiveness & familiarity?)
Don't simply do it 'To be different'
It depends on how wide you would define system look'n feel... But in general, you should keep it.
Do not surprise the user with differentiating from what he is used to. That's one of the reasons why we call him user ;-)
Firefox and Adobe products usually don't because they are targeting several plattforms which all have their own L&F. But Visual Studio keeps the typical Windows L&F. And, as long as you are developing only for Windows, so should you.
Apart from the fact that there is no well-defined look-n-feel on Windows, you should always try to follow the host platform native L&F. Note however that look-n-feel is just as much about how a program behaves as how it looks. Programs which behave in a counter-intuitive way is just as annoying as programs sporting their own ugly widgets.
Fraps is a good example (IMHO) of a program which is actually very useful, but breaks several user interface guidelines and looks really ugly.
If you're developing for Apple's Mac OS X or Microsoft Windows, the vendors supply interface guidelines which should be followed for any application to be "native".
See Are there any standards to follow in determining where to place menu items? for more information.
If you are on (or develop for) a Mac, then definitely YES!
And this should be true for Windows also.
In general, yes. But there's the occassional program that does well despite being not formatted for all the OSes it runs on. For example, emacs runs pretty much contrary to every interface guideline on OS X or Windows (and probably even gnome/KDE) and it's not going away any time soon.
I strongly recommend making your application look native.
A common mistake that developers who are porting an application to a new platform seem to make is that the new application should look-and-feel like it does on the old platform.
No, the new application should look-and-feel like all the other application that the user is used to on the new platform.
Otherwise, you get abominations like iTunes on Windows. The same UI design may be exactly right on one platform and very wrong on the next.
You will find that your users may not be able to pin-point why they dislike your application, but they just feel it hard to use.
Yes, there are valid exceptions, but they are rare (and sure enough, they tend to be the major applications like Office and Firefox, rather than the little ones). If you are unsure enough to have to ask on StackOverflow, your application isn't one of them.
I was playing a bit with Windows Vista (still using XP) and I liked how the standard Control Panel worked. Do you think this design is good also for normal applications?
I like the idea of showing main topics with large fonts + icons. Details within each main topic are displayed using a small font and are immediatelly accessible without the need to browse the menu. Probably everybody knows Vista, but anyway, here is the Control Panel layout.
Compared to a classic layout of icons for main topics and menu for minor topics, the Control Panel GUI seems to be good at first sight.
I haven't seen any app using this kind of GUI, so I don't know if I should rather use the common approach with icons and menu for a common application? Maybe this Control Panel GUI is suitable only for setting some options, other than working with any data?
I think it's suitable for certain types of applications. As usual with usability related questions, "it depends". I would guess one class of application this is good for is one that you don't use very often, and/or might be used by different people at different times. It is similar in concept to a wizard in that it presents you a list of choices, and selecting a choice takes you to a new page.
Whether this sort of thing is suitable for your application, it's hard to say. The best way to answer that question is to mock up your application and do some hallway usability testing. I would guess, though, if you're thinking of using this for an application people will use a lot, this sort of interface will be annoying. If you're dealing with perpetual beginners or casual users it might be a fine way for someone to start using your program.
I'm on the fence on this. The old Windows XP layout got cluttered quickly with programs adding their own control panel applets, while the new Windows Vista layout can be annoying to process visually at first. The search feature really helps (though not nearly as slick as Mac OS X's search) but I'm not a fan of visually laying out something that's better seen in a list into two distinct columns containing the same type of data. In list/details form it's intuitive for a user to sort the items through different attributes. I find this new presentation in the IIS 7 management applet to be particularly troublesome.