After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 586025 - use a slider instead of 2 zoom buttons
use a slider instead of 2 zoom buttons
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: User interface
Git
Other Linux
: Normal enhancement
: 0.13.4
Assigned To: Pitivi maintainers
Pitivi maintainers
: 599944 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-06-16 18:30 UTC by Jean-François Fortin Tam
Modified: 2010-02-07 10:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
mockup_with_slider (251.52 KB, image/png)
2009-06-27 19:56 UTC, antistress
Details
mockup_with_buttons (255.21 KB, image/png)
2009-06-27 19:56 UTC, antistress
Details
mockup_with_slider_plus_presets_through_the_timeline_contextual_menu (238.75 KB, image/png)
2009-06-30 00:18 UTC, antistress
Details
mockup_with_gimp_zoom_widget (252.41 KB, image/png)
2009-06-30 00:18 UTC, antistress
Details

Description Jean-François Fortin Tam 2009-06-16 18:30:14 UTC
The + and - magnifying glass buttons for zoom in/out, on the timeline toolbar, are currently a bit inefficient because
- They don't provide the user with a sense of scale at all
- You can't use the mouse wheel on them
- If you are not familiar with the mouse wheel (or don't have a wheel mouse!), you need to click multipe times to change zoom levels, instead just doing a click+drag operation.

I would suggest replacing them by a slider (with the zoom icons around it). An example of such behavior is F-Spot, iMovie or OpenOffice.
Comment 1 Jean-François Fortin Tam 2009-06-17 19:34:14 UTC
If possible, I would like a reply on this proposal, as it is "taken for granted" in the manual at the moment.
Comment 2 antistress 2009-06-27 19:55:46 UTC
You can use the wheel even without a slider : see Nautilus for an exemple

Personally i'd like to have 2 things : one system to define with precision the zoom factor PLUS 2 (or 3) presets that would allow for one to easily browse the project (zoom out x factor), for another to edit with precision a scene (with the razor for instance) (zoom in x factor)

With or without a slider, we should have 2/3 presets that would match usual tasks

I attach 2 mockups :
- one has a zoom slider and 2 presets buttons
- one has 2 zoom buttons and a drop down list with 3 presets (like Nautilus but with a drop down list). Of course, zoom buttons should allow a lot of zoom factors, not only presets.

As far as i'm concerned i prefer mockup with zoom buttons instead of a slider

Comment 3 antistress 2009-06-27 19:56:21 UTC
Created attachment 137472 [details]
mockup_with_slider
Comment 4 antistress 2009-06-27 19:56:57 UTC
Created attachment 137473 [details]
mockup_with_buttons
Comment 5 antistress 2009-06-27 20:05:47 UTC
"As far as i'm concerned i prefer mockup with zoom buttons instead of a slider"
besides, buttons may be easier to use with a touchpad than a slider i guess
Comment 6 antistress 2009-06-28 22:01:16 UTC
After some thinking, i think that the drop down list should propose the same selection of zoom factors that buttons
Comment 7 antistress 2009-06-28 22:13:06 UTC
Concerning the slider, from GNOME HIG
"Use a slider when:
    * adjusting the value relative to its current value is more important than choosing an absolute value. 
    * it is useful for the user to control the rate of change of the value in real time"

I think that it's important :
- to have only a selection of zoom factors that are useful for editing (we don't need to have 10 zoom factors)
- to have access to absolute values : once user know which zoom factor to use for browsing the project and which one to use for trimming, he has to be able to easily change from one to another (for instance he may work at 100% and need to switch to 150% for trimming or to 50% for browsing its project : drop down list allows that without having to to grope around)
Comment 8 Jean-François Fortin Tam 2009-06-29 17:18:38 UTC
> have only a selection of zoom factors that are useful for editing
> (we don't need to have 10 zoom factors)

Yuck, 10 is very insufficient. If you've done significant amounts of video editing, you probably had to zoom in and out all the time, from the bird-eye's view to the infinite precision of the atom.

I don't want 10 zoom levels: I want a (near) infinity of them. The only hard limit should be the "fully zoomed out" level, which should be relative to the duration of the timeline (see bug #586995).

> - to have access to absolute values : once user know which zoom factor to use
> for browsing the project and which one to use for trimming, he has to be able
> to easily change from one to another (for instance he may work at 100% and need
> to switch to 150% for trimming or to 50% for browsing its project : drop down
> list allows that without having to to grope around)

The problem is this: percentage of what? The timeline duration changes all the time. Having a percentage there doesn't make much sense to me (compared to, say, image editing apps who work on a canvas). If the percentage was relative to the duration of the timeline, then that means that adding clips would make your timeline shrink each time! Either that, or the percentage thing has no relation to the timeline's duration, and thus, no relation to anything in particular.
Comment 9 antistress 2009-06-30 00:17:27 UTC
After some thinking, i understand what you mean. With GIMP i also like having lots of zoom possibilities.

Then, what about having both a slider and a few presets for direct access (these presets could be seen like default bookmarks : some presets that could be widely used for some common tasks) ?
I'm sure that user may save a lot of times with preset zoom factors, choosen considering their usefulness.
And it would be less scary for new user.
Presets could be shown as buttons near the slider : see mockup_with_slider above
or in a timeline context menu (this menu still doens't exist in 0.13.1 version) : see mockup attached below (mockup_with_slider_plus_presets_through_the_timeline_contextual_menu)

Also think about manuals (like yours) and advises given on forums. It could be great to say to new user : "If you want to precisely trim your video, you may want to set a factor X. But if you need to browse your project, you'd better choose the Y factor."
It could be helpful to be able to refer to absolute convenient values.

"The problem is this: percentage of what?"
That's a good point. People don't want to know about percentage. Unit must be time or frames/sec (i.e 1 frame|25 frames (1)|3 minutes...)

Another idea could be to use GIMP zoom factor widget
see mockup attached below (mockup_with_gimp_zoom_widget)
It could offer the choice between time duration and fps as unit

(1) in a 25 fps project
Comment 10 antistress 2009-06-30 00:18:08 UTC
Created attachment 137597 [details]
mockup_with_slider_plus_presets_through_the_timeline_contextual_menu
Comment 11 antistress 2009-06-30 00:18:31 UTC
Created attachment 137598 [details]
mockup_with_gimp_zoom_widget
Comment 12 antistress 2009-06-30 01:05:52 UTC
the timeline contextual menu (as shown in above mockup) could have 2 more entries : "add like new preset" and "manage presets" (see the "Manage Search Engines..." window in Firefox as an exemple)
It would allow to strongly personalise PiTiVi's GUI considering user's needs
Comment 13 Jean-François Fortin Tam 2009-07-01 14:56:44 UTC
Warning, long reply.

> Presets could be shown as buttons near the slider : see mockup_with_slider
> above
But then you waste a ton of space (for users editing on low resolutions) duplicating functionality that is already all inside the single slider widget. Space that could (in theory/conjecture) be used for timeline operations.

Also, that bunch of buttons will add visual clutter (how many presets buttons are enough is a subjective matter; nobody will even agree on what the presets should be, they'll depend on the user, on the project, on the alignment of planets...). I mean, there's a reason why f-spot, openoffice, gimp, inkscape did not put a ton of zoom buttons in there.


> "If you want to precisely trim your video, you may
> want to set a factor X. But if you need to browse your project, you'd better
> choose the Y factor."
> It could be helpful to be able to refer to absolute convenient values.

Well, my current approach of just saying "zoom out for a global view to ease browsing, and zoom in as much as needed for precise edits" seems (to me) to be enough. I don't really think users need precise values ("You MUST zoom to 176% to have your precise edit!"). Anyway, the results of a zoom are pretty direct and intuitive (even moreso when you use a slider instead of buttons, because it zooms "continuously" if you keep dragging, instead of in sharp, monolithic increments).

> People don't want to know about percentage. Unit must be
> time or frames/sec (i.e 1 frame|25 frames (1)|3 minutes...)
> [...] (1) in a 25 fps project

The term "Frames per second" doesn't make sense for a zoom level. If I understand what you mean, you mean "Frames in the viewable area" only. You're not actually changing the /playback rate/ of the project. And even then, the "in a 25 fps project" doesn't apply, because you only care about the "amount of frames" (or seconds, or tomatoes, or smurfs) that "fit" in the width of the timeline in your computer screen, not about the project framerate settings.

And still, I'm not convinced. I never had to care/think about "oh, I want to zoom so that I have exactly 30 frames (or a certain percentage) stretched out on my screen". My brain is too slow. I just flip the darn mouse wheel and have it zoom in/out instantly to fit whatever clip/bunch of clips I want to have in my view. Thus, to me, the fact that the slider in f-spot does not even have a *label* doesn't worry me the least, because it doesn't matter at all, only the visual output is important (this is not exactly the same situation in OpenOffice Writer, where, if your DPI is set correctly, a 100% zoom seems to make it so that the page is exactly the size of the physical paper in front of your computer's screen).
Comment 14 antistress 2009-07-01 23:51:30 UTC
1°) "you waste a ton of space" "bunch of buttons will add visual clutter"
Not necessarily : it may be a drop-down list close to the slider.
2 widgets for the zoom fonction that you consider yourself as important looks reasonable

"duplicating functionality that is already all inside the single slider widget"
i don't agree
having the possibility to go to any website with an address bar or having the extra possibility to go to useful websites using bookmarks is not the same.
we could have some useful zoom factors already preset (and maybe the possibility for the user to add its own favourites zoom factors)

The drop down menu could be something like :

closest
close
current
far
farest
____
my own setting 1
my own setting 2
____
add new setting
manage settings

That menu would also be available through the timeline context menu.

To sum up :
- i agree that a slider provides the user with a sense of scale (if needed). It may most probably be an advantage. In any case it's the only advantage i see (1).
- freedom (of scale) is good but a user-friendly application should also propose default settings to help user at the beginning
- default settings could be complete with a way for the user to add its own settings to save time if needed

Considering the first point, i agree with the bug reporter (PiTiVi should use a slider instead of 2 zoom buttons)
Points 2 and 3 are about giving the user a convenient way to get the zoom factor he needs for usual tasks (trimming or browsing). Maybe i should open another bug report ? 

(considering the fps thing, i wanted of course to mean time duration of a graduation versus frames number by graduation)


2°) Another way of helping the user of easily getting the good zoom factor would be to propose the same presets that those found within Audacity : Adapt to the selection (2) / adapt to the project
(in french : adapter la sélection / adapter le projet)


(1) we've already seen that mouse wheel can also act on buttons for instance
(2) means that user is able to select part of the timeline within PiTiVi

Comment 15 antistress 2009-07-27 14:09:13 UTC
For the record, here is the zoom widget used by OpenShot Video Editor
It seems to use both buttons and slider and display zoom factor
http://4.bp.blogspot.com/_AuTEvUYi4Ms/SgkUcd6HENI/AAAAAAAAAkY/9xJ4i1O2uj4/s400/full_screen.png
Not so bad
Comment 16 Jean-François Fortin Tam 2009-09-09 01:54:36 UTC
Here is another argument in favor of a simple slider. Instant warping.

For example, go from full zoom to fully zoomed out, in *one* click, or warp from any zoom level to any other zoom level (approximatively, of course) with just one, single click. How? Middle-click. This sets a slider to the current mouse position without interpolating with the values inbetween.

Having regular zoom buttons on top of that makes little sense, considering that we have a near infinity of zoom levels (you'd have to click dozens of times), especially with bug #586995.

Can I have my poney now?
Comment 17 Brandon Lewis 2009-12-08 22:17:14 UTC
commit fe933cb37e13f0cf14470df1583d916bcf429892
Author: Brandon Lewis <brandon_lewis@alum.berkeley.edu>
Date:   Tue Dec 8 13:49:26 2009 -0800

    ui/timeline.py: add a gtk.HScale to upper left corner of timeline for zooming
    closes bug 586025
Comment 18 Stephen Griffiths 2010-02-07 10:59:33 UTC
*** Bug 599944 has been marked as a duplicate of this bug. ***