Difference between pages "Evaluation Notes - Icon Design" and "Windows, toolbox, inspectors analysed"
(New page: ==better behaving windows== A definite improvement in the UI must be made by making the toolbox/dialog windows (from now on named inspectors) behave like true floating windows, and not as...) |
|||
| Line 1: | Line 1: | ||
| − | == | + | ==better behaving windows== |
| − | |||
| − | + | A definite improvement in the UI must be made by making the toolbox/dialog windows (from now on named inspectors) behave like true floating windows, and not as real content windows. For this the following steps are necessary: | |
| − | |||
| − | + | # Solve that when GIMP is run with no image, that still an image window is shown. this will ensure that for linux and windows platforms there is always a place for the menu bar (singular) to be shown. There is an idea from the GIMP team to show a tip of the day in the otherwise empty window. We consider it an excellent idea to show something that helps in the ease of learning department in an less obstructive (not in a dialog) way. | |
| − | + | # Merge the menu bar of the toolbox window into the menu bar of the image window. | |
| − | # | + | # Give all the inspector windows their proper status, being not a normal window but a floating palette. The important goal here is not to make the inspectors always float on top of image windows, or to make them less chunky—those are just valuable side-effects. It is to keep them out of any window management overviews for users, e.g. the task bar on linux and windows. For the user the only thing that counts (and exists) is working on images, which takes place in image windows. All the inspectors and dialogs do not exist and should not show up when talking about ‘what windows are open?’ |
| − | # | ||
| − | |||
| − | + | When these changes are made, we confident that actually quite a few traits of | |
| + | current GIMP UI are removed that drive the constant user requests for a single | ||
| + | window interface, or WiW. | ||
| − | + | ==the single window interface, or WiW== | |
| − | |||
| − | + | The changes above also will put us on a sound basis to discuss a single window interface. | |
| − | |||
| − | + | Interaction architecture, like classical architecture, has trends in the solutions it prefers for a certain problem. And sure enough, the two important, high-end image applications that have entered the market lately—Apple’s aperture and Adobe’s lightroom—sport single window interfaces. | |
| − | |||
| − | + | From our point of view there are no negative sides to proving '''also''' a single window interface, except for doubling complication and effort in documentation and support in this area. | |
| − | + | ||
| − | + | We believe that the GIMP way of doing things can be that GIMP ships with the default set-up of two inspectors flanking the image window(s). With one single menu item (and not in the preferences dialog) the user could switch on single window mode. This results in an window where the first column (from left) is the toolbox inspector, the second is the image pane (where multiple images appear in tabs), and to the right of this the other inspector(s) in columns. The user has to be able to rearrange the the column order of these by dragging and re-docking, and to be able to tear off any and all of the inspectors to float them again. | |
| − | + | ||
| − | + | ==inspectors== | |
| − | + | ||
| − | + | Currently the contents of the inspectors is too fat, and not sportif enough. | |
| − | + | The cost of this is screen real estate and an actually permanent part of the | |
| − | + | interface that is taking too much attention from the image content. | |
| − | + | ||
| + | It is caused by implementing the inspector content with dialog look + feel. | ||
| + | One can see from the transient and attention grabbing nature of dialogs versus | ||
| + | the permanent and visually integrated nature of inspectors that a different | ||
| + | look + feel is necessary. | ||
| + | |||
| + | We cannot expect the UI guidelines for gNome, KDE or windows to define proper | ||
| + | inspector look + feel when it is Apple who is driving the development in this | ||
| + | field and the only platform to fully understand the benefits of inspectors. | ||
| + | Therefore some rule-bending and wheel-reinventing will be necessary by the | ||
| + | interaction architect on this project. Because of GIMP’s calibre, it will | ||
| + | have to push the envelope in this regard. | ||
| + | |||
| + | But it needs to be done to achieve a leaner and more efficient GIMP UI. | ||
| + | |||
| + | ==growing cramps== | ||
| + | |||
| + | The expert evaluation showed that there is no such thing as too big an image | ||
| + | window. Photographic images are automatically larger that a monitor (or two); | ||
| + | as is original art, when produced for print; production of a set of web | ||
| + | elements happens together on a canvas; even icon editing gets cramped quickly | ||
| + | when working enlarged on the hi-res version. | ||
| + | |||
| + | GIMP has to support a minimal monitor spec, and the only thing that needs to | ||
| + | be decided is whether it is a 1024 or 1280 screen laptop. If the user buys a | ||
| + | bigger monitor (or even two, not ''that'' common though we observed, among pros) then it | ||
| + | is the user who has to profit from this investment, with a larger image window | ||
| + | (== working) area, and not GIMP that feels that it can stretch out its UI a | ||
| + | bit in this not so cramped surroundings. | ||
| + | |||
| + | In short, we have to design for a minimal spec, and anything more that users | ||
| + | got in terms of real estate, is their gain. | ||
| + | |||
| + | At the moment the two default inspectors eat about 440 pixels of the width of | ||
| + | the screen. Changes mentioned above will already help us in this regard: | ||
| + | slimming down inspectors will fight their bulk, and making the inspectors true | ||
| + | floating windows will make it realistic for users work with bigger image | ||
| + | windows where the inspectors always overlap the window. Both of these will | ||
| + | create an enhanced user '''experience''' of having more working space. | ||
| + | |||
| + | But we need to explore further, into inspectors that—as the user wishes—shrink | ||
| + | to 1/3 of their width, and still make. And can automatically expand to | ||
| + | full-functioning width when the mouse hovers over them. | ||
| + | |||
| + | As a second strategy semi-transparency can be explored. | ||
Latest revision as of 18:36, 14 April 2007
Contents
better behaving windows
A definite improvement in the UI must be made by making the toolbox/dialog windows (from now on named inspectors) behave like true floating windows, and not as real content windows. For this the following steps are necessary:
- Solve that when GIMP is run with no image, that still an image window is shown. this will ensure that for linux and windows platforms there is always a place for the menu bar (singular) to be shown. There is an idea from the GIMP team to show a tip of the day in the otherwise empty window. We consider it an excellent idea to show something that helps in the ease of learning department in an less obstructive (not in a dialog) way.
- Merge the menu bar of the toolbox window into the menu bar of the image window.
- Give all the inspector windows their proper status, being not a normal window but a floating palette. The important goal here is not to make the inspectors always float on top of image windows, or to make them less chunky—those are just valuable side-effects. It is to keep them out of any window management overviews for users, e.g. the task bar on linux and windows. For the user the only thing that counts (and exists) is working on images, which takes place in image windows. All the inspectors and dialogs do not exist and should not show up when talking about ‘what windows are open?’
When these changes are made, we confident that actually quite a few traits of current GIMP UI are removed that drive the constant user requests for a single window interface, or WiW.
the single window interface, or WiW
The changes above also will put us on a sound basis to discuss a single window interface.
Interaction architecture, like classical architecture, has trends in the solutions it prefers for a certain problem. And sure enough, the two important, high-end image applications that have entered the market lately—Apple’s aperture and Adobe’s lightroom—sport single window interfaces.
From our point of view there are no negative sides to proving also a single window interface, except for doubling complication and effort in documentation and support in this area.
We believe that the GIMP way of doing things can be that GIMP ships with the default set-up of two inspectors flanking the image window(s). With one single menu item (and not in the preferences dialog) the user could switch on single window mode. This results in an window where the first column (from left) is the toolbox inspector, the second is the image pane (where multiple images appear in tabs), and to the right of this the other inspector(s) in columns. The user has to be able to rearrange the the column order of these by dragging and re-docking, and to be able to tear off any and all of the inspectors to float them again.
inspectors
Currently the contents of the inspectors is too fat, and not sportif enough. The cost of this is screen real estate and an actually permanent part of the interface that is taking too much attention from the image content.
It is caused by implementing the inspector content with dialog look + feel. One can see from the transient and attention grabbing nature of dialogs versus the permanent and visually integrated nature of inspectors that a different look + feel is necessary.
We cannot expect the UI guidelines for gNome, KDE or windows to define proper inspector look + feel when it is Apple who is driving the development in this field and the only platform to fully understand the benefits of inspectors. Therefore some rule-bending and wheel-reinventing will be necessary by the interaction architect on this project. Because of GIMP’s calibre, it will have to push the envelope in this regard.
But it needs to be done to achieve a leaner and more efficient GIMP UI.
growing cramps
The expert evaluation showed that there is no such thing as too big an image window. Photographic images are automatically larger that a monitor (or two); as is original art, when produced for print; production of a set of web elements happens together on a canvas; even icon editing gets cramped quickly when working enlarged on the hi-res version.
GIMP has to support a minimal monitor spec, and the only thing that needs to be decided is whether it is a 1024 or 1280 screen laptop. If the user buys a bigger monitor (or even two, not that common though we observed, among pros) then it is the user who has to profit from this investment, with a larger image window (== working) area, and not GIMP that feels that it can stretch out its UI a bit in this not so cramped surroundings.
In short, we have to design for a minimal spec, and anything more that users got in terms of real estate, is their gain.
At the moment the two default inspectors eat about 440 pixels of the width of the screen. Changes mentioned above will already help us in this regard: slimming down inspectors will fight their bulk, and making the inspectors true floating windows will make it realistic for users work with bigger image windows where the inspectors always overlap the window. Both of these will create an enhanced user experience of having more working space.
But we need to explore further, into inspectors that—as the user wishes—shrink to 1/3 of their width, and still make. And can automatically expand to full-functioning width when the mouse hovers over them.
As a second strategy semi-transparency can be explored.
