Development

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.

The repositories listed on the main Bluetile website are for version 0.4, which is available on Hackage. If you want to dive into the code, you might want to use the development version instead, which only uses code from xmonad darcs now. That would be:

darcs get http://code.haskell.org/xmonad
darcs get http://code.haskell.org/XMonadContrib
darcs get http://code.haskell.org/~jav/bluetile/

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

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)

Configuration system

It would be nice if Bluetile had a basic configuration system. The migration path to xmonad is fairly straightforward, so it is not impossible to configure Bluetile. But maybe someone just wants to change one key-binding or use a different terminal and there should be an easy way to make those minor tweaks.

Some thoughts about the design of a configuration system:

Nothing fancy, not everything has to be configurable, just some basics. Definitely no full-blown compiler step like xmonad does it. In my opinion that entails to many pitfalls for non-programmers. Maybe do something YAML-based.
Allow to: change key-bindings, global settings like the terminal and an option to hide Bluetile's dock. What about mouse bindings? Don't allow to: Change which layout algorithms are available etc. For that level of tinkering xmonad is better suited.
A verbose default configuration should be somewhere for the user to look at
The user configuration should be as minimal as possible, only containing the changes to the default configuration.
Add a button to the dock application that launches an editor with the configuration file. The configuration file in turn should contain some comments to teach the user how to modify the file and anything else he needs to know.

To elaborate on the minimal configuration: Many applications suffer from the problem, that they change their configuration scheme from time to time and break existing configurations. This should be avoided of course, but sometimes such a change is necessary to evolve the application further. Since it might be inevitable at some point, the user configuration should be as robust as possible to hopefully not need any adjustment. The user configuration should therefore be more of a changeset on top of the default configuration and only contain the changes the user made. That way, when something in the default configuration changes that the user hasn't touched, his configuration doesn't break. Mplayer is a good example for an application that works in this way.

--JanV 21:05, 26 February 2010 (UTC)

Managing dialog windows

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

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)

Logo

It would be nice if Bluetile had a logo. Especially once Bluetile gets packaged, a logo will probably come in handy.

--JanV 21:45, 7 March 2010 (UTC)

Bluetile/Development

Contents