Difference between pages "Windows, toolbox, inspectors analysed" and "Lgm"

From GIMP GUI Redesign
(Difference between pages)
Jump to: navigation, search
(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...)
 
(New page: top-10 lists: Here are 11 I have seen requested multiple times, and this is not exhaustive. Bill: # Single-window interface. (This is by far the most often-requested feature.) # More c...)
 
Line 1: Line 1:
==better behaving windows==
+
top-10 lists:
  
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:
+
Here are 11 I have seen requested multiple times, and this is not
 +
exhaustive.
  
# 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.
+
Bill:
# 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
+
# Single-window interface.  (This is by far the most often-requested feature.)
current GIMP UI are removed that drive the constant user requests for a single
+
# More control over window/dialog organization.
window interface, or WiW.
+
# Color management.
 +
# Better painting tools.
 +
# Better support for metadata.
 +
# Different menu organization.
 +
# Layer effects.
 +
# Save for web.
 +
# Ability to organize/categorize resources such as brushes, gradients, palettes etc.
 +
# Better printing support.
 +
# Better tablet support.
  
==the single window interface, or WiW==
+
Raphaël:
  
The changes above also will put us on a sound basis to discuss a single window interface.
+
# (by far) Single window interface, a.k.a. MDI. Note that there are two cases (Window-in-window MDI and Tabbed MDI that are probably mutually exclusive. Each option has its advantages and drawbacks, and each has its supporters who usually reject the other proposal: a) http://bugzilla.gnome.org/show_bug.cgi?id=7379 b) http://bugzilla.gnome.org/show_bug.cgi?id=121087
 
+
# Adjustment layers http://bugzilla.gnome.org/show_bug.cgi?id=79025
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.
+
# Layer trees or layer groups http://bugzilla.gnome.org/show_bug.cgi?id=86337
 
+
# Avoid popup dialogs for tools, file plug-ins, etc. http://bugzilla.gnome.org/show_bug.cgi?id=85579 http://bugzilla.gnome.org/show_bug.cgi?id=319963
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.
+
# Organize brushes, palettes, gradients... in categories http://bugzilla.gnome.org/show_bug.cgi?id=119874 ...and make it possible to delete or hide the default ones http://bugzilla.gnome.org/show_bug.cgi?id=118742
 
+
# Save for web http://bugzilla.gnome.org/show_bug.cgi?id=98017
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.
+
# Better printing support (colors, one image on multiple pages, multiple images per page, ...)
 
+
# Improvements to the text tool
==inspectors==
+
## Support for multiple styles (font, size, color, ...) http://bugzilla.gnome.org/show_bug.cgi?id=122706
 
+
## Applying transformations on text http://bugzilla.gnome.org/show_bug.cgi?id=125144
Currently the contents of the inspectors is too fat, and not sportif enough.
+
## Text along path http://bugzilla.gnome.org/show_bug.cgi?id=169616
The cost of this is screen real estate and an actually permanent part of the
+
## Adjustable letter spacing http://bugzilla.gnome.org/show_bug.cgi?id=331952
interface that is taking too much attention from the image content.
+
# Painting with "natural brushes" / simulate natural media http://bugzilla.gnome.org/show_bug.cgi?id=65118
 
 
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.
 

Revision as of 09:48, 21 April 2007

top-10 lists:

Here are 11 I have seen requested multiple times, and this is not exhaustive.

Bill:

  1. Single-window interface. (This is by far the most often-requested feature.)
  2. More control over window/dialog organization.
  3. Color management.
  4. Better painting tools.
  5. Better support for metadata.
  6. Different menu organization.
  7. Layer effects.
  8. Save for web.
  9. Ability to organize/categorize resources such as brushes, gradients, palettes etc.
  10. Better printing support.
  11. Better tablet support.

Raphaël:

  1. (by far) Single window interface, a.k.a. MDI. Note that there are two cases (Window-in-window MDI and Tabbed MDI that are probably mutually exclusive. Each option has its advantages and drawbacks, and each has its supporters who usually reject the other proposal: a) http://bugzilla.gnome.org/show_bug.cgi?id=7379 b) http://bugzilla.gnome.org/show_bug.cgi?id=121087
  2. Adjustment layers http://bugzilla.gnome.org/show_bug.cgi?id=79025
  3. Layer trees or layer groups http://bugzilla.gnome.org/show_bug.cgi?id=86337
  4. Avoid popup dialogs for tools, file plug-ins, etc. http://bugzilla.gnome.org/show_bug.cgi?id=85579 http://bugzilla.gnome.org/show_bug.cgi?id=319963
  5. Organize brushes, palettes, gradients... in categories http://bugzilla.gnome.org/show_bug.cgi?id=119874 ...and make it possible to delete or hide the default ones http://bugzilla.gnome.org/show_bug.cgi?id=118742
  6. Save for web http://bugzilla.gnome.org/show_bug.cgi?id=98017
  7. Better printing support (colors, one image on multiple pages, multiple images per page, ...)
  8. Improvements to the text tool
    1. Support for multiple styles (font, size, color, ...) http://bugzilla.gnome.org/show_bug.cgi?id=122706
    2. Applying transformations on text http://bugzilla.gnome.org/show_bug.cgi?id=125144
    3. Text along path http://bugzilla.gnome.org/show_bug.cgi?id=169616
    4. Adjustable letter spacing http://bugzilla.gnome.org/show_bug.cgi?id=331952
  9. Painting with "natural brushes" / simulate natural media http://bugzilla.gnome.org/show_bug.cgi?id=65118