The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Scroll Wheel:  Which way is zoom in?

My inclination is scroll forward -  wheel toward screed - is zoom-in.  I've seen it done both ways.  It's a CAD stype geometry/math app. in case that's pertinent.

TIA
Brad Siemens Send private email
Wednesday, May 14, 2008
 
 
I guess stype means style/type...
Brad Siemens Send private email
Wednesday, May 14, 2008
 
 
And screed is screen/display?!  Let's just forget the whole thing.  Nap time.
Brad Siemens Send private email
Wednesday, May 14, 2008
 
 
Scroll forward is pretty standard for "zoom in" in my experience. But why not have a setting that lets them flip it either way?
dood mcdoogle
Wednesday, May 14, 2008
 
 
done and done.  Thanks!
Brad Siemens Send private email
Wednesday, May 14, 2008
 
 
Avoid user settings.

The ability to flip the meaning will make everything much harder: your code, your manual, your support, and your customers supporting each other. User settings should never be used to transposed an unresolved design issue to the even less informed users.

Do a usability test and use empirical information to make a wise choice.
Karel Thönissen Send private email
Wednesday, May 14, 2008
 
 
In my app wheel away from you is zoom in - so rolling toward screen.  But shift-Lbutton and moving the mouse toward you is zoom in.
Seems inconsistent I should probably change it.

ps. Do have an alternate for laptop users
Martin Send private email
Wednesday, May 14, 2008
 
 
In IE, Ctrl + scroll back makes the text larger which is equivalent to zoom in. It makes sense to me, think of bringing a book closer to your face. If you scroll forward then you're pushing it further away from you.
John Topley Send private email
Wednesday, May 14, 2008
 
 
Karel, Don't let my flippant tone be indicative of my dedication toward a seamless user experience.  I've conducted extensive usability studies.  The results are ambiguous.  Across apps the opinion is polarized while app specific double blind studies concluded that Cad, Drawing and Imaging apps use wheel forward to zoom-in by a margin of 17%. +-  Hallway usability resulted in a 3-2 split in favor of "like Kirby Air-ride".  As far as passing the buck to the user, the two apps I most frequently use are Visual Studio and Cad software...  Have you ever looked at the options dialog on either one?  Although substantially scaled down, I assume my app falls within this niche and will be attractive to similar users.  Grandma isn't going to be trying to prove pythagoras or calculating derivatives from first principles.

I understand what you mean John but a screen is a fixed construct and I look at it more as if I'm flying (aviation background).  Yoke forward, etc.  With the grid turned on it appears eerily like a flight through an empty holo-deck and feels surprisingly natural.  The eventargs passed are positive for forward and negative for backward which, if you go by the + and - on zoom commands, seem to correlate.

Having said all that, I really don't know, thus go with my gut and have the option.

Thanks all!
Brad Siemens Send private email
Wednesday, May 14, 2008
 
 
What John said is true of Firefox as well.
Jeanne P. Send private email
Wednesday, May 14, 2008
 
 
Hi Brad, unfortunately with this there isn't one single way that everyone will agree on.

Some people will consider the scroll wheel to be manipulating your viewpoint. So moving your viewpoint "in" would mean zooming in.

Other people will focus on the objects and consider that their actions are working on the objects, so moving the objects "in" means making them smaller or zooming out.

I would definitely suggest having a setting for this, because there will be some people who will never get comfortable with whichever one you choose.

For the default, I would suggest rolling up is zooming in - this is the "manipulate the view" way which tends to be implicitly used in a lot of controls such as scroll bars. For example when have a scroll bar and you push Page Up, it moves the "view" of the scroll bar, which means the actual content on the screen goes down as you push Page Up.
Michael
Wednesday, May 14, 2008
 
 
Jeanne, are you sure?  I'm using Firefox right now, and if I hold down Ctrl and move the mouse wheel backwards (i.e. towards me), the text gets smaller.

As a matter of fact I find this very annoying: my expectation is that this action will make the text larger, because I'm "pulling the text towards me".  But I can equally see that other people might find it intuitive, because they're "scrolling downwards to decrease the text size".

Ideally this kind of thing would be controlled by the operating system, rather than individual programs... that way every program would be consistent.  But the only way to make that happen would be to wind the clock back many years, alas.
Iago
Wednesday, May 14, 2008
 
 
And forget about what Ctrl+Wheel does in web browsers, most people don't know anything about that.

It's far more common to use the wheel in a web browser without any control key modifier. This does a "manipulate the view" type operation, where the standard method is scrolling down pushes your view down, and actually content on the screen moves upwards.

That's why the default is probably better to be scroll up = zoom in.

