Archive for the ‘GUI’ Category

Navigation Object Window

octobre 7, 2007

A web browser stands in-between the user and the webdesigner. The latter can define the browser’s window, while, since CSS2, the former can override the css style with his own. More generally, a standard web page is really in-between.
I guess that one can improve the object window in such way that the navigation menus appear as some elements of the browser’s window like the status bar for example. That would permit to fix the navigation menus without the use of frames, i-frame, floating or overflowing style. Hence, scrolling would be related only to the content but not to get it. Some features handle by some javascripts could be handle by the browser itself, for example, showing/hidding a menu.

Here below, what would look the Reghardware at the Review section. The top navigation menu is embedded in the browser’s window, that’s notified by a bit of the chrome at the right-hand side. There are there a black dot to disable the function, and a double-arrows to collapse/expand the menu.

top nav embedded

To get this state or to inform the user, the simplest way is to modify the pointer appearance; it could be automatically done as a browser option or define as default by the webdesigner. Anyway, the options give the choice to the user: automatic; ask to me; show to me with the pointer; never.

Now one has chosen the first article and this one goes through several pages. The list of pages can be an element to place at will by the user:

page list embedded

Or the same list has been defined by the webdesigner:

page list embedded design

All that seems to works fine with a top navigation menu, what’s happen with a left/right navigation menu. Well this is the same principle as shown below, with both a top and right menus:

top and left nav embedded

One retrieves the same buttons as previously, plus some up and down buttons (it’s up to the user if he/she rather like a scroll bar, since that is handled by the application)

One can argue that this is useless since styles and scripts can do the same. Yes, but one can say that the less the browser’s engine has to perform, the best it is. That is less work for the webdesigner too, though that doesn’t prevent a fallback, but it’s up to the designer. Moreover, a few website are written with the accessibility in mind, so this purpose is let to the browser and that’s an other good reason.


Managing packages

août 20, 2007

The purpose here isn’t about the packages manager’s ability to find its way in the dependencies jungle, but how a linux distro user could manage easily the packages.
Linux is very flexible but to exploit its flexibility that requires some knowledge; packages manager are consequently flexible too but their front-end could present the things more clearly and distinctly. Because Windows and Mac close the hood for a better user experience, one has here a cultural misunderstanding : actually one installs « softwares » and nothing else. Is a « package » something else? The same about a library, a module, and so on. Looking at a front-end like Synaptic, one gets all this names at once which, hopefully, are categorized in several task area, but one could present all that through a higher level of category. The first level is the notion of package since this is a container, then, the second level is its content which is then related to a task area, the third level.

* package
** content (e.g library)
*** task area (e.g graphics)

At the second level, one has at least two categories: what is usually understood as « software » and the library. It doesn’t matter that the latter can be used by the user or only by some other programs, but it could be more interesting that the packages manager provides somes utilities for installing things more complexe, like desktop environment and servers, for example a LAMP. So, in this way, one has two other categories, lets say « desktop » and « server »

* package
** softwares | desktop | server | library
*** task area

One could as well put at this second level an utility related to the development, but as you understand one is just stripping out some task areas to the second level, either as an utility or a category. Legitimately, the system componments should be at the second level and, in this entry, one could have the utility to upgrade it entirely.

* package
** softwares | desktop | server | library | system
*** task area

The things are now a little bit more clear and distinct, one can go further by presenting the actions distinctly: updating, upgrading, adding and removing. Of course one can also downgrade and select the packages’location, but lets that as an option. Looking at Synaptic again, the stuff is presented whatever the status, of course one can filter all that. But if one wants to add something, one just wants to see the available packages and for the other actions, one just needs to see the installed packages. Hence, the GUI is more simple and understable: one has the list of the second level entries and the list of the actions.
However, a desktop environment has its own softwares and libraries, if one put them in their respective entry, one will find them at the third level and thus it’s a contradiction. The developement and server entries will lead as well to this problem. The solution isn’t a list but a matrix, something like « this for that ».

softwares | desktop | server | library | system
desktop   | desktop | server | library | system
server    | desktop | server | library | system
library   | desktop | server | library | system
system    | desktop | server | library | system

In this matrix some values don’t make sense, like server for library for example. Of course the GUI doesn’t have to show it, one could have three columns named « what », « for » and « action » or « do ». The content of the second column depends upon the selection in the first column. This way should cover all the combination, but there are not a lot indeed since only the entries « software » and « library » can be combined with the other. The GUI could look like this. Of course, one could arrange the order differently and/or change the labels, something like : « this »; optionally « for »; « to » update and else. Anyway, that won’t change the underlying scheme.

Appearance & Theme

août 8, 2007

I like remoted desktop. Yesterday I’ve registered to Cosmopod, by this way I can explore the KDE desktop. There’re too much things configurable for my taste but that doesn’t matter. In fact, as in the other environments, the user has still to cope with a list of setting. It’s inevitable but customizing his desktop could be less a matter of choice between several themes, with their own setting. I think that one better has to start with the desktop background and then, lets the user define the window, the widgets, the icons and texte. Otherwise, if one picks a theme and then one changes the desktop background, the theme could not fit well with the background, and reversely.

Ideally, the appearance should be a GUI editor, that don’t prevent to provide some themes, but one should be able to modify them as if they were a template.

The Big Board or why a panel?

juillet 10, 2007

I’ve look at the Big Board’s wiki, it seems that several goals are researched in this project with a lack of coherency. Mainly the purpose is to link the desktop with the rising usage of web-applications and take from them some ergonomic designs. Where this project tries to solve a problem of a different field is how to give a clue to the user at the early stage? For the instance, there are two proposals, one good and another one rather odd.
The good idea is to clearly show who is logged on the desktop, that gives a personnal touch and it could be used as an incentive to start with the system as a whole, to give a tour. The odd idea is to keep a statistic of the most used applications. If the intend there is to give a start for the user, that doesn’t work since at the beginning nothing has been used. Otherwise it’s just a global statistic proposed to the user but that seems too much for a start and don’t correspond necessarly to the user. If it’s just a replacement of the recently used applications, well, we have the same problem of an history-record and some additional problems.
How many entries should we display? Five, ten, more ? For an history-record, the more there are entries, the best it is. But a track of the most used applications is not a matter of quantity, for the user it’s a matter of importance which is not necessarly correlated to the usage. Should we track the files browser? Should we track the panel’s program itself? No, of course, excepted that there’s a pre-selection behind this idea which cannot catch what is important for the user. My point of view about the Big Board is that a panel is just a way to organize the space of the screen. One needs a launch-bar and a task-bar, the panel should be dedicated to the system as a whole and an other panel, at the opposite side, to take in account the use of web-applications along with some user’s setting like the sound, the screen resolution…On one side, the privacy, and on the other side, the network. The OLPC user interface has a similar approach.
Beside that, give a clue to the user at the beginning is nearby impossible if he or she has not a previous experience. It’s a field of research in itself, one can take some tricks from the web maybe, but a desktop has its own dynamic. At the beginning the environment could show itself where are the thing on a given request, that would be fun for a start and not a big annoyance as far as the user can disable this feature.

Vertical menu bar

mai 31, 2007

Currently horizontal, one puts the menu bar vertically. It could be display in a lateral pane or as a floating pallet. Two options at least for accessing to the menus : one at once, that needs a root menu or a selector; one expands them separately.
What do we gain by this way? Mainly some space. If each menu’s entries are illustrated by an icon, one could reduced the width of the pane to the size of the icons and one gets there something like a toolbar. Though, and depending the localization, the function’s name can be long, not mentioning the keyboard shortcuts, all that takes a little bit more space.
At a first glance, it would be less productive than the current position but one can display continuously a menu and without covering the canvas. That helps for the beginner to know the different functions of the app, and to relate the icons of the toolbars. This is maybe the main interest of this idea after all. One can in this sense keep the current menu bar, but its content is displayed in a lateral pane or a pallet

vertical menu bar

Horizontal files system navigation

mai 22, 2007

Currently, the UI presents the things horizontally or vertically. One tries to invert that to see what can be done.

The files system navigation seems to be a good candidate. The display in columns from OS X is an approach in this sense, however, folders and files of a given directory are still displayed from the top to the bottom. One suggests here to display them from the left to the right as below:

horizontal navigation

The white area is the content of a given directory and such disposition allows the user to expand independantly the folders of this area, thing that one can’t do with the OS X’s approach. In the picture above, the second folder is expanded (in blue) as well as the fourth (in green). In this latter an other folder is expanded (in pink), this is the usual display as list.
Besides the usual navigation tools (back, forward, scrolling bar…) a navigation window seems to be more convenient since one has here a presentation like a map. One could use also the separator lines as grip and move the map in every direction.

This display has the advantage to bring an overview and a representation, like a map, of the archiving. It is as well closed to a spreadsheet since each top folder can be seen as a field, and as well one could split the window as in a spreadsheet, thus, one can compare folders which are too distant between them. In the end one could apply here all the spreadsheet’s functionalities concerning display and maybe more upon the files system itself.

Task Tabs

février 26, 2007

Simply make a taskbar with tabs.


When for a given application there’s more than one window, the number appears on the tab (nothing new here), then one can expand horizontally the tab showing the windows by name.
One can expand a tab vertically as a drawer, the user decides how he wants to display the windows, either by name or with thumbnail. The user can as well put in the tab some tools or utilities of the application e.g for a web browser, the personnal bookmark.
Eventually there’s a scrolling bar, though one could also set the height of the drawer as needed.
Hovering an object displays information in the prompt. Though, it could be displayed with a layer as well.

There’s a tab too for the desktop, then, instead of put it in front, one just have to expand the tab to get its content. It could be the same for the trash folder.

By this mean, one can have a quick overview upon some documents related to a global task.

Let’s the user getting access to the functionalities

février 21, 2007

Currently GNOME is flamed about printing dialog, not enough functionalities. Maybe one better has to uncouple the back-end from the front-end.
Let’s say a driver, its functionalities are accessible through a set of keys which differents kind of values (boolean, integer…), something like Gconf. Then, with a GUI-toolkit, the user picks the keys that he needs and figure out graphicaly their values as he wants. By this means, everything being equal, people from GNOME can make their desktop environment as they think it ought to be; if the user disagree, he just has to change it.
No more flames about the printing dialog, just maybe that GNOME requires from the user some extra-works. Even not. If people can also share their customizations, the desktop environment developement will become a matter of back-end. Hence the front-end could be let to the user or to some communities of users.
Sure, my opinion is quite simple, but the technologies developement is better when they are uncoupled.


The GUI-toolkit

février 17, 2007

It could be a good thing if the GUI-toolkit used by the developers was shared with the user. Standardized GUIs are well conceived, nonetheless that doesn’t mean that they fit to the user needs and so on. Try every theme avialable on your desktop, let aside the look and feel, the structure doesn’t change but is more or less clear depending the theme.
So, having a lot of themes is great as well as to customize a toolbar, but that doesn’t touch really to the layout structure nor to its behaviours. That seems to be the same thing to have a lateral pane instead of a drawer, but not for the user because this is a subjective preference which corresponds to a reality at use. Last but not least, only the user knows what could be the best for him.


Of course, I let aside the kind of GUI-toolkit requiered for this purpose, obviously, it should be WYSIWYG, easy to use and so on; it could be a front-end able to struggle with GTK, Qt and Co°, or whatever. But, at least, there will be something in common between the developers and the users, that seems to be a win-win deal. Excepted for the consulting buisness in GUI design.

Contextual menu

février 17, 2007

What could be said about that ? Certainly, the philosophy there, is to give an access by a right-click to some functions that the target don’t present or offer itself. It’s not true under GNOME: the contextual menu of a launcher offers to launch the launcher, action which can be done by a simple click (is it not the function of a launcher?)
Now, what does one put in this utility? The choice could be completely arbitrary indeed. In other words, what is the context here? Well, in fact, there’s nothing really contextual, it’s just a remote control with a selection of functions.
So, one could let the user editing the contextual menu but, since it’s just a remote control, it seems better to provide a personal area like this one:


One puts there what one needs or used to use. Depending the task or the job to do, one gets directly the relevant tools of the software. Not really useful on 15″ screen monitor, but very useful on a 20″ and more. Ok, I’m not sure, but it’s not very new.