interesting argument, and it's definitely worth thinking about these kinds of UI assumptions.
But I'm still in favour of keeping them.
First of all even if they are 'training wheels', the user interface should be understandable by someone who's never used a computer before. Buttons and sliders have real-world analogies and as such if correctly implemented are easy to understand without requiring that the user has prior knowledge of 'the web2.0 way of doing things'.
Secondly, sometimes I just want to zoom right out, or zoom right in, without having to pass through every step in between. This is something that sliders afford which continuous scroll-to-zoom or click-to-zoom doesn't.
Thirdly, right-click to zoom out is not very webby at all, and I doubt many users are comfortable with that UI pattern. I've certainly never used it. Keeping 'webby' is hugely important - and not in conflict with my first point - because there are two relevant points to be aware of when implementing a UI: Firstly you're teaching users how to use the web, and secondly when you implement a UI you can expect (but not require) users to use it in the same way they use other web apps. Right-clicking fails badly on both of these.
This article is weird: Bing has not ditched its zoom slider, it has merely obfuscated it, hiding it behind a pair of (still present) looking glasses. In fact the author even mentions that in the linked article:
> In a way, though, the old slider is still there: all you have to do is hover over the new zoom controls (the magnifying glass buttons), and a new slider appears. From there, you can use the new slider in the same way that you would use the old one.
Now there really are two broad cases, zoom-slider wise:
1. On many mobile devices, pinch and unpinch are becoming pretty standard "zoom" and "unzoom" commands. Since they're analog and when they're handled correctly by the OS, they make sliders redundant as a control device. On the other hand, sliders still have one great advantage: they show the range of motion available and the position of the current view within that range
2. On non-mobile devices, you can not even be sure the device has a hardware way to manage zooming, and even when it does that devices may not be analog or accessible. Or it might be used for something else already (mousewheel to zoom on the map in a web page? How about no?)
also, taking common UI patterns on mobile devices and using their popularity as an argument for using those patterns on the web seems invalid to me. Sure, it works on mobile - but users have a different expectation of how things work on mobile.
I both agree and disagree: new usage patterns on mobile should be studied and considered to see whether they can be adopted on desktop/non-mobile devices. For instance applications which keep their state permanently saved are pretty much mandatory on modern mobile devices, but very rare on desktop (Notational Velocity is one of the few apps I know which does that), yet not having to save ever would be a pretty nifty desktop UI pattern.
On the other hand, mobile UI patterns don't necessarily translate well indeed. There will probably be a lot of chaff, just as for a long time mobile UI suffered because developers were using desktop UI patterns on mobile devices which have not the wrong resolutions (nb: modern mobile devices have far higher resolutions than desktop machines 15 years ago) but the wrong input and output (physical size, shape, rest position, …).
My fat fingers find pinch and zoom to be an annoyance on my phone, I nearly always go for the + button as if I zoom wrong or throw the map around it starts downloading more stuff and is momentarily unresponsive. So I find the buttons increase the speed and accuracy of my zooming.
It's premature to dump them until we can be sure that the majority have a great experience without using them.
Sometimes a UI goes wonky, and I find it useful to be able to click on the zoom as a way to 'reset' the display in a somewhat predictable way.
This may be like pressing an elevator call button to make it come faster, but I still like having some graphical evidence of an offered functionality. Without a zoom slider, then it's not clear whether other zoom functionality is enabled at all.
When you have 2-dimensional scrolling device (trackpad, Mighty Mouse for the first day before scroll ball clogs up) zoom-to-scroll is very awkward and annoying — you expect the 2d scrolling mechanism to scroll the 2d map.
But I'm still in favour of keeping them.
First of all even if they are 'training wheels', the user interface should be understandable by someone who's never used a computer before. Buttons and sliders have real-world analogies and as such if correctly implemented are easy to understand without requiring that the user has prior knowledge of 'the web2.0 way of doing things'.
Secondly, sometimes I just want to zoom right out, or zoom right in, without having to pass through every step in between. This is something that sliders afford which continuous scroll-to-zoom or click-to-zoom doesn't.
Thirdly, right-click to zoom out is not very webby at all, and I doubt many users are comfortable with that UI pattern. I've certainly never used it. Keeping 'webby' is hugely important - and not in conflict with my first point - because there are two relevant points to be aware of when implementing a UI: Firstly you're teaching users how to use the web, and secondly when you implement a UI you can expect (but not require) users to use it in the same way they use other web apps. Right-clicking fails badly on both of these.