Autohiding widgets: a prototype

After thinking about it for a bit I realized this was the second (or third?) time I have blogged about some idea I had, but never really tested out the theory. So this time I decided to try it out and see how it works. So here’s a prototype of the method I have been talking about the two last blogs. Picture on the left, and here’s a youtube video.

video in ogg version

The way it works is that widgets are inserted, along with a priority, into an object that does it’s magic when a resize event is triggered. It loks at the difference between the widgets size and its minimumSizeHint, and if it’s approaching zero it hides the least important widget. It uses the same value to accumulate how much slack there is (total difference between minimumsizehint and size), and determines if it’s ok to show the most higly prioritized widget.

Although this code here is just a big hack, it would be interesting to compile it into some kde applications and see how it works (if it works at all).


18 Responses to “Autohiding widgets: a prototype”

  1. Boudewijn Rempt Says:

    Well, that certainly looks interesting!

  2. Seb Ruiz Says:

    Hi Harald,

    I really like this example – it works very nicely for this given scenario. It would be interesting to see how this would work in a more complicated UI. A good example might be Krita where there are lots of docked widgets.

    However, it still doesn’t address the most pressing issue – loss of discoverability! These widgets suddenly disappear and there doesn’t seem to be a very effective way to find them again! Toolbars? Menus?

  3. dr.schnitzel Says:

    looks great!

  4. Harald Says:

    Well, a way to show where they went was described in the comments in on of the previous two blog posts (show an icon or something on the siden when it’s hidden). It is not implemented in this quick prototype though.

    And I’d like to again make the same point as before, that (although this prototype does it a little too aggressively) it is meant as a last resort for the times when it is simply not possible to resize the window any more, or when resizing it any more would make the work area useless. It’s just a matter of prioritizing loss of discoverability vs loss of usefulness (although I would go for the former, this is still something that should be put up for discussion. or maybe it could just be tested in a smaller application first to see how it works?)

  5. fish Says:

    How does an app know what docks are useless to the user and what docks aren’t? And why is a dock even on the screen if it’s useless? Useless docks shouldn’t exist at all…

  6. Harald Says:

    It doesn’t know that. The more used docks are just marked as higher prioritized, and as said above, when the user wants to resize it even smaller than what is possible (while keeping the interface useful), they are hidden only as a last resort.

    And the “useless dock” labels shouldn’t be taken seriously, I was just labeling them to make it clear which one are prioritized and which ones are not.

  7. Dan Leinir Turthra Jensen Says:

    The ribbon from the Office 2007 Fluent UI is trying to solve this same problem by using a slightly different methodology to yours – each item on the toolbar has several different size/designs and everything is sorted in order of importance.

    While we may not be able to do the sort of enormous quantitative studies required to estimate which item in the UI is more important than another, we are able to draw on our usability people inside KDE and come up with a fair estimation on the topic, as well as provide a sane fallback.

    The fallback, really, is what Sebr is talking about, i suspect – how do we make sure people are able to still access the features that are hidden in this manner? One way, as Sebr also suggests, would be to provide a simple button like what we’ve got in toolbars already – click it and the hidden items are shown in a popup or suchlike. Another option, which might be problematic on touch screen devices, would be to show this popup on mouse-over.

    A slightly more interesting approach might be to extend the existing framework in Qt, where widgets are scaled using layouts to also include several designs – Plasma already does this in part, where a plasmoid might be able to scale and relayout its contents to allow for a more space-optimized layout when screen real estate is at a premium. Qt already tries to scale contents, but it cannot, for example, change a large slider to a small spinner automatically when the space runs out.

    The contents in this link are a bit marketing-blurpey at times, but it does contain a number of good insights in the topic of scaling UIs: – Developer Overview of the User Interface for the 2007 Microsoft Office System

  8. Johnny Awkard Says:

    How about, instead of completely hiding the panels, just minimize them so that only their title is showing?

    Then, if the window *really* gets too small, then hide the titles as well and think of some cool way of showing where they’ve gone. I can’t think of such a way right now.

  9. uga Says:

    I can imagine a Joe user having two applications side by side to dnd, compare or copy between them, so that this KDE app is reduced in size. But the guy may still _need_ those tools that are hidden. Why not let the guy pick which of them he wants to remove? The application, unfortunately, cannot tell if those “less used” tools are needed

    just my 2eur cents.

  10. GreenPeace Says:

    I already say that this is good and may be is best of the year interface improvement!

  11. DanaKil Says:

    “it could just be tested in a smaller application first to see how it works?”

    maybe KTorrent ? It has at least 2 retractable dock that could collapse when the size of the windows become too small.

    About the discoverability issue, maybe a passive popup could help… (it would be cool if this auto-hide feature could be enabled or disabled (and the popup too) somewhere in System Settings

  12. Seb Ruiz Says:

    Harald, don’t misunderstand me – I think it’s fantastic that you are trying to tackle this issue, and I only wish to point out some of the issues that autohiding brings!

    great work!

  13. Miguel Says:

    We will have to see a real user case…
    But this remind me the auto hide menu options in my colleges’ Microsoft Office.
    Wich for me is kind of annoying.

  14. ris Says:

    “How about, instead of completely hiding the panels, just minimize them so that only their title is showing?”

    Or maybe, if it’s a stack of docks, compress them into a qtoolbox-style stack of rollups. (I say qtoolbox-style because qtoolbox is horibly wasteful of space.)

    This would let the user override the chosen dockwidget.

  15. Luis Says:

    Hi everyone! Maybe I’m bit out of context here but how important discoverability really is? Take gimp as an example: all the toolboxes can be switched from a menu and are off by default. In koffice they are on by default (which IMHO is a mistake s it totally clutters the working environment and distracts the user from the real work) but still are switchable from the menus. I think it is more important to have a piece of software that will let me work by default, no matter the size of my screen, than one I have to hide all the docks only to see the work space. Anyway, this is great work and I think it should be discussed with both the users and the usability experts.

  16. Prototipo per il ridimensionamento dinamico delle finestre « pollycoke :) Says:

    […] delle finestre“, ricordate? Adesso a distanza di un pochissimo sembra essere ufficialmente avviato il progetto che potrebbe portare questa piccola grande miglioria sui nostri […]

  17. litb Says:

    ok, i think it is alright as it is. hose toolbars will only be hidden when the window becomes extremely small. i think no caption is needed to say “oh here was a tool. maybe at the very top, there could then be a small bar saying
    “Click here, or enlarge the window to show more tools” . And if you click, then the window is resized automatically, so that everything is shown with the minimal window size.

    How about that?

  18. Nathan (Borker) Says:

    This looks like a job for some nice animations… It is already somewhat obvious that your available controls are being effected by the resize as they are disappearing at a disproportionate rate to the other areas of the screen. At the point at which they disappear completely or iconify or what have you, a neat indication of them zooming into icon mode or ‘popping’ as they disappear should assist in notifying the user what has happened

Comments are closed.

%d bloggers like this: