Archive for the ‘in-between’ 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.

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.

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.

uncoupling

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.

toolkit

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.

In Between

février 3, 2007

This category is created to list the utilities, programs and whatever which could stand between the user and a operating system, or a information system. Some third terms upon which one could enable an user interface a little more closed to the communication scheme.

Calendar, bookmarks, contact and tags these things are the easiest. This is mainly about content and its management, so a content managment system could be this third term.

Well, calendar is different since it is about event through the time but not primarly about content. Nonetheless, when one considers a mailer one has in this case some contents which are tied to some events: awaiting or giving a answer, for example. Further, the event is also an action, more exactly its output, hence, one retrieves here the cybernetic scheme: people have a common goal, they transmit and receive some content, perform some action upon it accordingly to the goal. This implies that content isn’t just a set of data, but can be a call to some action through the time just because there is a common finality. Maybe this is why some mail client present a task manager but this function doesn’t have to belong to the client only because most of these tasks involve somebody else. In this regard the mail notification scheme is more relevant since it gives a feedback about an event/action.

So far, one imagines the user as the person in front of a computer, though one can consequently include the developer as an indirect user. This is the case each time one does a bug report, either through the web or through a bugtracking program. Of course, this purpose is really complexe but it’s just to give the idea: the user is a broad notion.

If one sticks only to the solely user then, some other functions could be stand as a third term. For example the window manager. It’s primarly a service to the programs which are a set of service to the user. The window manager could be a service for the both, a common service. At use there is no difference between a window and an icon, in appearance one does more or less the same things. Maybe each object of a GUI could be a window. Certainly too much work for a single window manager and a poor graphics card, but let’s that aside. The main idea is that the system has to cope with the pixels meanwhile the user has to manage the limited space of the screen. Hence there is here again a common concern.

If you have a look at this post, feel free to comment the kind of thing which could be in between.