InfoPalette - Revision history

Conversion script: link fix

2006-01-22T02:33:12Z

link fix

← Older revision		Revision as of 02:33, 22 January 2006
Line 21:		Line 21:
	world of good.		world of good.

	A commentor on GnomeDesktop writes: "But, you've got to clean up the		A commentor on [[GnomeDesktop]] writes: "But, you've got to clean up the
	menus/interface - when the drawing starts it's really a mess and first		menus/interface - when the drawing starts it's really a mess and first
	impressions to users mean a lot. It really should open up a frame with		impressions to users mean a lot. It really should open up a frame with

195.177.212.225: remove spam

2004-10-18T10:36:49Z

remove spam

New page

This memo will serve to be the genus for what I would eventually like
to propose. I'm hoping for plenty of feedback from everyone to make
this tool as useful as possible. The core concept is quite simple
really, enumerate and visually explain all editable parameters of a
given shape on the canvas in a single floating palette.

1. Problem
Although much work is being done to promote existing dialogs to the
status of sane players on the workspace front, there are still pitfalls
in having all manner of oversized and disproportionate dialogs open on
the screen. Namely is simple visual clutter. Having several windows
open at once can cause both new users to become lost quickly, and more
seasoned users wasting time fidgeting with dialogs to position them
according to their wishes.

:I agree that the number of dialogs should be reduced. One idea we were discussing long ago was merging "transformations" and "size and position" in some useful way. You'll need to look up Sodipodi programming tasks and list archives on this one. I hope to return to this idea when I have time. --bb

---------
Agreed. The dialog situation is a frequently mentioned concern from new
and potential users, and getting it wrangled and simplified would do a
world of good.

A commentor on GnomeDesktop writes: "But, you've got to clean up the
menus/interface - when the drawing starts it's really a mess and first
impressions to users mean a lot. It really should open up a frame with
menus across the top and toolbars whereever. While it was easy enough to
create a new drawing - I couldn't figure out how to resize the
page/drawing. These are the first things a user does so it should be
there and be good. Compared to Karbon, the toolbar/menu thing is a
mess. This should be relatively easy to fix and will go a long way to
winning over users."
---------

:Sure, if anyone has any specific suggestions, be vocal. If they are simple I may have a look at once. To start, I will unify the names of the dialogs and corresponding menu commands which are now confusingly different. --bb

