Archive for October, 2008

Autohiding widgets: a prototype

October 18, 2008

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).

Advertisements

@mark, seb, re: discoverability with automatically hiding widgets

October 16, 2008

OK, I wanted to include a picture so I just made this into another blog post.
I would like to argue that this is more of a solution for making the app usable when it’s resized to less than normal sizes. If actually having to teach the user that it needs to make the window larger to get the controls he want on screen, then someone has messed up the defaults of the application. As long as it’s initially resized to a good size, it should feel natural to the user instantly if he sees windows grow smaller and then finally disappear when he gradually makes the window smaller.

And another point: have a look at this small krita.

…or even smaller!

Would you agree me with me if I say that in this case, the problem that the interface has just become practically unusable, should take priority over the fact that the user might be a little bit confused about how to get his windows back (although I still thinks it should feel natural if done right)? And instead, it automagically turned into this:

Hope I didn’t create any strawmen here by misunderstanding your arguments, yell back if I did 🙂

Space-prioritizing widgets

October 16, 2008

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:

Automated HCI testing: a research project aimed for use with KDE

October 6, 2008

Stupid wordpress. second time I’m writing this. OK, I would like to present my idea for the research project I will work on for a year from now.

Problem: Users don’t test usability in FOSS software enough. It’s too laborous and unrewarding.

Solution: Take advantage of the fact that many users enjoy trying out new features, but don’t go so far as to actually download, compile and test unreleased software. Build a solution that let’s them test unreleased software easily. Use technologies such as klik or glick to include all needed libraries in a single runnable binary. Allow for instrumenting the software with automated tests (for example, with a qt app, one could use a class that would attach to all qt buttons and menus and generate statistics on which buttons were used most, and how a certain task was performed, maybe even record all events and do some sort of a playback that the developer can observe). Distribute this instrumented software to a large group of users and generate a summary of the results that the developer can use for reference when (re)designing the software.

Implementation details: Since this is a one year research project, I aim at making a prototype of this solution, only implementing the needed parts as I go along. I do intend to write it so that the project can be continued afterwards as well. What I need from the community is help with testing this solution on a certain piece of software. What kind of software this would be is of course dependent on how I implement the prototype, but since I know KDE well I think choosing a KDE application would be a good choice. (Maybe even choose Ark, as some might remember that I also code on)

I have not yet finalized on this plan, it might change or even be replaced altogether. But either way I would like to know what the community thinks about the idea? Are there any obvious logical problems? Technical problems? Let me know in the comments.