It's impossible to make everyone happy with whatever you pick though so you need a setting for it.
Michael
Wednesday, May 14, 2008
 
 
There seems to be no real answer as to what the 'correct' way is. I switch between AutoCAD and Inventor all day and even though they're both Autodesk products the zoom function with the scroll wheel is opposite in the two programs by default. Inventor does allow you switch the direction though.

Just my personal observation of watching people using the mouse to zoom is that it doesn't really matter. People seem to just start scrolling and quickly switch when they realize it's going the wrong way.

Wednesday, May 14, 2008
 
 
Yep, moving the top of the wheel towards me makes the text bigger.

But Google Maps is the opposite.
Jeanne P. Send private email
Wednesday, May 14, 2008
 
 
Now with the wheel tilt, left or right? <g>
Brad Siemens Send private email
Wednesday, May 14, 2008
 
 
I prefer how Visual Studio handles zooming over how IE and/or Firefox handle it. 

Now if I could only remember which was which.
mwb
Wednesday, May 14, 2008
 
 
In World of Warcraft, scroll forward is zoom in, scroll backwards is zoom out.

But in 3D games like that, you're often manipulating a camera, so moving the camera is the instinctive response.
Rohan
Wednesday, May 14, 2008
 
 
On the Mac scroll forward (moving the mouse wheel towards the screen, or sliding your finger on the track pad towards the screen) is Zoom In.

I suppose they are the kind of people that do usability research on things like this.
not a guru Send private email
Wednesday, May 14, 2008
 
 
In Firefox 2 scrolling down zoomed in, in Firefox 3 it zooms out.  It annoyed me at first, but now I'm pretty much used to it.  I'm not even sure how the CAD apps I use are--I just reverse if it doesn't do what I want.  (I also do the same thing for control and alt to zoom or pan.)
A user option is good to have, and I'd probably set it up to be the same as my browser, but in the end I still wouldn't remember.
Michael
Thursday, May 15, 2008
 
 
OT Response:

My Cable company and TV Guide don't agree on which way is up.

If I'm in the program listings provided by TV Guide,  I hit the down button to see higher chnnels.  If I just want to move to the next higher channel without consulting the guide,  I have to hit the UP end of a double ended button.

This is all on a remote with about 45 buttons on it.  You would think that the world of TV remotes would place a big premium on simplicity.  Apparently not.  Or perhaps my view of simplicity is clouded by abstraction.
Walter Mitty Send private email
Thursday, May 15, 2008
 
 
FWIW, I believe nearly all apps agree that using the wheel without modifier keys moves the "camera" not the "subject": rolling the wheel "down" (towards yourself –the same direction to move the mouse pointer down), drags the scrollbar slider down, not the document. So for conceptual consistency, if not an actual advantage in user performance, Ctrl-scrolling towards yourself should zoom out. I say we, the JOS Community, declare that a standard and decree IE and FF 2 to be out of compliance.

More seriously, the lesson from the scrollbar may be to give your users feedback on what zooming is doing, whichever way you choose to do it. For example, you can have a display that represents the level of zoom as the distance a point-of-view symbol is below the subject. Ctrl-zooming moves the point-of-view symbol. The same display could also be used to control zooming. This is essentially what you see in Google Maps.
Michael Zuschlag Send private email
Thursday, May 15, 2008
 
 
Am I missing something? IE7 seems to work the way we are expecting it to. It's FF and IE6 that seem to have it backward. But this is probably because IE7 is an actual zoom which changes the size of every element of the screen. FF and IE6 only change font sizes when using the wheel which really isn't equivalent to zooming.
dood mcdoogle
Thursday, May 15, 2008
 
 
One more data point: Paint Shop Pro zooms in for scroll up, out for scroll down.  Has for 10 years.  It's an easy mental model, once you realize that up means bigger and down means smaller.  Only a nerd would think in terms of camera position moving back and forth.

This is consistent with the Control+Scroll in IE7 and MS Word, but I'm guessing not many people know about those functions.

If you click on a combo box with zoom levels in it and start scrolling, guess which way the zooms go?  Same again.

Don't think you can abdicate your responsibility just because you provide a setting.  You still have to pick a reasonable default, and a significant portion of your users (a majority?) will never discover the setting.
Mark Ransom Send private email
Thursday, May 15, 2008
 
 
I see what you mean Mark.  I should model my Cad style app after IE and Word or some other 10 yo entrenched standard instead of, say, AutoCAD or WorldWide Telescope.  I'm convinced!  Thanks.
Brad Siemens Send private email
Thursday, May 15, 2008
 
 
I can't presume to tell you which way to pick, all I'm trying to do is provide some additional information - and convince you that picking one is indeed important.

If most of your users frequently zoom in another application, then by all means use that application as your guide.  You know better than any of us what your users are used to.  I assumed that by asking your question on a forum, you were trying to see if there was a consensus or standard.  From my point of view, there is - I've never used AutoCAD or WorldWide Telescope.

One last thing, all my examples are apps which provide a 2D view of a flat document.  If yours is a 3D view, then using the scroll wheel to move your vantage point would be more natural than my previous negative comment would suggest.  It all boils down to the mental model people assume.  What mental model does the rest of your UI project to people?
Mark Ransom Send private email
Thursday, May 15, 2008
 
 
Oh, for the love of...

It's a Cad style app.  I think I mentioned that, twice.  And then went on to explain my thought process, in some detail.  I sincerely appreciate everyones input, including yours, but I could do without the dripping condescension and pronouncements regarding my relative nerd quotient.

Thanks again all!
Brad Siemens Send private email
Thursday, May 15, 2008
 
 
Brad,

Right now we are developing a desk top application for the editing and generation of a particular type of Finite State Machines. Today we added zooming with the scroll wheel of the mouse. This made it possible to do a little experimentation and find answers to your questions.

Here are the results from the jury (n=2):

* Our application is document-oriented. E.g. the entire document can be repositioned/panned inside its window by dragging the background itself. Therefore, we do not need scroll bars. Scroll bars are a problem anyway in the context of a zooming user interface.

* For above reason the mouse wheel should manipulate the document and not some imaginary camera that is between you and the document. So, moving the top of the wheel away makes the document zoom out. Once started (see next point) this feels very direct and *very* natural. It feels better than the reverse for us (n=2).

* However, as a frequent Google Maps user, I often start moving the wheel in the wrong direction. I use Google maps more than any other zooming application, so this has programmed my mental wiring.

* However, given the instantaneous visual feedback, this is corrected without conscious thought.

The latter point (mentioned by a previous poster) is very important: it allows you to make a choice and avoid user settings.
Karel Thönissen Send private email
Friday, May 16, 2008
 
 
I think the point about providing a mental model is extremely important.

In some applications there are scroll bars that are used to reposition/pan the document. The unmodified scroll wheel manipulates the scroll bars, not the document itself. So onWheelDown (towards you), moves the scroll bar down, which moves the content up. In this situation, one 'moves the camera', so one should do the same for zooming: modified scroll wheeling should 'move the camera'.

In our FSM-editor we use a full ZUI (zooming UI). Therefore, scroll bars are not possible for a number of conceptual reasons. So the user repositions/pans the 'world' by direct manipulation. Therefore, the scroll wheel should manipulate the document/world/content, not the 'camera'.

I agree the talking about manipulating the 'camera' is geekie. But for us geeks, it is very precise language. The alternative of talking about scroll wheel up and scroll wheel down is just as confusing for ordinary users and for us. First, I thought of it as /clicking/ with the wheeled middle button. Then I had to read three times to understand what it meant and had to physically label the directions on the mouse itself.

It should have been wheelAway and wheelTowards, wheelOut and wheelIn, or wheelForth and wheelBack.
Karel Thönissen Send private email
Friday, May 16, 2008
 
 
Karel

Thanks for taking the time!  I knew this would be somewhat contentious, but I had no idea to what extent.  Proves your (THE) point about mental model.

I think I see the problem now.  When I say camera I'm referring to the eyes of the user or the user position in space.  My app is plane or space oriented and, thus, potentially infinite in all direction -- obviously, not practically infinite -- so to even talk about moving the document never occurred, there is no document, only representations of spatial constructs.  (There is no spoon! <g>)

I must apologize, it just never occurred to me that my verbiage was anything but standard.

Again, I am viewing the screen as a portal, window, camera, view-point that the user manipulates.  Seems perfectly reasonable, for me, within the context of spatial geometry or when manipulating a plane -- fly-over in google maps, as you pointed out.  I would have thought that this, in and of itself, would be sufficient to make that an informed default with the option for users that simply couldn't stomach it.

You don't think that an option to change the default behaviour is reasonable?  On that we must agree to disagree.

Thanks!
Brad Siemens Send private email
Friday, May 16, 2008
 
 
In the spirit of full disclosure, I didn't know that my mouse wheel would tilt left and right until  this thread.  Panning shortcut, eh?
Brad Siemens Send private email
Friday, May 16, 2008
 
 
Do you know what other non-document, spatially displayed software (software where you are 'flying' around objects you are manipulating) your average user may use. If so I'd model it after that.