2. Accessibility concerns
Using many dialogs, users that cannot or do not use the mouse are
asked to traverse 3 tiers of information to edit shape data outside the
canvas. First they must achieve focus on a dialog ( ctrl+# ) , second
they must select ( in some cases ) a tab containing the subset of data
they wish to manipulate ( tab key? ) and third they must gain focus on
the cell or control that allows them to make the edit ( tab key? ).

:Tab switching I think should be ctrl-pageup/pagedown, any other suggestions? --bb

3. Solution
Provide an additional ( or alternative depending on how you lean )
palette for editing shape properties that contains an hierarchical list
of property groups and properties. This window would behave exactly as
other palettes ( esc to focus canvas, enter to affect change ), but
would centralize object properties in one dialog minimizing the memory
cost to the user for keyboard shortcuts to open dialogs ( they would
only need one, and we could make it an easy one, cmd+i // get info // )
Once the dialog has focus, the user could then use the arrow keys to
locate the property they wish to edit and affect the change desired.
While it may seem that we will lose the specificity of multiple
dialogs, this interface would provide us with a more open method of
combining property sets, and in the future it could be used as the
basis for generating custom property dialogs per user utilizing xml
documents to store dialog layout information.

:Also needed is a proposed rule for how to discriminate what should and should not be in this dialog box. Perhaps go through the current dialog boxes and identify which should be incorporated here, and which should not. - bryce

http://www.inkscape.org/mockups/layers_palette_with_props.png

:This looks pretty similar to the current XML editor. Perhaps we could use it as a base for such a palette, or better, develop the XML editor itself to be more "visual" so that you could e.g. edit a color in a CSS specification by clicking on it and choosing from swatches. Still, the ability to edit XML freely should be preserved in any case. --bb

:Overall, I doubt if such a palette will really be convenient to use in a large document. You could have hundreds of objects, and even if grouped in layers, they will still make the collapsing tree very unwieldy. I think you'll spend too much time scrolling the tree and collapsing/expanding its branches. However it's indeed convenient to see all properties of an object nicely lined up, so on a second thought I do think that developing the current XML editor to be more visual and less XML-ish is the best strategy. Such as, for example, making CSS specs display as interactive widgets instead of long text strings. --bb

4. A few key points
It appears that currently, you cannot enter a numerical value in the
float fields of the color dialog, is this intended behavior?

---------
Wrong question. Is this the _expected_ behavior? If users need to have
the capability of entering numerical values, then this should be
submitted as a feature request, so it can be implemented as resources
allow.
---------

:Fixed now. --bb

Users would be able to close tree paths in this new properties
palette that they might not use often, this allows the user to
immediately improve their productivity when performing these types of
edits.

Buliabyak: *

2003-11-27T02:08:54Z

← Older revision		Revision as of 02:08, 27 November 2003
Line 79:		Line 79:
	---------		---------

	:~~Yep, I thought about that too. Perhaps it's a simple thing like editable bit set on the control. I'll look into it~~. --bb		:Fixed now. --bb

	Users would be able to close tree paths in this new properties		Users would be able to close tree paths in this new properties

Buliabyak: *

2003-11-18T06:17:45Z

← Older revision		Revision as of 06:17, 18 November 2003
Line 60:		Line 60:
	documents to store dialog layout information.		documents to store dialog layout information.

	:Also needed is a proposed rule for how to discriminate what should and		:Also needed is a proposed rule for how to discriminate what should and should not be in this dialog box. Perhaps go through the current dialog boxes and identify which should be incorporated here, and which should not. - bryce
	should not be in this dialog box. Perhaps go through the current dialog
	boxes and identify which should be incorporated here, and which should
	not. - bryce

	http://www.inkscape.org/mockups/layers_palette_with_props.png		http://www.inkscape.org/mockups/layers_palette_with_props.png

Buliabyak: *

2003-11-18T06:17:18Z

← Older revision		Revision as of 06:17, 18 November 2003
Line 60:		Line 60:
	documents to store dialog layout information.		documents to store dialog layout information.

	~~---------~~		:Also needed is a proposed rule for how to discriminate what should and
	~~In general this sounds like a good approach, although I'd really like to~~
	~~see an example. Please add an example when you post this to Wiki.~~
	~~Describe how this would work for the particular shapes already~~
	~~implemented, as well as ones that may be added in the future. Itemize a~~
	~~list of exactly what properties would be included. Perhaps create some~~
	~~mockups of this conglomerated dialog.~~

	Also needed is a proposed rule for how to discriminate what should and
	should not be in this dialog box. Perhaps go through the current dialog		should not be in this dialog box. Perhaps go through the current dialog
	boxes and identify which should be incorporated here, and which should		boxes and identify which should be incorporated here, and which should
	not.		not. - bryce
	~~---------~~
			http://www.inkscape.org/mockups/layers_palette_with_props.png

	:~~Yes~~, the ~~idea is good, but can~~ you ~~provide~~ a ~~mock-up of what you have~~ in ~~mind? It would make discussion more specific~~. --bb		:This looks pretty similar to the current XML editor. Perhaps we could use it as a base for such a palette, or better, develop the XML editor itself to be more "visual" so that you could e.g. edit a color in a CSS specification by clicking on it and choosing from swatches. Still, the ability to edit XML freely should be preserved in any case. --bb

			:Overall, I doubt if such a palette will really be convenient to use in a large document. You could have hundreds of objects, and even if grouped in layers, they will still make the collapsing tree very unwieldy. I think you'll spend too much time scrolling the tree and collapsing/expanding its branches. However it's indeed convenient to see all properties of an object nicely lined up, so on a second thought I do think that developing the current XML editor to be more visual and less XML-ish is the best strategy. Such as, for example, making CSS specs display as interactive widgets instead of long text strings. --bb

	4. A few key points		4. A few key points

Buliabyak: my comments

2003-11-15T08:00:41Z

my comments

New page

This memo will serve to be the genus for what I would eventually like
to propose. I'm hoping for plenty of feedback from everyone to make
this tool as useful as possible. The core concept is quite simple
really, enumerate and visually explain all editable parameters of a
given shape on the canvas in a single floating palette.

1. Problem
Although much work is being done to promote existing dialogs to the
status of sane players on the workspace front, there are still pitfalls
in having all manner of oversized and disproportionate dialogs open on
the screen. Namely is simple visual clutter. Having several windows
open at once can cause both new users to become lost quickly, and more
seasoned users wasting time fidgeting with dialogs to position them
according to their wishes.

:I agree that the number of dialogs should be reduced. One idea we were discussing long ago was merging "transformations" and "size and position" in some useful way. You'll need to look up Sodipodi programming tasks and list archives on this one. I hope to return to this idea when I have time. --bb

---------
Agreed. The dialog situation is a frequently mentioned concern from new
and potential users, and getting it wrangled and simplified would do a
world of good.

A commentor on GnomeDesktop writes: "But, you've got to clean up the
menus/interface - when the drawing starts it's really a mess and first
impressions to users mean a lot. It really should open up a frame with
menus across the top and toolbars whereever. While it was easy enough to
create a new drawing - I couldn't figure out how to resize the
page/drawing. These are the first things a user does so it should be
there and be good. Compared to Karbon, the toolbar/menu thing is a
mess. This should be relatively easy to fix and will go a long way to
winning over users."
---------

:Sure, if anyone has any specific suggestions, be vocal. If they are simple I may have a look at once. To start, I will unify the names of the dialogs and corresponding menu commands which are now confusingly different. --bb

2. Accessibility concerns
Using many dialogs, users that cannot or do not use the mouse are
asked to traverse 3 tiers of information to edit shape data outside the
canvas. First they must achieve focus on a dialog ( ctrl+# ) , second
they must select ( in some cases ) a tab containing the subset of data
they wish to manipulate ( tab key? ) and third they must gain focus on
the cell or control that allows them to make the edit ( tab key? ).

:Tab switching I think should be ctrl-pageup/pagedown, any other suggestions? --bb

3. Solution
Provide an additional ( or alternative depending on how you lean )
palette for editing shape properties that contains an hierarchical list
of property groups and properties. This window would behave exactly as
other palettes ( esc to focus canvas, enter to affect change ), but
would centralize object properties in one dialog minimizing the memory
cost to the user for keyboard shortcuts to open dialogs ( they would
only need one, and we could make it an easy one, cmd+i // get info // )
Once the dialog has focus, the user could then use the arrow keys to
locate the property they wish to edit and affect the change desired.
While it may seem that we will lose the specificity of multiple
dialogs, this interface would provide us with a more open method of
combining property sets, and in the future it could be used as the
basis for generating custom property dialogs per user utilizing xml
documents to store dialog layout information.

---------
In general this sounds like a good approach, although I'd really like to
see an example. Please add an example when you post this to Wiki.
Describe how this would work for the particular shapes already
implemented, as well as ones that may be added in the future. Itemize a
list of exactly what properties would be included. Perhaps create some
mockups of this conglomerated dialog.

Also needed is a proposed rule for how to discriminate what should and
should not be in this dialog box. Perhaps go through the current dialog
boxes and identify which should be incorporated here, and which should
not.
---------

:Yes, the idea is good, but can you provide a mock-up of what you have in mind? It would make discussion more specific. --bb

4. A few key points
It appears that currently, you cannot enter a numerical value in the
float fields of the color dialog, is this intended behavior?

---------
Wrong question. Is this the _expected_ behavior? If users need to have
the capability of entering numerical values, then this should be
submitted as a feature request, so it can be implemented as resources
allow.
---------

:Yep, I thought about that too. Perhaps it's a simple thing like editable bit set on the control. I'll look into it. --bb

Users would be able to close tree paths in this new properties
palette that they might not use often, this allows the user to
immediately improve their productivity when performing these types of
edits.