https://gui.gimp.org/api.php?action=feedcontributions&user=Jehan&feedformat=atomGIMP GUI Redesign - User contributions [en]2024-03-28T22:34:55ZUser contributionsMediaWiki 1.28.0https://gui.gimp.org/index.php?title=Image_unit_workgroup&diff=2593Image unit workgroup2020-11-12T14:54:59Z<p>Jehan: Created page with "Category:Workgroups == Summary == The image unit is currently very random in GIMP. Here are basically the 4 concepts of image units right now: * image unit: defaults to..."</p>
<hr />
<div>[[Category:Workgroups]]<br />
<br />
== Summary ==<br />
<br />
The image unit is currently very random in GIMP. Here are basically the 4 concepts of image units right now:<br />
<br />
* image unit: defaults to "Pixels", saved in the XCF as PROP_UNIT.<br />
* print unit: can only be a physical unit (i.e. not pixels).<br />
* resolution unit: only many dots/pixels per physical unit.<br />
* display unit: shown in rulers for instance.<br />
<br />
Note: though "percentage" is sometimes shown in unit list on some dialogs (Scale, Canvas Size, etc.), it is not a proper unit and cannot be set for any of the units above.<br />
<br />
== Use Cases ==<br />
<br />
* You work for the screen (web, movie, etc.). You usually only care about pixel size.<br />
* You work for a physical medium (print or other), and you usually want to see your size in the unit adapted to your country/work/de-facto standard for the type of medium. Typically in the US, for paper print, I think they talk in inches, but in the EU, we use international metrics (mm, cm usually).<br />
<br />
== Current UI Analysis ==<br />
<br />
Currently:<br />
<br />
* The image unit is only changed when changing the resolution unit (which is a bug IMO).<br />
* The print unit concepts mixes with image unit. Basically when image unit is not pixel, then we have a print unit. We cannot reset the print unit right now (if we want to use "pixel") AFAIK.<br />
* The resolution unit is not stored and always considered as DPI. But somehow when we changed the print unit, it uses it for resolution unit (which is silly IMO).<br />
* Display unit is independent from image unit (though it defaults to the image unit). Changing it (usually the combo in status bar) does not change the image unit.<br />
<br />
== Random thoughts ==<br />
<br />
A lot of things are very unclear about how this all works:<br />
<br />
* How to set the image unit? Currently the unit is set in current cases:<br />
- New image: it uses the **resolution unit** as image unit, which seems silly to me (resolution is usually using DPI, hence inches, even when we want to see your image in cm/mm for instance).<br />
- New image from existing drawable(s): it uses the unit from previous image which seems fair.<br />
- New image from buffer: it uses the unit from the buffer.<br />
- Print size: uses the resolution unit if and only if physical size/resolution changed.<br />
- Scale size: uses the resolution unit if and only if pixel dimensions changed.<br />
* Print unit is basically the image unit if not pixel.<br />
<br />
The problems:<br />
<br />
* Why are we using the resolution units as image unit in various places? This doesn't match with the fact that from our experience, we more often use DPI while still using other physical units for dimension. Basically image unit is a mix of print unit + resolution unit.<br />
* It is never clear at all which action actually changes the image unit.<br />
* With current code, it doesn't look we ever can switch back to "pixel" as image unit (basically not a print job, we don't care about physical dimensions) once we moved away from it.<br />
* When changing the display unit, we don't actually change the image unit. Which is maybe fine (you might want to look temporarily at your image with another unit system) but also sometimes confusing.<br />
<br />
Questions:<br />
<br />
* How often are non-DPI resolution units used? I.e. for which use case do we want dots per mm for instance? Here in France for instance, even when all dimensions are in mm (or cm), we still use the DPI units for dot density.<br />
* As a result of answers from previous question, would we want to store both a dimension unit **and** a resolution unit in the XCF?<br />
<br />
Maybe we should have both a dimension unit and resolution unit concepts. Also we should make it clearer when you setting them or not.<br />
<br />
Finally I wonder if we should add the concept of image target. Basically when a work does not target print (or similar physical medium), disabling resolution would be helpful, at least to have people understand this concept is useless when you target the screen.<br />
<br />
[[User:Jehan|Jehan]] ([[User talk:Jehan|talk]]) 14:54, 12 November 2020 (UTC)</div>Jehanhttps://gui.gimp.org/index.php?title=Brush_creation_workgroup&diff=2582Brush creation workgroup2019-02-27T14:06:01Z<p>Jehan: /* Original Design */</p>
<hr />
<div>[[Category:Workgroups]]<br />
<br />
== Summary ==<br />
<br />
Currently creating evolved brushes (GIH in particular) is a brain-killer. In particular:<br />
<br />
* the concept of "cells" is a complete mess to organize your work (basically draw several variants of a brush in the same layer instead of one per layer).<br />
* The dimension system is completely non-understandable in its current GUI.<br />
<br />
https://docs.gimp.org/2.10/en/gimp-using-animated-brushes.html<br />
<br />
== Original Design ==<br />
<br />
The assumptions are:<br />
<br />
* the multi-cell system may make sense if you want to see your brush variants side by side, same as when you create an icon set, you like to create them in a single file (to be later exported in separate images).<br />
<br />
* The dimension system is extremely interesting once you get to know it:<br />
* It allows for instance to create random variants of a same brush or simply incremental variants (always same order). These are the most common usages that you can see in GIH brushes around.<br />
* You can also create random variants depending on the moving angle, or depending on your tilt, pressure and speed.<br />
* Now you can also mix this, and that's when your brain starts to melt. Like random variants depending on moving angle (so for each angle range, you'd have a random list of possible imprint). Or you could even have variant for every (angle, tilt, pressure) combination, with some randomness or incremental designs in there. And so on. This is where the dimension system comes to play.<br />
<br />
This is somewhat double usage with dynamics, yet still different. For instance dynamics allows you to modify things such as angle, aspect ratio, opacity, etc. In simple cases, this is enough (if not better). But the brush dimension system allows to have completely different drawings depending on various input. This is something dynamics doesn't provide.<br />
<br />
== Raised Issues ==<br />
<br />
The following issues have been raised:<br />
<br />
* The format is extremely powerful but the current creation GUI is just too complex; as a consequence probably nearly none use the format at its full potential.<br />
<br />
The currently GUI was properly just trying to reproduce the implementation graphically, which is the problem. We should not have to change the brush formats. For instance, the "dimension" logics makes perfect sense code-wise, simply you should not have to expose it.<br />
<br />
== Ideas ==<br />
<br />
* The various dimension criteria could be displayed in proper ways, specific to each criteria:<br />
* "Angular" could show as a full circle where variants depending on angle ranges would show around the circle.<br />
* "Speed" and "Pressure" could show linearly (left: low speed/pressure, right: high speed/pressure).<br />
* tilt could show as a half circle.<br />
* Incremental and random would show linearly.<br />
The goal would be to display and navigate brush variants on some GUI with above widgets to get a very quick and understandable overview of the brush.<br />
* It would be nice to be able to test the brush as you create it (rather than export, reload, test, export, reload, test…).<br />
* It would be nice to export directly the brush in the user brush folder. Of course exporting anywhere should still be a feature (for exchanging brushes), but the default "one click-no brainer" export should be for direct usage.<br />
* Rather than asking people to organize their layers in cels, maybe GIMP could be able to display brushes all side by side, or switch to editing one variant only, etc. Various viewing modes.<br />
<br />
Basically I also think that GIH brush creation could become a core feature. Many of the above ideas would not work well as plug-in implementation (at least not with current API).</div>Jehanhttps://gui.gimp.org/index.php?title=Brush_creation_workgroup&diff=2581Brush creation workgroup2019-02-27T14:05:17Z<p>Jehan: Created page with "Category:Workgroups == Summary == Currently creating evolved brushes (GIH in particular) is a brain-killer. In particular: * the concept of "cells" is a complete mess t..."</p>
<hr />
<div>[[Category:Workgroups]]<br />
<br />
== Summary ==<br />
<br />
Currently creating evolved brushes (GIH in particular) is a brain-killer. In particular:<br />
<br />
* the concept of "cells" is a complete mess to organize your work (basically draw several variants of a brush in the same layer instead of one per layer).<br />
* The dimension system is completely non-understandable in its current GUI.<br />
<br />
https://docs.gimp.org/2.10/en/gimp-using-animated-brushes.html<br />
<br />
== Original Design ==<br />
<br />
The assumptions are:<br />
<br />
* the multi-cell system may make sense if you want to see your brush variants side by side, same as when you create an icon set, you like to create them in a single file (to be later exported in separate images).<br />
<br />
* The dimension system is extremely interesting once you get to know it:<br />
<br />
1. It allows for instance to create random variants of a same brush or simply incremental variants (always same order). These are the most common usages that you can see in GIH brushes around.<br />
2. You can also create random variants depending on the moving angle, or depending on your tilt, pressure and speed.<br />
3. Now you can also mix this, and that's when your brain starts to melt. Like random variants depending on moving angle (so for each angle range, you'd have a random list of possible imprint). Or you could even have variant for every (angle, tilt, pressure) combination, with some randomness or incremental designs in there. And so on. This is where the dimension system comes to play.<br />
<br />
This is somewhat double usage with dynamics, yet still different. For instance dynamics allows you to modify things such as angle, aspect ratio, opacity, etc. In simple cases, this is enough (if not better). But the brush dimension system allows to have completely different drawings depending on various input. This is something dynamics doesn't provide.<br />
<br />
== Raised Issues ==<br />
<br />
The following issues have been raised:<br />
<br />
* The format is extremely powerful but the current creation GUI is just too complex; as a consequence probably nearly none use the format at its full potential.<br />
<br />
The currently GUI was properly just trying to reproduce the implementation graphically, which is the problem. We should not have to change the brush formats. For instance, the "dimension" logics makes perfect sense code-wise, simply you should not have to expose it.<br />
<br />
== Ideas ==<br />
<br />
* The various dimension criteria could be displayed in proper ways, specific to each criteria:<br />
* "Angular" could show as a full circle where variants depending on angle ranges would show around the circle.<br />
* "Speed" and "Pressure" could show linearly (left: low speed/pressure, right: high speed/pressure).<br />
* tilt could show as a half circle.<br />
* Incremental and random would show linearly.<br />
The goal would be to display and navigate brush variants on some GUI with above widgets to get a very quick and understandable overview of the brush.<br />
* It would be nice to be able to test the brush as you create it (rather than export, reload, test, export, reload, test…).<br />
* It would be nice to export directly the brush in the user brush folder. Of course exporting anywhere should still be a feature (for exchanging brushes), but the default "one click-no brainer" export should be for direct usage.<br />
* Rather than asking people to organize their layers in cels, maybe GIMP could be able to display brushes all side by side, or switch to editing one variant only, etc. Various viewing modes.<br />
<br />
Basically I also think that GIH brush creation could become a core feature. Many of the above ideas would not work well as plug-in implementation (at least not with current API).</div>Jehanhttps://gui.gimp.org/index.php?title=GIMP_GUI_Redesign&diff=2351GIMP GUI Redesign2017-05-16T18:51:16Z<p>Jehan: /* team */</p>
<hr />
<div>== Team ==<br />
<br />
The GIMP project's User Interface is discussed in an open manner through [http://www.gimp.org/irc.html IRC] and a [https://mail.gnome.org/mailman/listinfo/gimp-gui-list dedicated mailing list], in collaboration with users, developers and designers.<br />
<br />
The WIKI will contain the user interaction research results, and specifications coming out of our decisions.<br />
Contact the GIMP developers on IRC (the users "ankh" and "Jehan" are known to have an admin account) to get a login for the wiki.<br />
<br />
Everybody is welcome to [[Procedure_for_Specifications|discuss features and improvements with us]].<br />
<br />
''Note: there used to be [[Former_GUI_team|dedicated people]] working on the GUI. This is not how we work anymore.''<br />
<br />
== Project Vision ==<br />
<br />
NOTE: [https://gui.gimp.org/index.php?title=Talk:Project_Vision let's review the project vision]!<br />
<br />
Ultimately, every decision taken by our UI team is about realising the product vision. At the LGM 2006, peter sikking held a workshop with the GIMP team, and helped them to formulated their product vision:<br />
<br />
* GIMP is Free Software;<br />
* GIMP is a high-end photo manipulation application and supports creating original art from images;<br />
* GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;<br />
* GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;<br />
* GIMP is user-configurable to automate repetitive tasks;<br />
* GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.<br />
<br />
Want to go deeper? Read the [[Project vision | Project vision]].<br />
<br />
==functionality overview==<br />
<br />
To design something, you need to know ''everything'' it is suppose to do. At the beginning of this project a short, sharp [[media:GIMP_functionality.pdf | functionality overview]] was made, based on version 2.3.11 (extra kudos to Kamila for all that work).<br />
<br />
==[[User Scenarios | user scenarios]]==<br />
<br />
These [[User Scenarios]] are used in the GIMP redesign project. They are the result <br />
of workplace observations and a weekend workshop with the GIMP team.<br />
<br />
==[[Expert Evaluation Notes | expert evaluation notes]]==<br />
<br />
We spent a month and a half evaluating GIMP. Enjoy reading the raw [[Expert Evaluation Notes]].<br />
<br />
==[[analysis]]==<br />
<br />
Our [[analysis]] its the result all of our work on GIMP up to now, and shows the way forward for each aspect of GIMP UI, in the form of solution models.<br />
<br />
==[[usability]]==<br />
<br />
Tobi's work in progress to further improve the [[usability]] of GIMP.<br />
<br />
==[[work in progress]]==<br />
<br />
Notes, tables, sketches showing [[work in progress]] towards detailed specification.<br />
<br />
We are working on an [[Interaction design patch | interaction design patch]] format.<br />
<br />
==[[specifications]]==<br />
<br />
Solution models get further developed into UI [[specifications]], ready for implementation.<br />
<br />
[[:Category:Workgroups | > List of currently running workgroups]]<br />
<br />
==[[design guide]]==<br />
<br />
A (growing) [[design guide | guide]] for those who design interaction for GIMP, concentrating on how solutions can be fitted into the overall interaction framework, constraints and how things interconnect.</div>Jehanhttps://gui.gimp.org/index.php?title=GIMP_GUI_Redesign&diff=2350GIMP GUI Redesign2017-05-16T18:20:27Z<p>Jehan: /* Project Vision */</p>
<hr />
<div>==team==<br />
<br />
The GIMP project's User Interface is discussed in an open manner through [http://www.gimp.org/irc.html IRC] and a [https://mail.gnome.org/mailman/listinfo/gimp-gui-list dedicated mailing list], in collaboration with users, developers and designers.<br />
<br />
The WIKI will contain the user interaction research results, and specifications coming out of our decisions.<br />
Contact the GIMP developers on IRC (the users "ankh" and "Jehan" are known to have an admin account) to get a login for the wiki.<br />
<br />
Everybody is welcome to [[Procedure_for_Specifications|discuss features and improvements with us]].<br />
<br />
''Note: there used to be [[Former_GUI_team|dedicated people]] working on the GUI. This is not how we work anymore.''<br />
<br />
== Project Vision ==<br />
<br />
NOTE: [https://gui.gimp.org/index.php?title=Talk:Project_Vision let's review the project vision]!<br />
<br />
Ultimately, every decision taken by our UI team is about realising the product vision. At the LGM 2006, peter sikking held a workshop with the GIMP team, and helped them to formulated their product vision:<br />
<br />
* GIMP is Free Software;<br />
* GIMP is a high-end photo manipulation application and supports creating original art from images;<br />
* GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;<br />
* GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;<br />
* GIMP is user-configurable to automate repetitive tasks;<br />
* GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.<br />
<br />
Want to go deeper? Read the [[Project vision | Project vision]].<br />
<br />
==functionality overview==<br />
<br />
To design something, you need to know ''everything'' it is suppose to do. At the beginning of this project a short, sharp [[media:GIMP_functionality.pdf | functionality overview]] was made, based on version 2.3.11 (extra kudos to Kamila for all that work).<br />
<br />
==[[User Scenarios | user scenarios]]==<br />
<br />
These [[User Scenarios]] are used in the GIMP redesign project. They are the result <br />
of workplace observations and a weekend workshop with the GIMP team.<br />
<br />
==[[Expert Evaluation Notes | expert evaluation notes]]==<br />
<br />
We spent a month and a half evaluating GIMP. Enjoy reading the raw [[Expert Evaluation Notes]].<br />
<br />
==[[analysis]]==<br />
<br />
Our [[analysis]] its the result all of our work on GIMP up to now, and shows the way forward for each aspect of GIMP UI, in the form of solution models.<br />
<br />
==[[usability]]==<br />
<br />
Tobi's work in progress to further improve the [[usability]] of GIMP.<br />
<br />
==[[work in progress]]==<br />
<br />
Notes, tables, sketches showing [[work in progress]] towards detailed specification.<br />
<br />
We are working on an [[Interaction design patch | interaction design patch]] format.<br />
<br />
==[[specifications]]==<br />
<br />
Solution models get further developed into UI [[specifications]], ready for implementation.<br />
<br />
[[:Category:Workgroups | > List of currently running workgroups]]<br />
<br />
==[[design guide]]==<br />
<br />
A (growing) [[design guide | guide]] for those who design interaction for GIMP, concentrating on how solutions can be fitted into the overall interaction framework, constraints and how things interconnect.</div>Jehanhttps://gui.gimp.org/index.php?title=GIMP_GUI_Redesign&diff=2349GIMP GUI Redesign2017-05-16T18:18:49Z<p>Jehan: /* product vision */</p>
<hr />
<div>==team==<br />
<br />
The GIMP project's User Interface is discussed in an open manner through [http://www.gimp.org/irc.html IRC] and a [https://mail.gnome.org/mailman/listinfo/gimp-gui-list dedicated mailing list], in collaboration with users, developers and designers.<br />
<br />
The WIKI will contain the user interaction research results, and specifications coming out of our decisions.<br />
Contact the GIMP developers on IRC (the users "ankh" and "Jehan" are known to have an admin account) to get a login for the wiki.<br />
<br />
Everybody is welcome to [[Procedure_for_Specifications|discuss features and improvements with us]].<br />
<br />
''Note: there used to be [[Former_GUI_team|dedicated people]] working on the GUI. This is not how we work anymore.''<br />
<br />
== Project Vision ==<br />
<br />
NOTE: [[https://gui.gimp.org/index.php?title=Talk:Project_Vision|let's review the project vision]]!<br />
<br />
Ultimately, every decision taken by our UI team is about realising the product vision. At the LGM 2006, peter sikking held a workshop with the GIMP team, and helped them to formulated their product vision:<br />
<br />
* GIMP is Free Software;<br />
* GIMP is a high-end photo manipulation application and supports creating original art from images;<br />
* GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;<br />
* GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;<br />
* GIMP is user-configurable to automate repetitive tasks;<br />
* GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.<br />
<br />
Want to go deeper? Read the [[Project vision | Project vision]].<br />
<br />
==functionality overview==<br />
<br />
To design something, you need to know ''everything'' it is suppose to do. At the beginning of this project a short, sharp [[media:GIMP_functionality.pdf | functionality overview]] was made, based on version 2.3.11 (extra kudos to Kamila for all that work).<br />
<br />
==[[User Scenarios | user scenarios]]==<br />
<br />
These [[User Scenarios]] are used in the GIMP redesign project. They are the result <br />
of workplace observations and a weekend workshop with the GIMP team.<br />
<br />
==[[Expert Evaluation Notes | expert evaluation notes]]==<br />
<br />
We spent a month and a half evaluating GIMP. Enjoy reading the raw [[Expert Evaluation Notes]].<br />
<br />
==[[analysis]]==<br />
<br />
Our [[analysis]] its the result all of our work on GIMP up to now, and shows the way forward for each aspect of GIMP UI, in the form of solution models.<br />
<br />
==[[usability]]==<br />
<br />
Tobi's work in progress to further improve the [[usability]] of GIMP.<br />
<br />
==[[work in progress]]==<br />
<br />
Notes, tables, sketches showing [[work in progress]] towards detailed specification.<br />
<br />
We are working on an [[Interaction design patch | interaction design patch]] format.<br />
<br />
==[[specifications]]==<br />
<br />
Solution models get further developed into UI [[specifications]], ready for implementation.<br />
<br />
[[:Category:Workgroups | > List of currently running workgroups]]<br />
<br />
==[[design guide]]==<br />
<br />
A (growing) [[design guide | guide]] for those who design interaction for GIMP, concentrating on how solutions can be fitted into the overall interaction framework, constraints and how things interconnect.</div>Jehanhttps://gui.gimp.org/index.php?title=Talk:Project_Vision&diff=2348Talk:Project Vision2017-05-16T18:17:02Z<p>Jehan: </p>
<hr />
<div>Let's rework the project vision!<br />
IMO the project vision should be a one-liner. A list of features will always be non-exhaustive. For instance the current project vision more or less excludes painting (it can include it by stretching, but one can see that is playing blind) even though painting is clearly an important usage to many people. A lot of companies have one-liner project vision, and that is just fine.<br />
<br />
A remark on IRC I got is that it makes the vision useless. Maybe. If that's true, then the vision is useless. Let's just not have one! :P<br />
<br />
Also another remark is that we should stop call it "Product Vision". GIMP is not a product. We are not a company and we don't want to fall in such areas. GIMP is a software and a software.<br />
<br />
My proposed project vision: "GIMP is a high quality generic image editor."<br />
<br />
[[User:Jehan|Jehan]] ([[User talk:Jehan|talk]]) 18:16, 16 May 2017 (UTC)</div>Jehanhttps://gui.gimp.org/index.php?title=Talk:Project_Vision&diff=2347Talk:Project Vision2017-05-16T18:16:43Z<p>Jehan: Created page with "Let's rework the project vision! IMO the project vision should be a one-liner. A list of features will always be non-exhaustive. For instance the current project vision more o..."</p>
<hr />
<div>Let's rework the project vision!<br />
IMO the project vision should be a one-liner. A list of features will always be non-exhaustive. For instance the current project vision more or less excludes painting (it can include it by stretching, but one can see that is playing blind) even though painting is clearly an important usage to many people. A lot of companies have one-liner project vision, and that is just fine.<br />
<br />
A remark on IRC I got is that it makes the vision useless. Maybe. If that's true, then the vision is useless. Let's just not have one! :P<br />
<br />
Also another remark is that we should stop call it "Product Vision". GIMP is not a product. We are not a company and we don't want to fall in such areas. GIMP is a software and a software.<br />
<br />
My proposed project vision: "GIMP is a high quality generic image editor."<br />
<br />
:-)<br />
<br />
[[User:Jehan|Jehan]] ([[User talk:Jehan|talk]]) 18:16, 16 May 2017 (UTC)</div>Jehanhttps://gui.gimp.org/index.php?title=Vision_briefing&diff=2346Vision briefing2017-05-16T18:04:44Z<p>Jehan: Jehan moved page Vision briefing to Project Vision: Let's get some new vision!</p>
<hr />
<div>#REDIRECT [[Project Vision]]</div>Jehanhttps://gui.gimp.org/index.php?title=Project_Vision&diff=2345Project Vision2017-05-16T18:04:44Z<p>Jehan: Jehan moved page Vision briefing to Project Vision: Let's get some new vision!</p>
<hr />
<div>For reference let’s repeat the vision from the [[GIMP_UI_Redesign | front page]]:<br />
* GIMP is Free Software;<br />
* GIMP is a high-end photo manipulation application and supports creating original art from images;<br />
* GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;<br />
* GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;<br />
* GIMP is user-configurable to automate repetitive tasks;<br />
* GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.<br />
<br />
On purpose, a vison is a combination of concrete and more fuzzy definitions. This gives direction but also leaves space for further expanding on this direction.<br />
<br />
== GIMP and its core users ==<br />
<br />
The description of what GIMP is, and which core user groups it is made for, is encapsulated by the statements of which activities it supports:<br />
# '''high-end photo manipulation'''; note the word ‘high-end,’ this is in results that can be achieved with GIMP and workflow it supports; high-end is not mid-or low-end: touching up some holiday photos a couple times a year is not what GIMP is made for;<br />
# '''creating original art''' from images; this art ranges from freaking, underground cutting-edge to slick & commercial; the creativity flows from users into the work that is being done; note the ‘from images’ part, GIMP is an Image Manipulation Program; painting is just an extremely versatile means of image manipulation, not an end goal;<br />
# '''production'''—icons, graphical elements of web pages and art for user interface elements; again high-end, top quality results and workflows to get the (massive) job done; note: designing web pages through mockups is not part of the vision of GIMP;<br />
# '''programming algorithms''', by scientists and artists; bit of an odd one out compared to the other activities; note the ‘scientists and artists,’ it is not just software engineers who should be able to have access to this.<br />
<br />
=== value + traits ===<br />
<br />
The value that GIMP delivers to users can be derived as follows:<br />
; control<br />
: work with very high precision to the result needed; follows from the ‘high-end’ statements and the photo manipulation, being able to perform unlimited manipulations without leaving a trace.<br />
; the freedom to create<br />
: imagine users ''almost'' in trance while they are creating, they know what they are doing, but also react to what they see on the canvas in a very tight feedback loop; the tools in GIMP follow these users to wherever they want to go, even if this is way outside the intended use of a tool or algorithm;<br />
; speed, speed, speed<br />
: important for all activities, but especially for production; the tools get out of the way of getting things done and allow for accelerating the workflow for those who get to know them, up to a speed of two actions per second.<br />
<br />
== professionals? ==<br />
<br />
Saying a piece of software is ‘for professionals’ is meaningless. There are people earning a living operating graphics packages who are terrible hacks; there are very accomplished and respected artists/creators/editors who are pure amateurs, doing it for the love of it.<br />
<br />
It is more useful to define that '''GIMP is for intense use''':<br />
* intense in the number of hours users put in to really master the tools; this is exactly the same as the centuries old process of how people, through apprenticeship, master a certain craft, e.g. furniture making; it is also the same process as learning to play a musical instrument: humble beginnings, but with enough hours of practice one can enjoy becoming very accomplished and play for fun, or profit;<br />
* intense in the speed with which one can work;<br />
* intense in how creativity can flow.<br />
<br />
== copying + motivation ==<br />
<br />
Let’s get this over with: GIMP is not a for-free photoshop copy.<br />
<br />
It does not make sense to work on a project that is a blind copy of someone else’s software—even if you were paid for it. Why copy someone else’s legacy issues and design snafus? To know where the issues and snafus are one has to research, analyse, architect and design—aka. the fun part—on several levels (engineering, interaction, etc.). Once one has done that, one is making ones own software.<br />
<br />
To get there GIMP has a product vision. The vision of photoshop is unknown—does it have one? When vision are not equal, the resulting software will never be the same.</div>Jehanhttps://gui.gimp.org/index.php?title=GIMP_GUI_Redesign&diff=2344GIMP GUI Redesign2017-05-16T14:47:26Z<p>Jehan: /* team */</p>
<hr />
<div>==team==<br />
<br />
The GIMP project's User Interface is discussed in an open manner through [http://www.gimp.org/irc.html IRC] and a [https://mail.gnome.org/mailman/listinfo/gimp-gui-list dedicated mailing list], in collaboration with users, developers and designers.<br />
<br />
The WIKI will contain the user interaction research results, and specifications coming out of our decisions.<br />
Contact the GIMP developers on IRC (the users "ankh" and "Jehan" are known to have an admin account) to get a login for the wiki.<br />
<br />
Everybody is welcome to [[Procedure_for_Specifications|discuss features and improvements with us]].<br />
<br />
''Note: there used to be [[Former_GUI_team|dedicated people]] working on the GUI. This is not how we work anymore.''<br />
<br />
==product vision==<br />
<br />
Ultimately, every decision taken by our UI team is about realising the product vision. At the LGM 2006, peter sikking held a workshop with the GIMP team, and helped them to formulated their product vision:<br />
<br />
* GIMP is Free Software;<br />
* GIMP is a high-end photo manipulation application and supports creating original art from images;<br />
* GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;<br />
* GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;<br />
* GIMP is user-configurable to automate repetitive tasks;<br />
* GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.<br />
<br />
Want to go deeper? Read the [[Vision briefing | vision briefing]].<br />
<br />
==functionality overview==<br />
<br />
To design something, you need to know ''everything'' it is suppose to do. At the beginning of this project a short, sharp [[media:GIMP_functionality.pdf | functionality overview]] was made, based on version 2.3.11 (extra kudos to Kamila for all that work).<br />
<br />
==[[User Scenarios | user scenarios]]==<br />
<br />
These [[User Scenarios]] are used in the GIMP redesign project. They are the result <br />
of workplace observations and a weekend workshop with the GIMP team.<br />
<br />
==[[Expert Evaluation Notes | expert evaluation notes]]==<br />
<br />
We spent a month and a half evaluating GIMP. Enjoy reading the raw [[Expert Evaluation Notes]].<br />
<br />
==[[analysis]]==<br />
<br />
Our [[analysis]] its the result all of our work on GIMP up to now, and shows the way forward for each aspect of GIMP UI, in the form of solution models.<br />
<br />
==[[usability]]==<br />
<br />
Tobi's work in progress to further improve the [[usability]] of GIMP.<br />
<br />
==[[work in progress]]==<br />
<br />
Notes, tables, sketches showing [[work in progress]] towards detailed specification.<br />
<br />
We are working on an [[Interaction design patch | interaction design patch]] format.<br />
<br />
==[[specifications]]==<br />
<br />
Solution models get further developed into UI [[specifications]], ready for implementation.<br />
<br />
[[:Category:Workgroups | > List of currently running workgroups]]<br />
<br />
==[[design guide]]==<br />
<br />
A (growing) [[design guide | guide]] for those who design interaction for GIMP, concentrating on how solutions can be fitted into the overall interaction framework, constraints and how things interconnect.</div>Jehanhttps://gui.gimp.org/index.php?title=Former_GUI_team&diff=2343Former GUI team2017-05-16T14:44:54Z<p>Jehan: New page to clean out the "honour list" from the main page.</p>
<hr />
<div>GIMP used to have an on-and-off dedicated team of GUI experts, led by Peter Sikking, before 2012.<br />
This is not the case anymore. User interaction is now discussed openly on mailing lists and IRC with various professional user interaction experts, developers and creators using GIMP.<br />
<br />
The list below is the former list of people from the dedicated team and are not current contacts for discussing user experience in GIMP.<br />
<br />
===honour list===<br />
<br />
We thank these previous team members for their valuable contributions:<br />
<br />
* peter sikking, principal interaction architect, m+mi works—[http://blog.mmiworks.net blog], [http://blog.mmiworks.net/search/label/GIMP on GIMP]<br />
* Kamila Giedrojć, associate interaction architect —[http://kamilagiedrojc.com/info/index.html portfolio]<br />
* Ellen Reitmayr, usability consultant —[http://ellen.reitmayr.net/ website]<br />
* Kate Price, interaction architect<br />
* Tobias Ehni, usability consultant<br />
* Dominique Schmidt, associate interaction architect<br />
* Marinus Schraal, associate interaction architect</div>Jehanhttps://gui.gimp.org/index.php?title=GIMP_GUI_Redesign&diff=2314GIMP GUI Redesign2017-05-08T13:19:15Z<p>Jehan: Adding myself as contact for the wiki.</p>
<hr />
<div>==team==<br />
<br />
The GIMP project's User Interface is discussed in an open manner through [http://www.gimp.org/irc.html IRC] and a [https://mail.gnome.org/mailman/listinfo/gimp-gui-list dedicated mailing list], in collaboration with users, developers and designers.<br />
<br />
The WIKI will contain the user interaction research results, and specifications coming out of our decisions.<br />
Contact the GIMP developers on IRC (the users "ankh" and "Jehan" are known to have an admin account) to get a login for the wiki.<br />
<br />
Everybody is welcome to [[Procedure_for_Specifications|discuss features and improvements with us]].<br />
<br />
===honour list===<br />
<br />
We thank these previous team members for their valuable contributions:<br />
<br />
* peter sikking, principal interaction architect, m+mi works—[http://blog.mmiworks.net blog], [http://blog.mmiworks.net/search/label/GIMP on GIMP]<br />
* Kamila Giedrojć, associate interaction architect —[http://kamilagiedrojc.com/info/index.html portfolio]<br />
* Ellen Reitmayr, usability consultant —[http://ellen.reitmayr.net/ website]<br />
* Kate Price, interaction architect<br />
* Tobias Ehni, usability consultant<br />
* Dominique Schmidt, associate interaction architect<br />
* Marinus Schraal, associate interaction architect<br />
<br />
==product vision==<br />
<br />
Ultimately, every decision taken by our UI team is about realising the product vision. At the LGM 2006, peter sikking held a workshop with the GIMP team, and helped them to formulated their product vision:<br />
<br />
* GIMP is Free Software;<br />
* GIMP is a high-end photo manipulation application and supports creating original art from images;<br />
* GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;<br />
* GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;<br />
* GIMP is user-configurable to automate repetitive tasks;<br />
* GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.<br />
<br />
Want to go deeper? Read the [[Vision briefing | vision briefing]].<br />
<br />
==functionality overview==<br />
<br />
To design something, you need to know ''everything'' it is suppose to do. At the beginning of this project a short, sharp [[media:GIMP_functionality.pdf | functionality overview]] was made, based on version 2.3.11 (extra kudos to Kamila for all that work).<br />
<br />
==[[User Scenarios | user scenarios]]==<br />
<br />
These [[User Scenarios]] are used in the GIMP redesign project. They are the result <br />
of workplace observations and a weekend workshop with the GIMP team.<br />
<br />
==[[Expert Evaluation Notes | expert evaluation notes]]==<br />
<br />
We spent a month and a half evaluating GIMP. Enjoy reading the raw [[Expert Evaluation Notes]].<br />
<br />
==[[analysis]]==<br />
<br />
Our [[analysis]] its the result all of our work on GIMP up to now, and shows the way forward for each aspect of GIMP UI, in the form of solution models.<br />
<br />
==[[usability]]==<br />
<br />
Tobi's work in progress to further improve the [[usability]] of GIMP.<br />
<br />
==[[work in progress]]==<br />
<br />
Notes, tables, sketches showing [[work in progress]] towards detailed specification.<br />
<br />
We are working on an [[Interaction design patch | interaction design patch]] format.<br />
<br />
==[[specifications]]==<br />
<br />
Solution models get further developed into UI [[specifications]], ready for implementation.<br />
<br />
[[:Category:Workgroups | > List of currently running workgroups]]<br />
<br />
==[[design guide]]==<br />
<br />
A (growing) [[design guide | guide]] for those who design interaction for GIMP, concentrating on how solutions can be fitted into the overall interaction framework, constraints and how things interconnect.</div>Jehan