Re: [Clipart] new inkscape dialogs
[moved from Clipart back to Inkscape]
On Thu, 24 Jun 2004, Jon Phillips wrote:
Date: Thu, 24 Jun 2004 03:47:18 -0700 From: Jon Phillips <jon@...235...> To: Andrew Fitzsimon <andrew@...420...> Cc: clipart-list <clipart@...330...> Subject: Re: [Clipart] new inkscape dialogs
These are rocking man!!! I can't wait until they are fully implemented. It would be great if they could be ready by AUGUST so that I can present them at a couple of conferences and in time for OSCON2004!
It will be great to show the linkages between metadata in OCAL and in Inkscape directly!!! You are cool!!!
Jon
On Sun, 2004-06-20 at 23:14, Andrew Fitzsimon wrote:
Hi guys, just a few mockups comming from inkscape.
bryce mentioned you'd like to see them
http://andy.fitzsimon.com.au/obman/obman2.png http://andy.fitzsimon.com.au/obman/docset.png http://andy.fitzsimon.com.au/obman/docset2.png
I realise these dialogs fit in with Inkscapes current design, the are clear compact and well arranged but I think it is important to consider integration with Gnome.
The way I see it Sodipodi tried to make all dialogs as small and as compact as possible, and for non-modal dialogs that are expected to be left permantly open this makes sense. (Other graphics applications refer to these types of Dialogs as Palettes, and I try to do so too). I can understand that the Object Manager is probably something you would want to leave open.
These should be considered distinct and seperate from Transient dialogs (modal or non-modal, it doesn't matter) that are not intended to be left open. Transient dialogs are not under the same space constraints. As far as I know the Inkscape developers do want to follow the Gnome Human Interface Guidelines (mostly), so I hope I'm not out of line asking for a more standard layout.
The Document settings (document properties?) seems more like the latter type of transient Dialog. The reason I bring this up at all is that I immediatly wondered where the Cancel, OK buttons were. By positioning the "clear" button on the bottom right where the action/OK button usually is I expect some users will absent mindedly clear the data they just typed in when in fact they wanted to dismiss the dialog not clear the information. I believe that the Reset button and Icon the GIMP uses is a stock item, using it instead might help. The abbreviation "Info" should not be used, abbreviations make English harder to understand for non-native speakers and even native speakers will need to take an extra fraction of a second to mentally unscramble it. Anyway from an Internationalisation point of view there needs to be enough space in the user interface to accomodate other languages that are more verbose, so there is no advantage to be gained by the abbreviation. (You might also consider putting the Custom name,value pairs into a seperate tab as it would provide much more room as there could potentially be many other bits of metadata. Offhand I can think of Date, Copyright (which includes licensing), keywords, being needed for OpenClipart.org content). The item "Insert OpenClipart.org RDF" is very specific and could be confusing to new users who have discovered Inkscape through their Linux distribution, perhaps this could be changed to insert metadata from file/template and one of those templates would be the OpenClipart.org metadata?
I am not suggesting you redo these dialogs now but I hope you will take on these suggestions and incorporate them whenever you next need to revise the dialog.
Hope that helps.
Sincerely
Alan Horkan
Alan: just one line to tell you I love the way you reason your decissions. yours: Néstor Díaz
El Jueves, 24 de Junio de 2004 20:12, Alan Horkan escribió:
[moved from Clipart back to Inkscape]
On Thu, 24 Jun 2004, Jon Phillips wrote:
Date: Thu, 24 Jun 2004 03:47:18 -0700 From: Jon Phillips <jon@...235...> To: Andrew Fitzsimon <andrew@...420...> Cc: clipart-list <clipart@...330...> Subject: Re: [Clipart] new inkscape dialogs
These are rocking man!!! I can't wait until they are fully implemented. It would be great if they could be ready by AUGUST so that I can present them at a couple of conferences and in time for OSCON2004!
It will be great to show the linkages between metadata in OCAL and in Inkscape directly!!! You are cool!!!
Jon
On Sun, 2004-06-20 at 23:14, Andrew Fitzsimon wrote:
Hi guys, just a few mockups comming from inkscape.
bryce mentioned you'd like to see them
http://andy.fitzsimon.com.au/obman/obman2.png http://andy.fitzsimon.com.au/obman/docset.png http://andy.fitzsimon.com.au/obman/docset2.png
I realise these dialogs fit in with Inkscapes current design, the are clear compact and well arranged but I think it is important to consider integration with Gnome.
The way I see it Sodipodi tried to make all dialogs as small and as compact as possible, and for non-modal dialogs that are expected to be left permantly open this makes sense. (Other graphics applications refer to these types of Dialogs as Palettes, and I try to do so too). I can understand that the Object Manager is probably something you would want to leave open.
These should be considered distinct and seperate from Transient dialogs (modal or non-modal, it doesn't matter) that are not intended to be left open. Transient dialogs are not under the same space constraints. As far as I know the Inkscape developers do want to follow the Gnome Human Interface Guidelines (mostly), so I hope I'm not out of line asking for a more standard layout.
The Document settings (document properties?) seems more like the latter type of transient Dialog. The reason I bring this up at all is that I immediatly wondered where the Cancel, OK buttons were. By positioning the "clear" button on the bottom right where the action/OK button usually is I expect some users will absent mindedly clear the data they just typed in when in fact they wanted to dismiss the dialog not clear the information. I believe that the Reset button and Icon the GIMP uses is a stock item, using it instead might help. The abbreviation "Info" should not be used, abbreviations make English harder to understand for non-native speakers and even native speakers will need to take an extra fraction of a second to mentally unscramble it. Anyway from an Internationalisation point of view there needs to be enough space in the user interface to accomodate other languages that are more verbose, so there is no advantage to be gained by the abbreviation. (You might also consider putting the Custom name,value pairs into a seperate tab as it would provide much more room as there could potentially be many other bits of metadata. Offhand I can think of Date, Copyright (which includes licensing), keywords, being needed for OpenClipart.org content). The item "Insert OpenClipart.org RDF" is very specific and could be confusing to new users who have discovered Inkscape through their Linux distribution, perhaps this could be changed to insert metadata from file/template and one of those templates would be the OpenClipart.org metadata?
I am not suggesting you redo these dialogs now but I hope you will take on these suggestions and incorporate them whenever you next need to revise the dialog.
Hope that helps.
Sincerely
Alan Horkan
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, Jun 24, 2004 at 07:12:24PM +0100, Alan Horkan wrote:
On Sun, 2004-06-20 at 23:14, Andrew Fitzsimon wrote:
http://andy.fitzsimon.com.au/obman/docset.png http://andy.fitzsimon.com.au/obman/docset2.png
The abbreviation "Info" should not be used, abbreviations make English harder to understand for non-native speakers and even native speakers will need to take an extra fraction of a second to mentally unscramble it. Anyway from an Internationalisation point of view there needs to be enough space in the user interface to accomodate other languages that are more verbose, so there is no advantage to be gained by the abbreviation. (You might also consider putting the Custom name,value pairs into a seperate tab as it would provide much more room as there could potentially be many other bits of metadata. Offhand I can think of Date, Copyright (which includes licensing), keywords, being needed for OpenClipart.org content). The item "Insert OpenClipart.org RDF" is very specific and could be confusing to new users who have discovered Inkscape through their Linux distribution, perhaps this could be changed to insert metadata from file/template and one of those templates would be the OpenClipart.org metadata?
I have actually started this tab already (well, the ideas, anyway). The code is not far along at all, since I didn't have any good text-entry examples. :) But I did commit the changes needed to correctly track the RDF namespace in the XML.
I named the tab "Description". The items I was going to include were:
Title (dc:title) (freeform) Date (dc:date) (date) Author (dc:creator) (freeform) Owner (dc:rights) (freeform) Source (dc:source) (url) Keywords (dc:subject) (freeform) Description (dc:description) (freeform) License (license tag and License section) (pulldown)
(dc:type will be set to always contain rdf:resource="http://purl.org/dc/dcmitype/StillImage")
For the "License" section, I am initially going to just have a pull-down of: Custom Creative Commons Attribution Creative Commons Attribution-ShareAlike Creative Commons Attribution-NoDerivs Creative Commons Attribution-NonCommercial Creative Commons Attribution-NonCommercial-ShareAlike Creative Commons Attribution-NonCommercial-NoDerivs Public Domain
If "Custom" is selected, they can fill in another box that holds a URL.
On Thu, 24 Jun 2004, Kees Cook wrote:
I have actually started this tab already (well, the ideas, anyway). The code is not far along at all, since I didn't have any good text-entry examples. :) But I did commit the changes needed to correctly track the RDF namespace in the XML.
I named the tab "Description". The items I was going to include were:
Title (dc:title) (freeform) Date (dc:date) (date) Author (dc:creator) (freeform)
Btw, I've been shifting SVG::Metadata over to use 'creator' instead of 'author', to be consistent with the RDF. I'll keep author as an alias to creator, though.
Owner (dc:rights) (freeform) Source (dc:source) (url) Keywords (dc:subject) (freeform)
I've been thinking about whether we should use subject for the keywords, or do something different... Ideally I'd rather have each keyword be a separate XML element, instead of a freeform string, so we can maintain some consistency over how it is parsed. What do you think? I haven't checked the schema to see if something like this is provided, but probably should... We could of course add it ourselves via a custom namespace, but I'd kind of like to avoid that if at all possible.
Description (dc:description) (freeform) License (license tag and License section) (pulldown)
(dc:type will be set to always contain rdf:resource="http://purl.org/dc/dcmitype/StillImage")
For the "License" section, I am initially going to just have a pull-down of: Custom Creative Commons Attribution Creative Commons Attribution-ShareAlike Creative Commons Attribution-NoDerivs Creative Commons Attribution-NonCommercial Creative Commons Attribution-NonCommercial-ShareAlike Creative Commons Attribution-NonCommercial-NoDerivs Public Domain
If "Custom" is selected, they can fill in another box that holds a URL.
For brevity, perhaps 'Attribution' can be dropped?
It would probably be wise to load the pull-down contents from the preferences.xml file, so users can override the settings when they need to.
Anyway, looks good so far!
Bryce
On Thu, Jun 24, 2004 at 04:11:02PM -0700, Bryce Harrington wrote:
Author (dc:creator) (freeform)
Btw, I've been shifting SVG::Metadata over to use 'creator' instead of 'author', to be consistent with the RDF. I'll keep author as an alias to creator, though.
Do you mean the tag or name on the dialog? I was using the "dc:creator" tag in the XML, but the name "Author" in the dialog, since I thought it was more sensible.
Keywords (dc:subject) (freeform)
I've been thinking about whether we should use subject for the keywords, or do something different... Ideally I'd rather have each keyword be a separate XML element, instead of a freeform string, so we can maintain some consistency over how it is parsed. What do you think? I haven't checked the schema to see if something like this is provided, but probably should... We could of course add it ourselves via a custom namespace, but I'd kind of like to avoid that if at all possible.
Well, it seems like the only place it could go without creating a new namespace. According to the spec, they suggest using a limited vocabulary.
Creative Commons Attribution-NonCommercial-NoDerivs
For brevity, perhaps 'Attribution' can be dropped?
Well, that's an _element_ of the license, so I'd rather not. Maybe "CC", but if someone isn't familiar with it. I think the "best" route would be just a simple "Creative Commons" license, and then when that's selected a radio-button section becomes selectable, and that has the various combinations there.
It would probably be wise to load the pull-down contents from the preferences.xml file, so users can override the settings when they need to.
Well, I'm not sure about this since the the selected license impacts the <License> tag, and that needs to be programmatic or do some kind of XML merge if people are adding their own stuff. I was just going to blow away the entire License tree and put in our own if someone changed the setting away from "Custom".
On Thu, 24 Jun 2004, Kees Cook wrote:
On Thu, Jun 24, 2004 at 04:11:02PM -0700, Bryce Harrington wrote:
Author (dc:creator) (freeform)
Btw, I've been shifting SVG::Metadata over to use 'creator' instead of 'author', to be consistent with the RDF. I'll keep author as an alias to creator, though.
Do you mean the tag or name on the dialog? I was using the "dc:creator" tag in the XML, but the name "Author" in the dialog, since I thought it was more sensible.
I mean the function call in SVG::Metadata, as well as the tag. I also originally thought that "Author" would be clearer, but since the RDF has fields for creator, owner, and publisher, I thought it may be safer to match terms exactly.
You may be right that using Author in the Inkscape dialog would be more sensible, I just wanted to mention that I'd changed, just in case you had picked Author because I'd been using it for the clipart.
Keywords (dc:subject) (freeform)
I've been thinking about whether we should use subject for the keywords, or do something different... Ideally I'd rather have each keyword be a separate XML element, instead of a freeform string, so we can maintain some consistency over how it is parsed. What do you think? I haven't checked the schema to see if something like this is provided, but probably should... We could of course add it ourselves via a custom namespace, but I'd kind of like to avoid that if at all possible.
Well, it seems like the only place it could go without creating a new namespace. According to the spec, they suggest using a limited vocabulary.
Hmm... Well, certainly I could handle keywords by splitting the subject on common delimiters like space, comma, etc. Feels kludgy though... But probably better than adding a new namespace. I suppose we could do that initially, and see how well it works, and if we need more, add something more sophisticated later.
Well, that's an _element_ of the license, so I'd rather not. Maybe "CC", but if someone isn't familiar with it. I think the "best" route would be just a simple "Creative Commons" license, and then when that's selected a radio-button section becomes selectable, and that has the various combinations there.
Mmm, that's a good idea.
It would probably be wise to load the pull-down contents from the preferences.xml file, so users can override the settings when they need to.
Well, I'm not sure about this since the the selected license impacts the <License> tag, and that needs to be programmatic or do some kind of XML merge if people are adding their own stuff. I was just going to blow away the entire License tree and put in our own if someone changed the setting away from "Custom".
Ah, gotcha.
Bryce
On Thu, Jun 24, 2004 at 05:17:28PM -0700, Bryce Harrington wrote:
I mean the function call in SVG::Metadata, as well as the tag. I also originally thought that "Author" would be clearer, but since the RDF has fields for creator, owner, and publisher, I thought it may be safer to match terms exactly.
Hm... with the addition of "publisher", it does start to seem strange to keep "author". "Creator" is probably more clear.
Hmm... Well, certainly I could handle keywords by splitting the subject on common delimiters like space, comma, etc. Feels kludgy though... But probably better than adding a new namespace. I suppose we could do that initially, and see how well it works, and if we need more, add something more sophisticated later.
Actually, the spec says it should be keywords:
Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
(from http://dublincore.org/2003/03/24/dces)
actually, we could add "contributor" too... I think we could have multiple. :)
On Thu, 24 Jun 2004, Kees Cook wrote:
Actually, the spec says it should be keywords:
Typically, a Subject will be expressed as keywords,key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
Hmm... Guess we'll need to come up with a ''controlled vocabulary'' mechanism of some sort for our keywords...
So... we're going to need a syntax to parse against... so some questions:
* Can category keywords have spaces within them? * commas? * semicolons? * colons? * single or double quotation marks?
Bryce
On Fri, 2004-06-25 at 15:33, Bryce Harrington wrote:
Hmm... Guess we'll need to come up with a ''controlled vocabulary'' mechanism of some sort for our keywords...
So... we're going to need a syntax to parse against... so some questions:
- Can category keywords have spaces within them?
- commas?
- semicolons?
- colons?
- single or double quotation marks?
I like semicolons as the separator. Then you have space, and don't need to quote things. I don't think that anyone would want a semicolon in an actual keyword.
--Ted
On Sat, 26 Jun 2004, Ted Gould wrote:
On Fri, 2004-06-25 at 15:33, Bryce Harrington wrote:
Hmm... Guess we'll need to come up with a ''controlled vocabulary'' mechanism of some sort for our keywords...
So... we're going to need a syntax to parse against... so some questions:
- Can category keywords have spaces within them?
- commas?
- semicolons?
- colons?
- single or double quotation marks?
I like semicolons as the separator. Then you have space, and don't need to quote things. I don't think that anyone would want a semicolon in an actual keyword.
Okay, good points. Semicolon it is.
Bryce
Hi, I've noticed the last few days that if I do save as on a new document the dialog box selects eps in the file format list, even though the filter in the filename box is set to svg. This is on windows btw. Since we moved to using the extension system for file dialogs etc I have no idea where to find how this is being set.
cheers
John
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
On Thu, 2004-06-24 at 20:17, Bryce Harrington wrote:
Well, that's an _element_ of the license, so I'd rather not. Maybe "CC", but if someone isn't familiar with it. I think the "best" route would be just a simple "Creative Commons" license, and then when that's selected a radio-button section becomes selectable, and that has the various combinations there.
IIRC, for newly dedicated works, I think particularly for Public Domain, there are specific legal requirements for a formal declaration etc -- it's not always sufficient to just mark it up in the RDF.
I haven't been able to find any suggestions/guidelines for how to deal with this in _authoring_ tools on the CC site, but I admittedly haven't had time to look intensively.
It would be handy if we could provide a text box or something somewhere where one could just paste the RDF fragment they give you after filling out the appropriate dedication etc on the Creative Commons site, and we'd strip off the comments and stick it into the document as-is.
Also, maybe we should touch base with the CC in any case and see what suggestions they have?
-mental
On Fri, Jun 25, 2004 at 01:28:41AM -0400, MenTaLguY wrote:
IIRC, for newly dedicated works, I think particularly for Public Domain, there are specific legal requirements for a formal declaration etc -- it's not always sufficient to just mark it up in the RDF.
Correct. Unfortunately, it's beyond the scope of the tool to do that dedication. However, we could maybe add a warning label or something.
I haven't been able to find any suggestions/guidelines for how to deal with this in _authoring_ tools on the CC site, but I admittedly haven't had time to look intensively.
As you suggest later on, I'll send some email and see what they have to say.
It would be handy if we could provide a text box or something somewhere where one could just paste the RDF fragment they give you after filling out the appropriate dedication etc on the Creative Commons site, and we'd strip off the comments and stick it into the document as-is.
Yup, that's what I'd like to do for the "Custom" license section. I figure I can't just put it in "as is", but rather it would be parsed by the inkscape XML parser, and added to the internal repr. Is that what you had in mind?
BTW: I have done a commit for the data entry widget changes. They're hooked to nothing but debug callbacks right now, but at least people can see the layout. I ended up naming the tab "Metadata".
On Fri, 2004-06-25 at 10:42, Kees Cook wrote:
It would be handy if we could provide a text box or something somewhere where one could just paste the RDF fragment they give you after filling out the appropriate dedication etc on the Creative Commons site, and we'd strip off the comments and stick it into the document as-is.
Yup, that's what I'd like to do for the "Custom" license section. I figure I can't just put it in "as is", but rather it would be parsed by the inkscape XML parser, and added to the internal repr. Is that what you had in mind?
Yes.
BTW: I have done a commit for the data entry widget changes. They're hooked to nothing but debug callbacks right now, but at least people can see the layout. I ended up naming the tab "Metadata".
Sounds good; I'll check it out when I have a chance. ^_^
-mental
participants (7)
-
Alan Horkan -
Bryce Harrington -
John Cliff -
Kees Cook -
MenTaLguY -
Néstor Díaz Valencia -
Ted Gould