Space-prioritizing widgets

A thought struck me just now. My impression is that a lot of applications, when resized, will just resize the widgets, UI, toolwindows, everything with it in a proportional manner. Wouldn’t it be better if when you resize, the less important widgets and window elements are just hidden, and pop up again once you enlarge the window and give it a bit more screenspace?

How about a way to prioritize the elements on screen, such that you can define some things as always-needed (kind of like always on top in window manager space), and rank other less important tools below that. My vision is then, that for example an app like Krita, once you make the app really small it would only show the bare necessity, in this case somethinglike just the picture and a color chooser.

A picture I made with my awesome gimp skills for those of you that cannot see my vision through my words:

20 Responses to “Space-prioritizing widgets”

  1. Ian Monroe Says:

    We kind of want to do something like this with Amarok’s context view eventually. For really wide monitors it would be nice to open up spaces for additional widgets.

  2. Seb Ruiz Says:

    We’ve seen this sort of widget hiding with toolbars for a long time now. The “prioritising” simply hides the right most actions.

    Although it seems like a good solution to the problem of insufficient space, it has an unfortunate side effect – obscuring actions or widgets which the user might not realise exist. This in turn creates a discoverability problem when you don’t have a satisfactory method (or even space) to show, and more importantly access the hidden objects somewhere off screen.

  3. Seb Ruiz Says:

    We’ve seen this sort of widget hiding with toolbars for a long time now. The “prioritising” simply hides the right most actions.

    Although it seems like a good solution to the problem of insufficient space, it has an unfortunate side effect – obscuring actions or widgets which the user might not realise exist. This in turn creates a discoverability problem when you don’t have a satisfactory method (or even space) to show, and more importantly access the hidden objects somewhere off screen.

  4. Will Says:

    This is a really good idea.

    It reminds me of the OSX-Finder date columns, which when resized change the date format to one that fits. That is, a wide date column shows the weekday, full date and time, a small one only shows the short date, an even smaller one just shows “today” or “3 Oct”. Much easier than asking the users to choose how they want finder to display the date, just let them choose how big it should be.

  5. GreenPeace Says:

    Good Idea and there are some ways how this could be made without confusing user. I’d like to see “Information” panel in dolphin to be hidden on resize, and, may be, bookmark panel too.

  6. Mark Kretschmann Says:

    Seb is right: It looks good on paper, but discoverability is the real issue with this solution.

  7. vlad Says:

    I like the idea! In amarok2, if you have multiple monitors I noticed a while back that the context area gets 2 rows of widgets.

    One idea for keeping discoverability with this method would be to turn the ranked widget into tiny minimized sidebar when resizing the window smaller
    i’m going to try and do this ascii style .. below is the right half of the window:

    ——–
    _|
    |x|
    |x|
    _|
    |x|
    |x|
    ——–

    the two little sidebars are marked with x’s. That way the sidebar is still noticeable, but

    this would be particularly applicable to koffice applications which heavily rely on right-hand widgets

  8. vlad Says:

    wow, that didn’t work at all…

    i hope the idea got across. basically it’s kind of like most kde sidebars (amarok, konqueror), except having it look nicer with a more obvious space between each minimized widget .. perhaps a sliding-in and out animation

  9. Harald Says:

    @vlad: It worked great in my email notification of the comment, and I think it’s a good way to let the user know what happened to his windows. Throw in a small animation, and it’s even more visible.

  10. BoySka Says:

    has someone said Edje??😉

  11. Michael Says:

    Instead of hiding them completely you could simply reduce them to a small horizontal or vertical strip (depending on the direction of the “squeezing”), leaving only the window title. When the user clicks on the title, he could force it to re-open

  12. Fri13 Says:

    “Wouldn’t it be better if when you resize, the less important widgets and window elements are just hidden, and pop up again once you enlarge the window and give it a bit more screenspace?”

    I would say that is terrible idea. If the new user gots an window as too small by some reason in first time or in any other accident. User would believe a) there is not wanted options (marking somekind “pop-up” or “resize from here” does not fix problem!) b) the intuitive remembering of the GUI does not happend. c) If you have smaller screen where you just cant get window resized any bigger, and window will hide wanted features it makes whole configuration panel irrelevant. (because why you need options if you cant change them??)

    It is true that we need a toolboxes to be fitted for small screens (netbooks etc) but it does not mean that we can start playing with settings what would adapt itself to size of windows.

    We should study more about “smart” (adaptive) configurations, so user does not need to go the control panel in first place. Make the default settings as good as possible, so there would be no reason either in first place.

    We should have static configuration panel sizes, so it is _always_ same size in minimium size, so when we take screenshots and other important tips, it would look same as on any other situation. If the screenshot is taken in bigger size and help wanted person has it on smaller size, it just does not help. And you dont remember tips so easily because the documentation has be different then.

  13. Vide Says:

    @seb and amarok guys: while generally “intelligent” behaviours are to avoid, the discoverability argument here doesn’t have a point, really. You’re hiding widgets only when in a reduced size, and you’re only hiding second class widgets. When you maximize again the window, your widgets are there again (if you didn’t hide them manually, obviously)

  14. Jani Says:

    This concept is very much what the dynamic window managers, such as dwm (http://www.suckless.org/dwm/) are also trying to solve. The problem with trying to manage a set of rectangles in a meaningful way automatically is not so easy.

  15. Psychotron Says:

    I like this idea! I think the point is to have a sound initial window setup when the app is started. It needs to be large enough that everything is visible and nothing hidden by default (unless the screen is so tiny that’s it’s simply impossible to get everything on it). Then the hiding is a direct result of a user action, and she will know where the widgets are gone and how to get them back (simply using the opposite action). Of course and indicator/representation of the minimized widgets would be helpful as well.

    IMHO generally more smartness is needed in KDE about window sizes and setups. I just think for example about maximizing on widescreens, unusable defaults of kpdf/okular, splitting views in small dolphin windows, fitting browser windows to website widths,… but thats another topic I guess😉

  16. Ridimensionamento dinamico delle finestre « pollycoke :) Says:

    […] selettiva le immagini? Immagino di sì, perché era piaciuta a tutti. Leggo adesso nel blog di Harald Hvaal (mi sono permesso di modificare la sua immagine in quello che vedete qui sopra) che c’è una […]

  17. Leo S Says:

    No one here has used office 2007? It does exactly that with the ribbon. When you resize the window to smaller than could fit all the group boxes in the ribbon, some of the group boxes get collapsed to just their labels. Works pretty well I think.

  18. Top Posts « WordPress.com Says:

    […] Space-prioritizing widgets A thought struck me just now. My impression is that a lot of applications, when resized, will just resize the widgets, […] […]

  19. Andreas Says:

    I think you need more context and state in your layouts (or really, in the whole form design) to make this happen. But I do think it’s very possible to do. All you need is to ensure that certain widgets are added or removed, and certain layouts are enabled or disabled, depending on some logical expression, like form.width() < foo. Problem is only that form’s size is constrained by the layouts’ minimum sizes. But you could always switch layouts and hide widgets before reaching that limit…

  20. RichiH Says:

    If you display a simple hint which makes users aware that something is hidden, you don’t have any problems with discoverability.
    Also, don’t make stuff optional. Give it integer values for more fine-grained control over what phases out at what size.

Comments are closed.


%d bloggers like this: