Applications as canvas, rethinking how we design applications on Linux

In this article, I will try to imagine a new way to build applications on Linux. Starting from questions like: How applications can be easier to tune, to refactor and support the new platforms or input devices? Does Linux applications have problems that should be spotted? Does using a Software Bus improve or make a radical change of the way we currently develop?

The philosophy of the UNIX system

Ken Thomson has taken a lot of decisions while designing UNIX, he wanted to create a powerful system composed by writing small software pieces that "do one thing and do it well" and which can be connected together using pipes in order to accomplish a more complex tasks. 

Building short, simple, clear, modular, and extendable code has allowed an easy maintaining and understanding of how the full system work.

Linux has inherited such powerful philosophy, and this is why it is used everywhere in servers. When something bad happens, you know the cause and can fix the broken component. You can also write scripts that simplify things.

However, GUI applications in Linux don't apply the UNIX philosophy, each application is an independent island itself.

Two Unix Commands, connected using a pipe

What if have the possibility to extend this concept to existant GUI applications? We will try to present some of the scenarios we have got and we will limit this preliminary study to creative tools for designers.

Scenario 1: Scripting GUI Applications

Graphical applications can only be accessed through their interface proposed by the original main developers. The devices used are mostly the keyboard and the mouse, and if an advanced user wants to do a repetitive or a specific advanced task, he needs to use macro recording tools.

Macro recording tools are not available inside every application, same external applications can solve this like "snippets" but we still need the GUI interface to be available

Why we still external tools that depends on the GUI to automate things? Isn't better that we have the possibility to automate applications without relying on the proposed interface?

Many advanced tools in Linux, like inkscape and gimp, tried to provide this: a non GUI interface that can be accessed via scripts. But sometimes this interface lacks many of the functions, and we can't see what we are doing in live until we open output files.

import dbus
bus = dbus.SessionBus()
ro = bus.get_object("org.inkscape",
"/org/inkscape/desktop_0")
print ro.ellipse(0,0,100,100)
print ro.ellipse(100,100,200,200)
print ro.ellipse(50,50,150,150)
print ro.select_all()

Using a simple DBus API like above, we have all the benefits united, we can access the application from outside, script it, and we have the possibility to see the result live on the application canvas, we can modify script options, or directly manipulate objects for operations that is easy to perform without a script. DBus has many language bindings, so we can use any interface we want.

Going in the direction of a DBus solution, is like opening a Pandora Box.

Scenario 2: Interactive programming

In the previous scenario, we speak about scripting applications, but what if we combine some advanced script, add a GUI interface, and make them configurable ?

We have then the possibility to create "plugins", but which lay in another process, written maybe in another language, and can do a lot more things.

We can write a small script, see the result on the canvas, and modify parameters values to eliminate developers blind coding.

Interactive Coding applied on Inkscape objects. We can see the result directly when modifying objects properties.

More advanced tools can emerge if we add operating system architecture knowledge, like "magic lenses" concept. In this example we know many things about the application including its window, its objects, its functions, we provide semi-transparent window that can modify inkscape internal objects.

If we push more this concept, we can force a simple drawing application to act like a graph plotting app. We can even use it as an animation tool by modifying objects properties like position, color, size etc.

We can see the animation directly, and we can export a new image each time. The set of image can be combined to create a video or any animation.

This animation is created using inkscape by modifying stars properties, exporting each frame, and finally creating a full animation from the set of images.

Scenario 3: Factorisation of application programming

More than creating these advanced plugins for application, we can push the concept to the extreme. What if we eliminate the application default GUI and have the ability to show another interface we want and which is only connected to the core app through dbus calls ?

This may make some of you think about the ubuntu HUD

We can use an application using another interface and providing more functionalities, by taking its menu in the case of ubuntu HUD out of it, and communicating through DBus.

Solving tools inconsistency

Why in hell we need such a thing? A first argument is by asking the closest designer you know about the tools he uses. Most of times he will cite a lot of tools, most tools share a common base of functionalities (which is drawing..) but each one add other functions, like sketching templates, exporting a mockup scenario, vector drawing, animation making, ...

CAD Tools, mockup tools, animation tools, proposes the basic functionalities of drawing, in addition to a more advanced ones depending on the final use.

What if we can be able to share functionalities in a core-app, but make the interface pluggable depending on the use ? If we want to draw, we show a simple drawing GUI on top of the canvas. If we want sketching we show another one with sketching templates. If we want to animate, we show a timeline of animation.
The benefit here is that a huge amount of code is shared and developers will need to write less code.

Solving one device inconsistency

Designer use a lot of tools to do their job, but most of them use a creative suite built by one company. This means that the interaction logic behind the tools is almost the same. The icons are also the same. If someone use one tool, he won't be lost using another.

In the free/open source world, tools are created by different communities. And so are the icons, the interaction design, the logic etc. If you learn a tool, you really need to invest another big amount of time learning another. So the problem here rely in the interface and the interaction.

What to do if we want to solve this problem? A company which builds the platform and wants to invest in this, can hire a designer to create GUI for a set of applications, and they will share the same logic. Linking the interfaces with applications should be very easy if they export all their methods on DBus. It will be a functionalities-matching job.

I want here to cite libdbusmenu by Canonical, they have sorted to grab any application menu, show it where they wants, and they use other rules for matching like searching for the menu name. In recent releases they added "a scope" to provide fuzzy matching. As they have do this only for menus, they can do the same for more internal functionalities.

Getting rid of the main GUI interface and providing new ones by the company is the extreme case of such scenario.

Adding more input options

Some time ago, we wanted to add multitouch functionality to Ubuntu Maverick. At the time, a lot of things needed to be developed, we have some devices supported and emitting events from the Kernel, but applications just ignore all of them.

We had really a lot of discussions on what's the best way to route events through the layers of X then through libraries until reaching applications. We have to think about the raw multitouch events as well as gesture events. At the time, a quick solution to show to the world what we are doing is to develop Ginn, a gesture injection tool that works without the need of support from libraries, and without the modification of the target application itself.

The solution was quite simple:
Get gesture event, get the active app, Read the wishes of the user (configuration file), Convert these advanced events into something the application already understand: keyboard taps and mouse clicks.

That simple solution allowed us to show to the world the beauty of what we are doing. But we were limited to mouse and keyboard shortcuts. Beside the performance issues, just imagine the power of matching such events directly to internal applications functionalities through DBus.

Using hand angles detected by the Leapmotion device to move objects inside inkscape.

Solving platform inconsistency

Many users have more than one computing device, they can have a computer, a tablet, a phone, a TV. Software in each of the platforms is different. But the tasks we do on each of the platforms share a common basis of tasks.

Let's get back to creative and drawing applications example, we can use a drawing application on a desktop computer, and use another one on a tablet. The usual computer interface will be unusable on the tablet, as the input modalities and goals are different. What we still have are the application logic which stay the same: drawing, image filters, image operations (crop, resize, ...)

Do we need to create a new application for each platform? Or just one and show a new GUI and interaction model for each one? What if we want to start something on a device and complete/view it on another?

What will remain is just the canvas which will serve as the feedback for the operations, along with the included algorithms. All of the functionalities will be exposed through the DBus Software Bus.

The GUI interface will be an additional layer displayed on top of the application, it changes depending on the used platform.

Application developer will not be asked for creating specific interfaces but the platform development team, specially if they are targeting many platforms should think about this factorization of the development. No new application should be coded from scratch, but just interfaces matched to application internal functions published on the bus.

Scenario 4: Application composer

What if we have a platform that have a lot of applications exporting their functions on the bus. In some cases, a user wants to accomplish a task that use functions dispersed in many applications. An application composer is a meta-application that can accomplish this complex tasks. It connects the output of an application to the input of another in a similar way to CLI scripts. But here the "running mode" can be visible.

Concept image showing an application composer using a set of GUI applications in order to accomplish a bigger task.

Example:

I want to get data from a Calligra Sheets table, draw these data in an application, export to an image, draw a new set of data, export to another image, ... combine images into an animation. This pipeline can be abstracted and launched by an application composer which will connect applications themselves to accomplish the bigger task. 

Scenario 5: Interactive Documentation

A new way of building applications needs a new way of building documentation.Now there are two famous ways to create tutorials:
1. Record videos of a users using the software,
or
2. Take screenshots of the steps and write an accompanying article.

In the two cases user needs to switch back and forth between his software and the tutorial. This can be a problem for novice users as they can lost the step they are in, or fed up by pausing and playing the video each time.

What if we can create a tutorial which is aware of the current step of the user?

Application aware Documentation

In DBus, we don't only have methods export, we can also connect to signals and get more information from the application. We can create a tutorial by showing a small action to be done by the user, and then waiting for the signal of it being done. And moving to the next action.
This frees the user from switching between the application and the tutorial, and avoid being lost in a lot of information.

Generating usual documentation

We still can have the old way of documentation but that can be generated by automatically taking screenshot of steps or by my video recording. If the GUI or the icons change, we regenerated the tutorial.

Concept of recording the steps of a tutorial, using a specific GUI, and generating a video or textual information.

(This article is currently a draft that stayed at this state a long time.
Please be free to help improving the concept and idea by some brainstorming or/and critics
I may add more information that I have in an independent paper with some testing code in the coming days.)

Things that still need to be discussed:
Standardization, Drawbacks, "microcloud" (per House), ...

Unveiling The Technology Behind Leapmotion

The information written in this article are based on guesses using sources from the Internet, including scientific articles and demonstrations videos. Mirrors seems to be not used but other simpler mechanisms as cited below near Fig.5.

Introduction

Last month I have been surprised like everybody else while watching the leapmotion video. Many of the famous people working in the NUI area have doubts that it's a fake.

The technology used in leapmotion is 100x more accurate than the kinect and uses only 2% of the CPU, a complete not usual break to today's technologies.

Since the launch, I have been searching in my free time for the possible technology being used inside Leapmotion. And it appears that I have found how they managed to release such great device.

Search and Elimination

I have searched for all possible technologies which can recognize gestures:

• Ultra-Sound: can be used, but in that level, the precision can't even reach in best cases less than 1cm.
• Electric Field Sensors: Are not precise too, can't detect non-conductive objects.
• Structured light: Kinect-like ? but kinect is less accurate, and not as responsive as the leap.

You can find more guesses here and here

If not one of all these, what can the technology be ?

Tracking the tiny details

The leap have released many videos to demonstrate their gadget, after watching them carefully we can guess the limits of the system and from them guess the composition of the system.

Let's start with this photo:

Fig.1: David Holz demonstration

As you can see in Fig.1, the hand of David is a set of dynamic points, but also it doesn't appear to be an exact human hand. Fingers and the palm of the hand are fitted inside some sort of eggs. Which means only something: what we see is just a model of the hand, not the raw input.

Having a model, means also that there is no such complete information from the input. And this answers one of my first questions :

How have they managed to get all the surface of 3D objects ? Even the one which is not facing the sensor ?

Engadget is the first website to release another useful information detail: the nature of the sensors used.

Fig2. Sensors used in Leapmotion are just bare VGA cameras !

Having cameras as sensors confirms the use of a model to show the hand. Because cameras can only see a surface.

A precision of 0.01 mm ? This is another important detail. That precision coming from the data provided from bare cameras mean that there is more hidden data to be resolved in usual RGB color space. 0.01 mm = 10 µm which is not very far from the infrared wavelength.

Here we can no more speak about pixels, but only frequencies, The resolution space where the information will be calculated is the frequency domain after a Fourier Transform.

(And this is how I see it: if you can resolve an equation in a "usual" space, just find another space where it will become easy. Even in imaginary spaces like Complex Space etc. Reminds you about sci-fi movies and parallel space ? If you have a problem difficult to solve in you life, move it to another one and once you've the solutions get them back after a small transformation. ;-)

The Missing Link !

During my M.Sc in Human-Computer Interaction in Telecom Bretagne here in France, I have learned that it takes about 30 years for new invention to go from simple research to mainstream products which called by Bill Buxton the long nose of innovation. So if it's here now then it should have been for so long.

Searching inside the cloud of innovations I've seen in the past, I remembered a company which have made a lot of buzz last year, during this same period, it's called Lytro.

Lytro have made a new product which let's you take pictures then refocus on any object in posteriori. 

Here comes the missing link, if we are able to refocus objects, we'll be able to detect 3D depth from unfocused objects, the blur from unfocused objects is a continue function only limited by the light's wavelength and sensors accuracy resolved in the frequency space already mentioned. 

Once I have the right keywords, now I can search inside the research papers base. And it appeared that a lot of papers explained the concept in details.

Depth of scene from depth of field

The first paper I've found is published in 1982, 30 years from now confirming again the Buxton's Law of big Nose.

To be able to imagine the concept, take your smartphone, open the photo taking app, now touch the screen and you'll be able to focus any object in the scene. The phone has a function that moves the lenses to make an object looks fine, the function just selects where is the region with the minimum fuzz.

Now, image if we have the inverse of this, the lenses are just fixed to a predefined Focus distance and Depth of Field, images looks clear only when they are in that DoF, but if they are farther or nearer, they look fuzzy. Using the inverse function found in any cameras, you can predict the depth from the fuzz.

"Along each geometric ray between the image plane and the lens, the image moves from being in relatively poor focus, to a point of best focus, and then back to being out of focus. Thus if we could trace along the path of each incoming ray to find the point of exact focus then we could recover the shape of the 3D world."

That was the concept, but in real world you'll need to go deeper with mathematics and technical details.

 

Fig.3: Images with different DoF from a single shot [levin2007] 

The simple key formula for Distance to an image point used by Alex Paul Pentland is :

\( D=\frac{Fv_0}{v_0-F-\sigma f} \)

where:
\(v_0\): distance between the lens and the image plane

\(f\): f-number of the lens system

\(F\): focal length of the lens system

\(\sigma\): the spatial constant of the point spread function (radius of blur circle) which is the only unknown variable.

Because differing aperture size causes differing focal errors, the same point will be focused differently in the two images. The critical fact is that the magnitude of this difference is a simple function of only one variable: the distance between the viewer and the imaged point. To obtain an estimate of depth, therefore, we need only compare corresponding points in the two images and measure this change in focus.

\( k_1\sigma_2^2 + k_2 ln \sigma_2 + k_3 = ln F_1(\lambda) - ln F_2(\lambda) \)

The difference in localized Fourier power is a monotonic increasing function of the blur in the second image. Or by the first equation, the distance to the imaged point is a monotonic decreasing function of the difference in the localized Fourier Power.

And as this post is not a formal scientific article, I won't put a lot of math, but instead the reference to them. You only need to retain that with some bricolage you can get depth from focus and defocus and to know in details how this can be made, you can start reading [Pentlend87,Pentlend89] and [Xiong93] then follow all the new work coming out of these papers.

How is this used in the leapmotion ?

Fig.4: The optical system of multi-focus scene capture as explained by Pentland.

The leapmotion uses ~3 cameras, each cam should see the same picture frame to remove the need of calibration as in Fig.4, so a basic system of mirrors and lenses is needed. As you can see here, the scene  image enters the half-silvered mirrors system and is divided into 3 areas. Each one has a lens with different focal point. The resulting pictures transmitted by cameras are similar to the ones shown above in Fig.3 but simultaneously and in Real-Time.

In opposition to stereovision mechanism, this optical system removes any need of massive computations to calibrate the image and construct a disparity map and match objects.

Fig.5: The possible system used in leapmotion

Update: The Leapmotion can even not use a mirror system to generate the disparity map. Other than depth from defocus, there is other mechanisms which can provide ultraprecise depth variation detection.

Acceleration of the computation

After all this, we know that he uses many cameras to get the surface, and the resolution space is the frequency domain. But how have he managed to get a CPU use of 2% according to ExtremeTech ?

The Leapmotion is declared to use about %2 of the processor. This can be made very easily if we precompute all values of the main function and stores them in a cache. Then instead of using the CPU, we only read and use the values directly.

The post-Leapmotion era

The introduction of devices with such precision and accuracy and in the same time built on simple mathematical models makes a break at two levels:

1. The way input should be handled in today's computers and operating systems
2. The events and how to be routed inside apps, widgets, daemons.. (post-events abstraction era ?)

The first point is mainly a reorganisation of the input subsystem into a more dynamic way, we should not forget that Leapmotion is just 3 cameras + some magic mathematical formulas, I see the math as filter  to a bare video input from 3 input devices which brings us with more information than meets the eye. Any combination of new "filters" which mix input devices can bring more wonderful "sources".

The second point indicates that we are now standing on the edges of the old model of standard and prefixed input events. The model where widgets is by default subscribed to a keyboard/mouse events "or similar", taking it on focus then spreading it to upper widgets if they don't consume it.

Future applications or "Toolboxes" need a new model that allow the subscription to new "equivalent sources" with the ability for some either to subscribe or to cede the control of its internal functions access to third party managers eliminating even the need of providing a CLI/GUI/...

This part is discussed in part in the last post and needs effective working prototypes.

Linux is the only system where it will be possible to try a new concept of input handeling similar to how StreamInput is currently discussed. An input mechanism where the sources are chosen in cascade, optimised then compiled in input pipes and provided for upper level use. We may only lack enough bravery and will to change the way everything now works but with some help from mainstream kernel developers, the khronos group and people working on input and drivers factorisation from LII-ENAC, this can one day see the light.

Input Pipelines and Sensors Flow Soup

Fig 1. Input Layer Abstraction

By convention, Input devices are the peripherals which detect a human user input. And sensors are those which detect the environmental variation, related or not to the human.

Despite the existence of other definitions, both Input devices and sensors are needed to provide rich interaction with the user and allowing him to accomplish the tasks he want in less time.

Input devices can be the keyboard and the mouse and almost every application supports them but the definition also include touch and multitouch screens, touchpad, joysticks, etc.

From a wider point of view, keyboard and mouse seems to be two constant: K1, K2. They are modeled in operating systems using Finite State Machines and they are routed to the application without too much alteration of their original content. (Except the transformation of raw codes to ascii or unicode ones for example)

The "Why"

Operating systems, and I'll take Linux as an example, have abstraction layers to handle the input. Every peripherals generating key clicks is seen as a keyboard. For touchpads, mice, touchscreens, pen, etc they are attached to a virtual pointer device, and are handled as a conventional mouse.

Device drivers may generate other information (finger blob size, blob orientation, etc.) but they are all eliminated and don't reach the application.

Last years, we have faced the emergence of an 1.unlimited number of input devices and sensors, each of them provide very different information. And in the other side, 2.rich application, exposing a lot of features, or which have more dimensional variables than ones found in a single input device (3d object control in 3d environment).

With these 2 poles, the problem becomes obvious:

Why is the operating system preventing us from using all devices capabilities inside our rich applications ?

Ok, let's fix this and answer the question with another :

Do you have another solution for mapping input events to application features ?

Mapping Input events

Before speaking about mapping, we should study the input itself even taking few examples.

Touchpads have their input considered as a compatible form of mouse input. But their brute information comes very noisy. When using direct input your pointer moves in a similar way of a Parkinson disease patient. The developers of X.org have added a "filter" which smooths the movement (named "Response-augmented Exponentially Weighted Moving Average Filter").

Speaking about mouse input, the X.org add also another "filter" that alter the smoothed input to accelerate its movement, so you a user don't need to slide a lot of times to move the pointer in bigger screens.

And let's imagine that this flow represented in Fig 2. finishes as an input to control the camera in a 3D scene:

Fig 2. Input Flow to control a 3D scene

From the last representation, the input system can be seen as a flow and in each point, the input got transformed before being routed to the application. The 3D scene itself takes that input and maps it internally to control the camera view.

The problem in this case is that, what if you want that your management meets the standard and won't be considered as a hack? You can't avoid the virtual pointer, and you can't avoid this predefined set of filters. You can't also select the manner of which the input can be mapped inside the application ( mouse(x,y) → scene(x,y) or → scene(y,z) etc.)

Another problem is that, some filters are inside the input device driver, other are inside the Input layer, and the rest belongs to the application. And all of them are hardly written and can't be changed or remapped without recompilation of the full stack.

Any time we have a new device or new events to support in the system, we keep asking this question:

How we will fit the new device input inside this flow with minimum effort and the least loss of information ?  

Rethinking All the Stack
In 2009, I have discovered all of this and I have found some efforts to simplify input management. Just having the ability to imagine a possible change is a lot of bravery... For a system developer who only use a keyboard, why he should think about rewriting everything ? That's a lot of work man !

From the last figures, we can imagine that filters should be extracted outside of device drivers, and from any predefined flow in a system, and we can play with them to modify and transform raw input to any useful form.

The flow becomes a general graph, where a sensor input can control how much a filter transforms a device stream to another. For real-time and other needs we may add also a universal timing to master how much each filter takes time for his computation.

Fig 3. Input Flow as represented by StreamInput Khronos Model.

What about applications ?
Legacy applications takes only two sort of input : Keyboard and Mouse. These two inputs still very limited to what is possible to do. But We have already have filters which route information through them including keyboard mapping transformers (possibility to write in Arabic/French/Chinese with the same keyboard), mutlitouch injectors in legacy apps like Ginn (included in ubuntu), or whatever else.

But wait, shouldn't we rethink the application itself ? Why they don't expose their functionalities through a Software Bus, where we have the freedom to connect filters' input to the specific action to be performed?

Fig 4. Rethinking application input

By doing this the biggest work will become the mapping. And we will need to search best ways to do it to perform user goals in better ways.

Scientific background ?

A lot of scientific research have studied these problems. But each of them tried to fix either the input flow, or the best mapping. But not all the cycle from and to the user.

For the Input configuration you can see the work of Pierre Dragicevic : iCon.

Another interesting thesis is the one by Rami Ajaj (PhD in French)

Theoretical and architectural support for input device adaptation paper.

A lot of other notable exist but I can't cite it all. 

And for a deep study of mapping and to understand the need of filters, it is mandatory to study what is an input device, a sensor, do some morphological analysis of their design space, study actual standards implemented in operating systems and describing a large spectrum of devices and usages. 

(I have skipped many research areas related to this subject to keep this post clear and simple.)

Knowledge Grows When Shared

Long Time !

Many things happened and I haven't blogged about them !
Let's see if I can fill the gap...

Reviewing the Google Chrome

Google has invested a huge quantity of money and marketing for its Chrome browser. Sometimes people install it then use it without knowing that they changed their browser, by having only followed the link in the top right.

People install Chrome by clicking the link in Google page.

Many computer engineers know that this navigator has many advantages and technological power as being the fastest browser (for its Javascript interpreter/PseudoCompiler, and also from a usability PoV), the use of the best html/CSS engine (webkit), the SKIA library for showing graphics (few people know about this library now being called/integrated as chromium, firefox itself use cairo for rendering).

So, after all of this, is it only a bunch of technology assembled in disorder ?
From my point of view, and after having some human computer interaction courses, I started to view things in a different ways. And I have detected these points :

• The application of Fitts Law

Tabs are placed in the top of the screen, so the virtual growth of buttons are bigger, and we can switch tabs a lot easier than the traditional way.

(Apple use the same law from ages having always the menu in the top of the screen)

• Reducing human errors

People can make errors easily when trying to switch from one tab to another, when the width of the tab is too small, the probability of making the mistake of closing the tab rather than switching to it.

Google removes the close button when the tabs width is too small.

• Better feedback

I really enjoyed the search function, when I search Google tries to indicate the word positions inside the document but also in the right and exactly in the sliding bar. Every small yellow line indicates the word position.

• Better use of the screen

In Chrome, all the screen is used, no status bars, when there is a need to show something, it is shown using the needed place.

• Better interaction :

When closing a tab, the next close button comes to the current mouse cursor to facilitate closing others. (closing tab is contagious ?)

The tabs are redrawn only when you move your mouse outside the tabs.

Being different form Firefox, Chrome have only one place to enter urls, text search and every things.

The browser is intelligent enough to know what the user wants.

• Better usability :

In Chrome, every text input is resizable. When it is not wide as you need, just make it bigger.

Many other details exist (I speak about "Chrome only" features) and needs to be cited here, but these are the most important one.

This doesn't mean that Chrome is perfect. It has some problems dealing with RTL texts like Arabic sites that aren't shown correctly.

And the recovering of a crashed/closed browser (it exists but I feel it very bad). Some times I can't see the recovering button but in Firefox it is always present after a crash.

Visualization of Algorithms, how should it be ?

Last days, while I was teaching a student some sorting algorithms. I asked myself how can I explain it the easiest way. The evident solution was to use some visualization tips.
OK OK, I say some "InfoViz", but then, the big question would stay the same : HOW ?

According to the human-computer interaction course I have got, Humans don't react like machine, they should have "Mental Models" to manipulate information and resolve problems. We don't have one Human mental model but we are sure about some reactions.
According to (Philip Johnson-Laird, 1983), humans need examples to how a mathematical functions work (hmmm, we don't speak about math nerds here...), so when we see a formula, we need to play it on some examples in order to construct our mental model.

Visualization of BubbleSort algorithm on a sample data.

So, to understand an algorithm, we should see it running on a sample data step by step, and then we should select the best data to not fall in a trivial example and this is another problem...

But, why we don't add a step in between ?
We have the algorithm coded in some language in one side, and the algorithm running in the other side.
Maybe adding the visualization of the algorithm itself can help the reader constructing quickly his mental model and reducing the time needed to see the algorithm running on data.

Some people tried to visualize algorithms by translating loops directly using schematics like these :

Explaining the multiplication µAlgorithm inside the µProcessor and introducing the Booth Algorithm.

Another almost useless technique for visualization I have seen in a site

But can we mix the algorithm itself and the data manipulation in the same place ? I have produced this figure from my own thoughts but really, we should think in a new way than everybody is following.

Searching for a new and better figures to help construct quickly the mental model.

In the last figure, arrows explain movement, the limits are nicely seen and understood, and it is clear that the second variable start its position from i and not from zero.

Can we ameliorate this figure and prove this way of representation scientifically ?

Maybe it can be a good point to start from.

:)

Fitts' Law, a small presentation

One of the most known and applied laws of Human-Computer Interaction is the Fitts' law. A good interface should optimize and reduce the time presented by this formula :

"a" and "b" are only two constants, defined by the used hardware properties like a mouse. D is the distance from the object and W is the object width.
I want only to say that this is only the first formula, many other derviate ones exist.

The most important is how to design interfaces to optimize the time to select an object. I want to present the openSUSE menu where the developers have applied this :

 

When I've clicked in Developpement option, all the menu has changed.

Being different from a "standard" menu, the user haven't to move his mouse by width, but only up and down and no new menu windows are created. So less mouse movement.

In this precise example, not only the Fitts' law is applied, but also the Steering Law (Accot-Zhai).

This is just an introduction, and presentation for a small example, but I will to show interface features in other projects.

Linux Graphics, Part one

In this small post, I will speak about the Linux Graphic Stack and changes being addressed to it.


It is very clear, that the most thing that should change in Unix systems are the graphics. Most Unix systems use Xorg to handle all their graphics. I really think that is a very bad and old solution that should be changed.

• The Past

To make things looking clear, lets compare the architecture of the current implementations :

In almost any Unix-like system, if we use Xorg it will be the layer responsible from low level graphics to some more advanced features. So it is doing a job which only the kernel should be responsible for.
Even graphics card drivers, they are made for every Xorg release and not for a Linux release.


If we add to this that X releases are not as frequent as the two other layers, we can conclude that the Linux graphics mechanism is the Achilles' heel of all the system.

• Future

The future may be a lot better. With the include of the Kernel Mode Setting [1] in last Linux kernels (from 2.6.29) and specially in the 2.6.31, the kernel start getting his real role of the only thing accessing low level hardware.
The KMS allow less flicker, quicker terminal switching (with Ctrl-Alt-F1 to F7) and more.
Another feature is the ability to run Xserver itself as a normal application without root privileges. And allowing more security.

This start to let the Kernel do his job, is only the start. The Linux kernel 2.6.33 will include more work done to provide more low level handling : a KMS page-flipping ioctl [2] to optimize more and more time, and simplify management for other systems.


The page-flipping is a necessary thing for other projects like the Wayland Server, which is a lightweight replacement of X (and not a rewrite of it).
Xorg has become very old, new models of graphics and inputs come and its becoming more and more complex to make X supports them all.
Multi-touch input is a main area where X can't provide a good solution for that. Even Multi-pointer-X still doesn't answer all questions.


Wayland can become a solution if we design it having all new today problems in mind. It should be lightweight and easy to develop. After that, libraries like Nokia Qt could be easily ported to it.
The thing that everybody should know is that when a project becomes very old, with code that can't be understood, and huge, then it should be rewritten from scratch.
KDE developers faced many critics when they started rewriting KDE to release KDE4. But in the end, we now after releasing a "clean" desktop environment, we start seeing differences.


The design of Wayland, shouldn't be addressed without proposing a model being a skeleton of all manners of view surfaces and abstraction behind that. A recent paper [3] collected most of problems and it need to be applied on a real world implementation like Wayland.

To be continued...

• Links :

[1] http://en.wikipedia.org/wiki/Mode-setting

[2] http://www.phoronix.com/scan.php?page=news_item&px=NzY5OA

[3] http://portal.acm.org/citation.cfm?id=1629826.1629828&coll=Portal&dl=GUIDE&CFID=61492784&CFTOKEN=12278186

Google, THE monopole

The main goal of Google is to hold the maximum of viewed adverts on the net, and gain huge amount of money. Till now, ads are only shown as small links with some text. And the context intelligently matches user interests.

But, will google in the future, only rely on such type of incoming ?
My answer is simply : NO !

First step after acquiring Youtube is to play video ads before launching mostly viewed sequences, also put some intelligent context matching text ads somewhere. There is dailymotion and he already doing that.

But if we rethink another service that only google holds its sources, the GoogleStreetView !
Google Street View is a very helpful service provided by Google for free and for everybody.
Google can simply use some algorithms to detect the ad places in a street view, the orientation the deformation, and replace these zones with Google related stuff.

Goole StreetView, the next...

As explained in the photo, it won't be a difficult thing to be coded by the Mountain View team, and it will be a "Google only" stuff difficult to be reproduced in resonable time by other competitors. And of course, it will be a colossal source of money.

I really wish you "Don't be evil" Google !

Nanotechnologies & Nanostructured Materials workshop

From yesterday (15 March) and until 21~22 I will be in Hammamet.

I am proud to be member of the technical staff of a workshop that speaks about nanostructred materials and nanotechnology.

This is the first time in Tunisia and it is with collaboration with many US universities.


I will attach photos later ! Please wait !!! ;-)

Journée Texas Instruments

J'ai pas raté bien sûr le séminaire organisé par Texas Instruments le 7 Février à la Faculté des Sciences de Tunis



Voici une image du public présent !
(A ne pas oublier le grand nombre de la communauté open source qui a été présente)

Me voici avec mon Classmate Zied

Encore une fois

Et bien sûr nous n'avons pas oublié de prendre des photos avec Mathias le représentant de TI dans cette journée ainsi que mon ami Nizar !

SFD 2007 !

Software Freedom day 2007 !
It was a very exciting event ! I discovered many things and I have met many persons that I had known only by mail.

I got many photos and I am proud to show some in my blog !
This is a photo with Mr. Hatem Zidi one of the best IT engineers in Tunisia !


Other photos are coming soon ...

Novell Hack Week

J'ai entendu parler ces jours du Novell Hack week, c'est un événement qui a lancé Novell fin juin pour que ses ingénieurs et développeurs font ce qu'ils veulent faire !

Vraiment c'est très magnifique d'être payé pour faire ce qu'on veux ! et pendant toute une semaine ! De ce fait les développeurs ont pris un bon souffle et ont contribué à plusieurs projets.

Le résultat était en totalité bon mais il y a quand même des projets qui ont échoués !
En tout cas même pour ceux qui rien n'a marché pour eux, ils ont un prix de "Best Failure"

je ne pense pas avoir ce genre de chose dans les sociétés tunisiennes !

Link