Otherwise you get to pick and it really could be whatever. I don't think it's a deal breaker in the use of the software. As I mentioned above (forgot to sign in) the default installation of Autodesk Inventor and Autocad have opposite implentations of scroll behavior. And they are shipped and installed as a suite. Whenever I see a user actually encounter this difference of behavior (they are working in one and switch to another) they either just slightly grumble, sigh, make an audible noise of annoyance OR just ignore it and adjust the direction they're scrolling.

I just figured out why the behaviors are different and it may help you. In Autocad you're manipulating a database of geometric entities, and the display is a graphical respresentation of that. (The graphical display really only has meaning to to the user.) The display shown in a viewport is determined by camera settings. So when manipulating the display you are manipulating the camera with the view of the world changing around you. You're rarely focusing on a single entity with respect to the entire drawing (database). So scrolling up/forward moves the camera forward in the display having a zooming affect.

However in Inventor the entire program is dedicated to the design of an single part/assembly. By default when zooming and rotating the display reacts as though you're manipulating the parts themselves. (Also why devices like the spaceball works so well with 3d modelers). So when you scroll up/away you're pushing the object away.

So it all depends on the perspective you have on what you're manipulating and how you see the data.
TrippinOnIT Send private email
Friday, May 16, 2008
 
 
Another way to put it. In one the display is a cube you're manipulating in front of you. The other you're inside the cube looking around.
TrippinOnIT Send private email
Friday, May 16, 2008
 
 
That's exactly how I was envisioning it.  In the cube looking around.  Sorry, I missed your point.  I've not used inventor so I had no frame of reference.  Thank you.
Brad Siemens Send private email
Friday, May 16, 2008
 
 
Karel, your app sounds interesting.  I don't suppose you could elaborate?
Brad Siemens Send private email
Friday, May 16, 2008
 
 
For our main product (which is still in the works) we need lots and lots of complex finite state machines. The number of states and transitions is much larger than any FSM I had ever seen. The actions in an FSM can have complex formantics (‘semantics’), in that they are not simply opaque to the FSM: the action can change the working of the FSM dynamically.

Until now we use our own drawing methods (using pen and paper), because the existing standards and tools (UML, Visio, PowerPoint, I hear you) are completely inadequate for this kind of task. Our drawings are concise and very easy to understand. Unfortunately we have to draw every thing by hand. To reduce the burden of drawing, we have developed some best practice using transparent sheets, overhead markers and color copy machines. Then we compile the diagram to executable code, helped by a number of templates.

However, it has become economical to develop a tool for making the drawings, verifying certain properties and then generating the executable code that implements the FSM.

The editor is almost done. Placement of nodes is by hand, since this gives better results than automatic collision avoidance of nodes and edges. Diagrams are print quality. Transitions (edges) behave like rubber bands in that they always have nice minimal curved shapes. All objects in the diagram use direct manipulation, e.g. using drag and drop. Right now, the editor has /no menu at all/, nor controls outside the document. The user interface is completely zooming. The graph part (so excluding the various labels) of a 15-node FSM can be drawn from scratch in less than a minute.

I will come back to you, here and via my weblog, when I have more to show.
Karel Thönissen Send private email
Monday, May 19, 2008
 
 
"dripping condescension and pronouncements regarding my relative nerd quotient", yes. I'd like to apologize for that. What I should have said was:

Don't fall into the common developer trap of believing that your users think the same way you do.

With the mention of your aviation background, I thought this was a distinct possibility - again I'm sorry for the way I phrased it. The follow-up question about your UI was an attempt to see if your app promotes a mental model that matches the one that comes naturally to you.

Speaking of mental models, I can identify 4 that might apply. All have been mentioned previously, but I think it's helpful to summarize them here.

1. The simplistic model - the wheel directly controls the perceived size of on-screen objects. Up (forward) means larger, down (backward) means smaller.

2. The camera/viewpoint model - the wheel moves the viewpoint, forward zooms in, backward zooms out.

3. The object manipulation model - the wheel moves the object, forward away from the viewpoint zooms out, backward towards the viewpoint zooms in.

4. Trained response - they've used some other software extensively in the past and have gotten used to how it works, without thinking about it too much.

Notice that 1 and 2 have the same correlation of zoom and wheel direction.  4 of course will be inconsistent.
Mark Ransom Send private email
Thursday, May 22, 2008
 
 
Thanks Mark.  That's a pretty good summation, in my mind.  As to the other, accepted, graciously!
Brad Siemens Send private email
Friday, May 23, 2008
 
 
Me like look at this with 'Caveman model':

Ctrl-ScrollWheelUp  - make things big
Ctrl-ScrollWheelDown - make things small

Now me go invent scroll wheel out of dinosaur brains.
Oog
Friday, May 23, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz