Bluetile/Development

From HaskellWiki

Development[edit]

This page is a place to brainstorm ideas for the further development of Bluetile. Comments and suggestions are welcome! I (JanV) currently don't have the time to work on any of these actively. So if you feel like trying your hands on some of these ideas, your patches are welcome.

Bluetile doesn't have a separate mailing list or bug tracker. Since it is so closely related to xmonad, you can use xmonad's mailing list and bug tracker. Just make sure, you clearly state that you are referring to Bluetile. Happy hacking! :-)

Pretty window decoration[edit]

The current window decoration used by Bluetile is fairly bare bones, just sketching out the basic controls. I would like to improve on that. I'm not an artist, so if possible I would like to reuse something.

That gave me the idea to look into Compiz, which has several different possible decorators. Maybe it is possible to reuse the decorator of Compiz in Bluetile - like Compiz's gtk-window-decorator. This should allow for a very Metacity-like decoration.

Unfortunately, I couldn't find much documentation on how exactly Compiz talks with its decoration manager. These e-mails contain some information:

As far as I understand it, one marks the windows to be decorated with a special property. The decoration manager looks for windows with that property and prepares pixmaps with the decoration. The pixmaps are then communicated back to the window manager which draws them. Somehow a library called libwnck plays into all this and helps with some of the steps. It might be necessary to use Haskell's foreign function interface to make use of this library ( http://www.cse.unsw.edu.au/~chak/haskell/ffi/ ).

All of this is just a vague idea. I'm not sure if it is actually possible - especially considering that Compiz is a compositing window manager where different rules might apply (?). Comments from people with more insight into this area are appreciated. :-)

--JanV 23:16, 25 February 2010 (UTC)

Related to both, configuration system and window decoration. Importing themes from metacity or xfwm4 could be a good option. --diog 14:54, 17/06 2010 (GMT: -3)

Managing dialog windows[edit]

Bluetile tries to deemphasize the floating layer and provides a stacking window manager layout to be used instead. However, the floating layer still exists and is used in some cases. Mainly when things like dialog windows are opened. They are detected - just like xmonad does it - and automatically moved to the floating layer. In most cases this is what the user expects, because for things like an about box it usually doesn't make sense to tile the window. But occasionally a window might get such a treatment, where the user doesn't expect it and is confused why he can't manipulate the window in the usual way (floating windows aren't handled by a layout so they don't get any decoration). This confusion should be prevented. It might be enough to just add another button to the dock application to allow to 'de-float' a window. The tooltip for the button should contain a good explanation. Alternatively an extra control could be displayed in the upper right corner of a floating window enabling the user to do the same thing.

Currently a window can be 'de-float'ed with the keyboard shortcut Alt+t and floated with Alt+Shift+t. Most users will however not know this and in my experience the whole floating layer is somewhat of a confusing concept for users coming from traditional window managers.

--JanV 22:16, 28 February 2010 (UTC)

Help system[edit]

In my thesis (available online, but only in German) I discussed the idea of a help system, which would try to help the user to get acquinated with Bluetile's keyboard commands. Unfortunately it was outside the scope of the project to actually implement the system. But I would like to document the design considerations here, as I still think this is a worthwhile idea to pursue for future versions of Bluetile. The following is a rough translation of the relevant section of my thesis (p. 14f):

Bluetile tries to make the tiling paradigm easily accessible to users coming from traditional window managers. This often includes the use of mouse commands, because many users are familiar with them. However, a major benefit of tiling window managers is the fact, that this paradigm is very well suited for a keyboard-based workflow. Many tasks can be done very efficient with keyboard shortcuts [LNPS05, p. 140]. It would therefore be desirable to help the user in learning keyboard commands.
If we look at how to best achieve this, we face a general problem: Something called the "Paradox of the Active User" [CR87]. This term describes the effect, that once a user has learned one way to accomplish a task, they will usually keep doing things in this way, even if they suspect, that there might be a better way to do the same thing [KA08, p. 239].
A window manager, which offers mouse commands as an easy introduction and which later wants to encourage the user to use keyboard commands instead, faces this described paradox.
One approach to deal with this difficulty involves the detailed documentation of keyboard shortcuts in an accompanying manual. This is definitely an important thing to do, even though many users will never read such a document [CR87, p. 2]. Many applications therefore employ different, additional ways to inform the user. A common approach is to display a "tip of the day" when the application is started. Another approach is to briefly display additional information that are relevant to the current task the user is doing. An example for this would be the YouTube applet, which - upon switching into fullscreen mode - displays for a few seconds how to leave this mode again.
The use of a "tip of the day" seems too intrusive for a window manager. The previous, traditional window manager of the user probably did not require much documentation. So the user might not be very open towards the idea that Bluetile wants to teach them something on every single start. The brief display of information has the disadvantage that it usually diverts the user's attention. Even if it is just for a few seconds in which the user realizes, that the message is not of interest at the moment.
Another well-known example for context-driven help is Microsoft's Office Assistant, the paperclip. It is also an unfortunate example for the problematic nature that such help systems encompass, because the paperclip created a mostly negative reaction among users. In the study [Swa03] the paperclip has been described by users as "annoying", "always [...] in the way" and "patronizing". One participant remarked: "I don't want it to think you need help... I want to ask for it" [Swa03, p. 26f].
This prompts the question whether users just generally do not like to be lectured or whether just this particular implementation was done in a poor way.
Looking for a middle ground between unnoticed documentation and annoying paperclip, I propose the following solution: A small area of the screen should be reserved for context-driven help messages. Displaying these messages in the form of a brief overlay might save screen space, but as mentioned above, it is hard to ignore for the user. A special area, comparable to the status line of a browser, does not divert the user's attention if they choose to ignore the messages. The help system should be made very context-sensitive in such a way, that the displayed messages are relevant to what the user is currently doing. If the user, for example, clicks on the control to maximize a window, the status line could display the keyboard shortcut to accomplish the same thing.
  • [CR87] Carroll, John M. and Mary Beth Rosson: Paradox of the active user. In Carroll, John M. (editor): Interfacing thought: cognitive aspects of human-computer interaction, Cambridge, MA, USA, 1987. MIT Press.
  • [KA08] Krisler, Brian and Richard Alterman: Training towards mastery: overcoming the active user paradox. In NordiCHI ’08: Proceedings of the 5th Nordic conference on Human-computer interaction, pages 239–248, New York, NY, USA, 2008. ACM.
  • [LNPS05] Lane, David M., H. Albert Napier, S. Camille Peres, and Aniko Sandor: Hidden costs of graphical user interfaces: Failure to make the transition from menus and icon toolbars to keyboard shortcuts. International Journal of Human-Computer Interaction, 18(2):133–144, 2005.
  • [Swa03] Swartz, Luke: Why people hate the paperclip: Labels, appearance, behavior, and social responses to user interface agents. Stanford University, 2003.

--JanV 16:13, 3 March 2010 (UTC)