Slashdot Mirror

Wow, maybe the screenshot of his taskbar explains why he simply couldn't see how bad this interface design is. Who in their right mind could use that? the task buttons would be floating out in the middle of NOWHERE. As is the start button, but its possible that it will respond to the bottom left pixel anyway [i don't use windows]

Bad design, trying to rip off the entire macos gui in one application, trying to be safari, opera, and firefox all at the same time. Gah!

Where IE7 uses a check-mark, Mozilla uses a black dot. The concept is identical.

What the heck is up with having 7 buttons in such a small area in this screenshot? And what the heck do the bottom-right 3 do?

Just a point, the design should incorporate both form and function. I agree that a program's user interface will vary according to the requisite tasks that the program will have to perform. However, the UI of Internet Explorer 6 had a menu bar where most users would expect a menu bar - this isn't the case in the original parent's screen grab. So, if it has been changed, and if it was well designed to meet the function it was intended to carry out, either IE 6 or IE 7 beta is badly designed.

The placement of the refresh button is inconsistent with where it was in IE 6 also, and it's not the same as it is in Safari, Opera, Firefox, Konqueror, and probably others I can't recall at this time. It's counter-intuitive to put the refresh button, which is associated with navigation, so far away from the 'back' and 'forward' buttons, and even further still from the 'home' widget.

The layout of this implementation seems badly thought out, it is inconsistent with earlier UI models. It may be the easiest thing to change, but it also seems to have been changed for no reason other than it was easy to do. The widgets are in the wrong place. The menu bar is in a completely new place, committing the same sin of design that OpenOffice.org commits on the Mac. The new tab button, which the parent poster did not highlight, but which you will find referred to in this review or in this image is positioned on the tab bar itself, whereas it would be better placed outside of it, perhaps where the 'home' button is, such as it is implemented by default in recent versions of Opera.

I am not a professional software designer, I am not a programmer other than as a hobbyist. However, ergonomics and design features do interest me. I disagree however, with part of your claim that

If the UI determines the features or the other way around your design is flawed. A proper design allows for an UI which is independent from the application featureset.

The UI should not determine the features, we agree here. It's part of the reason, as an Apple user, I am appreciative of the requirement of a one-button mouse, but the compatibility with a 3-button mouse. The UI should be consistent in how it houses all the features (i.e. they are in intuitive locations, not only in right click menus, nor orphaned widgets).

Your other point, that the UI must be 'independent from the application featureset', is not the same thing. The UI should be designed around the featureset, the form should give complete access to the function. If the location of the menu bar, or the refresh button, or the width of the search engine bar is locked down, or invariably hard coded, this does nothing to accommodate the user who isn't used to this gratuitous redesign and relocation of UI components. They all provide sufficient functionality, in that they'll work when you click them I'm sure. But they are still badly designed from an early stage, and even if it can be pulled out of the fire now, and the placement of objects made consistent, the original post said I believe that it looked like something from an inexperienced group of developers, rather than team behind the most widely used browser on the web.

Just a point, the design should incorporate both form and function. I agree that a program's user interface will vary according to the requisite tasks that the program will have to perform. However, the UI of Internet Explorer 6 had a menu bar where most users would expect a menu bar - this isn't the case in the original parent's screen grab. So, if it has been changed, and if it was well designed to meet the function it was intended to carry out, either IE 6 or IE 7 beta is badly designed.

The placement of the refresh button is inconsistent with where it was in IE 6 also, and it's not the same as it is in Safari, Opera, Firefox, Konqueror, and probably others I can't recall at this time. It's counter-intuitive to put the refresh button, which is associated with navigation, so far away from the 'back' and 'forward' buttons, and even further still from the 'home' widget.

The layout of this implementation seems badly thought out, it is inconsistent with earlier UI models. It may be the easiest thing to change, but it also seems to have been changed for no reason other than it was easy to do. The widgets are in the wrong place. The menu bar is in a completely new place, committing the same sin of design that OpenOffice.org commits on the Mac. The new tab button, which the parent poster did not highlight, but which you will find referred to in this review or in this image is positioned on the tab bar itself, whereas it would be better placed outside of it, perhaps where the 'home' button is, such as it is implemented by default in recent versions of Opera.

I am not a professional software designer, I am not a programmer other than as a hobbyist. However, ergonomics and design features do interest me. I disagree however, with part of your claim that

If the UI determines the features or the other way around your design is flawed. A proper design allows for an UI which is independent from the application featureset.

The UI should not determine the features, we agree here. It's part of the reason, as an Apple user, I am appreciative of the requirement of a one-button mouse, but the compatibility with a 3-button mouse. The UI should be consistent in how it houses all the features (i.e. they are in intuitive locations, not only in right click menus, nor orphaned widgets).

Your other point, that the UI must be 'independent from the application featureset', is not the same thing. The UI should be designed around the featureset, the form should give complete access to the function. If the location of the menu bar, or the refresh button, or the width of the search engine bar is locked down, or invariably hard coded, this does nothing to accommodate the user who isn't used to this gratuitous redesign and relocation of UI components. They all provide sufficient functionality, in that they'll work when you click them I'm sure. But they are still badly designed from an early stage, and even if it can be pulled out of the fire now, and the placement of objects made consistent, the original post said I believe that it looked like something from an inexperienced group of developers, rather than team behind the most widely used browser on the web.

No really, they innovated a lot. Look at http://www.clothedandy.com/Writings/IE%207%20Beta% 201/Phishing-and-tabs-settings.png

Enable tabbed browsing (requires restart

I don't know if laugh or cry. Really.

it's just me who finds the new layout horrible?

Really, look at this: http://www.clothedandy.com/Writings/IE%207%20Beta% 201/screenshot.png. Why on earth did they put the "file edit view etc." menu between the tabs and the final page?

I mean, it's stupid. It "disassociates" tabs from the page, and it puts that menu in the middle. Why put in such relevant place a menu that it's so rarely used?

It's clearly a huge usability mistake IMO. It looks like IE developers though: "saving screen space == good usability". It's not. Good usability is good usability, and seeing that "file edit" menu there hurts my eyes.

I consider it rather strange that the renderings of the acid2 test pages IE7 produced in this guy's review differ somewhat from the results a colleague of mine got during his test with IE7 on Longhorn Beta 1.
 
Not that unreproducible behaviour of certain MS products is strikingly unfamiliar to me, though I still wonder what has happened there, and if this is going to be fixed (as well as the whole rest of the CSS-mess in IE) in the final version...